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

Alissa Cooper <alissa@cooperw.in> Wed, 21 December 2016 17:37 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 D2644129873 for <bfcpbis@ietfa.amsl.com>; Wed, 21 Dec 2016 09:37:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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, 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=D+5FkAqy; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=s4KuUNjc
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 HrzTGYEyVstY for <bfcpbis@ietfa.amsl.com>; Wed, 21 Dec 2016 09:37:58 -0800 (PST)
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 7B223129503 for <bfcpbis@ietf.org>; Wed, 21 Dec 2016 09:37:58 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E08C6207A1; Wed, 21 Dec 2016 12:37:57 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 21 Dec 2016 12:37:57 -0500
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-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=sp2DDEvf7KrBO6t 9KOmhnFHx0u8=; b=D+5FkAqy9ooXOZnl/Taby4hAoA7MbY7l9ipHJotNRRPNBM2 sGpMyfGiZN0W+dCYdH0hN3Y1sIRRUDUhZVNZhpw9Qz6Q3i4ZC/LkPOXvxeoTMNie 01D38auk8K4WvDB8MTH0QpZKV1vyUliV6muZGC0VFxpjBvuSmPxI4C3y0CJA=
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-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=sp2DDEvf7KrBO6t9KOmhnFHx0u8=; b=s4KuUNjco6cv60CFpiAK uq8MAC+4fDvmq6YyYuOk948Nd2Bzn1da+Jc8ohxNUyOXInEfZZit/s3YLM2IVYVZ IlPOBj1fBc/N82EXhgLj+YVBJw8VbmfGWBiP7zezPYYkOOUJnL3hrYKxn3a7SL0v YaIr0R3FF9NsC0VBmu0MDIk=
X-ME-Sender: <xms:9b1aWNCGA_UhDvPe1ZrrQQGNDYnznOhyT79DESXD8f8QUNh3e9Warw>
X-Sasl-enc: AQczVoofxiyHmn7dtLzbUYGJOcDDwUERsnAmIwCE+cDH 1482341877
Received: from sjc-alcoop-8812.cisco.com (unknown [128.107.241.181]) by mail.messagingengine.com (Postfix) with ESMTPA id 161E7241D1; Wed, 21 Dec 2016 12:37:56 -0500 (EST)
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: <5D387442-4F3E-428E-A7F3-7D503F33E2A6@cisco.com>
Date: Wed, 21 Dec 2016 12:37:55 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <E7D07F87-9853-448F-AA15-7784657B8FCB@cooperw.in>
References: <DDFDCD0B-AD0E-41AF-B6C8-9D29F6B10823@cooperw.in> <A1316C49-E517-49BF-A55A-145976651E63@cisco.com> <83516D34-D1DA-413F-A474-46D2B555C783@cooperw.in> <5D387442-4F3E-428E-A7F3-7D503F33E2A6@cisco.com>
To: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/8Mw-C-s_zS_yK3LUFTRy2_Iv7FY>
Cc: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Subject: Re: [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: Wed, 21 Dec 2016 17:38:00 -0000

> On Dec 21, 2016, at 11:49 AM, Ram Mohan R (rmohanr) <rmohanr@cisco.com> wrote:
> 
>    I will modify the last para of section 1 to below. Will remove some of the text that is not really relevant.
> 
> EXISTING:
>   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.
>   In most cases it is not viable for certificates signed by well known
>   authorities.  Thus, there is a need to indicate the connection URI
>   for the WebSocket Client.  For applications that use Session
>   Description Protocol (SDP) [RFC4566] to negotiate, the connection URI
>   can be indicated by means of an SDP attribute.  This specification
>   defines new SDP attributes to indicate the connection URI for the
>   WebSocket client.  Applications that use SDP for negotiation and
>   WebSocket as a transport protocol can use this specification to
>   advertise the WebSocket client connection URI.
> 
> 
> NEW:
> When WebSocket sub-protocol is used as a transport mechanism between a server and client, 
> there needs to be a way to indicate the connection URI from the Server to the 
> WebSocket Client. For applications that use Session Description Protocol (SDP) [RFC4566] 
> to negotiate, the connection URI can be indicated by means of an SDP attribute.  
> This specification defines new SDP attributes to indicate the connection URI for the
>   WebSocket client.  Applications that use SDP for negotiation and
>   WebSocket as a transport protocol can use this specification to
>   advertise the WebSocket client connection URI.
> 
>    Is this better?

Yes, thanks.
Alissa

> 
>> 
>>   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?)
>> 
>> <Ram> Yes this text was added based on feedback from SDP directorate. I think you have a valid point that the DNS resolution may be taken care at HTTP stack and the procedures in 
>> RFC6555 may be used at that level.   In that case this text may not fit well in here.   Do you want me to remove this from the doc  ?
> 
>> If the text stays in, it needs to be clarified. Or if you think you don’t need it, it can be taken out.
> 
> Yes. Will remove this line.
> 
>> 
>>   = 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?
>> 
>> <Ram> I have not seen many implementations use S/MIME. Most of them use SIP over TLS (even though it may not provide e2e security) in case they need to protect the SIP/SDP
> 
>>   Then I would suggest s/is the natural choice/is available/
> 
> Thanks, will fix it
> 
> Regards,
> Ram
> 
>> Thanks,
>> Alissa
> 
>> 
>> Will take care of the NITS below.
>> 
>> Thanks,
>> Ram
>> 
>>   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/
>> 
>> 
>>   _______________________________________________
>>   bfcpbis mailing list
>>   bfcpbis@ietf.org
>>   https://www.ietf.org/mailman/listinfo/bfcpbis
>> 
>> 
> 
> 
>