Re: [Gen-art] Gen-ART Last Call review of draft-ietf-clue-datachannel-13

[Christer Holmberg <[e-mail]>]

Submitted.

Regards,

Christer

-----Original Message-----
From: Alissa Cooper [mailto:[e-mail]] 
Sent: 09 August 2016 21:53
To: Christer Holmberg <[e-mail]>
Cc: Brian E Carpenter <[e-mail]>; [e-mail]; General Area Review Team <[e-mail]>
Subject: Re: Gen-ART Last Call review of draft-ietf-clue-datachannel-13


> On Aug 8, 2016, at 12:29 PM, Christer Holmberg <[e-mail]> wrote:
> 
> Hi,
> 
> I've created a new version of the draft, based on Brian's comments. It's not yet submitted, but can be found at GitHub:
> 
> https://github.com/cdh4u/draft-clue-datachannel/blob/master/draft-ietf
> -clue-datachannel.txt
> 
> The only change is to add a reference to the club protocol draft in the Introduction section.
> 
> Alissa, please let me know when I can submit the new version :)

You can go ahead and submit.

Thanks,
Alissa

> 
> Thanks!
> 
> Regards,
> 
> Christer
> 
> 
> -----Original Message-----
> From: Christer Holmberg [mailto:[e-mail]]
> Sent: 07 August 2016 20:13
> To: Brian E Carpenter <[e-mail]>; 
> [e-mail]; General Area Review Team 
> <[e-mail]>
> Subject: RE: Gen-ART Last Call review of 
> draft-ietf-clue-datachannel-13
> 
> Hi Brian,
> 
> ...
> 
>>>> Minor issues:
>>>> -------------
>>>> 
>>>> Mainly for my own education:
>>>> 
>>>> 3.2.6.  SCTP Multihoming
>>>> 
>>>>  SCTP multi-homing is not supported for SCTPoDTLS associations, and  
>>>> can therefore not be used for a CLUE data channel.
>>>> 
>>>> What is the advantage of SCTP if you don't get the benefit of multihoming?
>>> 
>>> There are other SCTP features that are used. The most essential is 
>>> the SCTP multi stream feature, which allows multiple data channels 
>>> using a single SCTP associations: each data channel is implemented using two unidirectional SCTP streams.
>>> 
>>> SCTP also provide different options when it comes to data transport reliability and ordering, and data channels can use different combinations.
>> 
>> OK, thanks. I have the impression that this explanation is given 
>> nowhere in the CLUE documents (and not in draft-ietf-rtcweb-transports either). I think it would be helpful if it was recorded *somewhere*.
>> It doesn't really belong in clue-datachannel.
> 
> I agree - it's not the task of CLUE to justify the decisions made by RTCWEB.
> 
> For the details of the data channel mechanism, please take a look at draft-ietf-rtcweb-data-channel.
> 
> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel
> 
> Regards,
> 
> Christer
> 
> 
> 
>> 
>> 
>>> Nits:
>>> -----
>>> 
>>> I expected a reference to draft-ietf-clue-protocol where CLUE is first mentioned in the Introduction.
>> 
>> I'll fix that.
> 
> Thanks
>    Brian