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

[Bo Burman <[e-mail]>]

This errata report seems correct and desirable to me.
Cheers,
Bo
MMUSIC co-chair

> -----Original Message-----
> From: RFC Errata System <[e-mail]>
> Sent: Friday, 9 February 2024 09:02
> To: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> Francesca Palombini <[e-mail]>; Bo Burman
> <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: [Technical Errata Reported] RFC8864 (7805)
> 
> 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