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

[Paul Kyzivat <[e-mail]>]

I disagree.

The point of this constraint was to allow concurrent use of the channel 
with both SDP negotiation of channels and DCEP dynamic channel 
management. Absent that I agree that SDP negotiation would be sufficient.

An example of when this could be a problem is when a session is already 
established. Then one side prepares to send an offer to negotiate a new 
channel via SDP. It sends an offer. Concurrently the other side begins 
to use a channel via DCEP rules. If they happen to choose the same 
channel number a problem arises. Using the same even/odd rules that DCEP 
uses prevents this problem.

Is there motivation for removing this restriction?

	Thanks,
	Paul

On 2/9/24 3:02 AM, RFC Errata System wrote:
> The following errata report has been submitted for RFC8864,
> "Negotiation Data Channels Using the Session Description Protocol (SDP)".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7805
> 
> --------------------------------------
> Type: Technical
> Reported by: Harald Alvestrand <[e-mail]>
> 
> Section: 6.1
> 
> Original Text
> -------------
>     In order to avoid SCTP Stream identifier collisions, in alignment
>     with [RFC8832], the endpoint acting as a DTLS client (for the SCTP
>     association used to realize data channels) MUST use even identifier
>     values, and the endpoint acting as a DTLS server MUST use odd
>     identifier values.
> 
> 
> Corrected Text
> --------------
> [RFC8831] does not restrict the SCTP Stream identifiers for data
> channels negotiated out-of-band. The endpoints are free to assign
> any numbers to the negotiated data channels; collisions are handled
> by the usual mechanisms used to avoid SDP signalling glare.
> 
> 
> 
> Notes
> -----
> The procedures of [RFC8832] are inappropriate in this case, because DCMAP indicates channels negotiated out-of-band and not via DCEP.
> 
> At initial offer, the DTLS direction attribute is ACTPASS, so the direction is not known. Thus, the RFC 8832 numbering rule is impossible to apply anyway.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". (If it is spam, it
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC8864 (draft-ietf-mmusic-data-channel-sdpneg-28)
> --------------------------------------
> Title               : Negotiation Data Channels Using the Session Description Protocol (SDP)
> Publication Date    : January 2021
> Author(s)           : K. Drage, M. Makaraju, R. Ejzak, J. Marcon, R. Even, Ed.
> Category            : PROPOSED STANDARD
> Source              : Multiparty Multimedia Session Control
> Area                : Applications and Real-Time
> Stream              : IETF
> Verifying Party     : IESG
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic