Re: [MMUSIC] Offer/Answer sections in SDP extension documents [Re: Eric Rescorla's No Objection on draft-ietf-mmusic-sdp-bundle-negotiation-51: (with COMMENT)]

[Eric Rescorla <[e-mail]>]

This is ultimately for the ADs to decide (hence, not a DISCUSS by me) but I
am fine with this.

-Ekr


On Tue, May 22, 2018 at 1:23 PM, Ben Campbell <[e-mail]> wrote:

> Adam and I (with AD hats on)  talked about this offline. Here’s our
> conclusions:
>
> While I’m not overly happy about the conflation of the “initial SDP offer”
> section with “Initial activation of an extension” in general, I recognize
> we’ve been doing it that way. We might should discuss changing that for
> future drafts, but it’s not reasonable to force such a change on bundle
> this late in the process.
>
> However, we think that implementors are too used to thinking of “initial
> offer” to mean “initial SDP offer” for a re-definition to stick in their
> minds. Especially not a one-time redefinition in a terminology section that
> many people will skip over. Therefore, we ask for the following changes:
>
> 1) Change the definition in the term section from “initial offer” to
> “initial bundle offer”. Do a human-assisted search and replace to change
> instances of “initial offer” to “initial bundle offer” where the change
> makes sense.
>
> 2) Add a sentence early in §7.2 to the effect of the following:
>
> “The procedures in this section apply to the first SDP offer that contains
> a bundle group. This could occur in an initial SDP offer or a subsequent
> SDP offer.”
>
> (I don’t think we need to add anything similar to §7.3 or §7.5. These
> sections already have language that, when taken with the proposed change to
> §7.2, seem to reasonably describe the intent”.
>
> I don’t think these requires a restructure, nor should they take very long
> to accomplish.
>
> Thoughts?
>
> Thanks!
>
> Ben.
>
> > On May 22, 2018, at 9:14 AM, Flemming Andreasen <[e-mail]>
> wrote:
> >
> > In the past, we have had a lot of trouble getting people to write clear
> offer/answer procedures for the SDP extensions they defined. In an effort
> to put some structure around that, we started insisting on people following
> RFC 3264, which defines the following stages:
> >
> > 1. Generating the Initial Offer
> > 2. Generating the Answer
> > 3. Offerer Processing of the Answer
> > 4. Modifying the Session
> >
> > Clearly, any new SDP extensions MUST define how the extension is to be
> used with these well-defined RFC 3264 procedures.
> >
> > Now, the argument here seems to be as to whether the "Modifying the
> Session" needs to get into a further level of granularity, e.g.
> > 4a. Modifying the Session when the Extension was *not* used previously
> > 4a1. Sending a Subsequent Offer with the Extension
> > 4a2. Generating the Subsequent Answer to Subsequent Offer with the
> Extension
> > 4a3. Offerer Processing of Subsequent Answer after Subsequent Offer with
> the Extension
> >
> > If we need that, then we also need:
> > 4b. Modifying the Session when the extension *was* used previously.
> > 4b1. Sending a  Subsequent Offer without the Extension (assumed here to
> be different from 4 above, which would keep using the extension)
> > 4b2. Generating the Subsequent Answer to Subsequent Offer without the
> Extension
> > 4b3. Offerer Processing of Subsequent Answer after Subsequent Offer
> without the Extension.
> >
> > We have shied away from requiring this structure in the documents
> because it becomes rather cumbersome, and in practice, it doesn't seem to
> be needed. Instead, the traditional RFC 3264 sections have generally been
> written in way that accommodates both the formal meaning of *initial*
> offer/answer exchange, as well as initial from the point of view of
> covering the first time the extension is used. In some cases, explicit
> caveats have been included to point this out (as has been done in bundle),
> and in others it has not. We have a number of published RFCs and IESG
> approved documents in MISSREF state that all follow this approach, and I
> cannot recall this resulting in any concerns from either the WG, the IESG,
> or implementers.
> >
> > In summary, my position remains what it has been for a long time, which
> is to follow the RFC 3264 structure outlined above, with proper
> clarifications in each of the resulting sections to account for the
> variations outlined in 4a and 4b.
> >
> > It's not clear to me that the current bundle document doesn't already
> achieve that, but if people feel otherwise, I would ask for specific text
> suggestions that could address that while keeping in-line with
> long-standing document structure MMUSIC has required for SDP extensions.
> >
> > Thanks
> >
> > -- Flemming (as WG co-chair and Individual)
> >
> > On 5/21/18 10:51 PM, Ben Campbell wrote:
> >>
> >>> On May 21, 2018, at 11:23 AM, Christer Holmberg <
> [e-mail]>
> >>>  wrote:
> >>>
> >>> .....and, to use an example you may be more familiar with: RID.
> >>>
> >>> Are you saying that the “initial offer” procedures can only be used
> for the initial offer of the SIP session, meaning I can’t introduce RID
> later in the session (to an existing and/or new m- line)? If so, I think
> that should be explicitly stated in the draft.
> >>>
> >>>
> >> *** MMUSIC Chairs and other SDP experts: Please feel free to jump in
> with your opinion about how we should expect the “Offer/answer
> considerations” sections be written in SDP extension RFCs. ***
> >>
> >> I will let Adam confirm his intent, but I read the “initial SDP offer”
> section as talking about the initial _SDP_ offer”. It says the initial
> offer _MAY_ contain one or more “a=rid” lines. The "Modifying the Session”
> section then goes on to say that such an offer MAY change the number of RID
> lines in use. I argue that going from zero to one or more RID line counts
> as changing the number of RID lines in use.
> >>
> >> I do not dispute that there may be some SDP extension RFCs that are
> written as you suggest. I would have to go back and re-read a bunch of
> documents to reasonably comment on how many. But picking a random target:
> >>
> >> draft-ietf-mmusic-dtls-sdp-32 seems ambiguous on this point. The
> “Generating initial SDP offer” section is written from the assumption the
> initial offer includes DTLS-SRTP. But the “modifying a session” section
> talks about putting a new offer for DTLS-SRTP in a subsequent SDP offer.
> Taken as a whole, this seems more in the vein of “initial SDP offer” is
> really the initial SDP offer, and it just (reasonably) neglected to
> describe the case where the initial offer does not include DTLS-SRTP.
> >>
> >> In the case of BUNDLE, I don’t think we are talking about a complete
> restructure. Just recognize the difference between invoking bundle in the
> initial SDP offer vs subsequent SDP offers. That probably means adding a
> few sentences to the “Initial SDP offer” and “Modifying the Session”
> sections.
> >>
> >>
> >> Ben.
> >>
> >>
> >>> Regards,
> >>>
> >>> Christer
> >>>
> >>>
> >>> Sent from my iPhone
> >>>
> >>> On 21 May 2018, at 18.37, Christer Holmberg
> >>> <[e-mail]>
> >>>  wrote:
> >>>
> >>>
> >>>> Hi,
> >>>>
> >>>>
> >>>>>> It is also important to remember that this affects virtually every
> SDP attribute we define, >> unless there are cases where "initial offer"
> always means the initial offer of a session, i.e., >> it is not possible to
> introduce an attribute later in a session.
> >>>>>>
> >>>>> I'm not following your logic here. Can you give an example?
> >>>>>
> >>>> Assume I establish a session, with audio and video.
> >>>>
> >>>> The initial offer will contain the m- lines, and associated SDP
> attributes, for audio and video.
> >>>>
> >>>> Later in the session, I send a subsequent offer, adding a BFCP m-
> line.
> >>>>
> >>>> When setting the SDP attributes associated with the BFCP m- line, I
> will now use the "initial offer" procedures for those attributes, because
> it is the initial offer for those attributes (while a subsequent offer for
> the SIP session).
> >>>>
> >>>> Regards,
> >>>>
> >>>> Christer
> >>>>
> >>>>
> >
>
>