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

Hi,

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.

I tend to agree. Reasonable time to migrate appears to be reasonable
"grace period." If unreasonable planning, hard (for me) to understand
need for unreasonable "grace period." 'reasonable' of course in need
of a defintion, but from what I see most (but perhaps not all, these
days... so I may be wrong) service providers allow sufficient "grace
period" to make the technical needs fly. I'm far from sure non-technical
issues should imply extended "grace period." Hrm,...

My few �ren (or french or canadian cents, if preferred :slight_smile:

mh

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.

How do you arrive at this conclusion? Did you read the filings? This is not
the customers position. Since I have only the customers filings and the judges
TRO online it maybe that NAC has counter claims of their own. However
in that case both parties would have put forth reasonable postions and the
I believe the standard then would be that the judge would have to look
at the harm
done to both parties. In the case of the customer they present an at
least passable
case that this will cause them to be put out of business. Thus the judge says,
Ok you keep paying NAC what you were paying them and NAC you work with
them to transtion NAC can certainly challenge the TRO as indicated in the
document itself

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.

And they claim they did but that NAC did not negotiate in good faith.
Also that as NAC
has indicated a desire to purchase them may have reason not to
negotiate in good faith.

No, it's just the unit got mangled through sloppy usage. It was
written as "60 megawatt hours", i.e. 60,000 kWh of energy.

Any ISP that drew 60MW would probably be visible from space :slight_smile:

>
>
> 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.

How do you arrive at this conclusion? Did you read the filings? This is not
the customers position. Since I have only the customers filings and the judges
TRO online it maybe that NAC has counter claims of their own. However

The customer's unhappy.. but I dont see anything bad going on here..

The customer's wording is sloppy for a legal doc and they have silly points
raised, like because nac wont accept payment by credit card they are forced to
pay off their outstanding balance hence having to pay twice (one to the card one
to nac) .. well duh .. thats how it works. Non-portability of IP space is well
known, sure, its hard work and I wouldnt wish to do it but its normal - right?

Yeah theyre upset, this story has history that we're not seeing and I'm sure for
that reason NAC are playing hard ball here. But I dont think wrt the question of
leaving NAC and the timescales and cancellation process involved that anything
illegal or unexpected is occuring.

in that case both parties would have put forth reasonable postions and the I
believe the standard then would be that the judge would have to look at the
harm done to both parties. In the case of the customer they present an at
least passable case that this will cause them to be put out of business.
Thus the judge says, Ok you keep paying NAC what you were paying them and NAC
you work with them to transtion NAC can certainly challenge the TRO as
indicated in the document itself

Presumably the judge is unsure and doing what seems to be a sensible option..

I hope the customer is using the time well to do some renumbering pdq!

> 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.

And they claim they did but that NAC did not negotiate in good faith. Also
that as NAC has indicated a desire to purchase them may have reason not to
negotiate in good faith.

Maybe, happens.. again dont know the history, not sure its important..

Steve

> > 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.
>
> How do you arrive at this conclusion? Did you read the filings? This is not
> the customers position. Since I have only the customers filings and the judges
> TRO online it maybe that NAC has counter claims of their own. However

The customer's unhappy.. but I dont see anything bad going on here..

It is very simple -

  Plaintiff files a motion.
  Defendant tries to have it dismissed (or maybe for whatever reason
      decides that as the network engineers they
      don't care about what a court has to say and ignores it)
  Plaintiff shows that he has a case.
  Defendant is unable to convince a judge that the plaintiff is full
  Judge grants the TRO.
  Defendant waves arms on nanog-l.

Moral -

  When a legal system is involved, use the legal system, not the
  nanog-l. The former provides provides ample of opportunities to
  deal with the issues, while the later only provides ample of
  opportunities to do hand waving.

The customer's wording is sloppy for a legal doc and they have silly
points raised, like because nac wont accept payment by credit card they
are forced to pay off their outstanding balance hence having to pay twice
(one to the card one to nac) .. well duh .. thats how it works.
Non-portability of IP space is well known, sure, its hard work and I
wouldnt wish to do it but its normal - right?

  The customer wording happened to be excellent - and TRO is a proof
of it. The court does not care about the good of internet and
portability/non-portability of IP address space because it is not the case
in front of it.

Presumably the judge is unsure and doing what seems to be a sensible option..

  Never presume. Always file.

Alex

OK... I'll take the risk here...

These guys look to be gross address polluters -- Here's what I found:

1. Pegasus Web Technologies is listed as AS25653 (ARIN whois)
2. route-views.oregon-ix.net has the following to say about prefixes
  with origin in AS25653 (only the first listed path is shown for each
  prefix):

route-views.oregon-ix.net>$ quote-regexp "_25653$" | include ^...[0-9]

*> 64.21.40.0/24 209.123.12.51 0 8001 25653 i
*> 64.247.26.0/24 209.123.12.51 0 8001 25653 i
*> 64.247.27.0/24 209.123.12.51 0 8001 25653 i
*> 64.247.30.0/24 209.123.12.51 0 8001 25653 i
*> 64.247.31.0/24 209.123.12.51 0 8001 25653 i
*> 64.247.34.0/24 209.123.12.51 0 8001 25653 i
*> 64.247.35.0/24 209.123.12.51 0 8001 25653 i
*> 64.247.47.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.3.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.28.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.32.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.33.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.35.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.36.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.37.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.38.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.39.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.40.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.41.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.42.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.43.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.44.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.49.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.50.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.51.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.52.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.53.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.54.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.55.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.60.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.62.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.63.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.64.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.65.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.74.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.75.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.76.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.77.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.78.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.85.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.86.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.87.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.88.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.89.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.97.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.98.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.106.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.107.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.108.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.109.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.110.0/24 209.123.12.51 0 8001 25653 i
*> 66.246.111.0/24 209.123.12.51 0 8001 25653 i
* 69.9.165.0/24 216.218.252.152 0 6939 4436 29791 25653 i
* 69.57.160.0/19 216.218.252.152 0 6939 8001 25653 i
* 69.72.128.0/18 216.218.252.152 0 6939 8001 25653 i
* 69.72.192.0/19 216.218.252.152 0 6939 8001 25653 i
* 69.72.224.0/19 216.218.252.152 0 6939 8001 25653 i
*> 207.99.34.0 209.123.12.51 0 8001 25653 i
*> 207.99.104.0 209.123.12.51 0 8001 25653 i
*> 207.99.126.0 209.123.12.51 0 8001 25653 i
*> 209.123.49.0 209.123.12.51 0 8001 25653 i
*> 209.123.61.0 209.123.12.51 0 8001 25653 i
*> 209.123.73.0 209.123.12.51 0 8001 25653 i
*> 209.123.134.0 209.123.12.51 0 8001 25653 i
*> 209.123.184.0 209.123.12.51 0 8001 25653 i
*> 209.123.246.0 209.123.12.51 0 8001 25653 i
*> 209.123.247.0 209.123.12.51 0 8001 25653 i
* 209.123.252.0/22 193.0.0.56 0 3333 6320 8001 25653 i
* 216.67.224.0/19 216.218.252.152 0 6939 8001 25653 i
*> 216.118.123.0 209.123.12.51 0 8001 25653 i

Of those, the following prefixes appear to have non-NAC transit paths:

  69.9.165.0/24

And the following are not exclusively "8001 25653"

  69.72.128.0/18
  69.72.192.0/19
  69.72.224.0/19
  216.67.224.0/19

I am not encouraging anyone to take any specific action WRT these prefixes,
and, I have not been asked or encouraged directly or indirectly by Alex
Rubenstein or any other NAC employee to post this. In fact, I have not
been contacted by anyone from NAC other than Alex's original pre-TRO
post. I have done this research of my own choosing based on other posts
from the community and am posting the results purely for informational
purposes.

Owen

These guys look to be gross address polluters -- Here's what I found:
*> 64.21.40.0/24 209.123.12.51 0 8001 25653 i

hmmm notice that all of these /24's are from ^_8001_ which peers with
route-views.oregon-ix.net which may from time to time include internal
iBGP prefixes that are otherwise not advertised to regular transits/peers,
to their way of making to GRT.

What you pasted is what route-views.oregon-ix.net sees. What I see is:

*> 69.9.165.0/24 63.239.36.245 1923 100 0 209 3549 4436 29791 25653 i
*> 69.57.160.0/19 63.239.36.245 1923 100 0 209 701 8001 25653 i
*> 69.72.128.0/18 63.239.36.245 1923 100 0 209 701 8001 25653 i
*> 69.72.192.0/19 63.239.36.245 1923 100 0 209 701 8001 25653 i
*> 69.72.224.0/19 63.239.36.245 1923 100 0 209 701 8001 25653 i
*> 216.67.224.0/19 63.239.36.245 1923 100 0 209 701 8001 25653 i

What cidr-report.org sees:
69.9.165.0/24 4637 4436 29791 25653
69.57.160.0/19 4637 8001 25653
69.72.128.0/17 4637 8001 25653 + Announce - aggregate of 69.72.128.0/18 (4637 8001 25653) and 69.72.192.0/18 (4637 8001 25653)
69.72.128.0/18 4637 8001 25653 - Withdrawn - aggregated with 69.72.192.0/18 (4637 8001 25653)
69.72.192.0/19 4637 8001 25653 - Withdrawn - aggregated with 69.72.224.0/19 (4637 8001 25653)
69.72.224.0/19 4637 8001 25653 - Withdrawn - aggregated with 69.72.192.0/19 (4637 8001 25653)
216.67.224.0/19 4637 8001 25653

-J