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

From: <[email-masked]>
Date: Wed, 21 Oct 2015 06:51:13 +0000

Hi Ben,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Ben Campbell [mailto:[email-masked]]
> Envoyé : mardi 20 octobre 2015 22:43
> À : The IESG
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> 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".

---

From: <[email-masked]>
Date: Fri, 23 Oct 2015 05:45:02 +0000

Hi Ben,

Please see inline.

Cheers,
Med

> Envoyé : vendredi 23 octobre 2015 00:59
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : The IESG; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Objet : Re: Ben Campbell's No Objection on draft-ietf-pcp-port-set-12:
> (with COMMENT)
> 
> Hi, thanks for the response. Comments inline. I removed sections that do
> not seem to need further discussion.
> 
> On 21 Oct 2015, at 1:51, [email-masked] wrote:
> 
> [...]
> 
> [...]
> > [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.
> 
> Ah, I see. I wasn't thinking about the discovery case.
> 
> >
> >>
> I think the issue goes back to the first sentence of the paragraph,
> which is not clear whether we are talking about the Internal Port Set as
> requested, or as actually mapped.
> 
> How about something like:
> 
> OLD:
> The Internal Port Set is defined as being the range of Port Set Size
>     ports starting from the First Internal Port.  The External Port Set
>     is respectively defined as being the range of Port Set Size ports
>     starting from the Assigned External Port.  The two ranges always
> have
>     the same size (i.e., the Port Set Size returned by the PCP server).
> NEW:
> The Internal Port Set is defined as being the range of Port Set Size
>     ports starting from the Internal Port

[Med] The internal port set starts from the "First Intenal Port".

 returned
>     by the PCP server.

[Med] I'm not OK with this mention because the definition is used in the document for both request and response. 

 Similarly, the External Port Set
>     is is the range of Port Set Size ports
>     starting from the Assigned External Port.  The two ranges always
> have
>     the same size.
> 
> [...]

[Med] In order to make it clear the sentence is about a response I updated the text to:

"The Internal Port Set returned in a response and the Assigned External Port Set have the same size."

> > "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."
> 
> I think that's helpful--but I also just noticed you have a reference to
> 4787 to explain this in section 4.
> 
> [...]