North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Can a Customer take their IP's with them? (Court says yes!)

  • From: Stephen J. Wilcox
  • Date: Tue Jun 29 16:12:41 2004

Hi James, 
 i would agree except NAC seems to have done nothing unreasonable and are 
executing cancellation clauses in there contract which are pretty standard. The 
customer's had plenty of time to sort things and they have iether been unable to 
or unwilling to move out in the lengthy period given.

This too isnt uncommon and the usual thing that occurs at this point is the 
customer negotiates with the supplier for an extension in service which they pay 
for.

These guys seem to not want to admit they've failed to plan this move, dont want 
to pay for their errors and are now either panicking or trying to prove a point 
to NAC.

Steve

On Tue, 29 Jun 2004, James wrote:

> 
> quite frankly, looking at the TRO (thanks Richard for posting them here), UCI has
> requested permission to use Prior UCI Addresses being part of NAC, until September
> 1st, 2004. i am failing to see the problem with this TRO, given that customer is
> simply requesting relief & guarantees that their move-out operation to new facility
> shall go unrestricted and not interfered by NAC.
> 
> granted, the actual order fell from the court doesn't specifically state 9/1/04 as
> the deadline (which would be the policy issues w/ IP address portability), I think
> we need to take a look at both side's opinions and situations before blackholing
> NAC->UCI leased IP space(s) out of the blue as some here on this mailing list have
> stated they would do so.
> 
> all i can see here is that UCI, being a customer is simply interested in doing
> what they can do to protect their business. moving entire business operational 
> assets between colocation facilities is not an easy task, and can be quite risky
> for them. yes, i would take issues if UCI is simply requesting permanent portability
> of the IP space administrated by NAC, but so far looking at the documents, it
> appears UCI seems to be requesting enough period of time to help with their transition
> to the new facility, including enough time for renumbering of IP addresses in the
> process.
> 
> Page 15, 45. of http://e-gerbil.net/ras/nac-case/restraining-order.pdf
> 
> my 0.02
> 
> -J
> 
> On Tue, Jun 29, 2004 at 12:24:44PM -0400, Richard A Steenbergen wrote:
> > 
> > On Tue, Jun 29, 2004 at 09:11:08AM -0700, william(at)elan.net wrote:
> > > 
> > > 
> > > Actually, after reading most of the papers which Richard just made available
> > > at http://www.e-gerbil.net/ras/nac-case/ I don't see that court made an 
> > > incorrect decision (it however should have been more clear enough on when 
> > > TRO would end in regards to ip space). If you read through 
> > 
> > It is very likely that Pegasus made the correct decision to protect their
> > business, regardless what a bunch of engineers on NANOG think about the IP
> > space question. It also seems that the TRO is about far more than IP space
> > (i.e.  the continuation of full transit services, at existing contract
> > rates).
> > 
> > > then they did other customers. Now, I do note that is probably just one
> > > side of the story, so likely there would be another side as this 
> > > progresses through court (hopefully Richard will keep the webpage current 
> > > with new documents), atlthough I have to tell you what I saw mentioned so 
> > > far did not show NAC or its principals in the good light at all.
> > 
> > I would like to post the NAC response to this so that we can hear all
> > sides of the story, but unfortunately the case was moved from the US
> > District Court back to the NJ Superior Court, where I no longer have easy
> > access to the documents. I would be happy to take offline submissions of
> > the legal filings from anyone willing to waste more on this than the
> > $0.07/page that PACER charges. :)
> > 
> > -- 
> > Richard A Steenbergen <[email protected]>       http://www.e-gerbil.net/ras
> > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
> 
>