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

Christer Holmberg <> Mon, 08 August 2016 19:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 951B212B02C; Mon, 8 Aug 2016 12:29:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UriFh-dnWwmf; Mon, 8 Aug 2016 12:29:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F4EF12B02B; Mon, 8 Aug 2016 12:29:21 -0700 (PDT)
X-AuditID: c1b4fb3a-0618b980000009bd-5d-57a8dd8fcbe5
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 18.EF.02493.F8DD8A75; Mon, 8 Aug 2016 21:29:19 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0301.000; Mon, 8 Aug 2016 21:29:18 +0200
From: Christer Holmberg <>
To: Brian E Carpenter <>, "" <>, General Area Review Team <>
Thread-Topic: Gen-ART Last Call review of draft-ietf-clue-datachannel-13
Thread-Index: AQHR6GAWo4fktv+/Z0efGyJg4oP+yqA0qdiQgAenOYCAAXtKkIABuL1A
Date: Mon, 08 Aug 2016 19:29:18 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM2K7om7/3RXhBn/3K1q0XdzHZDH1+yt2 i6uvPrM4MHvsnHWX3WPJkp9MAUxRXDYpqTmZZalF+nYJXBmHWhexF3RIVOxadpWxgXGHeBcj J4eEgInE7L/trF2MXBxCAusZJfpvvGECSQgJLGaUaDxh18XIwcEmYCHR/U8bJCwisJdR4nib IYgtLOAucePqO0aIuIfEyWfn2SBsN4lT69tYQGwWARWJtvVTweK8Ar4S67bfY4MY/51RYsUl LRCbU8BPov/jC1YQm1FATOL7qTVgJzALiEvcejKfCeJOAYkle84zQ9iiEi8f/2OFsJUkFt3+ zARyJrOApsT6XfoQrYoSU7ofskOsFZQ4OfMJywRGkVlIps5C6JiFpGMWko4FjCyrGEWLU4uL c9ONjPRSizKTi4vz8/TyUks2MQJj4uCW31Y7GA8+dzzEKMDBqMTDu+DEinAh1sSy4srcQ4wS HMxKIrwRV4FCvCmJlVWpRfnxRaU5qcWHGKU5WJTEef1fKoYLCaQnlqRmp6YWpBbBZJk4OKUa GHk39tc+q3nE+HjpHiUXheztOTvvb9I+ethakFc1ImP2o8h5Jr6sm1ewza5Kn2t6ouR2TcZH D7HaSz4qkVUuTElf5Nd+sK6b9Xud3wl+E2M/B9MjLJqmlTxfzjz5fjx5qeY8vpLvTnsNZoZ8 v68zbU7lqhkCO65v2O6yu/yqX5qx+ecZZxavL1FiKc5INNRiLipOBADpmYlJhQIAAA==
Archived-At: <>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-clue-datachannel-13
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Aug 2016 19:29:35 -0000


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:

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 :)




-----Original Message-----
From: Christer Holmberg [] 
Sent: 07 August 2016 20:13
To: Brian E Carpenter <>;; General Area Review Team <>
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.



>> Nits:
>> -----
>> I expected a reference to draft-ietf-clue-protocol where CLUE is first mentioned in the Introduction.
> I'll fix that.