On Mon, Aug 11, 2003 at 08:19:46AM +0200, leo vegoda wrote:
Below is a summary of the recent discussions on the PI TF mailing list.
As the pi-tf mailing list seems to have been closed (at least I'm unable to subscribe - pi-tf-request@ripe.net bounces as unknown), I guess further discussion should take place here (which makes some sense).
1. Reduce the minimum allocation size from /20 to /21
Agreed.
2. Remove the requirement to show an immediate need for 25% of the allocated address space (a /23 in this case)
Agreed.
3. No longer assign PI (Portable) address space to End Users
Strongly disagreed. Upstream-independent address space is _needed_. This cannot be ignored.
4. End Users requiring a portable address block could become an LIR and receive a /21 allocation.
An end-user can't be a LIR by definition. :-) Let's take a look at four entity categories: A) Commercial ISPs, assigning subnets to customers B) Enterprises (from very small companies to multinational heavyweights) C) non-commercial organisations (NCOs) being absolute end-users D) non-commercial organisations (NCOs) assigning subnets to org members Cat A is quite clear. They should become regular LIRs, receive an initial allocation under provisions of #1 and #2 above. RIPE NCC efforts are covered by LIR membership fees. Cat B should be able to get an IP block according to documented need plus some reserve (perhaps at least a /22 by default) without ability to sub-assign subnets. RIPE NCC efforts are primarily one-time and thus the requestor should pay a one-time fee for the request processing, plus a periodic, moderate maintenance fee to cover administrative and operational costs for their data in the RIPE systems like the RIPE DB. Usually, those kind of entities are nowadays typical PI requestors (getting IP space for free via a LIR), or Enterprise LIRs (paying significant yearly fees, but not requiring any cost-intensive RIPE NCC service like hostmaster support as no registry function is performed). Cat C+D are most interesting. The aim for those should be to keep cost as low as possible. Cat C would be typical PI requestors today, with no fees to be paid at all. IMHO, we should keep this cost neutrality for those kind of NCOs. Cat D is where the fun starts. Currently, Cat D NCOs would usually request larger PI blocks, and "silently" (without documentation in the RIPE DB due to the nature of PI assignments) sub-assign subnets to NCO members. As an example, imagine a "computer club" having built a city-wide "club WAN" by some creative means, being BGP multihomed to some ISPs, connecting club members with static IP subnets to this "club backbone". Naturally, the club would like to document those assignments in RIPE to provide sensible contact information for IP ranges, but isn't allowed due to the "end user" style of PI assignments (mnt-lower to RIPE NCC). NCOs like clubs usually can't afford to become LIRs, but would like to document such sub-assignments. I would suggest to treat them like Cat C, but: - Allocate a netblock of justified size, at least /21, like ISP LIRs - Allow assignments within this allocation for documentation reasons (NOT usage level _justification_) in RIPE DB. - require them to request their stuff via an established LIR like with Cat C and usualy PI requests today. - no fees Overall, in short: A) normal LIR status, with normal LIR payments to RIPE NCC B) end-user status, one-time fee plus moderate periodic maintenance fee C) non-commercial (totally) end-user status, no fees, request via a LIR D) non-commercial organisation able to document usage of IP blocks within their IP range, no fees, request via a LIR So, Cat A+D would receive PA allocations, and Cat B+C would receive PI assignments. Reading all that again, I might overcomplicate things. But then again, I don't simpler models being equally "fair". :-/
Finally, it was noted that there is a requirement for globally unique addresses that will not be routed on the Internet.
This would fall under Cat B (if commercial) or Cat C (non-commercial). Please take above as a proposal for discussion. I'm highly interested in comments. Best regards, Daniel