Hi, This is my AD evaluation of draft-ietf-codec-opus-update-07. I have a few material comments, and some nits. I’d like to address the material comments prior to IETF last call. The nits can be handled now, or later along with any IETF last call comments.
Thanks! Ben. Material Comments: - Introduction: — I don’t think we can expect IETF LC and IESG reviewers to know the history of RFC 6716 going into this. Please expand the first paragraph in the introduction to explain how the normative part of RFC 6716 is in the form of attached C code in appendix A, and that the patches in this draft patch that code. — How can people be certain that the “formatted” patches match the patches in this draft, and do not change over time? Would it make sense to include a hash in this document, simularly to how 6716 has the hashes for the test vectors? (And are the IETF98 proceedings really where you want to store these?) - 11: The draft should include hashes for the new test vectors, similarly to in 6716. -12: The security considerations need some real content. For example, several of the fixes here seem to fix potential buffer overruns or other memory management errors. Does that reduce the attach surface for DoS or other attacks? I suspect the answer is “no”, since several of those sections mention that the bugs don’t appear to be exploitable. But the security considerations should at least summarize these sorts of changes and say why you believe they have no material impact on security. Nits: -3, last paragraph: Is no “significant” impact on test vectors the same as no impact? Also, I note that none of the other patch sections talk about test vector impact, and the section on new test vectors explains which patches impact the vectors. Could the comment in this section just be removed? -5, list items 2 and 3: These paragraphs (and others in the draft) mention symbols from the code without any explanation what they mean. Some of the symbol names are self-documenting, but that is not consistently true. It would be helpful to add short comments about the meaning of each of these (perhaps in parentheses). One might think of this as similar to expanding acronyms on first use. Also, the use of underscores for emphasis is, to my knowledge, not meaningful in the context of an RFC. Is the emphasis really needed? (I assume you don’t want to wait for the new RFC format for this sort of thing :-) ) — paragraph after the list: "However, proving that is non- obvious.” - Odd sentence structure. Would it make sense to say “However, the authors know of no obvious approach to proving that.”? -8: Please expand NaN on first mention. -9: Please expand LCG on first mention _______________________________________________ codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/codec
