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

[Ben Campbell <[e-mail]>]

> On May 22, 2018, at 11:37 PM, Christer Holmberg <[e-mail]> wrote:
> 
> Hi,
> 
> I am happy with the suggested way forward, and will create a PR where I try to implement it.

Excellent, thanks!

> 
> Having said that, what do we do with other extensions that are still in the WGCL/IESG? For example, RTCWEB defines the SDP 'identity' attribute, and I have commented that the O/A procedures (together with some other clarifications) are needed for that. Another example is BFCPbis, where we are about to request publication for the 4583bis draft.

I assume you are asking whether we will force them to follow my view of “initial SDP offer” vs “initial offer of the extension”. I’m not going to insist on restructuring mostly-done drafts as long as they are clear. And if they are not clear, I expect that someone will complain.  (I’m not picking on Ekr—that could easily be Adam, me, or someone else.)

I would like to see MMUSIC participants pick a long-term way forward, but I realize my view may not represent that consensus.

Ben.



> 
> Regards,
> 
> Christer
> 
> -----Original Message-----
> From: Ben Campbell [mailto:[e-mail]]
> Sent: 22 May 2018 22:24
> To: Flemming Andreasen <[e-mail]>; Christer Holmberg <[e-mail]>; Adam Roach <[e-mail]>
> Cc: [e-mail]; Eric Rescorla <[e-mail]>; mmusic WG <[e-mail]>; The IESG <[e-mail]>; [e-mail]
> Subject: Re: Offer/Answer sections in SDP extension documents [Re: Eric Rescorla's No Objection on draft-ietf-mmusic-sdp-bundle-negotiation-51: (with COMMENT)]
> 
> 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
>>>>> 
>>>>> 
>> 
>