Re: [pcp] Ben Campbell's No Objection on draft-ietf-pcp-port-set-12: (with COMMENT)

<mohamed.boucadair@orange.com> Wed, 21 October 2015 06:51 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A891B2B92; Tue, 20 Oct 2015 23:51:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
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 9NAOrf5zD6R4; Tue, 20 Oct 2015 23:51:16 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E561B3610; Tue, 20 Oct 2015 23:51:15 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 45B263B4347; Wed, 21 Oct 2015 08:51:14 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 1B5254C048; Wed, 21 Oct 2015 08:51:14 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0248.002; Wed, 21 Oct 2015 08:51:13 +0200
From: <mohamed.boucadair@orange.com>
To: Ben Campbell <ben@nostrum.com>, The IESG <iesg@ietf.org>
Thread-Topic: Ben Campbell's No Objection on draft-ietf-pcp-port-set-12: (with COMMENT)
Thread-Index: AQHRC3fgpdGSoec5vEa8UQ6vn+IvKJ51fhdQ
Date: Wed, 21 Oct 2015 06:51:13 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933008C84117@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <20151020204235.18192.47356.idtracker@ietfa.amsl.com>
In-Reply-To: <20151020204235.18192.47356.idtracker@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.10.21.44517
Archived-At: <http://mailarchive.ietf.org/arch/msg/pcp/Orp6Sp0qAnj7iuAzp_j1tR325jE>
Cc: "draft-ietf-pcp-port-set@ietf.org" <draft-ietf-pcp-port-set@ietf.org>, "pcp@ietf.org" <pcp@ietf.org>, "rapenno@yahoo.com" <rapenno@yahoo.com>, "pcp-chairs@ietf.org" <pcp-chairs@ietf.org>
Subject: Re: [pcp] Ben Campbell's No Objection on draft-ietf-pcp-port-set-12: (with COMMENT)
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Oct 2015 06:51:18 -0000

Hi Ben,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Ben Campbell [mailto:ben@nostrum.com]
> Envoyé : mardi 20 octobre 2015 22:43
> À : The IESG
> Cc : draft-ietf-pcp-port-set@ietf.org; pcp-chairs@ietf.org;
> rapenno@yahoo.com; pcp@ietf.org
> Objet : Ben Campbell's No Objection on draft-ietf-pcp-port-set-12: (with
> COMMENT)
> 
> Ben Campbell has entered the following ballot position for
> draft-ietf-pcp-port-set-12: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-pcp-port-set/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I have a few minor comments and a question:
> 
> - Section 4:
> 
> How is Port Set Size encoded? (something like unsigned short integer?)

[Med] Updated the text to indicate "A 16-bit unsigned integer.".

> 
> Why might the first internal port  in a response differ from the
> requested internal port? Even if the server could not map the entire
> range, wouldn't the first internal port still be the same?

[Med] This is likely to be the case for most cases, but as indicated in Section 5.2, there may be cases where this is not true. The specification allows for both.

> 
> The statement that the internal and external set sizes will always be the
> same could use some elaboration. I assume this means the set sizes will
> match after mapping, _not_ that the external set size will always match
> the _requested_ set size.

[Med] What about?

OLD:
The two ranges always have the same size (i.e., the Port Set Size returned by the PCP server).

NEW:
The Internal Port Set and the Assigned External Port Set have the same size.

> 
> -4.1:
> 
> should "port preservation" be "parity preservation"?
[Med] Fixed. Thank you for catching this.

 Also, I assume you
> use port parity in terms of even/odd parity. It might be useful to state
> that somewhere.

[Med] Updated as follows: 

OLD: 

"If parity preservation is required, the PCP client MUST set the parity bit (to 1) to ask the PCP server to preserve the port parity."

NEW:

"If parity preservation is required (i.e., an even port to be mapped to an even port, and an odd port to be mapped to an odd port), the PCP client MUST set the parity bit (to 1) to ask the PCP server to preserve the port parity."

> 
> - 4.1: Isn't the statement that PREFER_FAILURE MUST NOT  (which is, btw,
> redundant with the similar statement in section 4) appear a requirement
> on the client rather than the server? Is there some server action
> expected in the (invalid) case that it does?  (Also, you do not merely
> "not recommend" PREFER_FAILURE. You forbid it.)

[Med] Good point. I made the following changes:

* Delete the sentence in Section 4.
* Move the text to the client's behavior section
* Add this third bullet in Section 4.2: "If PREFER_FAILURE option is present, a MALFORMED_OPTION error is returned."

> 
> Editorial Comments:
> =================
> 
> - 4.3, first sentence:
> 
> The word "unconditionally" doesn't seem to be needed. That it, it doesn't
> really change anything.

[Med] Works for me.

> 
> - 6.3, last paragraph:
> 
> Is _intentional_ overlap okay?
> 
> - 7, first sentence:
> 
> There seems to be a missing word in the phrase " In order to prevent a
> PCP client to control ...". Do you mean "prevent... from controlling"? or
> "prevent ... from attempting to control"?
> 

[Med] Changed to "prevent... from controlling".