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

[Jari Arkko]

Joel et al: thank you very much for the review and changes. I have balloted 
no-obj.

Jari

On 15 Feb 2016, at 19:25, Joel Halpern  wrote:

> Yes, draft 13 addresses all my comments (and also addresses issues I engaged 
> them on following the review) and is ready for publication as a Proposed 
> Standard.
> 
> My thanks to the authors for their work.
> 
> Yours,
> Joel
> 
> On 1/15/16 5:26 PM, Joel M. Halpern wrote:
>> 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
>> 
>> .
>> 
>> 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
>> 
>> ___
>> Gen-art mailing list
>> Gen-art@ietf.org
>> https://www.ietf.org/mailman/listinfo/gen-art
>> 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Joel Halpern]

Yes, draft 13 addresses all my comments (and also addresses issues I 
engaged them on following the review) and is ready for publication as a 
Proposed Standard.


My thanks to the authors for their work.

Yours,
Joel

On 1/15/16 5:26 PM, Joel M. Halpern wrote:

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

.

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

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Ben Campbell]

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

.

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



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Harald Alvestrand]

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

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

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

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

[Harald Alvestrand]

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

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[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

.

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

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Joel M. Halpern]

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

On 1/15/16 6:52 PM, Timothy B. Terriberry wrote:

Joel M. Halpern wrote:

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.


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



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Joel M. Halpern]

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:

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 > wrote:


At the very least, the last call needed to identify the downref to RFC
3533.


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Timothy B. Terriberry]

Joel M. Halpern wrote:

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.


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


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Ralph Giles]

On 15/01/16 02:26 PM, Joel M. Halpern wrote:
> 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.

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

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

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Ben Campbell]

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  wrote:
> 
> At the very least, the last call needed to identify the downref to RFC 3533.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Joel M. Halpern]

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

On 1/15/16 6:41 PM, Ralph Giles wrote:

On 15/01/16 02:26 PM, Joel M. Halpern wrote:

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.


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.

 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?


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



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art