Subject: [AVTCORE] FW: New Version Notification for draft-ietf-avtcore-rfc5285-bis-13.txt

From: Roni Even <[email-masked]>
Date: Sun, 23 Jul 2017 06:26:52 +0000

Hi,
I submitted a version that I hope addresses all the comments from the IESG review.
The major open issue was the category of allowed-mix in bundle and based on the WG preference it is now Identical.

Thanks
Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: יום א 23 יולי 2017 09:23
To: Harikishan Desineni; HariKishan Desineni; Roni Even; [email-masked]; David Singer; Roni Even
Subject: New Version Notification for draft-ietf-avtcore-rfc5285-bis-13.txt

A new version of I-D, draft-ietf-avtcore-rfc5285-bis-13.txt
has been successfully submitted by Roni Even and posted to the IETF repository.

Name:		draft-ietf-avtcore-rfc5285-bis
Revision:	13
Title:		A General Mechanism for RTP Header Extensions
Document date:	2017-07-22
Group:		avtcore
Pages:		24
URL:            https://www.ietf.org/internet-drafts/draft-ietf-avtcore-rfc5285-bis-13.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/
Htmlized:       https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis-13
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rfc5285-bis-13
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rfc5285-bis-13

Abstract:
   This document provides a general mechanism to use the header
   extension feature of RTP (the Real-Time Transport Protocol).  It
   provides the option to use a small number of small extensions in each
   RTP packet, where the universe of possible extensions is large and
   registration is de-centralized.  The actual extensions in use in a
   session are signaled in the setup information for that session.  This
   document obsoletes RFC5285.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Ben Campbell <[email-masked]>
Date: Mon, 24 Jul 2017 16:52:29 -0500

Hi Roni,

I agree this covers the IESG comments. However, I am confused about some of the new text in section 7 about an answerer marking an extension as “inactive”. I assume these are here in response to Alexey’s questions about why the SHOULDs are only SHOULDs.

In the first instance:

   "If an extension is marked as "sendonly" and the answerer desires to
   receive it, the extension MUST be marked as "recvonly" in the SDP
   answer.  An answerer that has no desire to receive the extension or
   does not understand the extension SHOULD remove it from the SDP
   answer.  An answerer MAY want to respond that he supports the
   extension and may use it in the future will mark the extension as
   “inactive””

What does “willing to use it in the future” mean that is different than just being willing to receive it, which is already covered by marking it as “recvonly”? Do we contemplate that the offerer may at some point in the future send an updated offer or answer that changes this to “recvonly”?

Similarly in the second instance:

  If an extension is marked as "recvonly" and the answerer desires to
   send it, the extension MUST be marked as "sendonly" in the SDP
   answer.  An answerer that has no desire to, or is unable to, send the
   extension SHOULD remove it from the SDP answer.  An answerer MAY want
   to respond that he support this extension and may send in the future
   or will be able to receive by marking the extension as "inactive"

… is the answer expected to mark the extension as “sendonly” at some point in the future?

If it turns out that the added text is roughly correct, the text is still confusing from a pure sentence structure perspective. I would suggest text, but we probably need to resolve the above questions first.

Thanks!

Ben.

> On Jul 23, 2017, at 1:26 AM, Roni Even <[email-masked]> wrote:
> 
> Hi,

---

From: Roni Even <[email-masked]>
Date: Wed, 26 Jul 2017 05:03:48 +0000

HI Ben,
Inactive means I support the extension but would not like to send or receive at the moment. May do it in a future offer/answer. This is when the answerer understands the offered extension.
Roni

> From: Ben Campbell [mailto:[email-masked]]
> Sent: יום ג 25 יולי 2017 00:52
> To: Roni Even
> Cc: [email-masked]; Magnus Westerlund; The IESG
> Subject: Re: New Version Notification for draft-ietf-avtcore-rfc5285-bis-
> 13.txt
> 
> Hi Roni,
> 
> I agree this covers the IESG comments. However, I am confused about some
> of the new text in section 7 about an answerer marking an extension as
> “inactive”. I assume these are here in response to Alexey’s questions about
> why the SHOULDs are only SHOULDs.
> 
> In the first instance:
> 
> What does “willing to use it in the future” mean that is different than just
> being willing to receive it, which is already covered by marking it as
> “recvonly”? Do we contemplate that the offerer may at some point in the
> future send an updated offer or answer that changes this to “recvonly”?
> 
> If it turns out that the added text is roughly correct, the text is still confusing
> from a pure sentence structure perspective. I would suggest text, but we
> probably need to resolve the above questions first.
> 
> Thanks!
> 
> Ben.
> 
> 
> > The major open issue was the category of allowed-mix in bundle and based
> on the WG preference it is now Identical.
> >
> > Thanks
> > Roni Even
> >
> > Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >

---

From: Ben Campbell <[email-masked]>
Date: Wed, 26 Jul 2017 15:24:44 -0500

> On Jul 26, 2017, at 12:03 AM, Roni Even <[email-masked]> wrote:
> 
> HI Ben,

Hi Roni,

I think it would be helpful to add a sentence to that effect for each instance.

Thanks!

Ben.