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

"Ram Mohan R (rmohanr)" <rmohanr@cisco.com> Wed, 21 December 2016 07:01 UTC

Return-Path: <rmohanr@cisco.com>
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 CEECC1297C2 for <bfcpbis@ietfa.amsl.com>; Tue, 20 Dec 2016 23:01:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.622
X-Spam-Level:
X-Spam-Status: No, score=-17.622 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 b5NmB-z7LRye for <bfcpbis@ietfa.amsl.com>; Tue, 20 Dec 2016 23:01:08 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4B31294B3 for <bfcpbis@ietf.org>; Tue, 20 Dec 2016 22:51:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4738; q=dns/txt; s=iport; t=1482303078; x=1483512678; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+H8DAfh7Em1ENJUNZKKRKWYmJ9NPmBHhBqUwKgPaDXs=; b=UNavAUEB2e14n53v3wzOvgi+nS7CB7Voqn5GMAgVNSxE2rKzQxFQq/oS /Baw7PQgsTNcja1ZqbiKcyNOsh3xMa/Gp+39hD2Q2l+nOWchTCT9WThVQ Apoe0shGCr7wOSxy2Kw11lMi5wPcb5u0mTB1VDSokEuLiuYUcDyDdv5y9 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AVAQD9JVpY/5tdJa1dGQEBAQEBAQEBAQEBBwEBAQEBgzYBAQEBAR9agQYHjUmWWZUOggofC4UuSgIagVI/FAECAQEBAQEBAWIohGgBAQEEAQEQEREzBxcEAgEIEQMBAgMCJgICAiULFQgIAgQBEiKISQ6ZdAGNdoIoixMBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhyiCXIQqHTOCSi2CMAWPAYtvAZEzgXSFA4lWjhqEDgEfN4EmLA8BhUpyh3qBDQEBAQ
X-IronPort-AV: E=Sophos;i="5.33,382,1477958400"; d="scan'208";a="175352186"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Dec 2016 06:51:01 +0000
Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uBL6p0Yh015463 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Dec 2016 06:51:01 GMT
Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 21 Dec 2016 01:51:00 -0500
Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1210.000; Wed, 21 Dec 2016 01:51:00 -0500
From: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
To: Alissa Cooper <alissa@cooperw.in>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Thread-Topic: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-sdp-ws-uri-06
Thread-Index: AQHSUlPULEivK+h/zEa27ao50+0e5qESuIoA
Date: Wed, 21 Dec 2016 06:51:00 +0000
Message-ID: <A1316C49-E517-49BF-A55A-145976651E63@cisco.com>
References: <DDFDCD0B-AD0E-41AF-B6C8-9D29F6B10823@cooperw.in>
In-Reply-To: <DDFDCD0B-AD0E-41AF-B6C8-9D29F6B10823@cooperw.in>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1a.0.160910
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.196.92.37]
Content-Type: text/plain; charset="utf-8"
Content-ID: <026726A5FBA2234985F2961D59112D66@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/E36TbU-zi0IkRe8iDhUfKt8EFZo>
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 07:01:10 -0000

Hi Alissa,

Thanks for your feedback. Please see inline

-----Original Message-----
From: bfcpbis <bfcpbis-bounces@ietf.org> on behalf of Alissa Cooper <alissa@cooperw.in>
Date: Saturday, 10 December 2016 at 1:08 AM
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Subject: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-sdp-ws-uri-06

    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."

<Ram> This text was added to indicate that it is not always possible to get the 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?)

<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  ?
    
    = 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
    
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