Re: [MMUSIC] Roman Danyliw's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)

["Roni Even (A)" <[e-mail]>]

Thanks for the review, see inline


-----Original Message-----
From: Roman Danyliw via Datatracker [mailto:[e-mail]] 
Sent: Tuesday, April 09, 2019 11:00 PM
To: The IESG
Cc: [e-mail]; Bo Burman; [e-mail]; [e-mail]; [e-mail]
Subject: Roman Danyliw's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)

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.

RE: will  add "stream-id = 1*5DIGIT" ; same as dcmap-stream-id

(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?

RE: The behavior is protocol specific, offer answer may be used by multiple signaling protocol e.g. SIP


----------------------------------------------------------------------
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./

[RE] Not sure - the allowing refers to [rtcweb-data-channel]

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/

[RE] prefer to use as is

(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]./
[OK]

(3) Section 3.  Editorial Nit.
old: "delivery... )."; new: "delivery, etc.)."
[RE] OK



(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.”

[RE] thanks, will remove the first instance


(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.
[RE]  I can remove the note, does not provide any vaue


(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”?
[RE] yes, this is what semantics means