Can a customer take their IPs with them? (Court says yes!)

Paul Robinson postmaster at paul.washington.dc.us
Tue Jun 29 17:47:48 UTC 2004


In an attempt to add a little more light than heat to this issue, let me add my .02 Euros.  I am not a lawyer although I've had to defend myself in court a few times, so I do know a few things.

This is a temporary restraining order.  These are commonly issued "ex parte" meaning at the request of one of the parties and may even be done where the other party did not even show up or was given notice.  The purpose is to "preserve the status quo."  The court apparently - from the description of the TRO - issued it verbatim as the plaintiff filed it.  I doubt the court even knew what half the terms on the order meant.  I had trouble and I'm somewhat familiar with Internet networking.

In the case at hand, it may be that the contract with the provider could in theory have allowed immediate repossession of the IP address space which was loaned to them in the event they changed providers.  In which case, if the company that has the particular IP space, allowing them to have their address range "snatched away" from them immediately would constitute irreparable harm, since it can take up to a week for an address change to propagate throughout the Internet.

A Temporary Restraining Order is intended to keep things as they are at the time it was issued, until such time as a court has the opportunity to hear evidence and to make a decision.  Generally they are issued subject to the following conclusions:

1.  The party asking for the order (the plaintiff, here) is quite likely to suffer irreparable harm if the relief requested by the order is not granted.
2.  The party to whom the order is issued against (the defendant, here) either will not suffer harm as a result of the order or the amount of harm is minor or substantially less than that which would occur to the other party if the order isn't granted..

There are additional conditions involved, but these are the two most important.  Here, allowing the customer to keep the number on a temporary basis while the court decides the issue does not necessarily harm the defending ISP and failing to do so would probably be devastating to the customer.

Now, to the extent the customer has other options (such as using the number block which they have been assigned directly) will provide the court with a reasonable solution as to why the TRO should be dissolved after the customer has some reasonable time to correct the problem, e.g. to renumber their systems and advertise the new routes to the various routers and DNS systems might require, say 7-10 days.  

Also, if the contract between the company and the ISP provides them sufficient protection to allow them the time necessary to renumber and reroute then the need for the TRO becomes moot.  However, if the contract was silent on this point or explicitly allowed immediate repossession then the TRO may have been a valid issue in order to preserve the status quo for the time being until the issue can be sorted out.

This is the basic reason such decisions are issued, so that things can remain as they are until the court can figure out who is entitled to relief.  It does not necessarily mean the customer will win or even has a valid cause of action, it just simply means that it is less catastrophic to the ISP to require they not "yank" the IP addresses from the customer than it would be to allow them to do so, pending the outcome of the actual trial on the merits of the issues involved.

Please excuse me if this is obvious, but I thought it might help.

--
Paul Robinson  "Above all else... We shall go on..."
"...And continue!"
"If the lessons of history teach us anything it is
that nobody learns the lessons that history teaches us."


-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/P d-(-)>-- s+:+++ a+ C++ UL--->$ P+ L+>$ !E W++>$ N++ !o !K-- w+>--$ O->- !M-- !V- PS+++>$ PE !Y !PGP t> !5 !X !R tv+ b++++(++++)>++++ DI() D++>++ G> e> h+(+)>$ r> y+**(+) 
------END GEEK CODE BLOCK------ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20040629/dc86ac68/attachment.html>


More information about the NANOG mailing list