[arin-ppml] A compromise on legacy space?

[Kevin Kargel]

 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 
> differently?   
> > My
> > proposal is also simple:
> >
> > Group #1:
> >  Upon the next regular renewal of the ARIN RSA all legacy 
> resources,  
> > 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 
> confusing)  
> > 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.
> 
> Owen
> 
> _______________________________________________
> PPML
> 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:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080910/4c3f8bee/attachment.bin>