Port Control Protocol (PCP) Extension for Port-Set Allocation
draft-ietf-pcp-port-set-13

Just one question about Port Set Size = 1:

In Section 4.1:

   A PCP client MUST NOT send a PORT_SET option for single-port PCP MAP
   requests (including creation, renewal, and deletion).

...but earlier, in Section 4:

   Port Set Size:  Number of ports requested.  MUST NOT be zero.

Should the Port Set Size definition instead say "MUST be greater than 1.", given what 4.1 says?

...and in Section 4.2:

   o  If the Port Set Size is zero, a MALFORMED_OPTION error is
      returned.

What happens if Port Set Size is 1?  This seems to answer that:

   SHOULD map at least one
   port (which is the same behavior as if Port Set Size is set to 1).

...but how is that allowed, given what Section 4.1 says?

I have a few minor comments and a question:

- Section 4:

How is Port Set Size encoded? (something like unsigned short 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?

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.

-4.1:

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

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

Editorial Comments:
=================

- 4.3, first sentence:

The word "unconditionally" doesn't seem to be needed. That it, it doesn't really change anything.

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

- section 4, last sentence: I didn't get why this MUST NOT was
needed. I've no clue if it'd be obvious to a PCP implementer
or not though. 4.2 does say though, maybe consider moving the
note up?

- 4.1: size == 0xffff has gotta be operationally dangerous,
I'm surprised you don't have a bunch of caveats on it's use.
Shouldn't you have at least some guidance in 4.2 for that as
well? 6.1 and section 7 cover this though I guess. 

- 4.2: Is there a possible troublesome case where the client
asks for parity and gets that but gets fewer ports than
requested? E.g. if client wants 6 with parity and only gets 5,
then the client might not be able to use that as it really
needs 3 pairs of ports. Did you consider saying that a server
has to return an even number of ports if parity is requested?
(Or would that make sense?, I'm not sure:-)