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

[Ben Campbell <[e-mail]>]

Hi Roni,

This version looks good. I approved it for publication. It’s now in the hands of the RFC Editor.

Thanks!

Ben.

> On Aug 7, 2017, at 2:58 AM, Roni Even <[e-mail]> wrote:
> 
> Hi Ben,
> Added such a sentence in the new revision -14
> Roni
> 
>> -----Original Message-----
>> From: Ben Campbell [mailto:[e-mail]]
>> Sent: יום ד 26 יולי 2017 23:25
>> To: Roni Even
>> Cc: [e-mail]; Magnus Westerlund; The IESG
>> Subject: Re: New Version Notification for draft-ietf-avtcore-rfc5285-bis-
>> 13.txt
>> 
>> 
>>> On Jul 26, 2017, at 12:03 AM, Roni Even <[e-mail]> wrote:
>>> 
>>> 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.
>> 
>> Hi Roni,
>> 
>> I think it would be helpful to add a sentence to that effect for each instance.
>> 
>> Thanks!
>> 
>> Ben.
>> 
>> 
>>> Roni
>>> 
>>>> -----Original Message-----
>>>> From: Ben Campbell [mailto:[e-mail]]
>>>> Sent: יום ג 25 יולי 2017 00:52
>>>> To: Roni Even
>>>> Cc: [e-mail]; 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:
>>>> 
>>>>  "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 <[e-mail]> wrote:
>>>>> 
>>>>> 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: [e-mail] [mailto:[e-mail]]
>>>>> Sent: יום א 23 יולי 2017 09:23
>>>>> To: Harikishan Desineni; HariKishan Desineni; Roni Even; avtcore-
>>>> [e-mail]; 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
>>>>> 
>>> 
>