Hi Robert, Thanks for the review. The main issue with including uuencoded testvectors in the document is that it would cause the RFC to be around 32000 pages long. That's why RFC6716 included the source code, but not the test vectors. Back then, we were told that the meeting material was the only place we could put the test vectors. I don't really like doing that, but it still beats the other options I'm aware of (unless I missed something). Cheers, Jean-Marc On 01/08/17 02:07 PM, Robert Sparks wrote: > Reviewer: Robert Sparks > Review result: Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-codec-opus-update-08 > Reviewer: Robert Sparks > Review Date: 2017-08-01 > IETF LC End Date: 2017-08-09 > IESG Telechat date: Not scheduled for a telechat > > Summary: Ready for publication as a Standards Track RFC > > This document is straightforward in the changes it is making to OPUS. > > My only note of sadness is that it continues to use a documentation mechanism > started by RFC6716 of effectively making a normative reference to the > _proceedings_ of previous IETF meetings. (Note that this document does this > twice: once for the patch file, which is a convenience - the information is in > the draft, and once for the updated test vectors. This is _not_ a convenience, > the information is not in the draft. If, for whatever reason, the proceedings > URL could not be retrieved, someone could not verify their implementation with > the updated test vectors). > > On the one hand, we've set the precedent, and we could agree to just let this > go (I'm recommending that to the IESG with this review). On the other hand, we > could make things _slightly_ better (or perhaps just different) by putting the > test vectors in the doc as an appendix as a uuencoded compressed tarball. >