IETF Logo Mail Archive

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

RFC Errata System <rfc-editor@rfc-editor.org> Fri, 09 February 2024 08:02 UTC

Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEFFC14F6F3 for <mmusic@ietfa.amsl.com>; Fri, 9 Feb 2024 00:02:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.658
X-Spam-Level:
X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0lAeLXY9meT for <mmusic@ietfa.amsl.com>; Fri, 9 Feb 2024 00:02:27 -0800 (PST)
Received: from rfcpa.amsl.com (rfcpa.amsl.com [50.223.129.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB88FC14F6FF for <mmusic@ietf.org>; Fri, 9 Feb 2024 00:02:27 -0800 (PST)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 970F611821EC; Fri, 9 Feb 2024 00:02:27 -0800 (PST)
To: drageke@ntlworld.com, mmraju@gmail.com, richard.ejzak@gmail.com, jeromee.marcon@free.fr, ron.even.tlv@gmail.com, superuser@gmail.com, francesca.palombini@ericsson.com, bo.burman@ericsson.com, fandreas@cisco.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: harald@alvestrand.no, mmusic@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20240209080227.970F611821EC@rfcpa.amsl.com>
Date: Fri, 09 Feb 2024 00:02:27 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/A8BBY_F12Rnu1us-sl2FLep8kCo>
Subject: [MMUSIC] [Technical Errata Reported] RFC8864 (7805)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Feb 2024 08:02:31 -0000

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 <harald@alvestrand.no>

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

v2.23.0 | Report a Bug | By Email