Subject: [AVTCORE] Adam Roach's Yes on draft-ietf-avtcore-rfc5285-bis-12: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Tue, 20 Jun 2017 16:16:19 -0700

Adam Roach has entered the following ballot position for
draft-ietf-avtcore-rfc5285-bis-12: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The use of the term "local" in this document is implicit and therefore
confusing. Section 5 refers to "local identifier (ID)", while section 7 refers
to "Local identifiers". Neither indicates what the identifiers are local to,
and some implementors have chosen to interpret this as meaning "local to the
sender machine." See, for example,
https://bugzilla.mozilla.org/show_bug.cgi?id=1361206

I believe the intention here is for "local" to mean "local to this session."
This meaning should be made explicit. And, for avoidance of doubt, the document
should clarify that the negotiated identifiers use the same numeric value in
both directions. This is implied by much of the text, but it never stated
outright. Because so many other session attributes (e.g., payload types) can be
negotiated to be different in each direction, many implementors are likely to
assume the same applies here. As the above bug demonstrates, this leads to real
interop issues in the field.

Nits:

   element (no alignment is needed), and parsing stops at the earlier of
   the end of the entire header extension, or in one-byte headers only
   case, on encountering an identifier with the reserved value of 15.

Put quotation marks around "one byte headers only".
____

   Each extension element MUST starts with a byte containing an ID and a
   length:

s/starts/start/
____

The attribute definition in section 6 says "Value:" instead of "Value: none." 
-- Fix or refer to the IANA section instead.

---

From: Roni Even <[email-masked]>
Date: Wed, 21 Jun 2017 06:04:13 +0000

Hi Adam,
Inline
Roni

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]]
> Sent: יום ד 21 יוני 2017 02:16
> To: The IESG
> Cc: [email-masked]; Magnus Westerlund; avtcore-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Adam Roach's Yes on draft-ietf-avtcore-rfc5285-bis-12: (with
> COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> confusing. Section 5 refers to "local identifier (ID)", while section 7 refers to
> "Local identifiers". Neither indicates what the identifiers are local to, and
> some implementors have chosen to interpret this as meaning "local to the
> This meaning should be made explicit. And, for avoidance of doubt, the
> document should clarify that the negotiated identifiers use the same
> numeric value in both directions. This is implied by much of the text, but it
> never stated outright. Because so many other session attributes (e.g.,
> payload types) can be negotiated to be different in each direction, many
> implementors are likely to assume the same applies here. As the above bug
> demonstrates, this leads to real interop issues in the field.

[Roni Even] I also think you are right and should be clarified as "local to RTP session" 
I will also verify this on the AVT list and with my co-authors

> Put quotation marks around "one byte headers only".
[Roni Even] OK
>    Each extension element MUST starts with a byte containing an ID and a
[Roni Even] OK
> -- Fix or refer to the IANA section instead.
[Roni Even] OK, will change n section 6 to "Value:none"

---

From: Roni Even <[email-masked]>
Date: Wed, 21 Jun 2017 06:08:49 +0000

Hi,
Adam made the following comment in the IESG review.
I think that his interpretation is correct and the intention is " local to this RTP session" having the same id in the offer and answer
What is your view?

Thanks
Roni

The use of the term "local" in this document is implicit and therefore confusing. Section 5 refers to "local identifier (ID)", while section 7 refers to "Local identifiers". Neither indicates what the identifiers are local to, and some implementors have chosen to interpret this as meaning "local to the sender machine." See, for example,
https://bugzilla.mozilla.org/show_bug.cgi?id=1361206

I believe the intention here is for "local" to mean "local to this session."
This meaning should be made explicit. And, for avoidance of doubt, the document should clarify that the negotiated identifiers use the same numeric value in both directions. This is implied by much of the text, but it never stated outright. Because so many other session attributes (e.g., payload types) can be negotiated to be different in each direction, many implementors are likely to assume the same applies here. As the above bug demonstrates, this leads to real interop issues in the field.

---

From: David Singer <[email-masked]>
Date: Wed, 21 Jun 2017 13:51:57 -0400

Yes, “local” means “locally to this session”

> On Jun 21, 2017, at 2:04 , Roni Even <[email-masked]> wrote:
> 
> Hi Adam,
> Inline
> Roni
> 

David Singer
Manager, Software Standards, Apple Inc.