Hm. I was confused. This document is about embedding OPUS (a standards-track document) inside of OGG (an informational); I was thinking of the precedent of embeedding video formats (informational at best) inside RTP (a standards-track), with the document specifying the embedding being standards-track.
So the precedent is not a precedent. My apologies. (I don't have a strong opinion on which way it should go, and am happy to let the desire of the authors be a guideline.) Den 17. jan. 2016 22:04, skrev Ron: > On Sun, Jan 17, 2016 at 08:15:33PM +0100, Harald Alvestrand wrote: >> 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. > > I don't think anyone would have any objection to seeing RFC 3533 progress > to standards track either, but our understanding was that this was not a > strict prerequisite for the CODEC WG publishing this document. And it's > not quite clear if CODEC would actually be the right group to do that > work for 3533. Maybe CELLAR would be a better fit of the currently > active groups? > > For RFC 4732, informative seems correct to me. Not everything in that > document is relevant to this situation, and there may be things relevant > to specific implementations or users of this spec which aren't wholly > covered there either (including novel attack methods that nobody has > thought of previously). It's a topic that implementors should be aware > of, but we can't really mandate "if you do this you will be safe", nor > "if you don't do this, you won't" in a generally applicable way. Much > will depend on the specifics of the actual user and use case. > > Cheers, > Ron > > > _______________________________________________ > 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
