Port Control Protocol (PCP) Anycast Addresses
draft-ietf-pcp-anycast-08

Given the issue described in 5.1, I'm curious about this text:

"PCP clients usually send PCP requests to these addresses if
   no other PCP server addresses are known or after communication
   attempts to such other addresses have failed."

Would it make more sense to make a normative recommendation about the order in which addresses should be tried, to help minimize the frequency of cases where PCP requests to the anycast address(es) leak out unnecessarily?

I think items 2 and 3 from Robert Spark's Gen-ART review deserve more consideration:

https://mailarchive.ietf.org/arch/msg/ietf/I7D6wPEGZ5lxqHCzFSfi7qC55qo

Editorial Comments:

2.1, "The PCP anycast addresses ...  are added..."
Added by what?

2.2, 2nd paragraph:
Same as the anycast address? It seems odd to embed the “iana-assigned” bit in this sentence. That fact deserves it’s own sentence. 

5.2, first paragraph:

s/"... require to impersonate..."/" ... require the attacker to impersonate..."/   ; or "require the impersonation"

My DISCUSS was:
I'm surprised by the lack of RFC 2119 keywords in a spec like this.
For example:

   The PCP anycast addresses, as defined in Sections 4.1 and 4.2, are
   added after the default router list (for IPv4 and IPv6) to the list
   of PCP server(s)

              MUST?

     ...

   A PCP Server can be configured to listen on the anycast address for
   incoming PCP requests.

	Is this a MAY or SHOULD?

I received this message:
  the authors have discussed with the doc shepherd and the AD that 
  not a single statement in the document has to be reinforced by a MUST, 
  in order to insure interoperability or avoid unneccessary harm to the 
  Internet as a whole[1]. There are two sentences where a SHOULD would 
  make some sense, but leaving it as is does not seem too bad either.  So 
  we decided to move forward without introducing RFC 2119 language.

So some RFC 2119 keyword would make sense, but the responsible AD doesn't insist on doing what's right.
I'm surprised. This is a bad signal for future documents. However, I won't stand in the way but I want my 
point of view to be archived in this COMMENT.

Thanks for writing this useful document. Before recommending its approval
I would like to raise one small question.

I believe it might be appropriate to use clearer language to specify that
BCP 105 (RFC4085) recommendations are to be followed. Specifically,
while the "hard-coding" language has changed, I would have wanted to
seein the later statement about configuration or override, the use of
"SHOULD" instead of "should".

Points 2 and 3 from Robert Spark's Gen-ART review should be considered.

Thanks for addressing the SecDir review questions.  Filtering and setting a TTL seem like the best options to prevent leakage, but I do agree with the reviewers that it may not happen on many networks.  I do appreciate the warning and advice though for the gateway.

Say if PCP authentication is supported and the PCP client can
authenticate with various different PCP servers, e.g. at home
and in the office. Imagine further that the secrets for the
home PCP authentication leak (or are guessed). Wouldn't we
want the PCP client in the office in such a case to not accept
a PCP server that uses the home secrets? Is that scenario
possible? If so, and if the PCP client has some way to know
that it is at home or in the office, (could it?), shouldn't
there be some security considerations text saying to not
accept authenticated responses that come from the "wrong" PCP
server? That would probably mean extending the last paragraph
of 5.2 to say "if the client knows what server it expects to
authenticate to it after the anycast request was sent, then
the client MUST check that the response is authenticated from
that server (and not some other)."

Separately, I hate one of the arguments used (twice!) in 5.2.
What you are saying is "I don't need to do stuff because worse
things can happen." If all protocol developers made that
argument then we would never improve security or privacy.
It's a bad argument. You need instead to argue that there's
really nothing practical than can be done and that would be
used and that would improve over doing nothing.