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

[Bo Burman <[e-mail]>]

> On Sep 5, 2018, at 6:43 PM, Ben Campbell <[e-mail]> wrote:
> 
> > On Sep 5, 2018, at 5:18 AM, Bo Burman <[e-mail]> wrote:
> >
> > Hi,
> >
> > Regarding this question to the chairs:
> >> - 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?)
> >>
> >
> > As said at the IETF 102 MMUSIC session, since there seems to be no interest in progressing the MSRP datachannel draft
> we propose to let it expire and remove the milestone. A confirming question on that was sent to this list Aug 23 with
> deadline to respond end of this week (Sep 7). So far there were no objections. When that poll has concluded and if there
> are still no objections, I suggest to simply remove the reference to the MSRP datachannel draft from this draft.
> 
> Thanks Bo, that confirms my (apparently weak) memory on the matter.
> 
> I think there’s more here than just the reference, though. MSRP is used as an example throughout.

[BoB] True, but without the MSRP datachannel draft there is no draft or RFC that describes any datachannel sub-protocol in SDP, so there is really no choice but to describe something that has no explicit backing in a reference. I don't see MSRP being any worse than anything else in that aspect, and if keeping MSRP in the text there's at least the (potential) benefit that there is an expired draft to look at (even if not explicitly referenced).

> 
> >
> > Cheers,
> > /Bo
> > (MMUSIC co-chair)
> >
> >
> >> -----Original Message-----
> >> From: mmusic <[e-mail]> On Behalf Of Ben Campbell
> >> Sent: den 28 augusti 2018 05:06
> >> To: [e-mail]
> >> Cc: [e-mail]
> >> Subject: [MMUSIC] AD Evaluation of
> >> draft-ietf-mmusic-data-channel-sdpneg-20
> >>
> >> 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.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >