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

[Roni Even <[e-mail]>]

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