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

(Jari Arkko) (was Discuss) Yes

The document says:

   However multihoming also has some operative and administrative
   burdens besides chosing multiple addresses per interface [33]
   [25][24].

I'm not sure these references are adequate. It would be good to
point to the recent v6ops document that described issues with
address selection, for instance. Also, I wonder if pointing to
Shim6 documents as Informative references would be useful as well.

References to RFC 3041 should be replaced by references to 4941.

(Ron Bonica) Yes

(Lisa Dusseault) Yes

This comment is only a bunch of nits, I liked the doc itself

Section 1.  Reference [32] is to an expired draft -- draft-chown-v6ops-renumber-thinkabout.  I hope the authors revive this (and as an aside, if you do, I hope to better understand the overlap with RFC4192)

Section 2.1: Reference [33] is too broad and unstable.  Aren't references [25] and [24] enough here?

Section 2.2: RPF should be expanded (Reverse Path Forwarding)

Section 2.3: RIR should be expanded (Regional Internet Registries?)

Section 2.4: 

   However, there is no rule to disallow large networks to use a 
   single ULA for all 'sites'

I believe this should be 

   However, there is no rule to disallow large networks to use a 
   single ULA prefix for all 'sites'

Section 2.4.2: HD should be expanded, I mention this for completeness because the reference right there makes this one easy to track down.  to get really nitpicky, the reference itself is wrong tho, should be "Host-Density" instead of "H-Density".

Section 3.3.1.1: last sentence doesn't parse to me...

(Mark Townsley) (was Discuss) Yes

(Ross Callon) No Objection

(Lars Eggert) No Objection

(Pasi Eronen) (was Discuss) No Objection

Version -10 has couple of editorial nits, which probably
should be fixed before sending this to the RFC editor: Sections 4..8
got renumbered to 3.2..3.5 -- a misplaced </section> tag, perhaps?
And in Section B.2.1, "earlier in this section" should be "later in 
this section".

(Russ Housley) (was Discuss) No Objection

(Cullen Jennings) No Objection

(Chris Newman) No Objection

(Tim Polk) No Objection

There are a number of useful suggestions and editorial corrections in
Elwyn Davies' GenArt Review.  Since this review was posted on May 6, I
wanted to call it to the authors and wg chairs attention.  There are
three specific issues I found especially compelling:

s1, bullet 3 (near end): s/traffic storm and level/potential traffic
storms and the level/  No further mention of traffic storms is made in
the document... should it be to give some hints on subnet sizing? 


s2.2, para3: 'Using a random chosen ULA address will be conform in case
   (a) provide suboptimal aggregation capability, while in case (c)
   there will be overconsumption of address space.'
This sentence is not good English and I don't understand what it is
trying to say regarding case (a).


s3.3, para 3: It would be useful to explain why the u and g bits might
come back to bite us in future or provide a reference which discusses
why they are relevant at all.


While I am most anxious to resolve the three issues above, all the
changes Elwyn proposed appear well founded to me.  The full review
is available at 

http://www.ietf.org/mail-archive/web/gen-art/current/msg02970.html

(Dan Romascanu) (was Discuss) No Objection

1. Please expand RIR and LIR at first occurence

2. The 'we' language in subsection of Annex A1 seems unappropriate

3. The 'requirements' language in subsections A2.1.1, A2.1.2, A2.1.3 seems unappropriate. This being an Informational RFC and the ennexes describing operational experience in specific deployments it seems right to talk about 'recommendations' rather than 'requirements;.

(David Ward) No Objection

Magnus Westerlund No Objection