Please allow me to send this off again to some of you. Ignore the first one if you got one. Kosuke ---------------------------------------------------------------- Thank you, Arano-san Takashi Arano wrote:
At 09:52 02/02/07, CJ Wittbrodt wrote:
Maybe we should look at the people you refer to as wanting to be "in" and figure out what distinguishes them from just some end user who should have a /48 from their upstream...?
Yes, this is the point.
I basically supports RIPE's consensus. First, requiring 776 customer sites as criteria of getting /32 is a too high barrier and should be relaxed in any way. Maybe, anyone can agree with this so far.
Yes, actually, there are some voice in JP as well about this initial allocation criteria, most from ISPs running accessing services in less populated cities.
Next, "any LIR can get /32 until 2000 /32 per a region" is almost OK, but one problem may be to use the existing definition(s) of "LIR" mainly defined for IPv4. In ARIN region, you can become a LIR if you pay some money as far as I heard. This may include an large enterprise.
If this is true, then, it seems like "buying" an address block, which will be against our goal of "IP address is public resource", as well. This is not quite good from this point of view.
One concern here is that this rule will give /32 end users even if they are large enterprise. We should avoid this as Thomas suggested.
So my small modification proposal is to replace "any LIR" with
- ISP or organization who assigns and registers /48s to organizations other than itself
This sounds very reasonable at lease for bootstrap. The current draft was well-thought based on the deep care of "aggregation", not from the aspect of vast availability of address space, since the routing technology seems not that sophisticated enough to allow everyone with /32. In this sense, an organization should contribute to the world community in keeping routing table a practical size, and should report assignment status for community to monitor our activity. If it fails, then, it could be very hard to maintain the order and the good nature of our community. We should keep these in mind, I guess.
Although it is still ambiguous, we know the perfect definition is impossible due to the nature of things. Actually, an enterprise or university which has subsidiaries in their networks like an ISP can be difficult to be categorized.
Anyway, I believe this is better than just saying "any LIR", maybe because we can omit obvious end users.
I think so. There is no need to give an independent /32 to end users. If they want more than one /48, then, they can request to have another.
Those who think this rule is still too loose can propose some additional option such as AS-holder or multihomed. But IMHO, we don't need these just for a bootstrapping phase. These new concepts would bring another issues.
By limiting bootstrapping, we can minimize damages if we have. I am for Gert in this point.
Let's see what happen.
Lastly, we may have many ways for limiting the phase. I can give you another options here. 1) 2000 /32s * 3 as RIPE supports 2) the end of year 2003 3) 2001:0200::/23, 2001:0400::/23, 2001:0600::/23 only Maybe, we should take LACNIC and AfriNIC into consideration and learn from some confusion about "100 sTLAs".
To avoid any future trouble of "go for other regions to get a /32" type of things by hitting the cap in one region, I guess, the second option is fair enough. Then, we do not have to care about LACNIC or AfriNIC community coming in later on. However, if we set this bootstrapping phase in the Interim policy, then, we should also agree to switch to the current criteria at the end of the phase with no question unless we have an alternative criteria agreed by then.
All are not a good or bad thing, just an issue to be decided. We need good compromise.
I am sorry if you don't understand my bad English. But please be aware that this is a GLOBAL mailing list, not ARIN's nor RIPE's. Sometimes we don't understand difficult idioms nor spoken languages. Thank you for your collaboration and cooperation.
Regards, Takashi Arano
so am I.:-) Kosuke -- **********IPv6 Internet Wonderland!************ Kosuke Ito, Base Strategy Planning Group IPv6 Promotion Council of Japan Tel:+81-3-5209-4588 Fax:+81-3-3255-9955 Cell:+81-90-4605-4581 mailto: kosuke@v6pc.jp http://www.v6pc.jp/ Lifetime e-mail: kosuke@stanfordalumni.org