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

[<[e-mail]>]

Hi Ben,

Please see inline.

Cheers,
Med

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