[ppml] Policy Proposal 2007-15: Authentication of Legacy Resources

Leo Bicknell bicknell at ufp.org
Wed Jul 25 20:42:35 EDT 2007

In a message written on Wed, Jul 25, 2007 at 05:00:27PM -0400, William Herrin wrote:
> 1. Ending RDNS for legacy registrants violates both the spirit and the
> letter of how ARIN promised to treat the legacy registrants during its
> formation a decade ago. If circumstances require ARIN to walk away
> from its promise, then a decent respect to the community it serves
> requires ARIN to acknowledge the breach and declare the causes which
> compel it. This proposal does an adequate job of neither.

I'm really interested by the concept of an "implied contract" for
legacy space.  I generally agree with the late great Samuel Godlwyn,
"A verbal contract isn't worth the paper it's written on."  However
I've attempted to put that aside and try to see things from the
other side of the coin here.

First, a reminder of what makes a contract.


Let's walk through it.

Was there a "meeting of the minds", specifically with respect to
the following issues:

That the contract was...
  * permanent.
  * transferable.
  * survivable.
  * reassignable.
  * automatically extended to cover "new services".
  * for the "ownership" of the space.
  * for the "right to use" the space.
  * unable to be amended by future policy changes.
  * that the implied contract with ARIN is identical to the original
    contract and not a new contract.

Offer and acceptance seems pretty clear, IP space was offered in
exchange for the user filling out various paperwork and providing
various information.  [Note, said paperwork and information changed
over time; which may have bearing on some of the points above.]

Mutual consideration.  The requester obtains address space they can
use, that part is clear.  What of value goes in the other direction.
It surely wasn't money in the early days.  The only thing that seems
clear to me is information, namely the company name and contact
information.  The thing of value provided by the requester is the
information about who's responsible for the block.

Performance / Delivery.  Now we get to some really interesting
ideas.  If you take that part of the mutual consideration was the
exchange of a range of addresses for contact information, than
doesn't letting your contact information lapse (specifically e-mail
and snail mail information that is undeliverable) represent breach
of contract?  If your RDNS servers fall lame, would that be enough to
represent breach of contract?

Good faith.  If the requester thought the contract covered things
that SRI, InterNIC, DoDNIC or others did not, were they acting in
good faith?  It largely goes back to the meeting of the minds

No violation of public policy.  Wow, here's a briar patch.  Is
ARIN's "Open Policy Process" public policy?  Do the contracts between
ICANN and the Government constitute public policy that may limit
the contract?  Issues that quickly become quite complicated.

However, some public policy is simpler.  Contracts generally have
to abide by the statue of frauds.  See
http://en.wikipedia.org/wiki/Statute_of_frauds.  Of interest here,
if legacy space is more like a lease, where ARIN maintains RDNS and
whois records then would it not be a contract that cannot be performed
in a year and thus generally be required to be in writing?  If you
take the view that legacy space is more like property, then you run
up against goods over $500 need to have a contract in writing.
What's the value of a /24?  Of a /16?

Objectively, I would not want to be ARIN or a Legacy Holder should
this ever go to court.  If I were a betting man I'd bet neither
side got what they wanted.

Indeed, that's the crux of the whole problem.  I think it's clear
at this point that to have a meeting of the minds, in the contract
or philosophical sense both sides are going to have to move to the
middle.  Neither party is going to concede to the other.  The
question is, how do we come together and find some reasonable middle

       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- 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/20070725/93f6821b/attachment-0001.sig>

More information about the ARIN-PPML mailing list