Re: [MMUSIC] [Technical Errata Reported] RFC8864 (7805)

[Harald Alvestrand <[e-mail]>]

Yes, there are applications that both establish pre-agreed datachannels 
and use DCEP. For those cases, the odd/even restriction does not apply; 
it is up to the application to rendezvous properly.

This erratum removes the incorrect claim that SDP-negotiated channels 
are capable of obeying the odd/even rule, bringing SDP-negotiated 
channels in line with the rules for pre-agreed datachannels.

Harald


On 3/27/24 11:48, Christer Holmberg wrote:
> Hi,
> 
>>>>> The issues (AFAIU) is when the offerer sends the *initial* offer,
>>>>> with ACTPASS, and creates one or more data channels using SDP. At
>>>>> that point the offerer does not yet know whether it will become DTLS
>>>>> client or server, but it still has to assign identifiers (odd or even) to
>>>>> the
>>>>> data channels.
>>>>
>>>> Good point. At that point there should be no risk of conflict with
>>>> DCEP.
>>>> Maybe a revision is needed to deal with that.
>>>
>>> Yes.
>>>
>>> And, if DCEP is then later used to create another data channel, it
>>> needs to make sure that it does not re-use the same identifier (no matter
>>> if it is
>>> odd or even).
>>>
>>>>> Once the DTLS roles have been determined, the DCEP rules work
>>>>> fine also for SDP.
>>>>>
>>>>> (Personally I have never seen a use-case where both DCEP and SDP
>>>>> are used to create and manage data channels.)
>>>>
>>>> It is hard to envision a use case for it. But as I recall we were trying
>>>> to avoid precluding it. One alternative would be for the SDP negotiation
>>>> to
>>>> include the choice of either DCEP or SDP for negotiating data channels.
>>>> But
>>>> could that be done in a backward compatible way?
> 
> The usage of dcmap does indicate such choice in my opinion.
> 
> But, again, I cannot guarantee that there are no implementation that use both
> SDP and DCEP within the same session.
> 
>>>> If we were able to verify that there is currently no concurrent use in
>>>> the wild then perhaps we could amend to say that use of SDP to negotiate
>>>> data channels precludes use of DCEP.
>>>
>>> It is difficult to verify that.
>>>
>>> But, as discussed above, if we say that in case of ACTPASS the offerer
>>> can choose either an odd or even value.
>>
>> It sounds to me like this is something you'd want to discuss should a -bis
>> document ever become a reality, but not confirm the erratum as-is.  Is that
>> correct?  If so, then we want "Hold For Document Update" rather than
>> "Verified" for this one, correct?
> 
> We can discuss whether we should fix this using a -bis or an erratum.
> 
> But, the current erratum should not be agreed in its current form.
> 
> I think the first thing we need to do is how the solution would look like: the
> easiest solution would be to simply that say:
> 
> 1)	If one uses SDP one SHOULD/MUST NOT use DCEP
> 2)	Remove the even/odd requirement when using SDP (at least when using
> ACTPASS)
> 
> Regards,
> 
> Christer
> 
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic