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