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