Subject: [clue] Benjamin Kaduk's No Objection on draft-ietf-clue-datachannel-15: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 10 Apr 2019 07:16:58 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-clue-datachannel-15: No Objection

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-clue-datachannel/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1

                                           This includes SCTP
   considerations specific to a CLUE data channel, the SDP Media
   Description (m- line) values, and usage of SDP attributes specific to
   a CLUE data channel.

nit: "m= line"

Section 2

Please use the RFC 8174 boilerplate.

Section 3.1

   the WebRTC data channel mechanism.  This includes a set of SCTP
   characteristics specific to a CLUE data channel, the values of the m-
   line describing the SCTPoDTLS association associated with the WebRTC

nit: "m= line"?

Section 3.2.7

   As described in [I-D.ietf-rtcweb-data-protocol], in order to close a
   data channel, an entity sends an SCTP reset message [RFC6525] on its

This reference would normally make draft-ietf-rtcweb-data-protocol a
normative reference, but I think that perhaps the intended reference is
actually draft-ietf-rtcweb-data-channel (which is already a normative
reference).  In particular, Section 6.7 of the latter document is about
"Closing a Data Channel" and mentions resetting the streams.

Section 3.3.2

   The values of the SDP dcmap attribute
   [I-D.ietf-mmusic-data-channel-sdpneg], associated with the m- line

nit: "m= line"?

Section 5.1

I note that the WebSocket Subprotocol Name Registry has the "first come,
first served" registration policy, which makes a declarative statement like
this ("this document adds") a bit risky -- what if someone else swoops in
to register this name?

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Apr 2019 14:39:53 +0000

Hi Benjamin,

Thank you for the review! Please see inline!

Section 1
    
>Description (m- line) values, and usage of SDP attributes specific to
  
There is no rule on how to write it. Sometimes m- lines is used.

But, I can change to "m=" line, as that's what is used in 4566bis.

----
  
Section 2
    
>Please use the RFC 8174 boilerplate.

Will fix.

----

Section 3.1
    
>line describing the SCTPoDTLS association associated with the WebRTC
  
See comment on Section 1.
  
----

Section 3.2.7
    
>"Closing a Data Channel" and mentions resetting the streams.

Correct. I will change the reference to draft-ietf-rtcweb-data-channel.

----
  
Section 3.3.2
    
>[I-D.ietf-mmusic-data-channel-sdpneg], associated with the m- line

See comment on Section 1.

----
    
Section 5.1
    
>this ("this document adds") a bit risky -- what if someone else swoops in
    
Well, IF that would happen, we would have to deal with it, and there is nothing we can do in the draft to prevent that. I don't think this draft should update the registry policy.

Also, the risk applies to any draft registering new values, and if it becomes a problem I guess someone will have to look into it.

Thanks!

Regards,

Christer