[arin-ppml] A compromise on legacy space?

Tue Sep 9 15:48:30 EDT 2008

In a message written on Tue, Sep 09, 2008 at 11:22:56AM -0700, Owen DeLong wrote:
> 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.

I am open to discussion, however my initial reaction is they should
be included.  For instance, I believe at least one of the Class A
holding private companies also has ARIN assigned space (due to
mergers, I think).  There are plenty of universities that have a
pre-ARIN /19 and a ARIN /19, as an example too, it makes no sense to
treat the two halves of their address space differently.

> >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.

While I realize I am making a stretch, everyone in group #1 has
already signed the more restrictive RSA for part of their space.
They have already opted-in to the community.  They have already
agreed, for instance, that their legacy space counts in utilization
requirements when they come back for more space.

Where I grant you there is more of an issue is where a firm has
already signed the LRSA.  In that case there exists two competing
contracts.

However, I have long held as a successor in interest ARIN has the
ability to change the terms on legacy holders, as long as it is done
through the open public policy process.  I think ARIN's position in this
case is defendable; it's hard for an ISP with multiple RSA covered
blocks who's already agreed to part of the terms on their legacy block
to continue to defend it should be something separate, particularly if
the open process says otherwise.

> 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.

Nope.  You have made a stretch I have not.

I believe ARIN can stop providing whois, in-addr.arpa, free acceess
for two members to the public policy meeting and other services to
legacy holders who terminate their contract.  I do not believe ARIN
can dump the entry from their internal database or assign the same
numbers to someone else.

There is a difference between not providing services to non-paying,
non-contracted entities and revoking an assignment.  Revocation is an
affirmative action that requires a letter to be sent stating "Netblock
abc is no longer yours to use" and putting it back in the pool that may
be given to some new requester.  I do not advocate revocation in any
circumstances.

In a message written on Tue, Sep 09, 2008 at 12:07:45PM -0700, Michael Sinatra wrote:
> What about other non-profit, government and community-based 
> organizations that provide services?  And, of course, what about 
> universities?  We are covered by RSA for our IPv6 allocation, but our 
> IPv4 space is all legacy, and we certainly don't intend to ask for more. 
>  In spirit, I'd hope that we fit more into group 2 than group 1.
> 
> Would it make more sense to have the definition refer only to IPv4 
> space, and ignore, for the purposes of defining the two groups, any IPv6 
> RSAs that an entity may have?

I have no issues with limiting the entire scope of my original post
to IPv4 only.  Thus group 1 would include any entity with IPv4
addresses under an RSA, and not include IPv6 or ASN holders.

Indeed, that's really what I intended and I was imprecise with my
language.

> In my case, I suspect state governments and legislatures may have 
> something to say about this.  Given the laws of California as they apply 
> to contracts with state- and state-supported-agencies, I think there 
> might be legal issues in forcing legacy resources into a regular RSA. 

This may sound flippant, but I really don't mean it to be...

There are legal issues with everything, including taking no action.
While I want to solicit various legal input from both sides that
should be done towards the end of the community agreement process.
The strength here is the community agreeing to the right action.
I have faith that if we can get 80% of the community behind a
proposal the lawyers can find a way to make it hold up in court
most of the time.

ARIN Counsel has said before they have worked with government to adjust
for specific legal requirements on government agencies, this may be one
of those cases.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080909/e6c0949c/attachment.sig>