IPv6 Unicast Address Assignment Considerations
RFC 5375
Note: This ballot was opened for revision 10 and is now closed.
(Jari Arkko) (was Discuss) Yes
Comment (2008-05-22)
No email
send info
send info
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
Comment (2008-05-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
send info
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
Comment (2008-09-22)
No email
send info
send info
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
Comment (2008-05-07 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
send info
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
Comment (2008-05-21)
No email
send info
send info
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;.