Port Control Protocol (PCP) Extension for Port-Set Allocation
RFC 7753
Yes
No Objection
Note: This ballot was opened for revision 11 and is now closed.
Alvaro Retana No Objection
(Brian Haberman; former steering group member) Yes
(Alia Atlas; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
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
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
(Deborah Brungard; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
- 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