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

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