[arin-ppml] A compromise on legacy space?

[Leo Bicknell]

There are many reasons people are interested in legacy space, and
I personally find some level of merit to all of them:

- Updating contact information and/or securing (e.g. via PGP, S/MIME)
  updates to the records.
- Having Legacy Holders pay their "fair share".
- Finding fallow space, and reclaiming it.  [Both the truly fallow,
  e.g. all people/companies associated with it are dead/dissolved,
  and space where someone is still associated, but it is not being
  used.]
- Preventing unfair addressing competition (ISP's giving away a /24
  of their legacy space with a new circuit, no justification
  required.).

As I've also said before, there are multiple subgroups of legacy
space users.  Treating a person with their own personal /24 the
same way a large ISP is treated that has a legacy /8 doesn't make
any sense.  They are different situations, and very different
cost/benefit situations for ARIN and the community.

It seems to me it may be prudent then to divide the group.  I've been
pondering how to do that in a fair manor though, and I think I've come
up with a good idea.  I post it here for everyone else to rip apart.

Group #1:
  Definition: Legacy holders who also hold space covered by a regular
              ARIN RSA.

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.

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.

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.

Group #1 fixes what I feel are the worst violations of the community
trust.  There are plenty of ISP's with legacy resources and ARIN
assigned resources that have used the legacy ones over the years
to game the system.  At various points in time I have seen first
hand companies giving out resources with no justification, or coming
back to ARIN for new resources without showing they have used their
legacy resources.  I believe this has always been unfair to the
community as a whole, and that it is absurd that a single company
might be able to treat two numbers from the same pool differently
because of when they received them.  They are a global, community
resource and need to be treated as such.

Group #2 doesn't generally have that problem.  It's a bunch of
individuals and small businesses that have never 'come back to the
well'.  They are living in their legacy space and happy to keep
doing so.  There is no fairness issue here, no need to expend
resources harassing this group.  As I've stated before, I strongly
believe it is in both parties interest to have a contract, and also
to have some requirement for periodic touch.

What do people think?

-- 
       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/ae31e279/attachment.sig>