Den 15. jan. 2016 23:26, skrev Joel M. Halpern: > 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 > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Document: draft-ietf-codec-oggopus-10 > Ogg Encapsulation for the Opus Audio Codec > Reviewer: Joel M. Halpern > Review Date: > IETF LC End Date: 27-January-2016 > IESG Telechat date: N/A > > Summary: > This document is nearly ready for publication as a Proposed Standard. > The reviewer believes the status issues needs to be addressed, and > would like the minor issue identified below discussed. > > Major issues: > I do not see how we can have a standards track document for using an > Informational format. RFC 3533 is Informational. At the very least, > the last call needed to identify the downref to RFC 3533. (It is not > clear whether the reference to RFC 4732 needs to be normative or could > be informative.) I agree with the need to have the downref be explicit, but this has been the norm since the IETF first decreed that RTP encapsulations should be standards track. I believe you were on the IESG at the time, too... it was that long ago. > > Minor issues: > While I do not completely understand ogg lacing values, there > appears to be an internal inconsistency in the text in section 3: > 1) "if the previous page with packet data does not end in a continued > packet (i.e., did not end with a lacing value of 255)" > 2) "a packet that continues onto a subsequent page (i.e., when the page > ends with a lacing value of 255)" > The first quote says that continued packets end with a lacing value > of 255, and the second quote says that continued packets end with a > lacing value of less than 255. At the very least, these need to be > clarified. > > Nits/editorial comments: > is there some way to indicate that the ogg encoding constraints > (e.g. 48kHz granule and 2.5 ms timing) are sufficiently broad to cover > all needed cases? > > Yours, > Joel Halpern > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art