Skip to main content

Port Control Protocol (PCP) Extension for Port-Set Allocation
RFC 7753

Yes

(Brian Haberman)

No Objection

Alvaro Retana
(Alia Atlas)
(Benoît Claise)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Martin Stiemerling)
(Spencer Dawkins)
(Terry Manderson)

Note: This ballot was opened for revision 11 and is now closed.

Alvaro Retana No Objection

(Brian Haberman; former steering group member) Yes

Yes (for -11)

                            

(Alia Atlas; former steering group member) No Objection

No Objection (for -12)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (2015-10-20 for -12)
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?

(Ben Campbell; former steering group member) No Objection

No Objection (2015-10-20 for -12)
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"?

(Benoît Claise; former steering group member) No Objection

No Objection (for -12)

                            

(Deborah Brungard; former steering group member) No Objection

No Objection (for -12)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -12)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -12)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (for -12)

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -12)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -11)

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2015-10-22 for -12)
- 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:-)

(Terry Manderson; former steering group member) No Objection

No Objection (for -12)