Subject: [Gen-art] A *new* batch of IETF LC reviews - 2016-01-14

From: "A. Jean Mahoney" <[email-masked]>
Date: Thu, 14 Jan 2016 16:28:12 -0600

Hi all,

The following reviewers have assignments:

Reviewer          LC end      Draft
---------------------------------------------------------------------
Francis Dupont    2016-02-04  draft-mahesh-mef-urn-01

Joel Halpern      2016-01-27  draft-ietf-codec-oggopus-10

Jouni Korhonen    2016-01-28  draft-ietf-ecrit-held-routing-04

Matt Miller       2016-01-29  draft-ietf-rtgwg-mrt-frr-architecture-09

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The updated template is included below.

Thanks,

Jean

-------------------------------------------------------------------

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:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 15 Jan 2016 17:26:45 -0500

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.)

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

---

From: Ralph Giles <[email-masked]>
Date: Fri, 15 Jan 2016 15:41:31 -0800

> lacing value of less than 255.  At the very least, these need to be

Thanks for taking time to review the draft. You're right that the logic is inverted in the last section. I've corrected the i.e. clause in the last paragraph.
> (e.g. 48kHz granule and 2.5 ms timing) are sufficiently broad to cover

Hmm. RFC 6716 sec 2.1.3 and 2.1.4 give 48 kHz and 2.5 ms as the maximum sample rate and minumum packet duration, respectively. I suppose sec. 4 of the draft assumes these constraints.

It does indicate that 2.5 ms is the minimum packet duration, but we could add a reference, or a statement that 48 kHz is the effective maximum sample rate of the codec if it's cause for concern.

 -r

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 15 Jan 2016 18:47:50 -0500

Thanks Ralph.

On the minor note, I had not realized those were already relevant 
parameters.  Anyone using this can reasonably be expected to know that, 
so it is not a big deal.  Given that it would only take one sentence, it 
might be nice to add the statement anyway.

Yours,
Joel

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 15 Jan 2016 15:52:14 -0800

> might be nice to add the statement anyway.

We can certainly add text to point out that this is a limitation of RFC 
6716, e.g., "The duration of an Opus packet as defined in RFC 6716 can 
be any multiple..."

For 48 kHz, we might say, "It is possible to run an Opus decoder at 
other sampling rates, but all of them evenly divide 48 kHz. Therefore, 
the value in the granule position field always counts samples assuming a 
48 kHz decoding rate..."

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 15 Jan 2016 19:42:30 -0500

That would work very well.  Thanks Tim.
Yours,
Joel

---

From: Ben Campbell <[email-masked]>
Date: Fri, 15 Jan 2016 21:21:03 -0600

The last call announcement included the following  text:
> Please note that the document makes normative references to RFCs 3533 and 4732, which are informational.
> 
Thanks!

Ben.

Sent from my iPhone

> On Jan 15, 2016, at 4:26 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> At the very least, the last call needed to identify the downref to RFC 3533.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 15 Jan 2016 22:27:49 -0500

I somehow missed that line (I did go look at the announcement.)  Sorry.

In this case, it seems a bit more extreme than the usual downref.  given 
that it is standardizing the use of this format, it seems to be 
essentially standardizing the document defining the format.

Is the intent of the working group to follow up by moving ogg to 
standards track?

Yours,
Joel

On 1/15/16 10:21 PM, Ben Campbell wrote:
> On Jan 15, 2016, at 4:26 PM, Joel M. Halpern <[email-masked]
> <mailto:[email-masked]>> wrote:
>

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 17 Jan 2016 20:15:33 +0100

Den 15. jan. 2016 23:26, skrev Joel M. Halpern:
>     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,

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.

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Ron <[email-masked]>
Date: Mon, 18 Jan 2016 07:34:27 +1030

> 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

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 18 Jan 2016 12:35:08 +0100

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.)

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 28 Jan 2016 14:43:47 -0600

> 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.
>>>> an