Skip to main content

IPv6 Unicast Address Assignment Considerations
RFC 5375

Yes

(Mark Townsley)
(Ron Bonica)

No Objection

Lars Eggert
(Chris Newman)
(Cullen Jennings)
(David Ward)
(Magnus Westerlund)
(Ross Callon)
(Russ Housley)

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

Lars Eggert No Objection

(Jari Arkko; former steering group member) (was Discuss) Yes

Yes (2008-05-22)
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.

(Lisa Dusseault; former steering group member) Yes

Yes (2008-05-06)
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; former steering group member) (was Discuss) Yes

Yes ()

                            

(Ron Bonica; former steering group member) Yes

Yes ()

                            

(Chris Newman; former steering group member) No Objection

No Objection ()

                            

(Cullen Jennings; former steering group member) No Objection

No Objection ()

                            

(Dan Romascanu; former steering group member) (was Discuss) No Objection

No Objection (2008-05-21)
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; former steering group member) No Objection

No Objection ()

                            

(Magnus Westerlund; former steering group member) No Objection

No Objection ()

                            

(Pasi Eronen; former steering group member) (was Discuss) No Objection

No Objection (2008-09-22)
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".

(Ross Callon; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Tim Polk; former steering group member) No Objection

No Objection (2008-05-07)
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