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

[Christer Holmberg <[e-mail]>]

Hi,

I¹ll fix the other things, and submit a new version.

Thanks!

Regards,

Christer


On 20/06/16 20:48, "Alissa Cooper" <[e-mail]> wrote:

>Thanks Christer, this all looks good. One comment below.
>
>> On Jun 12, 2016, at 10:41 AM, Christer Holmberg
>><[e-mail]> wrote:
>> 
>> 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.
>
>Ok. If anyone else disagrees, please speak up. Otherwise I think you can
>publish a revision and I¹ll change the state to indicate that we¹re
>waiting on an external document.
>
>Thanks,
>Alissa
>
>
>> 
>> -------------
>> 
>> 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
>