Note: This ballot was opened for revision 05 and is now closed.

(Ted Lemon) Yes

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

- general: Is there any case where a bad actor could
use this multiple times (say after reboots/resets that
are visible to the ISP) getting different answers each
time and thus being able to infer that some prefix
similar to one received is now topologically nearby
the bad actor?  E.g. if I see Prefix#1, then reboot,
wait a while and next see Prefix#1+10, I might
conclude that 9 other nearby home gateways have
rebooted perhaps and try use that for nefarious
purposes. Can we think of any such nefarious purpose?
I can't, hence this not being a discuss:-) However,
if there were such a nefarious purpose, maybe it'd be
worth some advice to deployments about making the
prefixes unpredictable? (Just wondering.)

- general: More friendly to DNSSEC? Fantastic!

- 3.2.1: can a host synthesize AAAA records sufficient
to verify all DNSSEC? Just wondering, but I'd have
guessed some more detail might be needed. Is there
really enough specified here?

- Fig 1: Adding a "See Figure 2" below the IPv4 Prefix
List would be clearer.

- 4.3: I wasn't clear what an invalid prefix might be
here - do you mean a bogon, such as 10/8? (Sorry,
maybe I was reading too quickly.)

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

(Barry Leiba) No Objection

(Pete Resnick) No Objection

4.3:

   If the PCP client
   fails to contact a given PCP server, the PCP client SHOULD clear the
   prefix(es) and suffix(es) it learned from that PCP server.

What constitutes "fails to contact"? Is there some timeout involved there? And I'm not totally clear on why I'd clear the list just because I "failed to contact" the server. Could you explain?

(Martin Stiemerling) No Objection