[MMUSIC] AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20

[Ben Campbell <[e-mail]>]

Hi,

This is my AD evaluation of draft-ietf-mmusic-data-channel-sdpneg-20. I think the draft is in pretty good shape, but I have some comments and questions I would like to discuss prior to IETF last call.

Please note that I have a question for the MMUSIC chairs in my second substantive comment.

Thanks!

Ben.

-----------------------

Substantive Comments:

- There are 6 authors listed. Normally the limit is 5 unless there is a really good reason. Did all of the authors contribute substantial text? Could the author list be reduced to just editors, and have the rest in a “contributors” section?

- I understand the MSRP data channel usage draft is effectively dead. Please consider whether you want continue to use it as an example if it is not likely to progress.  (MMUSIC chairs: do you have thoughts on the likely future of the MSRP data channel usage draft?)

§2: Unless you have a specific reason not to do so, please use the updated boilerplate from RFC 8174.

§5.1: " It is assumed that the data channel properties
   (reliable/partially reliable, ordered/unordered) are suitable per the
   subprotocol transport requirements.”

What does it mean to assume that? Consider a statement to the effect that the “properties need to be suitable”

§5.1.7: I suspect the “MUST” in the first sentence is a statement of fact. Isn’t the actual normative requiremeint defined in rtcweb-data-protocol? If so, please use descriptive language here.

§8: I am skeptical that this adds no security considerations above those in sctp-sdp. In particular, it seems worth mentioning that each subprotocol may come with it’s own security considerations that need to be documented as part of the subprotocol definition. (As an example, MSRP has security considerations about the URL used in the a=path attribute that would apply to any definition of the use of “path” at the dcsa level.)

§9.1: What is the rational for sharing the websocket subprotocol registry rather than creating a new one for data channels? The websocket subprotocol name registry has a policy of “First Come First Served”. This draft seems to state requirements for subprotocol specifications, but FCFS does not require specifications.

§12.2: It seems like the references to [I-D.ietf-rtcweb-data-protocol] and [RFC4960] should be normative. It’s not necessary to include references to IANA registries; just mention them in the text.

Editorial Comments:

- Abstract: The abstract will not age well. Years from now, no one will think in terms of what RTCWeb vs some other working group defined. I suggest recasting this in terms of the documents and protocols, not the working groups.  (Comment repeats for introduction.)


§1:
- " Data channels are created by endpoint applications
through the WebRTC API (Application Programming Interface), or other
users of a data channel like CLUE [I-D.ietf-clue-datachannel]”

Incomplete sentence--are there missing words?

- “They can be used to transport proprietary or well-defined protocols, which...”

The antecedent to “They” is ambiguous. Also, proprietary protocols can still be well-defined. I think you mean “proprietary or standardized”

- Please include a citation for the first mention of WebSocket.

§3:

- "If an SDP offer/answer exchange is used as specified in
      this document to negotiate the establishment of data channels,
      corresponding data channel properties, associated data channel
      subprotocols and data channel subprotocol properties, then the
      data channel subprotocols may be identified by the values of the
      "subprotocol" parameters of the SDP "a=dcmap" attribute as
      described in Section 5.1.4.”

Convoluted sentence. Please consider breaking it into simpler sentences.

§4: Improper comma use after “... the Session
   Description Protocol (SDP) [RFC4566]”

§5: Improper comma use after “attributes” and “parameters”.

§5.1, 2nd paragraph: I can’t parse the first sentence.

§5.1.1, last paragraph:
s/ “... either only one...” /  “... only one ...”
The “MAY” is not a normal “normative” use of MAY; consider lower case. (The following “MUST NOT” is sufficient.)

§6.2: “ By definition max-retr and max-time are mutually exclusive, so at
   most one of them MAY be present...”

This would be better formulated as a MUST NOT. (MAY is typically used to give permission, not create constraints.)

§6.5, first bullet: s/closes/close

§6.6: Improper comma use after “subsequent offer”

§6.6.1, first paragraph: Comma needed after “data channel”.

§7: Please refer to the figures by number rather than relative position. (e.g. “The example in figure 2” rather than “The above example”.)

§9.3, first paragraph: " SDP attributes that are defined for use at the dcsa
   usage level only SHALL use the dcsa usage level when registering the
   attribute.”

I don’t understand this sentence. Consider a MUST NOT/SHALL NOT construction.