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

Alissa Cooper <alissa@cooperw.in> Fri, 10 June 2016 18:49 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A802912D095 for <clue@ietfa.amsl.com>; Fri, 10 Jun 2016 11:49:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=1dOW032g; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=n+5Bm0lf
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rXRCtuFB9hWG for <clue@ietfa.amsl.com>; Fri, 10 Jun 2016 11:49:00 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF84A12B047 for <clue@ietf.org>; Fri, 10 Jun 2016 11:49:00 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 3BD6A20964 for <clue@ietf.org>; Fri, 10 Jun 2016 14:48:59 -0400 (EDT)
Received: from frontend2 ([]) by compute5.internal (MEProxy); Fri, 10 Jun 2016 14:48:59 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=Crf aunAm3f6rfKO9AdLWJtLN0Jk=; b=1dOW032g+eJP0ZmfAFLqclJV3VzzHroaPK2 1CjctTJwLjHx5cz9zpXEw5lOsNSNCv/I3d0eZq5t41eDerdchtW4WhHucam5ZKIg DznqHn2Dex4l8xVx+gWei/6cu0MSBuspqWe22PNzykLV4ZWG+ZJONVgqHt0lrdUN BQwMqfSU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=CrfaunAm3f6rfKO9AdLWJtLN0Jk=; b=n+5Bm 0lf+VtKd1qjEM2O4cWdIPN8UQkZI1ZgYDyi8tVY/Md3+gLBZrInc73rTk56eKYy+ f6q1C6M1cfgBdvhy/HpygX69Dkn/HQV9XAE81Fs4oWDIbe5wKaeYGHE4BuzQ4tuZ orT9NhmsZjrSqRom79Pk7Hwm2gWncuffYrSnHk=
X-Sasl-enc: tjIZjS4QE1q0yZp5oI7wJTaICmmMs6+UfuwvoFT77SQP 1465584538
Received: from dhcp-171-68-20-136.cisco.com (dhcp-171-68-20-136.cisco.com []) by mail.messagingengine.com (Postfix) with ESMTPA id C0AB9CCDAC for <clue@ietf.org>; Fri, 10 Jun 2016 14:48:58 -0400 (EDT)
From: Alissa Cooper <alissa@cooperw.in>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <7C34ECF9-51B4-4E0C-B24B-508C468ABCA0@cooperw.in>
Date: Fri, 10 Jun 2016 11:48:58 -0700
To: CLUE <clue@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/clue/2UmJmLaXNfAO9sCpOInSm6LR5cc>
Subject: [clue] AD evaluation: draft-ietf-clue-datachannel
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/clue/>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jun 2016 18:49:03 -0000

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.


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?


- 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