[bfcpbis] AD evaluation: draft-ietf-bfcpbis-sdp-ws-uri-06

Alissa Cooper <alissa@cooperw.in> Fri, 09 December 2016 19:38 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35EC129550 for <bfcpbis@ietfa.amsl.com>; Fri, 9 Dec 2016 11:38:29 -0800 (PST)
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_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=31X9Pupn; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=VRtxIAqD
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 ri9WTOxU9s6l for <bfcpbis@ietfa.amsl.com>; Fri, 9 Dec 2016 11:38:28 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A814129532 for <bfcpbis@ietf.org>; Fri, 9 Dec 2016 11:38:28 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E0D9620B08 for <bfcpbis@ietf.org>; Fri, 9 Dec 2016 14:38:27 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Fri, 09 Dec 2016 14:38:27 -0500
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-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=Qw/oQHPLpgTNKMjylZF/N1RKJRc=; b=31X9Pu pn2dyoHjyZyW2eGwxvZXlfprKAy6UwQc2I+JJUiM8vl1TCw5+Bm2lOusFe6Gt7Nr K/RjKNSiIqKwwBEEKUuz25NhZuPuZKNbVTD73Efr2mkLdo95DpxM7Uz1Wz0vuH0P 88sL3ExfOGBGAoPioxYa8eAVNtp+1F38Qoj5I=
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-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Qw/oQHPLpgTNKM jylZF/N1RKJRc=; b=VRtxIAqDGyXIArxnk8K51U83kzLVGJWz0zz3/CWd4xT//8 4bhL00vRzrrO74t9Wamy7cfomibsEsTaRqhwpCL8rzUElqf4bGgTAWwFbP/hDFLa MwIZyPwF2DeCTGwsbfTuVs/l2QqKc8JPx8bYHzmb1RJ4yGZVUceeymRWoXzfk=
X-ME-Sender: <xms:MwhLWLunmnZntAnn7dNvpDPVEC-7vX2A9Gr3IE4cnzFIT7LFcxKQaA>
X-Sasl-enc: tdovlG3QxyLs3QcV/HtrgDGVw0fhyxDQtEKNUmvcI2wC 1481312307
Received: from sjc-alcoop-8819.cisco.com (unknown [128.107.241.190]) by mail.messagingengine.com (Postfix) with ESMTPA id 762E77E398 for <bfcpbis@ietf.org>; Fri, 9 Dec 2016 14:38:27 -0500 (EST)
From: Alissa Cooper <alissa@cooperw.in>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <DDFDCD0B-AD0E-41AF-B6C8-9D29F6B10823@cooperw.in>
Date: Fri, 09 Dec 2016 14:38:25 -0500
To: bfcpbis@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/bfcpbis/sTLsfwJvJjlLgm5MGpg1XLUFXrM>
Subject: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-sdp-ws-uri-06
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2016 19:38:30 -0000

I have reviewed this document in preparation for IETF last call. I have a couple of comments to discuss before issuing the last call. I’ve also included some nits below that should be resolved together this IETF LC comments.

Substantive comments:

= Section 1 =

"In most cases it is not viable for certificates signed by well known
   authorities."

I don't understand what this sentence means.

= Section 5 =

"If there are
   multiple records returned for the connection URI in the "a=wss-uri"
   or "a=ws-uri" then the clients MAY use procedures in Section 4 of
   [RFC6555] to attempt the connection towards the server."

I'm confused about this. Why would there be multiple URIs? This isn't explained anywhere in the document. (Furthermore, I don't understand the comment from Dan Wing that was the origin of this text, I think. I thought the point of all of this work is to take advantage of the underlying WebSocket to send BFCP messages, so wouldn't DNS resolution be handled by the HTTP stack on the client?)

= Section 6 =

"Consequently, it is strongly
RECOMMENDED that integrity protection be applied to the SDP session
descriptions. For session descriptions carried in SIP [RFC3261], S/
MIME is the natural choice to provide such end-to-end integrity
protection."

Is this just suggesting S/MIME to have nice words in the text, or do you expect to see implementations using S/MIME to protect their SDP bodies?


Nits:

= Section 1 =

OLD
As defined in Section 3 of [RFC2818], when using Secure WebSockets
   the Canonical Name (CNAME) of the Secure Sockets Layer (SSL)
   [RFC6101] certificate MUST match the WebSocket connection URI host.

NEW
When using Secure WebSockets
   the Canonical Name (CNAME) of the Secure Sockets Layer (SSL)
   [RFC6101] certificate MUST match the WebSocket connection URI host (see Section 3 of [RFC2818]).
   
= Section 5 =

s/on Internet/on the Internet/   

s/ports (80 or 443)/port (80 or 443)/

= Section 6 =

s/it is strongly RECOMMENDED/it is RECOMMENDED/