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

[Alissa Cooper <[e-mail]>]

I have reviewed this document in preparation for IETF last call. I think it is almost ready. I have a couple of questions I'd like to discuss first and some nits that should be resolved together with any last call comments.

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.

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.

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.

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?

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.

- 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

Thanks,
Alissa