Re: [pcp] Alissa Cooper's No Objection on draft-ietf-pcp-anycast-07: (with COMMENT)

[Sebastian Kiesel <[e-mail]>]

Hi Alissa,

On Mon, Sep 14, 2015 at 11:01:05AM -0700, Alissa Cooper wrote:
> Alissa Cooper has entered the following ballot position for
> draft-ietf-pcp-anycast-07: No Objection
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 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?

thanks for your feedback!

our draft specifies (in Sec. 2.1) that the anycast addresses are
appended to the list of (candidate) PCP server addresses and that this
list is processed as specified in RFC 7488, which says that the list has
to be sorted as specified in RFC 6724, sec. 6.  This sorting causes
that the anycast addresses are tried after the default routers and
other addresses in topological vicinity of the client, which might be
known from other sources such as DHCP or configuration files.

I must admit that this chain of normative references may be somewhat
confusing.  I was trying to write a short self-contained specification
but gave up - would have to copy too much text from the existing RFCs.
On the other hand, a plus of the current situation is that if an
implementor already has an implementation of RFC 6724, (s)he can just
include/link/call it.

Regrads,
Sebastian