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

["Murray S. Kucherawy" <[e-mail]>]

On Wed, Feb 14, 2024 at 3:22 AM Christer Holmberg <christer.holmberg=
[e-mail]> wrote:

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

-MSK