[MMUSIC] Roman Danyliw's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
Roman Danyliw via Datatracker <noreply@ietf.org> Tue, 09 April 2019 20:00 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: mmusic@ietf.org
Delivered-To: mmusic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2AD120222; Tue, 9 Apr 2019 13:00:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mmusic-data-channel-sdpneg@ietf.org, Bo Burman <bo.burman@ericsson.com>, mmusic-chairs@ietf.org, bo.burman@ericsson.com, mmusic@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <155484000356.19554.8395796686893872238.idtracker@ietfa.amsl.com>
Date: Tue, 09 Apr 2019 13:00:03 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/u3zSWuLh87TQBgmk-stz784RdKk>
Subject: [MMUSIC] Roman Danyliw's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 09 Apr 2019 20:00:04 -0000
Roman Danyliw has entered the following ballot position for draft-ietf-mmusic-data-channel-sdpneg-25: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) Section 5.2.1. The ABNF of stream-id of “dcsa-value = stream-id …” does not appear to be defined explicitly or by reference in the draft. (2) Section 6.6, “… the offerer SHALL include previously negotiated SDP attributes … associated with the channel”. What is the behavior of the receiver if the attributes included by the offerer are NOT those that were previously negotiated? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) Section 1. Editorial Nits. s/The concept of establishing a bi-directional data channel running on top of the Stream Control Transmission Protocol (SCTP) is in [I-D.ietf-rtcweb-data-channel] allowing applications to use data channels./ The concept of establishing a bi-directional data channel running on top of the Stream Control Transmission Protocol (SCTP) in [I-D.ietf-rtcweb-data-channel] allows applications to use data channels./ s/An in-band Data Channel Establishment Protocol (DCEP) is in [I-D.ietf-rtcweb-data-protocol], however other in-band or out-of-band protocols may be used for establishing data channels./ In addition to the in-band Data Channel Establishment Protocol (DCEP), other in-band and out-of-band protocols may be used for establishing data channels/ (2) Section 1. Typo (extra space between close bracket and period) s/For MSRP they are documented in [I-D.ietf-mmusic-msrp-usage-data-channel] ./ For MSRP they are documented in [I-D.ietf-mmusic-msrp-usage-data-channel]./ (3) Section 3. Editorial Nit. old: "delivery... )."; new: "delivery, etc.)." (4) Section 6.1. Editorial Nit. There appears to be two instances of the sentence, “SCTP stream identifiers associated with data channels that have been negotiated using DCEP MUST NOT be included in SDP offers and answers.” (5) Section 6.5. The sentence “Note: DCEP is not used, that is neither the SDP offerer nor the SDP answerer send an in-band DCEP DATA_CHANNEL_OPEN message” uses a triple negative so the guidance is not clear. (6) Section 6.7, Per “SDP offer or answer has an "a=dcsa" attribute, whose subprotocol attribute is known, but whose subprotocol attribute semantic is not known for the data channel transport case”, consider a case where the sub-protocol attribute is known but the value is invalid. Is that case a sub-set of what is meant by the “attribute semantic is not known”?
- [MMUSIC] Roman Danyliw's Discuss on draft-ietf-mm… Roman Danyliw via Datatracker
- Re: [MMUSIC] Roman Danyliw's Discuss on draft-iet… Roni Even (A)
- Re: [MMUSIC] Roman Danyliw's Discuss on draft-iet… Roman Danyliw