On 8/1/17 3:08 PM, Jean-Marc Valin wrote:
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).
Sounds like a requirement for storage of supporting "documents" that are
normatively referenced by an RFC.
Thanks,
Paul
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.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
