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

Alissa Cooper <alissa@cooperw.in> Mon, 20 June 2016 17:48 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E321712D8DD for <clue@ietfa.amsl.com>; Mon, 20 Jun 2016 10:48:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
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_H4=-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=tYi/Iiqu; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=ioE1jVxQ
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKV07502XdMa for <clue@ietfa.amsl.com>; Mon, 20 Jun 2016 10:48:02 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FEA712D814 for <clue@ietf.org>; Mon, 20 Jun 2016 10:48:02 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 8A97B2046C; Mon, 20 Jun 2016 13:48:01 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 20 Jun 2016 13:48:01 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=qeCOx6FFCpBxLyg9bHmSULHKowU=; b=tYi/Ii quXMYqVsjHTlagiV63kQW3T+MfsDjSFgH3zYmwyPVrIGnZjk1N0/Xfqu1vbT8NA6 oJANrL3Lu+FW/Tmkxjg6R3i45LaXMb66or9aAHyzGLdnHni5NFDE+a5JGanm4vyr 5lxCzLeczZO4sEaCGNTOfBSxmTwRVIM5gtuQY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=qeCOx6FFCpBxLyg 9bHmSULHKowU=; b=ioE1jVxQM1fqPnLjk1/1HO9gaIYZkP6eiBYXrUvBOGvOBh3 tTcfs7AHnsu3lu3aQ+l2GVh4RsX7YsiUR02UvdAbr9bXLaXCI7idxKN4X7+XcJk/ iCJU88yggpecu4U8tEftpJK05cin4w5aNy2fKAfnPT4fkfGNLx4iqSi2U1dk=
X-Sasl-enc: tR/Hgj/LKwxz7jVwEZNqEReuiVpomXDXnDMiDArUNJX7 1466444881
Received: from [10.35.132.59] (unknown [128.107.241.161]) by mail.messagingengine.com (Postfix) with ESMTPA id D547DCCDB9; Mon, 20 Jun 2016 13:48:00 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B3804C7E2@ESESSMB209.ericsson.se>
Date: Mon, 20 Jun 2016 10:48:00 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <F522F0A5-6610-4C70-AC95-E282BBC6A8D3@cooperw.in>
References: <7C34ECF9-51B4-4E0C-B24B-508C468ABCA0@cooperw.in> <7594FB04B1934943A5C02806D1A2204B3804C7E2@ESESSMB209.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/clue/8Xqx_Db3L-aUowiwAudo3q_rtsg>
Cc: CLUE <clue@ietf.org>
Subject: Re: [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: Mon, 20 Jun 2016 17:48:04 -0000

Thanks Christer, this all looks good. One comment below.

> On Jun 12, 2016, at 10:41 AM, Christer Holmberg <christer.holmberg@ericsson.com> 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