[arin-ppml] A compromise on legacy space?
kkargel at polartel.com
Wed Sep 10 09:12:52 EDT 2008
Well said Owen. When everyone understands that Arin provides a unique
database entry and not a number the whole paradigm changes.
> -----Original Message-----
> From: arin-ppml-bounces at arin.net
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
> Sent: Tuesday, September 09, 2008 1:23 PM
> To: Leo Bicknell
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] A compromise on legacy space?
> > Group #1:
> > Definition: Legacy holders who also hold space covered by a regular
> > ARIN RSA.
> I'd like to refine this a bit. I think it would be more
> appropriate to say "Legacy Holders who are also Subscriber
> Members of ARIN."
> This covers those who have allocations from ARIN (ISPs) while
> leaving out those organizations who are end-users. I find it
> unlikely that end users (some of which do have legacy+rsa
> space) fit in the category you are attempting to include here.
> > Group #2
> > Definition: All legacy holders not in group #1.
> > There are a few minor implementation details that may need
> to appear
> > in the definition. For instance, is group one determined
> by ORG-ID,
> > by legal entity, or some other definition. I honestly
> don't know the
> > details we could get some input from staff. The concept
> though is if
> > you run a network using both legacy and ARIN assigned space
> you're in
> > that group though.
> Would my proposed re-definition of group 1 solve this?
> > Now, the question is, how do we treat those two groups
> > My
> > proposal is also simple:
> > Group #1:
> > Upon the next regular renewal of the ARIN RSA all legacy
> > covered by an existing RSA, LRSA, or not covered at all shall be
> > rolled under a single, current, ARIN RSA.
> Or what? What if the group #1 members do not agree to this
> or do not want to agree with it? I don't believe ARIN really
> has the authority to do this. Especially in the case of
> legacy resources covered by LRSA. The LRSA specifically
> precludes ARIN taking such an action unilaterally if I
> understand it correctly.
> > Group #2:
> > A "Legacy Service Agreement" (I won't use LSA, that's too
> > shall be created. It should state:
> > - ARIN provides services to legacy holders, including but not
> > limited to: whois, rdns, uniqueness, public policy meetings,
> > mailing lists, and more.
> > - The Legacy Holder must pay a fee (fees are not policy, but I'm
> > thinking around $100 per year as has been discussed)
> to continue
> > the use of these services.
> > The Legacy Services Agreement can be terminated by the
> legacy holder
> > at any time. Of course, at that time ARIN may cease to
> provide whois,
> > rdns, or any other service. No revoking of services, no one sided
> > termination, etc. Those two simple ideas, wrapped up in
> the minimum
> > legal language necessary.
> I think we are applying meta-issues which obscure reality.
> Let's talk about what ARIN really provides. ARIN provides a
> number of services, but, the key service at issue is
> registration of numbers in a database which assures that no
> other entity cooperating in the same system of databases
> receives the same numbers.
> ARIN does not give, lease, transfer, or otherwise grant
> numbers to people. Integers are integers and regardless of
> what ARIN does, every member of society remains perfectly
> within their rights to use any integer they choose for any
> lawful purpose they wish.
> We have (perhaps mistakenly) referred to these registrations
> as assignments and/or allocations, but, we aren't really
> assigning or allocating integers. We are assigning or
> allocating slots in one particular database. The available
> slots in said database are a subset of 32 bit integers. That
> subset is determined by a "parent" database which registers
> (for uniqueness) the entire set of 32 bit integers, and,
> which records what subsets of the entire set have been
> registered to which RIR (or other entity in some rare
> cases). The "parent" database is operated by IANA.
> The only reason the contents of ARIN's database have any
> relevance whatsoever is that a large portion of the ISPs have
> chosen to cooperate in the RIR system such that they treat
> registrations in the various RIR database as the
> authoritative source of information they choose to
> incorporate into routing policy. ARIN does not control this.
> ARIN does take this trust seriously and works hard to avoid
> violating this trust.
> NOTE: I am not advocating for this to occur, but, If a
> sufficient critical mass of ISPs were to choose to create
> their own registry system, there is little or nothing ARIN
> could do about it.
> Certainly ARIN would not be able to sue such a competing
> registry or the ISPs that choose to cooperate with it on the
> basis that they were using integers which "belonged"
> to ARIN.
> So... If we approach this from the perspective that IP
> addresses truly are not property and that ARIN does not
> issue, assign, allocate, or otherwise transfer IP addresses
> from one entity to another, but, instead, holds a database
> for a portion of the IP space in which they record
> registrations which are prevented from overlapping with other
> registrations held in the ARIN database or the cooperating
> other RIR/IANA databases.
> Then... We can conclude that ARIN terminating such services
> means that those slots become available in the ARIN database.
> This means one of two things, depending on how you want to
> define the term "reclamation".
> If you define "revocation" as marking the space available to
> be issued to another entity, then, termination of service
> almost automatically becomes reclamation.
> If you define "revocation" as ARIN preventing someone from
> using a given integer for some particular purpose, then, ARIN
> has no ability to reclaim anything. Never has, and, likely
> never will.
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3107 bytes
Desc: not available
More information about the ARIN-PPML