[arin-ppml] ARIN actions regarding address blocks with no valid POCs (was: Re: Deceased Companies?)

[Ronald F. Guilmette]

In message <651e83ae-3cb5-c5ff-5601-07ffefd44550 at ipinc.net>, 
Ted Mittelstaedt <tedm at ipinc.net> wrote:

>It is likely that what the community does with regards to the legacy 
>blocks will have an effect on the "deceased company" issue but the 
>simple reality with registered blocks, which John has tried to get 
>people to understand, is that as long as an entity is paying the renewal 
>fees, while it might be apparent that the block is "on autopilot" and is 
>not in use/being sat on/etc. and that is incredibly irritating, the 
>existence of ongoing payments and ongoing claims that the block is "in 
>use" by the payor and the existence of the original contract between the 
>entity and the RIR, all of that establishes a legal right to continue to 
>have the registration, by that entity.

No.  I believe that you are seriously misreading and misinterpreting John's
comments.

My interpretation of John's comments here recently is that if indeed a
legal entity to which ARIN staff had assigned some resources ceases to
exist, e.g. because it has been dissolved, then by definition, and under
law, any previously executed RSA or LRSA that the entity in question and
ARIN both entered into is effectively null and void.  Standing on its own,
any such contract has no more legal weight than if you had a contract with
a dead man.

     "If you had a contract, it was with him, and it died with him."
                                -- Pappagallo (Michael Preston)
                                -- The Road Warrior (1981)

I am in complete agreement with this viewpoint, and indeed, I believe that
this is the only legally defensible view that it is possible to have on this.

>From a legal perspective, it doesn't matter one wit if some _other_ person,
persons, corporate entities, or some other unrelated mystery benefactor(s)
have been continuing to pay the annual ARIN invoices.  Absent some explicit
judicial ruling to the contrary, you can't have a contract with a dead man,
or with a dead company.  That's just not how any of this works.

Now, it is of course possible that some court in some jurisdiction _may_
possibly issue a ruling that the dead company's assets, including, in
particular, its ARIN-administered number resources (or the rights associated
therewith), shall be transfered to some new and different "owner", but if
ARIN staff do not receive a verified copy of such a judicial ruling in a
timely fashion then there is nothing which would reasonably preclude ARIN
from simply (and unilaterally) declaring the old contract null and void,
and then returning all relevant number resources to inventory.

Please note also that the most recent version(s) of the RSA and LRSA take
some pains to assert that EVEN IF some heir, successor, or assign (or any
other party) of some recently deceased entity were to try to have a court
transfer ARIN-administered number resource assets to that heir, successor,
or assign, any such attempt is itself null, void, and contrary to the plain
terms of the RSA/LRSA contract, (See Section 7 and also Section 10(c).)

Also, John asserted another sepatate but relevant point:  He knows of no
special "magic" which forces, legally or otherwise, ARIN to treat legacy
resources any differently from non-legacy resources EXCEPT insofar as ARIN
staff have been explicitly _instructed_ to treat legacy resources differently
BY THE COMMUNITY.  (I feel sure that John will correct me if I am
misrepresenting his recent comments here in any way, but I don't think that
I am.)

So there you have it friends.  Legally speaking, and in the absence of any
explicit judicial ruling to the contrary, it doesn't matter in the slightest
if some related or unrelated party has or has not continued to pay the
annual ARIN invoices.  It also doesn't matter in the slightest if the
number resources at issue are legacy or non-legacy.  If the legal entity
to which the resources were originally assigned is dead, then it's dead.
Full stop.  (Note that the vast majority of both legacy and non-legacy
resource registrants are quite obviously non-dead, e.g. AT&T, the U.S.
Department of Defense, MIT, Hewlett Packard, Stanford University, Apple,
Inc. etc., etc..)

For all entities that _are_ dead/dissolved however, ARIN owes them nothing,
for the simple reason that there is no applicable contract which has not
already been rendered null and void by the demise of all such entities.
And it logically follows that ARIN can do with the assigned number resources
of all such entities whatever it pleases, or, more accurately, whatever the
community directs ARIN staff to do with or about such resources.

>The actual truth is that if the community was united it could revoke all 
>legacy blocks tomorrow despite whatever legalities people out there 
>would argue. 

I am not persuaded that this is true.  As I have argued above, I believe
that ARIN staff may, if so directed by the community, reclaim and return
to inventory most or all of the number resources that have been assigned
to legal entities that are provably dead.  (The only rare exceptions would
arise when some misguided judge someplace issues an explicit order saying
otherwise.)  The set of provably dead legal entities is likely a subset of
_both_ (a) legacy registrants and (b) non-legacy registrants, but it is by
no means all, nor even a majority of either of those two categories.

Where a legacy registrant is still provably alive, I think that ARIN would
be ill-advised, for multiple reasons, to try to reclaim any associated
number resources.

My view is very different however when it comes to dead resource registrants.
Keeping these corporate zombies on ARIN's books is clearly a Bad Idea, and
for multiple reasons.  My hope is that others here will agree with this view,
and I do intend to submit a policy proposal which, if adopted, would have
the effect of explicitly directing ARIN staff to reclaim the assigned
resources of any such dead entity, as and when they become aware of any such.


Regards,
rfg