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

[Ron <[e-mail]>]

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