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

[Flemming Andreasen <[e-mail]>]

This seems like a very reasonable way forward to me.

Thanks

-- Flemming

On 5/22/18 4:23 PM, Ben Campbell 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
>>>>>
>>>>>