Re: [clue] AD evaluation: draft-ietf-clue-datachannel

[Christer Holmberg <[e-mail]>]

Hi Alissa,

Thanks for your comments! See inline.

> I will note that the security considerations here ultimately rely on draft-ietf-rtcweb-security and draft-ietf-rtcweb-security-arch, which are not finished yet. This
> means it is hard to fully evaluate this spec at this time. We can proceed with IETF LC after discussion of the questions below, but I would suggest either not
> proceeding further than that until those documents are done, or developing specific text for this document that documents the security considerations if you don't want to wait.

I am ok waiting for the generic rtcweb-security drafts to be finished. After that it will be easier to see what/if CLUE data channel specific security text we need to add.

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

Questions:

1) In Section 3.2.5, the text says "Other features of [RFC5061] MUST NOT be used." Can you clarify what "other features" this is in reference to? Is this just about the ability to set a primary IP address, or something else? I think it would help to be more specific here.

The text refers to the new 'Supported Extensions Parameter' parameter, a generic mechanism for signalling support of SCTP extensions, defined in RFC 5061.

I more or less copied the text from draft-ietf-rtcweb-data-channel:

   "o  The dynamic address reconfiguration extension defined in [RFC5061]
      MUST be used to signal the support of the stream reset extension
      defined in [RFC6525].  Other features of [RFC5061] are OPTIONAL."

So, I guess we could simply refer to that text, and say something like:

    "As defined in [ref-to-draft-rtcweb-data-channel], the dynamic address reconfiguration extension 
     ('Supported Extensions Parameter' parameter) defined in [RFC5061] must be used to signal the 
     support of the stream reset extension defined in [RFC6525]. Other features of [RFC5061]
     MUST NOT be used for CLUE data channels."

Now, if you think that the 'Supported Extensions Parameter' parameter shall be spelt out explicitly, I guess that comment should also be given for draft-ietf-rtcweb-data-channel.

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

2) I think Section 3.3 needs to be more clear about whether it is specifying things for all WebRTC data channels, or just for CLUE data channels. 3.3.1 uses the term WebRTC data channel when I would have expected it to use the term CLUE data channel.

I can change to "CLUE data channel" in section 3.3.1.

In section 3.3.1.1 I think we shall keep "WebRTC data channel", because the text is about WebRTC data channels in general.

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

> 3) IF DCEP is out of scope, why do you then say that this specification relies on the security properties of draft-ietf-rtcweb-data-protocol?

DCEP used to be in scope, and when we made it out of scope it seems like I forgot to remove the text from the security considerations. I will remove the text.

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

Nits:

> - Sec. 1
>
> I find it a bit odd to say that DCEP is out of scope here but not mention that negotiation of the CLUE data channel is defined in 
> draft-ietf-clue-signaling. I think at a minimum a reference to the signaling doc is needed, and would also recommend dropping 
> the note about DCEP unless you think you really need it.

The negotiating of the CLUE data channel is defined in draft-ietf-mmusic-data-channel-sdpneg, which the does does reference.

draft-ietf-clue-signaling is more about negotiating the CLUE session in general.

I suggest to keep the test as it is.

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

> - Sec 3.2.3
>
> s/A CLUE entity MUST NOT use the partial reliability and limited retransmission SCTP extensions/A CLUE entity MUST NOT use the partial reliability or limited retransmission SCTP extensions

Will fix as suggested.

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

I've created a pull request with the suggested changes:

https://github.com/cdh4u/draft-clue-datachannel/tree/alissa_comments

Thanks!

Regards,

Christer