Stephen Farrell has entered the following ballot position for draft-ietf-codec-oggopus-13: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - general, (but a nit): there are some odd unexplained numbers here, which is fine ... but odd. (E.g. 125,829,120) It might be nicer to explain to the reader why these values were chosen. I assume there are unstated reasons that an implementer need not know - if an implementer really should grok why one of these odd numbers is used, then that would be better explained. - An example or diagram in the intro or section 3 would maybe have helped. - section 5: Q7.8 is a new one to me. Maybe add a reference? - 5.1.1.5: Could figures 3-8 do with some body text to explain them? That's (having body text that refers to the figures), general good practice and I'm not sure if they're sufficiently clear for an implementer to get right. (But as I'm not coding this, I don't know, so just checking:-) - 5.2: You don't say that the user comment strings must also be UTF8, but you do for the vendor string. Why not? I think it'd be good to call that out. - 5.2.1: [vorbis-comment] is, correctly, a normative reference here but I wonder if a xiph.org URL is a good enough reference for that. Is there anything better, or are we confident enough in that URL? - 5.2.1: From what namespace are the -573 and 111 values here selected? How is that managed? (Just wondering.) - section 9: While I like the MUST NOT here, it's really only wishful thinking and isn't a strictly valid use of 2119 terms. I'm ok with that though. The SHOULD NOT statement is also kind of bogus. Generally this section would be better if it had guidance on where implementers are likely to go wrong in ways that cause security issues. Reference such as are provided in RFC 6562 about the dangers of VBR might also be useful here, not sure. _______________________________________________ codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/codec
