Port Control Protocol (PCP)
draft-ietf-pcp-base-29

Document was returned to IESG state while issue raised by Sam Hartman was addressed.  Sam pointed out what he considered to be a vulnerability introduced into the protocol by a change (see http://www.ietf.org/mail-archive/web/pcp/current/msg02401.html)

The document was returned to "IESG" state temporarily while the IESG reviewed the issue

Stephen, Sean and Ralph discussed the issue and concluded that Sam needs to show a more concrete case before the vulnerability needs to be addressed.  Stephen will work with Smam to determine if the vulnerability can be shown to be realistic.  Meanwhile, the document has gone back to the RFC Editor.

[Ballot comment]
I am still convinced that the notion of "subscriber" is unnecessary for this protocol and should be removed. It is sufficient to talk about per-host limits and quotas to explain the concepts that are there and then the document will not have to talk about the mapping of a business model onto the protocol.

I am still convinced that sections 11-13 should move earlier in the document so that you can get the definitions of the opcodes done early and then you can refer to them. I understand that you want to use MAP and PEER throughout the earlier sections because people couldn't track the difference between static and dynamic, but if you're going to do that, you should move the sections up.

That said, I don't think you have to use the opcodes earlier in the document, especially in the definitions. For instance:

Section 3:

Please define "Peering" in this section.

In the bit on "Third Party", don't mention "THIRD_PARTY Option" or "MAP request" here; they are undefined, and they're not needed. Instead, change to:

      In the case where one device is managing Mappings on behalf of
      some other device that does not implement PCP, this protocol
      supports the ability of a Third Party to supply a specific
      address as the Internet Address for a Mapping, rather than the
      PCP server inferring the Internal Address from the source IP
      address of the PCP request.

Where you say:

      *  Explicit dynamic mappings are created as a result of explicit
        PCP MAP and PEER requests.

You could instead say:

      *  Explicit dynamic mappings are created as a result of explicit
        PCP protocol Mapping or Peering requests.  Like a DHCP address
        lease, explicit...

Section 7.3

  PCP clients are free to ignore any or all Options included in
  responses, although naturally if a client explicitly requests an
  Option where correct execution of that Option requires processing the
  Option data in the response, that client is expected to implement
  code to do that.

Clients aren't just *free* to ignore Options they don't understand in responses; they ought to (MUST?) ignore such things. The above paragraph doesn't say that.

Section 14:

  There are two mechanisms to perform rapid recovery, described below.
  A PCP server that can lose state (e.g., due to reboot) or might have
  a mapping change (e.g., due to IP renumbering) MUST implement either
  the Announce Opcode or the Mapping Update mechanism and SHOULD
  implement both mechanisms.  Failing to implement and deploy a rapid
  recovery mechanism will encourage application developers to feel the
  need to refresh their PCP state more frequently than necessary,
  causing more network traffic.

Please just swap the last two sentences. I think it makes it clearer.

[Ballot discuss]
I understand the design philosophy now with section 6. There is only one thing that remains a concern to me, and if it is the consensus of the group that I am wrong on this, I will consider myself "in the rough" and remove this DISCUSSion item:

Section 14:

  There are two mechanisms to perform rapid recovery, described below.
  PCP servers SHOULD implement both mechanisms.

I think PCP servers MUST implement the ANNOUNCE Opcode and MUST send it unsolicited upon reboot, either to the link-scoped multicast, to pre-configured unicast addresses, OR TO THE BROADCAST ADDRESS IF NEITHER OF THE ABOVE IS AVAILABLE.

I say this because if you do not provide this explicitly, PCP clients who are providing application services (i.e., TCP or UDP listening as servers) *will* be implemented to re-request their mappings long before their lifetime expiration, likely on the order of a few minutes, as a keep-alive. If you are running a server and you have no reasonable likelihood of knowing whether you'll get a best-effort notification that your mappings have disappeared, a keep-alive is your only reasonable option. This would be a terrible result, with lots of unnecessary increased traffic. If I can at least trust that a conformant server will send a best-effort UDP message indicating a reboot, I (as a client writer) am much more comfortable allowing for the possibility of a reboot and will not insist on sending the keep-alive.

I believe this has to be a requirement for PCP servers in order to assure that clients will not do bad things.

Again, if you address this item and tell me I am in the rough, I'll drop this DISCUSS.

[Ballot comment]
I am still convinced that the notion of "subscriber" is unnecessary for this protocol and should be removed. It is sufficient to talk about per-host limits and quotas to explain the concepts that are there and then the document will not have to talk about the mapping of a business model onto the protocol.

I am still convinced that sections 11-13 should move earlier in the document so that you can get the definitions of the opcodes done early and then you can refer to them. I understand that you want to use MAP and PEER throughout the earlier sections because people couldn't track the difference between static and dynamic, but if you're going to do that, you should move the sections up.

That said, I don't think you have to use the opcodes earlier in the document, especially in the definitions. For instance:

Section 3:

Please define "Peering" and "Mapping" in this section. Those definitions are missing.

In the bit on "Third Party", don't mention "THIRD_PARTY Option" or "MAP request" here; they are undefined, and they're not needed. Instead, change to:

      In the case where one device is managing Mappings on behalf of
      some other device that does not implement PCP, this protocol
      supports the ability of a Third Party to supply a specific
      address as the Internet Address for a Mapping, rather than the
      PCP server inferring the Internal Address from the source IP
      address of the PCP request.

Where you say:

      *  Explicit dynamic mappings are created as a result of explicit
        PCP MAP and PEER requests.

You could instead say:

      *  Explicit dynamic mappings are created as a result of explicit
        PCP protocol Mapping or Peering requests.  Like a DHCP address
        lease, explicit...

Section 7:

  All PCP messages are sent over UDP, with a maximum length of 1024
  bytes.

What 1024-byte size limit?

Section 7.3

  PCP clients are free to ignore any or all Options included in
  responses, although naturally if a client explicitly requests an
  Option where correct execution of that Option requires processing the
  Option data in the response, that client is expected to implement
  code to do that.

I cannot figure out what the above is trying to accomplish that is non-obvious. Is there some case where this makes some sort of interoperability difference? How could you tell if the client actually ignored it or processed it?

[Ballot comment]

I've cleared my discuss since the THIRD_PARTY feature is now
constrained as discussed. However, I still feel that section 17 could
do with some substantive editorial work. But since that's editorial
work, I've made this a comment. I hope that the authors will
try to take this into account. The suggested edits below are based
on version-25 but I think still apply for -26.

I think that sections 17.1 and 17.2 are still all wrapped around one
another and more work is needed.

I *think* that's editorial work mainly, but I just can't tell from
reading it for sure. I'd start by moving any "meta" text such as chunk
"A" below into a bit of introductory text, and by breaking complex
conditions such as chunk "B" below into bullet lists so that e.g. its
clear what's a conjunction and what's a disjunction.

17.1.2 is now wrong since it has only 1 example and the sub-structure
doesn't seem worth it.

There is still a mention of, but no reference to, "a PCP security
mechanism" that "would need to be specified" - I'd say what's needed
there is an informative ref to the I-D for the security mechanism and
to say that if the advanced threat model applies then you need to
implement that spec or an equivalent or else you're not safe.

There's also "meta" text in 17.2 that probably ought be moved - that's
chunk "C" below.

And I've made a suggestion for a way this might all be restructured
which is just after chunks A-C.

Chunk A:
  PCP Servers that comply with the Simple Threat Model and do not
  implement a PCP security mechanism described in Section 17.2 MUST
  enforce the constraints described in the paragraph above.

That chunk is at the end of 17.1 before 17.1.1 so its not clear if
"Simple Threat Model" means only 17.1 text before this or all of 17.1
or not.

Chunk B:
  A PCP Server is secure under this threat model if the PCP Server is
  constrained so that it does not configure any explicit mapping that
  it would not configure implicitly.  In most cases, this means that
  PCP Servers running on NAT boxes or stateful firewalls that support
  the PEER Opcode can be secure under this threat model if all of
their
  hosts are within a single administrative domain (or if the internal
  hosts can be securely partitioned into separate administrative
  domains, as in the DS-Lite B4 case), explicit mappings are created
  with the same lifetime as implicit mappings, the PCP server does not
  support deleting or reducing the lifetime of existing mappings, and
  the PCP server does not support the third party option.  PCP Servers
  can also securely support the MAP Opcode under this threat model if
  the security policy on the device running the PCP Server would
permit
  endpoint independent filtering of implicit mappings.

Parsing chunk B is too hard IMO if you're trying to figure out what to
implement, or trying to compare it the simple and advanced threat
models to try figure what's safe and what's not.

Chunk C:
  PCP Servers implementing the PCP security
  mechanism MUST enforce the constraints described in Section 17.1
  above, in their default configuration, when processing
  unauthenticated requests.

That seems generic. I don't get why it only applies in the "advanced"
threat model.

Here's my suggestion for a new way to lay all that out:

17 - intro text
17.1 - attacks considered (current 17.1.1)
17.2 - threat models - text chunks A & C here
17.2.1 - simple threat model - chunk B here as bullets
17.2.2 - advanced threat model
17.3 - residual threats (17.3)

Finally, a new comment (not discuss point) I'd make:

17.1 has added the claim that: "PCP is secure against off-path
attackers who can spoof the PCP server's IP address." That's a bit too
terse, can you explain what's meant by "secure against"
there? I suspect the claim would be ok if it were a bit more precise.

[Ballot discuss]
#1 3rd party thing and authorization. I don't get the justification
for why its ok to leave authentication up to implementers? How would
a client know what to do to become "properly authorized"? I also
don't think not defining any cryptographic protection is obviously
correct here esp.  for PCP servers operated by ISPs (while at the
same time not wanted for foist crypto that won't get used on a
protocol.) Is the 3rd party thing really needed in the base protocol
or would that not be better in a separate document where additional
security could be defined as needed?

#2 The last para of 16.1 says "do the 2nd last para of 16.1 unless
you implement 16.2" but I 16.2 doesn't specify anything that can be
implemented, except where it points at 16.1;-) That's a bit of a
mess. Again, I think moving the stuff (mainly 3rd party) that needs
more security elsewhere seems right.

#3 cleared

[Ballot discuss]
1. cleared.

2. As understand the specification, one of the key points on which
client and server behavior is based is that there is a one-to-one
mapping between internal and external address/protocol/port triples.
Clients and servers use this property to identify the mappings
referred to in PCP messages.  If I have that right, it might be
helpful to mention the assumption explicitly - unless it's absolutely
obvious to everyone else in the world.

I want to check that a mapping is identified by a triple  and that just  is insufficient.  If I
have that right, there are several places in the specification where a
mapping is said to be identified by  and those parts of
the specification need to be corrected.

For example, should this text from section 10.3:

  It is possible that a mapping might already exist for a requested
  Internal Address and Port.

read "Internal Address, Protocol and Port"?

(Note: I think there are still 3 occurrences of "internal address and port".)

3. cleared.

4. cleared.

5. I'm confused about the port usage as specified in section 13.1.
This text in section 13.1.1 seems to specify using different ports
depending on the direction of the Restart message:

    Discussion: A separate port is used for server-to-client Restart
    Announcements (5350) than client-to-server requests (5351)

but this text in 13.1.2 seems to specify different ports for unicast
and multicast:

When sending unsolicited unicast ANNOUNCE
responses, they are sent to port 5351.  When sending unsolicited
multicast ANNOUNCE responses, they are sent to port 5350

These two text snippets appear to be in conflict.

(Note that this Discuss point will be cleared in -25.)

6. cleared.

[Ballot comment]
1. cleared.

2. cleared.

3. cleared.

4. I think section 7.4 needs editing for clarification, in light of
"single-homed" assumption.  As I read it, it mashes together multiple
interfaces on different links with multiple addresses on one
interface.

5. cleared.

[Ballot discuss]
[I am updating simply to remove things that have been addressed. However, though the new section 6 explains the design motivation, it invites a list of other questions that I still wish to DISCUSS. I will leave the text of my DISCUSS on this topic the same, but I will update it soon.]

Section 6:

I believe there's a missing bit of functionality in this protocol to pull off idempotency: Let's say I send a request that results in an error condition, and the error response is sent back but it is delayed. I'm an aggressive client, so I send another request. That one succeeds. Now I get back the error response. Or I get the success response first, and then finally the error response comes back. How do I know which request succeeded and which one failed? Do I have to check the Epoch Time to put them in order and assume that none of the responses were lost? A serial or sequence number in the request that is turned around in the response would solve this problem. Am I missing something?

[Ballot comment]
The notion of "subscriber" is unnecessary for this protocol and should be removed. It is sufficient to talk about per-host limits and quotas to explain the concepts that are there and then the document will not have to talk about the mapping of a business model onto the protocol.

All of the forward references in this document make it somewhat confusing, and I suspect longer than it needs to be. I don't see why sections 11-13 can't be moved earlier in the document.

Section 3:

      *  Explicit dynamic mappings are created as a result of explicit
        PCP MAP and PEER requests.

MAP and PEER are not defined yet. You could define the actions of mapping and peering and then use the verbs instead of the OPCODEs here. These appear elsewhere in the document without being defined.

Section 7:

  All PCP messages are sent over UDP, with a maximum length of 1024
  bytes.

What 1024-byte size limit? This is the first mention in the document.

Section 7.3

  PCP clients are free to ignore any or all Options included in
  responses, although naturally if a client explicitly requests an
  Option where correct execution of that Option requires processing the
  Option data in the response, that client is expected to implement
  code to do that.

I cannot figure out what the above is trying to accomplish that is non-obvious. Is there some case where this makes some sort of interoperability difference? How could you tell if the client actually ignored it or processed it?

Section 8:

  PCP messages MUST be sent over UDP [RFC0768].

It seems to me that ICMP might be the correct choice instead of UDP, but I understand I may be blowing into the wind.

Section 11.2:

  If the client wants all protocols mapped it uses Protocol 0 (zero)
  and Internal Port 0 (zero).

I don't understand how this will work. If I am a client that says "Protocol 0, Internal Port 0", haven't I just taken over the entire external address from the NAT, and therefore nobody else connected to that NAT can use PCP?

[Ballot discuss]
1. This point addresses the scope of PCP and should be easily
addressed with some additional text.  I think it's important to have a
brief discussion about this scoping issue first.  Section 4 includes
this text:

  It is also possible for the PCP functionality
  to be provided by some other device, which communicates with the
  actual NAT or firewall via some other proprietary mechanism, as long
  as from the PCP client's perspective such split operation is
  indistinguishable from the integrated case.

There is no explicit requirement here that there be a one-to-one
relationship between the "other device" providing the PCP
functionality and the actual NAT or firewall.  Is such a requirement
intended or could one other device control multiple NATs and/or
firewalls to solve the multi-homing problem.

2. As understand the specification, one of the key points on which
client and server behavior is based is that there is a one-to-one
mapping between internal and external address/protocol/port triples.
Clients and servers use this property to identify the mappings
referred to in PCP messages.  If I have that right, it might be
helpful to mention the assumption explicitly - unless it's absolutely
obvious to everyone else in the world.

I want to check that a mapping is identified by a triple  and that just  is insufficient.  If I
have that right, there are several places in the specification where a
mapping is said to be identified by  and those parts of
the specification need to be corrected.

For example, should this text from section 10.3:

  It is possible that a mapping might already exist for a requested
  Internal Address and Port.

read "Internal Address, Protocol and Port"?

3. I think this point is clarified later in the description of the
generation of responses, but I raise it as a Discuss because the
intention is not clear to me.

In this text from section 6.1:

  Reserved:  96 reserved bits.  For requests that were successfully
      parsed, this MUST be sent as 0, MUST be ignored when received.
      This is set by the server.  For requests that were not
      successfully parsed, the server blindly copies the 96 bits from
      the request message into a response.

It's not clear to me what 96 bits from the request are copied into
these reserved bits in the response.  And what does "blindly" mean?

Related to the above (which may be more an editorial comment than a
Discuss), this text in section 6.3 was confusing to me.  I read it at
first to mean a copy of the request message was carried as a payload;
elsewhere in the specification, I think I read that the response is
generated by starting with a copy of the request message and then
modifying some of the fields.

  The response MUST consist of a complete copy of the
  request packet with the error code and other appropriate fields set
  in the header.

4. To be clear about this text from section 7.3, this text means the
client must be prepared to receive asynchronous messages from the
server that apply to some state previously requested by the client?

  A PCP client SHOULD be
  prepared to receive multiple responses from the PCP Server at any
  time after a single request is sent.  This allows the PCP server to
  inform the client of mapping changes such as an update or deletion.
  For example, a PCP Server might send a SUCCESS response and, after a
  configuration change on the PCP Server, later send a NOT_AUTHORIZED
  response.

Taken at face value, I would assume that a client needs to keep copies
of all of its request messages so it could map the responses to those
requests.  Is it enough that the results of the request are encoded in
some mapping state in the client that subsequent responses can then
modify?

While I'm not inclined to require alternative behavior every "SHOULD"
in a specification, this example seems important.  What should a
client do if it is not prepared to receive multiple responses?

5. I'm confused about the port usage as specified in section 13.1.
This text in section 13.1.1 seems to specify using different ports
depending on the direction of the Restart message:

      Discussion: A separate port is used for server-to-client Restart
      Announcements (5350) than client-to-server requests (5351)

(BTW, is Restart Announcement == ANNOUNCE?)

but this text in 13.1.2 seems to specify different ports for unicast
and multicast:

  When sending unsolicited unicast ANNOUNCE
  responses, they are sent to port 5351.  When sending unsolicited
  multicast ANNOUNCE responses, they are sent to port 5350

These two text snippets appear to be in conflict.

6. Use of link-scoped multicast for ANNOUNCE: is there an assumption
elsewhere that clients and servers are all on the same link?

[Ballot comment]
1. From section 6.1:

  Requested Lifetime:  An unsigned 32-bit integer, in seconds, ranging
      from 0 to 2^32-1 seconds.  This is used by the MAP and PEER
      Opcodes defined in this document for their requested lifetime.
      Future Opcodes which don't need this field MUST set the field to
      zero on transmission and ignored on reception.

Won't the specifications for future opcodes be responsible for the
details of specifying how the Requested Lifetime field is used?

2. From section 6.3:

  If the PCP server
  encounters an invalid option (e.g., option length extends beyond the
  length of the PCP Opcode itself),

What, exactly, does "option length extends beyond the length of the
PCP Opcode itself" mean?

3. In section 7.3: Does "(limited) value"? == "duration of the lifetime"?

4. I think section 7.4 needs editing for clarification, in light of
"single-homed" assumption.  As I read it, it mashes together multiple
interfaces on different links with multiple addresses on one
interface.

5. In section 9.2, is there a citation available for the definitions
of EIM and EDM?

[Ballot discuss]
#1 3rd party thing and authorization. I don't get the justification
for why its ok to leave authentication up to implementers? How would
a client know what to do to become "properly authorized"? I also
don't think not defining any cryptographic protection is obviously
correct here esp.  for PCP servers operated by ISPs (while at the
same time not wanted for foist crypto that won't get used on a
protocol.) Is the 3rd party thing really needed in the base protocol
or would that not be better in a separate document where additional
security could be defined as needed?

#2 The last para of 16.1 says "do the 2nd last para of 16.1 unless
you implement 16.2" but I 16.2 doesn't specify anything that can be
implemented, except where it points at 16.1;-) That's a bit of a
mess. Again, I think moving the stuff (mainly 3rd party) that needs
more security elsewhere seems right.

#3 The text on p22 about creating the error response doesn't say
what to do with the client IP address field in the request and
"possibly updating...if appropriate" is too vague as well.

[Ballot comment]
- I agree with the many discusses about the lack of a transaction
ID, the current scheme is not great and seems brittle.

- I agree with Russ' and Robert's discuss about spoofed ANNOUNCE.

- I guess I wonder what'd happen if I bring my laptop with a PCP
client into the office. Do you need to RECOMMEND something there,
e.g. that clients can be configured to use PCP only with some
networks or something?

- p16 - where's the 1024 byte limit specified? mentioned here but
not yet stated. p22 says it can be bigger

- encoding rule for clients allowing any order is bad for any crypto
- is it needed? maybe add a SHOULD to put fields in order input to
any crypto processing to make life easier for all (and allowing >1
instance of an option means that verifiers need to do c14n which is
a PITA)

- result code 10 has the concept of a user - where is that defined?
is it an IP address? that needs fixing probably

- you should explain on p13 why the client IP address field is
included I think (its on p23 now)

- what if I ask to control the UDP port used by the PCP server for
PCP requests?  You might want a MUST NOT for that and possibly other
well-known ports?

- section 7 - is that really idempotent? I think maybe you mean it
is if all goes well, but not always

- section 7.1 - should you tell the reader that they ought to stop
retrying if the client UI indicates that? "still desires" is a bit
vague and could be misinterpreted maybe

- 7.2: "MUST only accept normal (non-THIRD_PARTY)" is not great -
better to say what MUST NOT be done IMO

- 7.3 running over UDP a server could send SUCCESS and then
NOT_AUTHORIZED and those could arrive out of order, where's the
warning about that? a sequence number would help here

- 11.1 - what if the remote peer comes in to me from many different
or random ports?

- What prevents a combination of the 3rd party and filter options
from allowing me to put someone else off the network?

- 17.4 - the optional/mandatory to process numbering of options
should be explained in the body of the text and not just here (or
did I miss it?)

[Ballot comment]
Other reviewers have provided significant input. I have a few additional comments.

In Section 7.5, is the recommendation about 6.25% clock skew based on empirical evidence?

In Section 8 (bullet 6), why would the client expect that the server might support its old version after 30 minutes?

[Ballot comment]
In Section 7.5, is the recommendation about 6.25% clock skew based on empirical evidence?

In Section 8 (bullet 6), why would the client expect that the server might support its old version after 30 minutes?

[Ballot comment]
I find all of the references to the "interworking function" from UPnP to be inappropriate in this document and should be removed. This is specific implementation advice for a specific environment, not protocol and not required for interoperability. I think it weakens the protocol specification and could have bad effects down the road. (Cf. IMAP, where specific accomodation of implmentation semantics led to all sorts of interoperability failures.) I think having a separate document with specifics of how to do PCP for UPnP is fine, but it shouldn't be in this document.

The notion of "subscriber" is unnecessary for this protocol and should be removed. It is sufficient to talk about per-host limits and quotas to explain the concepts that are there and then the document will not have to talk about the mapping of a business model onto the protocol.

All of the forward references in this document make it somewhat confusing, and I suspect longer than it needs to be. I don't see why sections 10-12 can't be moved earlier in the document.

Section 3:

PCP Client definition. I don't find the parenthetical bit about several web browsers useful; readers will confuse multiple instances of the same browser with multiple browsers and the message will be muddied. Not only that, anyone who will be coding this is well aware that multiple applications can run on a single host. I found myself wondering what the note was trying to get at. I also found the reference to UPnP not terribly helpful. I would strike it and simplify this description.

PCP Server definition is circular. Better would be: "A PCP software instance that resides on the NAT or Firewall that receives PCP requests from the PCP Client and sets up the appropriate state in response to that request."

      *  Explicit dynamic mappings are created as a result of explicit
        PCP MAP and PEER requests.

MAP and PEER are not defined yet. You could define the actions of mapping and peering and then use the verbs instead of the OPCODEs here.

Section 6.1:

  Version:  This document specifies protocol version 1.  This value
      MUST be 1 when sending, and MUST be 1 when receiving.

I'll begrudingly allow that it "MUST be 1 when sending", but I find this to be a silly use of 2119 anyway; it MUST be 1 iff you are implementing this version of the protocol, which seems stupidily redundant. I think such language also encourages receivers to do stupid things if the version is not 1. ("Well, the protocol says that it MUST be 1, so I don't have to do any error checking.") So, I would drop that bit. But it is simply not true that it "MUST be 1 when receiving." It very well might not be, which is why there's an error code for wrong version.

  Requested Lifetime:  An unsigned 32-bit integer, in seconds, ranging
      from 0 to 2^32-1 seconds.  This is used by the MAP and PEER
      Opcodes defined in this document for their requested lifetime.
      Future Opcodes which don't need this field MUST set the field to
      zero on transmission and ignored on reception.

So, it seems to me (given the last sentence) that this should have been opcode specific and appeared in that part of the header. I assume that ship has sailed. But I still don't understand the last sentence: Why should future opcodes be required to have that field filled with zero if it's not being used? If I use it, I fill it in with what I think it means. If it's not used, neither side will use it and the opcode will specify that. I don't see what use it is to make the admonishment here. (Same issue in 6.2.)

And again, MAP and PEER are used before being defined. (I'll not mention this problem again, but MAP and PEER are mentioned several times before section 9 rolls around.)

Section 6.3:

  It is the
  responsibility of the PCP client to ensure the server has sufficient
  room to reply without exceeding the 1024-byte size limit.

What 1024-byte size limit? This is the first mention in the document.

  An Option MAY appear more than once in a request or
  in a response, if permitted by the definition of the Option.  If the
  Option's definition allows the Option to appear only once but it
  appears more than once in a request, and the Option is understood by
  the PCP server, the PCP server MUST respond with the MALFORMED_OPTION
  result code; if this occurs in a response, the PCP client processes
  the first occurrence and MAY log an error.

What's this error logging business? Is the server (for some interoperability reason) not allowed to log an error but the client is? This doesn't sound like protocol to me; sounds like implementation advice, and boring implementation advice at that. Strike the "and MAY log an error." A client doesn't need your permission to do so.

  PCP clients are free to ignore any or all Options included in
  responses, although naturally if a client explicitly requests an
  Option where correct execution of that Option requires processing the
  Option data in the response, that client is expected to implement
  code to do that.

I cannot figure out what the above is trying to accomplish that is non-obvious. Is there some case where this makes some sort of interoperability difference? How could you tell if the client actually ignored it or processed it?

Section 7:

  PCP messages MUST be sent over UDP [RFC0768].

It seems to me that ICMP might be the correct choice instead of UDP, but I understand I may be blowing into the wind.

Section 8:

  1.  If a client or server supports more than one version it SHOULD
      support a contiguous range of versions -- i.e., a lowest version
      and a highest version and all versions in between.

Why is it useful (let alone an interoperability RECOMMENDation) to do that? I can see a stinker of a version potentially come out and the implementer decide that it's not worth implementing that version. What's the downside?

Section 9:

  Some applications will break if mappings are created on different IP
  addresses, so applications should carefully consider the implications
  of using this capability.

What applications are those? And what is the nature of that breakage? I don't understand what this sentence means.

  Static mappings for that Internal Address
  (e.g., those created by a command-line interface on the PCP server or
  PCP-controlled device) SHOULD also be assigned to the same External
  Address.

Why? What breaks if they are assigned to different External addresses? (I'm also not sure why static mappings are discussed in this document at all; there is no protocol involved in static mappings.) Also, what happens if the client requests two different explicit mappings? What should the server do then?

Section 10.2:

  If the client wants all protocols mapped it uses Protocol 0 (zero)
  and Internal Port 0 (zero).

I don't understand how this will work. If I am a client that says "Protocol 0, Internal Port 0", haven't I just taken over the entire external address from the NAT, and therefore nobody else connected to that NAT can use PCP?

[Ballot discuss]
(1) In Section 13.1.3, when discussing responses to unsolicited multicasted ANNOUNCE messages, there seems to be potential for a large number of packets to be generated all at once.  There should be some guidance here about whether the responses need to be dithered or paced in some way.  This was raised as part of Pasi Sarolahti's TSVDIR review.


(2) It seems that there isn't a good way to unambiguously match a response up to the request that generated it; especially when there have been (perhaps multiple) retransmissions.  Is this really the case?  If so, it seems that it should either be remedied or the impact needs to be discussed.


(3) In Section 7.1, note that the guideline from RFC 5405 for retransmission is one datagram per RTT or in absence of an RTT measurement, one datagram every 3 seconds.  The 2-3 seconds in section 7.1 is slightly more aggressive than this.  I think timers on the order of seconds may be horribly long though compared to the expected RTT between the client and server.  Would it be possible to cache an RTT if it could be measured during some request-response pair, and use that rather than the 2-3 second rule?  (note this would require unambiguous relation of responses to requests, as in the prior DISCUSS point).

[Ballot discuss]
1) Section 7 paragraph 2 asserts the protocol is idempotent, but then shows an example where it isn't.
If you allow a retransmitted request to produce a different response, the protocol is not idempotent.
Given that you allow this, not changing any bits in the request when you retransmit it allows the
client and server to end up with different views of the request's success. Example:

View in a fixed-width font:

  Client                  Server
    |          req            |
    |------------------------>|
    |        error response  |
    |    X<------------------|
    |      req              |
    |----------->X            |
    |          req            |
    |------------------------>|
    |        error response  |
    |              ----------||  Big delay in network between
    |  req      /          ||  client and server here
    |------------c--.        ||
    |          /    \        ||
    |<---------      `------>|
    |      success response  |
    |        X<--------------|
    |                        |
    |                        |

Note that epoch time doesn't help with this, but might with the below variants:
variant 1 - the success response actually delivers, after the client is no longer looking for a response
variant 2 - the success response delivered first, followed by the delayed error response

Adding a transaction identifier would only help if it was allowed to change with retransmission, and then the client would have to keep retransmitting until it got a response matching its most recent transmission before assuming it and the server were in agreement about the state at the server. Alternatively, you could require the server to actually be idempotent and never respond differently to the same request. (But you would need to put a finite limit on how long a client should retry before giving up on getting a response so that the server wouldn't have to remember the request and what response it sent forever).

2) Having text written for having a list of servers, and other text that says "for this document, the list can only have one element in it" is very confusing, and will likely lead to implementation mistakes. Would it be too hard to rewrite the text to say "the server" instead of "the first server in its list", and add a section warning implementers to anticipate handling lists when the protocol is extended? 

3) I'm not seeing a discussion of the consequences of someone being able to spoof an unsolicited ANNOUNCE response - that seems like an attractive target for someone wanting to DoS a large scale server. Related - if you are operating a CGN-sized server, what keeps sending such an ANNOUNCE response from effectively resulting in an avalanche-restart style flood of traffic from all the clients using that server?

[Ballot discuss]
1) Section 7 paragraph 2 asserts the protocol is idempotent, but then shows an example where it isn't.
If you allow a retransmitted request to produce a different response, the protocol is not idempotent.
Given that you allow this, not changing any bits in the request when you retransmit it allows the
client and server to end up with different views of the request's success. Example:

View in a fixed-width font:

  Client                  Server
    |          req            |
    |------------------------>|
    |        error response  |
    |    X<------------------|
    |      req              |
    |----------->X            |
    |          req            |
    |------------------------>|
    |        error response  |
    |              ----------||  Big delay in network between
    |  req      /          ||  client and server here
    |------------c--.        ||
    |          /    \        ||
    |<---------      `------>|
    |      success response  |
    |        X<--------------|
    |                        |
    |                        |

Note that epoch time doesn't help with this, but might with the below variants:
variant 1 - the success response actually delivers, after the client is no longer looking for a response
variant 2 - the success response delivered first, followed by the delayed error response

Adding a transaction identifier would only help if it was allowed to change with retransmission, and then the client would have to keep retransmitting until it got a response matching its most recent transmission before assuming it and the server were in agreement about the state at the server. Alternatively, you could require the server to actually be idempotent and never respond differently to the same request. (But you would need to put a finite limit on how long a client should retry before giving up on getting a response so that the server wouldn't have to remember the request and what response it sent forever).

2) Having text written for having a list of servers, and other text that says "for this document, the list can only have one element in it" is very confusing, and will likely lead to implemementation mistakes. Would it be too hard to rewrite the text to say "the server" instead of "the first server in its list", and add a section warning implementers to anticipate handling lists when the protocol is extended? 

3) I'm not seeing a discussion of the consequences of someone being able to spoof an unsolicited ANNOUNCE response - that seems like an attractive target for someone wanting to DoS a large scale server. Related - if you are operating a CGN-sized server, what keeps sending such an ANNOUNCE response from effectively resulting in an avalanche-restart style flood of traffic from all the clients using that server?

[Ballot discuss]
[Note: I'm on vacation this week and therefore my RTT will be exceedingly long. I've only just gotten through the beginning of section 7 and already I have a slew of comments. Some of the ones in the COMMENT section might move up to DISCUSS, but I haven't had time to sort through all of it yet. The two that are currently labeled DISCUSS are definitely in that category. Either way, I asked Jari and he said to send you what I've got so far. More to come soon.]

Section 6.3:

  The handling of an Option by the PCP client and PCP server MUST be
  specified in an appropriate document, which MUST state whether the
  PCP Option can appear in a request and/or response, whether it can
  appear more than once, and indicate what sort of Option data it
  conveys.

This does not belong here. This sounds like an IANA Consideration, that you are requiring a document for registration, and you are specifying what goes in that document. If so, then put this (without the MUST) into the IANA Considerations section with appropriate language. Otherwise, I don't understand what protocol force this documentation requirement has. 

  Option definitions MUST include the information below:

Again, that looks like IANA considerations.

Section 7:

  PCP is idempotent

That's a fine thing, but I believe there's a missing bit of functionality in this protocol to pull it off: Let's say I send a request that results in an error condition, and the error response is sent back but it is delayed. I'm an aggressive client, so I send another request. That one succeeds. Now I get back the error response. Or I get the success response first, and then finally the error response comes back. How do I know which request succeeded and which one failed? Do I have to check the Epoch Time to put them in order and assume that none of the responses were lost? A serial or sequence number in the request that is turned around in the response would solve this problem. Am I missing something?

[Ballot discuss]
Section 6.3:

  The handling of an Option by the PCP client and PCP server MUST be
  specified in an appropriate document, which MUST state whether the
  PCP Option can appear in a request and/or response, whether it can
  appear more than once, and indicate what sort of Option data it
  conveys.

This does not belong here. This sounds like an IANA Consideration, that you are requiring a document for registration, and you are specifying what goes in that document. If so, then put this (without the MUST) into the IANA Considerations section with appropriate language. Otherwise, I don't understand what protocol force this documentation requirement has. 

  Option definitions MUST include the information below:

Again, that looks like IANA considerations.

Section 7:

  PCP is idempotent

That's a fine thing, but I believe there's a missing bit of functionality in this protocol to pull it off: Let's say I send a request that results in an error condition, and the error response is sent back but it is delayed. I'm an aggressive client, so I send another request. That one succeeds. Now I get back the error response. Or I get the success response first, and then finally the error response comes back. How do I know which request succeeded and which one failed? Do I have to check the Epoch Time to put them in order and assume that none of the responses were lost? A serial or sequence number in the request that is turned around in the response would solve this problem. Am I missing something?

[Ballot comment]
I find all of the references to the "interworking function" from UPnP to be inappropriate in this document and should be removed. This is specific implementation advice for a specific environment, not protocol and not required for interoperability. I think it weakens the protocol specification and could have bad effects down the road. (Cf. IMAP, where specific accomodation of implmentation semantics led to all sorts of interoperability failures.) I think having a separate document with specifics of how to do PCP for UPnP is fine, but it shouldn't be in this document.

The notion of "subscriber" is unnecessary for this protocol and should be removed. It is sufficient to talk about per-host limits and quotas to explain the concepts that are there and then the document will not have to talk about the mapping of a business model onto the protocol.

Section 3:

PCP Client definition. I don't find the parenthetical bit about several web browsers useful; readers will confuse multiple instances of the same browser with multiple browsers and the message will be muddied. Not only that, anyone who will be coding this is well aware that multiple applications can run on a single host. I found myself wondering what the note was trying to get at. I also found the reference to UPnP not terribly helpful. I would strike it and simplify this description.

PCP Server definition is circular. Better would be: "A PCP software instance that resides on the NAT or Firewall that receives PCP requests from the PCP Client and sets up the appropriate state in response to that request."

      *  Explicit dynamic mappings are created as a result of explicit
        PCP MAP and PEER requests.

MAP and PEER are not defined yet. You could define the actions of mapping and peering and then use the verbs instead of the OPCODEs here.

Section 6.1:

  Version:  This document specifies protocol version 1.  This value
      MUST be 1 when sending, and MUST be 1 when receiving.

I'll begrudingly allow that it "MUST be 1 when sending", but I find this to be a silly use of 2119 anyway; it MUST be 1 iff you are implementing this version of the protocol, which seems stupidily redundant. I think such language also encourages receivers to do stupid things if the version is not 1. ("Well, the protocol says that it MUST be 1, so I don't have to do any error checking.") So, I would drop that bit. But it is simply not true that it "MUST be 1 when receiving." It very well might not be, which is why there's an error code for wrong version.

  Requested Lifetime:  An unsigned 32-bit integer, in seconds, ranging
      from 0 to 2^32-1 seconds.  This is used by the MAP and PEER
      Opcodes defined in this document for their requested lifetime.
      Future Opcodes which don't need this field MUST set the field to
      zero on transmission and ignored on reception.

So, it seems to me (given the last sentence) that this should have been opcode specific and appeared in that part of the header. I assume that ship has sailed. But I still don't understand the last sentence: Why should future opcodes be required to have that field filled with zero if it's not being used? If I use it, I fill it in with what I think it means. If it's not used, neither side will use it and the opcode will specify that. I don't see what use it is to make the admonishment here. (Same issue in 6.2.)

And again, MAP and PEER are used before being defined. (I'll not mention this problem again, but MAP and PEER are mentioned several times before section 9 rolls around.)

Section 6.3:

  It is the
  responsibility of the PCP client to ensure the server has sufficient
  room to reply without exceeding the 1024-byte size limit.

What 1024-byte size limit? This is the first mention in the document.

  An Option MAY appear more than once in a request or
  in a response, if permitted by the definition of the Option.  If the
  Option's definition allows the Option to appear only once but it
  appears more than once in a request, and the Option is understood by
  the PCP server, the PCP server MUST respond with the MALFORMED_OPTION
  result code; if this occurs in a response, the PCP client processes
  the first occurrence and MAY log an error.

What's this error logging business? Is the server (for some interoperability reason) not allowed to log an error but the client is? This doesn't sound like protocol to me; sounds like implementation advice, and boring implementation advice at that. Strike the "and MAY log an error." A client doesn't need your permission to do so.

  PCP clients are free to ignore any or all Options included in
  responses, although naturally if a client explicitly requests an
  Option where correct execution of that Option requires processing the
  Option data in the response, that client is expected to implement
  code to do that.

I cannot figure out what the above is trying to accomplish that is non-obvious. Is there some case where this makes some sort of interoperability difference? How could you tell if the client actually ignored it or processed it?

Section 7:

  PCP messages MUST be sent over UDP [RFC0768].

It seems to me that ICMP might be the correct choice instead of UDP, but I understand I may be blowing into the wind.

[Ballot comment]
Note to responsible AD. This document requests the creation of
regsistries that use the "specification required" allocation policy.
That means you will need designated experts.

---

Please consider addressing the minor points and questions raised by
Loa Anderson in his Routing Directorate review especially the question
about Section 15.

Additionally, I have some comments as follows. There are quite a few
and some of them are relatively significant. None of them merits a
Discuss, but I do hope you will take them seriously.           

---

Section 6.3

  It is the
  responsibility of the PCP client to ensure the server has sufficient
  room to reply without exceeding the 1024-byte size limit.

This is the first mention of the "1024-byte size limit" (I think you
mean the 1024=byte message size limit") and it would be helpful to
explain why that limit applies.

---

Section 7

  Every PCP request   
  generates at least one response, so PCP does not need to run over a
  reliable transport protocol.

Now, I can see how this would be made to work by a protocol spec that
implements a timer waiting for a response and a retransmission (as
described in Section 7.1), and a "more responses to follow mechanism"
(as possibly hinted at in Section 7.3), but your statement is too bold
as it stands. Perhaps you could rewrite as:

  Every PCP request generates at least one response, amd PCP is
  responsible for retrying requests and correlating responses, so PCP
  does not need to run over a reliable transport protocol.

It would also be good (maybe in 7.3) to clarify the processing when
there are multiple responses to a request. How does the client actually
know that it has received all of the responses?

---
 
Section 7.1

  Prior to sending its first PCP message, the PCP client determines
  which server to use.  The PCP client performs the following steps to
  determine its PCP server:

  1.  if a PCP server is configured (e.g., in a configuration file or
      via DHCP), that single configuration source is used as the list
      of PCP Server(s), else;

  2.  the default router list (for IPv4 and IPv6) is used as the list
      of PCP Server(s).

  For the purposes of this document, only a single PCP server address
  is supported.  Should future specifications define configuration
  methods that provide a list of PCP server addresses, those           
  specifications will define how clients select one or more addresses         
  from that list.

It seems to me that the second option listed here is exactly a case of
a configuration method where there is a list of PCP server addresses.
So don't you need to define the method of selection (probably, first in
the list is selected)?

Furthermore, a couple of paragraphs later you have:

  When attempting to contact a PCP server, the PCP client sends a PCP
  message to the first server in its list of PCP servers,

which seems to be exactly the specification of how to select a server
from a list.

---

Section 7.1

  As with all UDP or TCP client
  software on any operating system, when several independent PCP
  clients exist on the same host, each uses a distinct source port
  number to disambiguate their requests and replies.  The PCP client's
  source port SHOULD be randomly generated [RFC6056].

I suggest you don't need/want to mention TCP here. While what you say is
true, it is not relevant to this spec.
                                                             
---

Unless I missed it, you have not described the fact that a client can
receive an apparently unsolicited response from a server. This could
happen after client restart.

---

Section 10.1

There is some fluff in the terminology where (e.g.) the figure is
described as showing the packet format where it actually shows the
opcode-specific data.

Same issue in Section 11.1 and Sections 12.1, 12.2 etc.

---

Sections 17.2, 17.3, and 17.4

It seems entirely perverse to me to have just one code point available
in each registry (and three in one of the registries) for future
Standards Action, but many for specification required and private use.

[Ballot discuss]
The Gen-ART Review by Richard Barnes on 27-Feb-2012 raised a few
  concerns.  Please respond to at least these concerns:
 
  (1) Several people, including Richard, think that implementation would
  be simplified if a transaction identifier were used.  An identifier
  can simplify response processing, clarify the meaning of lifetime
  parameters, and provide some protection against address spoofing.

  (2) Add explanation of consequences from spoofed packets. (Or better,
  make it easier to detect and discard them.)  An off-path attacker
  might be able to break synchronization in state between clients and
  servers, for example, by sending gratuitous responses.  Richard offers
  this example flow as a way for an off-path attacker to steal traffic:
  >
  > 1. Attacker obtains mapping from address:port=A:P on PCP controlled
  >    device to one of its ports B:Q
  > 2. Attacker convinces client that it has a mapping from A:P to its
  >    port C:R
  > 3. Attacker acts as a man in the middle: remote -> A:P -> B:Q -> C:R

  (3) It seems the ANNOUNCE method provides an opportunity for an
  attacker capable of spoofing to cause an arbitrary number clients to
  flood the server with requests.  Please add explanation of
  consequences if an attacker mounts this attack.  (Or better, make it
  more difficult for an attacker to do so.)

[Ballot comment]
The Gen-ART Review by Richard Barnes on 27-Feb-2012 raised a few
  concerns.  Please consider these points:
 
  (a) The document says that v4-mapped addresses are not used as source
  or destination addresses for real IPv6 packets.  Richard is aware of
  some work on IPv6 traceroute scanning where numerous routers will
  respond from v4-mapped addresses.  It probably would be accurate to
  say that these addresses would never appear in a mapping.

  (b) In Section 6.4, the first paragraph says that each error is "long"
  or "short", but they're not all marked.  Is there a default?  It also
  seems like some of these errors are effectively permanent, such as
  UNSUPP_VERSION; the PCP NAT isn't going to support a new version of
  the protocol half an hour from now.

  (c) In Section 7.1, you first say that "only a single PCP server
  address is supported", but then in a couple of other places mention
  a "list of PCP servers".  Which is it?

  (d) In Section 7.1, it seems like it would be pretty unusual for the
  PCP server to be the first-hop router, at least outside of the CPE
  case.  Would it be better to use an anycast address to find the server?

  (e) I did not find that the code samples in Section 9 added any
  information.  The one case where one would have been helpful (9.4),
  there was none.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Port Control Protocol (PCP)) to Proposed Standard


The IESG has received a request from the Port Control Protocol WG (pcp)
to consider the following document:
- 'Port Control Protocol (PCP)'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-02-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Port Control Protocol allows an IPv6 or IPv4 host to control how
  incoming IPv6 or IPv4 packets are translated and forwarded by a
  network address translator (NAT) or simple firewall, and also allows
  a host to optimize its outgoing NAT keepalive messages.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pcp-base/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pcp-base/


No IPR declarations have been submitted directly on this I-D.

I have completed my review of the PCP base specification. Overall, I am very happy with the way that this specification has been written. I did not find any major issues. A few comments below, however.

Dan tells me that he wants to update the draft one more time before progressing it. I will wait for that (and the updates to correct the small issues that I discovered) before initiating IETF Last Call.

>    notification of the event to lesson the impact.

lessen

>    When an implicit dynamic mapping is created, some NATs and firewalls
>    validate destination addresses and will not create an implicit
>    dynamic mapping if the destination address is invalid (e.g.,
>    127.0.0.1).  If a PCP-controlled device does such validation for
>    implicit dynamic mappings, it SHOULD also do a similar validation of
>    the Remote Peer IP Address and Port for PEER-created explicit dynamic
>    mappings.

It would be nice (though not mandatory) if we had a reference to an RFC that explained what the exact validation rules should be.

> Determining which PCP clients are authorized to use the THIRD_PARTY
>    Option for which other hosts is deployment-dependent.
> A cryptographic authentication
>    and authorization model is outside the scope of this specification.

I am certainly OK with this (particularly with the third party mode not being mandatory). However, I expect there to be some IESG comments on this. We can deal with those as they come.

>    The FILTER Option is formatted as follows:
>
>      0                  1                  2                  3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | Option Code=3 |  Reserved    |  Option Length=20            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |    Reserved  | Prefix Length |      Remote Peer Port        |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                                                              |
>      |              Remote Peer IP address (128 bits)              |
>      |                                                              |
>      |                                                              |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>                      Figure 15: FILTER Option layout

Please specify what protocols are being filtered. Do you mean that all protocols (with port numbers) are allowed? Only TCP? Only UDP? The same protocol as in the entry already held for this client by the PCP gateway, i.e., from the MAP Opcode? Something else?

> [ff02::1]:5350
>    (ff02::1 is for all nodes on the local segment)....
>    IPv6 listens for packets sent to the IPv6 multicast address [FF02::
>    1]:5350.  A PCP client device which sends PCP requests using both

Please use the lowercase address format. (See http://tools.ietf.org/html/rfc5952)


Jari

I am continuing with my review, and have read until about page 50. I have no suggested improvements at this point.

I will complete the last part of the review tomorrow.

Jari

I have reviewed the first part of this draft, up until about page 30. Here are  my comments:

In general, I have found that the spec is very well written and I found no technical issues. It was a pleasure to read, and while I made some notes as I read it on, I was mostly able to delete my notes as I found the answers later. Thank you for writing this well.

Technical:

None

Editorial:

>    Checking nits according to http://www.ietf.org/id-info/checklist :
>    ----------------------------------------------------------------------------
>
>    == There are 2 instances of lines with non-RFC5735-compliant IPv4 addresses
>      in the document.  If these are example addresses, they should be changed.
>
>    == There are 2 instances of lines with multicast IPv4 addresses in the
>      document.  If these are generic example addresses, they should be changed
>      to use the 233.252.0.x range defined in RFC 5771
>
>
>    Miscellaneous warnings:
>    ----------------------------------------------------------------------------
>
>    == Line 1260 has weird spacing: '...nternal  exter...'

Please check these.

>  Each error code below is classified as either a 'long
>    lifetime' error or a 'short lifetime' error, which provides guidance
>    to PCP server developers for the value of the Lifetime field for
>    these errors.  It is RECOMMENDED that short lifetime errors use a 30
>    second lifetime and long lifetime errors use a 30 minute lifetime.
>
>    0  SUCCESS: Success.
>
>    1  UNSUPP_VERSION: Unsupported protocol version.
>
>    2  NOT_AUTHORIZED: The requested operation is disabled for this PCP
>        client, or the PCP client requested an operation that cannot be
>        fulfilled by the PCP server's security policy.  This is a long
>        lifetime error.
>
>    3  MALFORMED_REQUEST: The request could not be successfully parsed.
>
>    4  UNSUPP_OPCODE: Unsupported Opcode.
>
>    5  UNSUPP_OPTION: Unsupported Option.  This error only occurs if the
>        Option is in the mandatory-to-process range.
>
>    6  MALFORMED_OPTION: Malformed Option (e.g., appears too many times,
>        invalid length).
>
>    7  NETWORK_FAILURE: The PCP server or the device it controls are
>        experiencing a network failure of some sort (e.g., has not
>        obtained an External IP address).  This is a short lifetime error.
>

The error codes have not all been categorized to short/long. Please clarify.

>    For as long as the client still desires the indicated mapping, if no
>    response is received before the timer expires then the request is re-
>    transmitted and the timer is doubled (to 4 seconds).

The last part should be "... first to 4 seconds ...", I think.

Jari

  (1.a) Who is the Document Shepherd for this document?

Dave Thaler

        Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Yes.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members?

Yes.

        Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

No concerns.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No concerns.  Margaret Wasserman (with assistance from Sam Hartman)
reviewed for security and provided much of the security text that was
added to the document.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of?

No.

        For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here.

The parts of the document that did not have consensus to be in the
base spec were already removed and left for consideration as extensions.

        Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

No IPR disclosures have been filed.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

There is a strong concurrence of the most active individuals, and the
WG as a whole has consensus on it.  For example, many people participated
in polls of the room during face to face meetings, not just a few individuals.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No.  During the first WGLC, two individuals objected that a separate draft
(on rapid recovery) was not folded into the base spec.  As a result
of WG discussion, consensus was to fold it in, which was done.  The WGLC
was repeated and no further threats occurred.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough.

Yes.  The shepherd ran idnits in verbose mode and verified there were
no errors.  All warnings are false positives.  Specifically idnits
warns:

    (1585): Line has weird spacing: '...nternal  exter...'

The above are table column headers and are intentional.

    (2256): Found possible IPv4 address '127.0.0.1' in position 7; ...
    (2803): Found possible IPv4 address '127.0.0.1' in position 4; ...

The above refer to the loopback address specifically, and this use is
intentional.

    (3345): Found possible IPv4 address '224.0.0.1' in position 4; ...
    (3373): Found possible IPv4 address '224.0.0.1' in position 4; ...

The above refer to the specific multicast address used by the protocol,
and this use is intentional.

        Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

N/A.  No MIB, media type, URI type, etc. present in this document.
   
  (1.h) Has the document split its references into normative and
        informative?

Yes.

        Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state?

No.

        If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

No.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document?

Yes.

        If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries?  Are the IANA registries clearly identified?

Yes (in section 17.1).

        If the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations?

Yes (in section 17.2).

        Does it suggest a
        reasonable name for the new registry?


Yes ("PCP Opcodes").

        See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

N/A (allocation procedure is not Expert Review).

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

N/A (no formal language snippets present).

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:
    Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

The Port Control Protocol allows an IPv6 or IPv4 host to control how
incoming IPv6 or IPv4 packets are translated and forwarded by a network
address translator (NAT) or simple firewall, and also allows a host to
optimize its outgoing NAT keepalive messages.

    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

At the outset, the WG looked at many other protocols that have been
proposed in the past for doing similar things, but almost none have
been successful in getting real deployment.  The exceptions are NAT-PMP
and UPnP-IGD.  Between them, the WG concluded that NAT-PMP was more
closely aligned with the intended scenarios and hence used NAT-PMP
as the starting point for PCP.

    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification?

Several PCP implementations exist, and some interoperability testing
has already been done.

        Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues?

Margaret Wasserman did a thorough security analysis and wrote the
security considerations section.

Many others (beyond the authors themselves), including a number of
implementers, have also done reviews and are acknowledged in the document.

        If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

N/A (no MIB or Media Type).