> This is an IPv6 working group last call for comments on submitting the > following document for consideration as a Proposed Standard RFC:
My assumption is that the purpose of this document is spelled out in the introduction: While this approach was originally thought to be a good way to allocate IPv6 addresses, subsequent experience and discussion showed that it would be better to leave flexibility in the definition of IPv6 allocation policies to the Internet Address Registries, in order to allow a better balance among the competing requirements. This is consistent with the recommendations made by the IAB and IESG in [RFC3177]. As the above doesn't really have a lot of detail, some more explanation would be good. For example, I still see people occasionally make statements about how IPv6 address allocation will enforce some sort of strict heirarchy (this comes from reading 2374, which this one is obsoleting). Explicitly explaining why that thinking is no longer in vogue would seem useful. Also, this document doesn't say anything about exchanges, whereas 2374 has explicit text. Should this document say anything about this? Are exchanges no longer supported? (I don't think that is the answer, but by not mentioning exchanges, one might draw that conclusion.) As for section 2.0, it seems to just be restating stuff documented in addr-arch. Generally, I think it's better not to repeat stuff from other documents. Also, wording like: The specific format of global unicast address under the 2000::/3 prefix is: might cause some folk to think that the format of addresses under 2000::/3 is somehow different than that for other prefixes. But that isn't the case; the other prefixes generally follow the same format. I don't see how it makes things more clear to single out the 2000::/3 prefix for special discussion on this point. Thus, I think all of Section 2 could be removed. If Section 2.0 is removed, there is nothing in the document that needs to be on standards track. Indeed, given that none of section 2 is new, it all restates stuff on addr-arch, I don't think even this document should go on standards track. Having this document be info, and obsoleting 2473 would work just fine process wise. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
