Re: [Gen-art] Review: draft-ietf-codec-oggopus-10

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@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art