Re: Review of draft-ietf-bfcpbis-sdp-ws-uri-07

"Ram Mohan R (rmohanr)" <rmohanr@cisco.com> Tue, 03 January 2017 08:36 UTC

Return-Path: <rmohanr@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11C6129429; Tue, 3 Jan 2017 00:36:23 -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=ham 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 xb5g0kR5VQAj; Tue, 3 Jan 2017 00:36:21 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 723AA129417; Tue, 3 Jan 2017 00:36:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5452; q=dns/txt; s=iport; t=1483432581; x=1484642181; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7SESjH3wsvAkoiRIZgvshoHz4Mjb/Kbhs4n+62nxJS0=; b=T7hzuv7hQwkDCDsr4+vFcTD5tg0zsHEfyvYEmzmoiDtnzObV58QLVQcU ODW8VuhAgJ2c8bDmDkTrrfn3ND4ry9vy7ugwE2NefT9gd9Oe/T0JX4wpc f6CruIla89kcjVfV02u4S9UW3QNEvQKTtsDInRHZ7cjFlkguIm4bfMIUj I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQADYmtY/5RdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAR9fgQwHjVCURZUbgggqhXgCGoFFPxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRoAQEBBCMRRQwEAgEIDgMDAQIDAiYCAgIwFQgIAgQBDQWIcA6vAoIlijsBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhzwIgleERgcxAoJKLYIwBZp9AYZTimq?= =?us-ascii?q?BdYUIiViOLoQOAR84gSo8AYVOcocxgQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.33,451,1477958400"; d="scan'208";a="367976232"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jan 2017 08:36:20 +0000
Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v038aKlf021599 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 Jan 2017 08:36:20 GMT
Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 3 Jan 2017 03:36:19 -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; Tue, 3 Jan 2017 03:36:19 -0500
From: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
To: Joel Halpern <jmh@joelhalpern.com>, "gen-art@ietf.org" <gen-art@ietf.org>
Subject: Re: Review of draft-ietf-bfcpbis-sdp-ws-uri-07
Thread-Topic: Review of draft-ietf-bfcpbis-sdp-ws-uri-07
Thread-Index: AQHSXXJ3pLtQUw9UTkO4OUC5WRZooqEnLgaA
Date: Tue, 3 Jan 2017 08:36:19 +0000
Message-ID: <571231A9-2757-4B86-BC65-2491B6B7F882@cisco.com>
References: <148253493203.16856.4857620752315294427.idtracker@ietfa.amsl.com>
In-Reply-To: <148253493203.16856.4857620752315294427.idtracker@ietfa.amsl.com>
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.60]
Content-Type: text/plain; charset="utf-8"
Content-ID: <7F215CA95AFAD948AA31E78DBCFD7D78@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/MjKGOMBlUu9rb49wkRz73nZsVTc>
Cc: "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-bfcpbis-sdp-ws-uri.all@ietf.org" <draft-ietf-bfcpbis-sdp-ws-uri.all@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jan 2017 08:36:24 -0000

Hi Joel,

Thanks for your response. Please see inline

-----Original Message-----
From: Joel Halpern <jmh@joelhalpern.com>;
Date: Saturday, 24 December 2016 at 4:45 AM
To: "gen-art@ietf.org"; <gen-art@ietf.org>;
Cc: "bfcpbis@ietf.org"; <bfcpbis@ietf.org>;, "ietf@ietf.org"; <ietf@ietf.org>;, "draft-ietf-bfcpbis-sdp-ws-uri.all@ietf.org"; <draft-ietf-bfcpbis-sdp-ws-uri.all@ietf.org>;
Subject: Review of draft-ietf-bfcpbis-sdp-ws-uri-07
Resent-From: <alias-bounces@ietf.org>;
Resent-To: <rmohanr@cisco.com>;, <gsalguei@cisco.com>;, <keith.drage@alcatel-lucent.com>;, <eckelcu@cisco.com>;, <ben@nostrum.com>;, <alissa@cooperw.in>;, <aamelnikov@fastmail.fm>;, Charles Eckel <eckelcu@cisco.com>;
Resent-Date: Saturday, 24 December 2016 at 4:45 AM

    Reviewer: Joel Halpern
    Review result: Ready with Nits
    
    I am the assigned Gen-ART reviewer for this draft. The General Area
    Review Team (Gen-ART) reviews all IETF documents being processed
    by the IESG for the IETF Chair.  Please treat these comments just
    like any other last call comments.
    
    For more information, please see the FAQ at
    
    <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;.
    
    Document: draft-ietf-bfcpbis-sdp-ws-uri-??
    Reviewer: Joel Halpern
    Review Date: 2016-12-23
    IETF LC End Date: 2017-01-12
    IESG Telechat date: 2017-01-19
    
    Summary: This document is ready for publication as a Proposed Standard
    RFC.  I have a few minor comments that should be considered s they may
    improve future understanding of the document.
    
    Major issues: None
    
    Minor issues:
        In reading section 4.2 and 4.3, I believe I can guess at certain
    intended behaviors, but it is not as clearly stated as I think is
    desirable.  There is also one odd statement in section 4.3
    
        Taking the odd statement first, the text in section 4.3 refers the
    active answerer "towards
       the IP address and port of the offerer".  But when WebSockets is
    used, one does not connect to the IP address and port, but to the URI
    specified.

<Ram> I will replace the text as below:

EXISTING:
Towards the IP address and port of the offerer using the procedures described
   in [RFC6455]
    
NEW:
Towards the URI specified in a=ws-uri or a=wss-uri attribute using procedures described 
   in [RFC6455]

        I believe that the intent in 4.2 and 4.3 is that whichever side
    will be "passive" is required to provide an a=ws-uri or a=wss-uri so
    that the other side can establish the connection to the URI.  But
    section 4.2 does not say that. 

<Ram>
EXISTING:
   The offerer SHOULD assign the SDP "setup" attribute with a value of
   "active" (the offerer will be the initiator of the outgoing TCP
   connection), unless the offerer insists on being a receiver of an
   incoming connection, in which case the offerer SHOULD use a value of
   "passive".  The offerer MUST NOT assign an SDP "setup" attribute with
   a "holdconn" value.

NEW:
   The offerer SHOULD assign the SDP "setup" attribute with a value of
   "active" (the offerer will be the initiator of the outgoing TCP
   connection), unless the offerer insists on being a receiver of an
   incoming connection, in which case the offerer SHOULD use a value of
   "passive".  The offerer MUST NOT assign an SDP "setup" attribute with
   a "holdconn" value. If the “setup” attribute has a value “passive” it MUST also
have URI in the a=ws-uri or a=wss-uri attribute.

 And the text in section4.3 that talks
    about providing the URI in the a= does not qualify whether it is
    required with active, passive, or both.  

<Ram>
NEW:
If the answers assigns SDP “setup” attribute with “passive”, then it MUST have URI in either 
a=ws-uri or a=wss-uri attribute.

Does this look good and makes it more clear ?

Regards,
Ram
    
    Nits/editorial comments:  N/A