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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 09 Apr 2019 13:00:03 -0700

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

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 11 Apr 2019 09:24:39 +0000

Thanks for the review, see inline

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

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

(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

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

[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

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 11 Apr 2019 14:56:21 +0000

> From: Roni Even (A) [mailto:[email-masked]]
> Sent: Thursday, April 11, 2019 5:25 AM
> To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; Bo Burman
> <[email-masked]>; [email-masked]; [email-masked]
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-mmusic-data-channel-
> sdpneg-25: (with DISCUSS and COMMENT)
> 
> Cc: [email-masked]; Bo Burman; mmusic-
> [email-masked]; [email-masked]; [email-masked]
> 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.)
> 
> 

OK.  Thanks for the fix.

> signaling protocol e.g. SIP

Understood.  Could you add that simple sentence that the behavior on mismatch is protocol specific.

> 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/
> 
> [RE] prefer to use as is

No problem.  Keep the original text.
 
> (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] ./
> associated with data channels that have been negotiated using DCEP MUST
> NOT be included in SDP offers and answers.”
> 

Thanks for these changes.

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

Understood.  Thanks for the clarity.

Roman