On 02/08/2016 09:47, Christer Holmberg wrote:
> Hi Brian,
>
> Thanks for your review! Please see inline.
>
>> I am the assigned Gen-ART reviewer for this draft. The General Area Review
>> Team (Gen-ART)
>> reviews all IETF documents being processed by the IESG for the IETF Chair.
>> Please treat these comments just like any other last call comments.
>>
>> For more information, please see the FAQ at
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-clue-datachannel-13.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2016-07-28
>> IETF LC End Date: 2016-08-01
>> IESG Telechat date:
>>
>> Summary: Ready
>> --------
>>
>> 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.
>
>
>> Nits:
>> -----
>>
>> I expected a reference to draft-ietf-clue-protocol where CLUE is first
>> mentioned in the Introduction.
>
> I'll fix that.
Thanks
Brian
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
