On 18 Jan 2016, at 5:35, Harald Alvestrand wrote:
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.
There may be another. The Ogg media type registrations (RFC 5334, and
the obsoleted RFC 3534) are standards track, and normatively reference
RFC 3533.
(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
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
