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

[Christer Holmberg <[e-mail]>]

Hi Benjamin,

Thank you for the review! Please see inline!

----------------------------------------------------------------------
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"
  
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
    
>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"?
  
See comment on Section 1.
  
----

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.

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

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

See comment on Section 1.

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