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

[Ben Campbell <[e-mail]>]

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