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

[Roni Even <[e-mail]>]

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

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