Re: Network nerd poker night 11/8 in Seattle

[Gordon Cook]

Hi Avi

long time no talk

 regards Gordon


> On Nov 7, 2017, at 3:22 PM, Avi Freedman  wrote:
> 
> 
> If there are any network+poker nerds in the Seattle area tomorrow, we have 5 
> seats left at a network nerd poker night I'm hosting tomorrow night.
> 
> Attendees are from cloud, content provider, hosting, infra services, travel, 
> and SaaS analytics industries.
> 
> We'll have food, drinks, a training session, and will be running ~3 
> single-table No Limit Texas Hold'em tournaments.  
> 
> If there's time/interest afterwards I may also initiate anyone interested 
> into the wonders of Pot Limit Omaha.
> 
> Prizes will be Bose head sets, to avoid corporate gift issues with playing 
> for or awarding $.
> 
> It's at the W Hotel in Bellevue, at 6pm tomorrow night.
> 
> The focus is poker, socializing, and free-form network tech, business, and 
> policy nerd discussions.  Travel and gadget geeking allowed as well.  Kentik 
> is sponsoring the space, tables, and professional dealers, and we'll have a < 
> 5 minute sponsor presentation.
> 
> RSVP / info @ 
> https://www.greenvelope.com/viewer/?ActivityCode=.public:ab155c3532ca4bd5ad563ff222b6a338393435313037#details
> 
> If it overflows we'll cut off RSVPs at the URL and/or let people know by 
> email.
> 
> We're also going to organize to do another in Seattle in Feb and larger ones 
> in NY and the Bay area in Q1, so if you have interest or ideas for format or 
> quick content topics we could cover, please let me know.  One thing we're 
> considering is adding a table for heads-up battles - participants to decide 
> if they want to add peering as part of the stakes.
> 
> Thanks,
> 
> Avi
> 

Re: Google Cloud and IX - Traffic behavior

[Gordon Cook]

Hi Alain and all the rest
  I het it now 

no offense and alain no harm done and all of nanog thank you and i will 
continue observing as i have since 1995

thank you allagin
PS and BTW i am interested in CLOUD

:-)
thanks once more




> On Jun 19, 2017, at 9:36 AM, Alain Hebert  wrote:
> 
>Hi,
> 
>Yes Stephen, we're talking the usual like GTT...
> 
>And no latency wise they're about the same.  In the 35ms range.
> 
>But I still can't figure out the 10 x drop, that level of latency alone 
> cannot be the factor.
> 
>( And Gordy...  what?!? )
> 
> -
> Alain Hebertaheb...@pubnix.net
> PubNIX Inc.
> 50 boul. St-Charles
> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
> Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
> 
> On 06/16/17 19:42, Stephen Fulton wrote:
>> Alain,
>> 
>> When you refer to "normal peering" do you mean Internet transit? Or are 
>> these PNI's with Google?  Do the GCLD instance you reach through "normal 
>> peering" have higher latency than through TorIX?
>> 
>> -- Stephen
>> 
>> On 2017-06-16 6:58 PM, Alain Hebert wrote:
>>> Hi,
>>> 
>>> Anyone aware of different traffic behavior depending if the target goes 
>>> through normal peering than through an exchanges google exists in?
>>> 
>>> We're facing a weird issue where the same GCLD Instance can upload up 
>>> to 200Mbps (Ref 1) if the target path goes through, lets say TorIX, but 
>>> cannot get more than 20Mbps on similar hosts (8 of them) sittings on our 
>>> peering links.
>>> 
>>> PS; Those sames hosts get up to their link limit ( 1Gbps ) between each 
>>> others and others test points we have;
>>> 
>>> PS: Wireshark capture show nothing abnormal;
>>> 
>>> PS: Links aren't congested, and so on...
>>> 
>>> Ref 1 - 200Mbps is on a link rate-limited to 300Mbps.  Its my only test 
>>> point with a TorIX access
>>> 
>> 
> 
> 

Re: Google Cloud and IX - Traffic behavior

[Gordon Cook]

 please accept my apologies this response was totally out of context

> On Jun 16, 2017, at 9:25 PM, Gordon Cook  wrote:
> 
> 
> i also see now that you are a guru rinpoche as wlell
> 
> but with valerie home any minute i must stop
> 
> will come back though
>> On Jun 16, 2017, at 7:42 PM, Stephen Fulton  wrote:
>> 
>> Alain,
>> 
>> When you refer to "normal peering" do you mean Internet transit?  Or are 
>> these PNI's with Google?  Do the GCLD instance you reach through "normal 
>> peering" have higher latency than through TorIX?
>> 
>> -- Stephen
>> 
>> On 2017-06-16 6:58 PM, Alain Hebert wrote:
>>>Hi,
>>>Anyone aware of different traffic behavior depending if the target goes 
>>> through normal peering than through an exchanges google exists in?
>>>We're facing a weird issue where the same GCLD Instance can upload up to 
>>> 200Mbps (Ref 1) if the target path goes through, lets say TorIX, but cannot 
>>> get more than 20Mbps on similar hosts (8 of them) sittings on our peering 
>>> links.
>>>PS; Those sames hosts get up to their link limit ( 1Gbps ) between each 
>>> others and others test points we have;
>>>PS: Wireshark capture show nothing abnormal;
>>>PS: Links aren't congested, and so on...
>>> Ref 1 - 200Mbps is on a link rate-limited to 300Mbps.  Its my only test 
>>> point with a TorIX access
>> 
> 
> 

Re: Google Cloud and IX - Traffic behavior

[Gordon Cook]

i also see now that you are a guru rinpoche as wlell

but with valerie home any minute i must stop

will come back though
> On Jun 16, 2017, at 7:42 PM, Stephen Fulton  wrote:
> 
> Alain,
> 
> When you refer to "normal peering" do you mean Internet transit?  Or are 
> these PNI's with Google?  Do the GCLD instance you reach through "normal 
> peering" have higher latency than through TorIX?
> 
> -- Stephen
> 
> On 2017-06-16 6:58 PM, Alain Hebert wrote:
>> Hi,
>> Anyone aware of different traffic behavior depending if the target goes 
>> through normal peering than through an exchanges google exists in?
>> We're facing a weird issue where the same GCLD Instance can upload up to 
>> 200Mbps (Ref 1) if the target path goes through, lets say TorIX, but cannot 
>> get more than 20Mbps on similar hosts (8 of them) sittings on our peering 
>> links.
>> PS; Those sames hosts get up to their link limit ( 1Gbps ) between each 
>> others and others test points we have;
>> PS: Wireshark capture show nothing abnormal;
>> PS: Links aren't congested, and so on...
>> Ref 1 - 200Mbps is on a link rate-limited to 300Mbps.  Its my only test 
>> point with a TorIX access
> 

Re: Templating/automating configuration

[Gordon Cook]

agree
 again all of  the above
 
thanks
> On Jun 11, 2017, at 7:58 PM, Gordon Cook  wrote:
> 
> again  I understand and agree
> 
> 
> 
> the reach of your drowning analysis and understanding is awesome
> 
> hi randy bush
> 
> 
> oops and hi jp confused of calcutta and chris locke rage boy  
> 
>> On Jun 7, 2017, at 6:17 PM, Andrew Dampf  wrote:
>> 
>> Salt is great for generating configs based on jinja templates, and you can
>> use napalm in conjunction with salt to push the configs to the device on a
>> set schedule (typically this is done hourly). If manual changes are made to
>> the router, salt would override them on the next run, so it's a great way
>> to make sure configs are consistent.
>> 
>> 
>> On Tue, Jun 6, 2017 at 9:25 AM Graham Johnston 
>> wrote:
>> 
>>> Short of complete SDN, for those of you that have some degree of
>>> configuration templating and/or automation tools what is it that you run?
>>> I'm envisioning some sort of tool that let's me define template snippets of
>>> configuration and aids in their deployment to devices. I'm okay doing the
>>> heaving lifting in defining everything, I'm just looking for the tool that
>>> stitches it together and hopefully makes things a little less error prone
>>> for those who aren't as adept.
>>> 
>>> Graham Johnston
>>> Network Planner
>>> Westman Communications Group
>>> 204.717.2829 <(204)%20717-2829>
>>> johnst...@westmancom.com<mailto:johnst...@westmancom.com>
>>> 
>>> 
>> 
> 
> 

Re: Templating/automating configuration

[Gordon Cook]

again  I understand and agree



the reach of your drowning analysis and understanding is awesome

hi randy bush


oops and hi jp confused of calcutta and chris locke rage boy  

> On Jun 7, 2017, at 6:17 PM, Andrew Dampf  wrote:
> 
> Salt is great for generating configs based on jinja templates, and you can
> use napalm in conjunction with salt to push the configs to the device on a
> set schedule (typically this is done hourly). If manual changes are made to
> the router, salt would override them on the next run, so it's a great way
> to make sure configs are consistent.
> 
> 
> On Tue, Jun 6, 2017 at 9:25 AM Graham Johnston 
> wrote:
> 
>> Short of complete SDN, for those of you that have some degree of
>> configuration templating and/or automation tools what is it that you run?
>> I'm envisioning some sort of tool that let's me define template snippets of
>> configuration and aids in their deployment to devices. I'm okay doing the
>> heaving lifting in defining everything, I'm just looking for the tool that
>> stitches it together and hopefully makes things a little less error prone
>> for those who aren't as adept.
>> 
>> Graham Johnston
>> Network Planner
>> Westman Communications Group
>> 204.717.2829 <(204)%20717-2829>
>> johnst...@westmancom.com
>> 
>> 
> 

Re: Russian diplomats lingering near fiber optic cables

[Gordon Cook]

I have just scanned this whole thread - it is the most amazing analysis of 
technical details I have e ver seen

national security also
sean I am taking this in the sense of what the hell could these russian 
diplomats be doing?

I have been a nanog reader  since this list began   in the spring of 1995 i 
believe

remember i am parsing comments from the russian side as well
 
 i met aleksei soldatov at the kurchatov institute for the first time in april 
1992.  about 3 days earlier i met  the demos guys who  told soldatov   
suggested to soldatov that  he  should met me  at kurchatov 

I followed the development of the russian internet very closely between April 
1992 and 1999  not much after that.

meanwhile i am
well aware of international fiber optic cables geographic issues of same  — see 
telegeography for example,  His coordinates etc
 interception  of cable via submarine etc

see the US Sub named Jimmy  carter

I visited Russia for the first time in 1964  
my dissertation completed in 1972

dis on site work for the Phd in Russia for 2 months summer of 1970
including pushkinskii Dom

Thanks to steve Goldstein of NSF I received an invite to attend the second Nato 
sponsored conference on the future e of   the  russian internet  met larry land 
weber there at Golitsyno - the conf  was sept 30 to Oct 2 1994 

The point?  I have long experience with my Cook Report on Internet Protocol  in 
April 1992 issue #1

and an even lon\ger experience  with russian history language and culture 

 I am also well aware this message will be readable by a ver large number of 
people both  here and abroad.

even visited the westin bldg In i think 1994.
 take a bow Sean!!

:-)



> On Jun 11, 2017, at 11:38 AM, Gordon Cook  wrote:
> 
> Hi Sean
> 
> You and I first met when i was at OIA about 1992   LOONG TIME ago
> 
> Always thought  of you as brilliant collector of info as well as analyst 
> there of 
> 
> this question of yours is absolutely brilliant
> 
> look at the responses (more) than 45!!!
> 
> 
> 
> 
> 
> 
>> On Jun 1, 2017, at 2:02 PM, Sean Donelan  wrote:
>> 
>> 
>> There must be a perfectly logical explanation  Yes, people in the 
>> industry know where the choke points are. But the choke points aren't always 
>> the most obvious places. Its kinda a weird for diplomats to show up there.
>> 
>> On the other hand, I've been a fiber optic tourist.  I've visited many 
>> critical choke points in the USA and other countries, and even took selfies 
>> :-)
>> 
>> 
>> http://www.politico.com/story/2017/06/01/russia-spies-espionage-trump-239003
>> 
>> In the throes of the 2016 campaign, the FBI found itself with an escalating 
>> problem: Russian diplomats, whose travel was supposed to be tracked by the 
>> State Department, were going missing.
>> 
>> The diplomats, widely assumed to be intelligence operatives, would 
>> eventually turn up in odd places, often in middle-of-nowhere USA. One was 
>> found on a beach, nowhere near where he was supposed to be. In one 
>> particularly bizarre case, relayed by a U.S. intelligence official, another 
>> turned up wandering around in the middle of the desert. Interestingly, both 
>> seemed to be lingering where underground fiber-optic cables tend to run.
>> 
>> According to another U.S. intelligence official, “They find these guys 
>> driving around in circles in Kansas. It’s a pretty aggressive effort.”
>> 
>> It’s a trend that has led intelligence officials to conclude that the 
>> Kremlin is waging a quiet effort to map the United States’ 
>> telecommunications infrastructure, perhaps preparing for an opportunity to 
>> disrupt it.
>> 
> 
> 

Re: Russian diplomats lingering near fiber optic cables

[Gordon Cook]

Hi Sean

You and I first met when i was at OIA about 1992   LOONG TIME ago

Always thought  of you as brilliant collector of info as well as analyst there 
of 

this question of yours is absolutely brilliant

look at the responses (more) than 45!!!






> On Jun 1, 2017, at 2:02 PM, Sean Donelan  wrote:
> 
> 
> There must be a perfectly logical explanation  Yes, people in the 
> industry know where the choke points are. But the choke points aren't always 
> the most obvious places. Its kinda a weird for diplomats to show up there.
> 
> On the other hand, I've been a fiber optic tourist.  I've visited many 
> critical choke points in the USA and other countries, and even took selfies 
> :-)
> 
> 
> http://www.politico.com/story/2017/06/01/russia-spies-espionage-trump-239003
> 
> In the throes of the 2016 campaign, the FBI found itself with an escalating 
> problem: Russian diplomats, whose travel was supposed to be tracked by the 
> State Department, were going missing.
> 
> The diplomats, widely assumed to be intelligence operatives, would eventually 
> turn up in odd places, often in middle-of-nowhere USA. One was found on a 
> beach, nowhere near where he was supposed to be. In one particularly bizarre 
> case, relayed by a U.S. intelligence official, another turned up wandering 
> around in the middle of the desert. Interestingly, both seemed to be 
> lingering where underground fiber-optic cables tend to run.
> 
> According to another U.S. intelligence official, “They find these guys 
> driving around in circles in Kansas. It’s a pretty aggressive effort.”
> 
> It’s a trend that has led intelligence officials to conclude that the Kremlin 
> is waging a quiet effort to map the United States’ telecommunications 
> infrastructure, perhaps preparing for an opportunity to disrupt it.
> 

verizon fios bounced a legit private email of mine telling me it was spam and they would not allow it

[Gordon Cook]

dear Nanog

Sorry to bother you,   I am sitting here in shock,   I have been a Verizon to  
FiOS customer for about the past six years at least I think maybe eight.
every now and then the Verizon server will bounce an email back and tell me 
that it’s busy or not functioning but just now it bounced one back and I’m 
sorry I don’t have a screenshot of what it said but it clearly said that it 
considered me to be a spammer.   I may be a lot of things but a spammer I am 
not.  ;-)   when I get an email bounced back Apple OS X  always volunteers to 
use the pair networks server and I always automatically take that choice giving 
it never a second thought.

 it also reminded me that there was a limit on the amount of private emails a 
customer could send.

 And it said I needed to take the alleged spam and send it to 

spamdetector.upd...@verizon.net  and if I remember correctly wait at least an 
hour and then try to send the message again.

 Stating very clearly that no human being would talk to me.

 what in God’s name is going on?   Please a year and a half or two years ago 
when a route  to Ecuador was being filtered a couple of NANOG folk  knew whom 
to contact and the problem was fixed in record time.   I am hoping   that I 
will experience the same thing.   I should not be a stranger to any old time 
Nanog-ers.   but right now I’m feeling really paranoid!

routing issue? could someone from verizon FiOS please take a look?

[Gordon Cook]

Verizon Fios cannot connect me  to  lavra.spb.ru 

This is the Russian site of the second most important monastery in Russia.

It is reachable from Boston  avra.spb.ru (91.218.229.131), 64 hops max, 52 byte 
packets
 1  192.168.100.1 (192.168.100.1)  2.293 ms  0.815 ms  0.764 ms
 2  100.64.0.129 (100.64.0.129)  1.108 ms  3.013 ms  1.068 ms
 3  10.16.28.1 (10.16.28.1)  1.411 ms  1.277 ms  1.068 ms
 4  10.16.13.1 (10.16.13.1)  4.796 ms  2.301 ms  5.207 ms
 5  69.46.226.129.lightower.net (69.46.226.129)  4.380 ms  3.138 ms  4.630 ms
 6  ae2.bstpmallj42.lightower.net (64.72.64.113)  3.768 ms  6.008 ms  3.888 ms
 7  xe-4-0-2.bar2.boston1.level3.net (4.53.56.153)  6.030 ms  4.890 ms  7.058 ms
 8  ae-231-3607.edge4.london1.level3.net (4.69.166.25)  91.525 ms  81.571 ms
ae-232-3608.edge4.london1.level3.net (4.69.166.29)  81.327 ms
 9  ae-231-3607.edge4.london1.level3.net (4.69.166.25)  78.121 ms
ae-232-3608.edge4.london1.level3.net (4.69.166.29)  79.734 ms  78.890 ms
10  195.50.122.186 (195.50.122.186)  173.491 ms  133.054 ms  198.495 ms
11  * * *
12  oversun-gw.transtelecom.net (217.150.54.25)  210.399 ms  138.519 ms  
139.291 ms
13  mr-o-rtc1-rsw-2.oversun.ru (94.198.48.154)  131.070 ms  131.007 ms  129.553 
ms
14  mr-o-rtc5-rsw-2.oversun.ru (94.198.48.110)  140.012 ms  208.023 ms  145.352 
ms
15  vip-h5.ihc-ru.net (91.218.229.131)  131.485 ms  133.319 ms  129.822 ms

and from comcast and other locations

apparently it has v6 routing info as well  ..someone much more knowledgable 
than i suggested that this can be a source of reachability problems

but  here is what happens on my machine

ordons-mac-pro:~ gordoncook$ traceroute lavra.spb.ru
traceroute to lavra.spb.ru (92.242.140.21), 64 hops max, 52 byte packets
 1  wireless_broadband_router (192.168.1.1)  0.654 ms  0.351 ms  0.295 ms
 2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  4.607 ms  4.326 ms  
7.869 ms
 3  g0-1-0-0.cmdnnj-lcr-22.verizon-gni.net (130.81.223.100)  12.172 ms  9.502 
ms  7.242 ms
 4  xe-9-1-6-0.ny5030-bb-rtr2.verizon-gni.net (130.81.199.226)  15.080 ms
xe-9-1-2-0.ny5030-bb-rtr2.verizon-gni.net (130.81.209.144)  8.986 ms
xe-4-1-8-0.ny5030-bb-rtr2.verizon-gni.net (130.81.209.84)  22.085 ms
 5  * * *
 6  0.ae1.br2.nyc4.alter.net (140.222.229.91)  79.467 ms  77.046 ms  74.729 ms
 7  204.255.168.114 (204.255.168.114)  85.591 ms  86.899 ms
204.255.168.110 (204.255.168.110)  87.011 ms
 8  be2061.ccr42.jfk02.atlas.cogentco.com (154.54.3.69)  96.323 ms
be2060.ccr41.jfk02.atlas.cogentco.com (154.54.31.9)  84.779 ms
be2061.ccr42.jfk02.atlas.cogentco.com (154.54.3.69)  85.063 ms
 9  be2482.ccr21.cle04.atlas.cogentco.com (154.54.27.157)  31.562 ms  31.990 ms
be2483.ccr22.cle04.atlas.cogentco.com (154.54.29.201)  27.548 ms
10  be2351.ccr41.ord01.atlas.cogentco.com (154.54.44.85)  37.087 ms
be2185.ccr42.ord01.atlas.cogentco.com (154.54.43.177)  42.273 ms
be2351.ccr41.ord01.atlas.cogentco.com (154.54.44.85)  39.590 ms
11  be2157.ccr22.mci01.atlas.cogentco.com (154.54.6.117)  49.793 ms
be2156.ccr21.mci01.atlas.cogentco.com (154.54.6.85)  50.583 ms
be2157.ccr22.mci01.atlas.cogentco.com (154.54.6.117)  49.492 ms
12  be2133.ccr22.sfo01.atlas.cogentco.com (154.54.30.65)  77.446 ms
be2132.ccr21.sfo01.atlas.cogentco.com (154.54.30.53)  77.060 ms
be2133.ccr22.sfo01.atlas.cogentco.com (154.54.30.65)  77.001 ms
13  be2164.ccr21.sjc01.atlas.cogentco.com (154.54.28.34)  74.999 ms  74.569 ms
be2165.ccr22.sjc01.atlas.cogentco.com (154.54.28.66)  74.852 ms
14  be2063.rcr21.b001848-1.sjc01.atlas.cogentco.com (154.54.1.162)  74.377 ms
be2095.rcr21.b001848-1.sjc01.atlas.cogentco.com (154.54.3.138)  77.126 ms  
89.476 ms
15  c1.sj.mpt.fiberinternetcenter.net (66.201.58.2)  82.483 ms  86.964 ms  
80.094 ms
16  sanjose2.barefruit.co.uk (66.201.32.134)  125.112 ms  106.932 ms  124.778 ms
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
31  * * *
32  * * *
33  * * *
34  * * *
35  * * *
36  * * *
37  * * *
38  * * *
39  * * *
40  * unallocated.barefruit.co.uk (92.242.140.21)  111.898 ms *
gordons-mac-pro:~ gordoncook$ 

PS:  my FIOS contract is up in april.  Any suggestion of how to avoid a $30 per 
month price increase would be greatly appreciated

OFF list of course  many thanks

Gordon Cook

COOK Report on Internet Protocol


signature.asc
Description: Message signed with OpenPGP using GPGMail

It worked! Huge Thanks Re: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking FLOKsociety.org by accident or on purpose?

[Gordon Cook]

Really glad i posted  take a boqand thank you again!
=
The COOK Report on Internet Protocol, (PSTN) 609 882-2572 
Back Issues: 
http://www.cookreport.com/index.php?option=com_docman&task=cat_view&gid=37&Itemid=61
  
 Cook's Collaborative Edge Blog 
 http://www.cookreport.com/wp/
  Subscription info: 
http://www.cookreport.com/index.php?option=com_content&view=article&id=54&Itemid=65
=










On Oct 4, 2013, at 3:50 PM, "Moore, Matthew S"  wrote:

> Thanks eric...scott
> 
> From: Sieg, Eric W
> Sent: Friday, October 4, 2013 3:14 PM
> To: Christopher Morrow
> Cc: Moore, Matthew S; Gordon Cook; Young, David E
> Subject: RE: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking 
> FLOKsociety.org by accident or on purpose?
> 
> Everything is complete, all associated prefix-lists for this customer have 
> been updated. 
>  
> Thank you for choosing Verizon,
>  
> Eric Sieg
> IP Non Managed Operations Support | IP/DNS/DNE Administration
> Tel: 248 728 5294 | Vnet: 443-5294
>  
> 
>   
>  
> From: christopher.mor...@gmail.com [mailto:christopher.mor...@gmail.com] On 
> Behalf Of Christopher Morrow
> Sent: Friday, October 04, 2013 3:01 PM
> To: Sieg, Eric W
> Cc: Moore, Matthew S; Gordon Cook; Young, David E
> Subject: Re: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking 
> FLOKsociety.org by accident or on purpose?
>  
>  
>  
> 
> On Fri, Oct 4, 2013 at 2:59 PM, Christopher Morrow  
> wrote:
>  
>  
> 
> On Fri, Oct 4, 2013 at 2:54 PM, Sieg, Eric W  wrote:
> I’ll get it added to their other sites and follow up with them to let them 
> know.  Give me about 20.
>  
>  
> sweet, thanks!
>  
> forgot, from a fios customer perspective:
>  2  G0-9-4-6.WASHDC-LCR-22.verizon-gni.net (130.81.183.118)  10.434 ms  6.308 
> ms  3.699 ms
>  3  ae6-0.RES-BB-RTR1.verizon-gni.net (130.81.199.146)  5.45 ms 
> ae5-0.RES-BB-RTR1.verizon-gni.net (130.81.209.222)  3.375 ms 
> ae2-0.RES-BB-RTR1.verizon-gni.net (130.81.199.138)  4.592 ms
>  4  0.ae4.XL2.IAD8.ALTER.NET (152.63.8.125)  8.32 ms  3.457 ms  5.700 ms
>  5  0.xe-9-3-0.GW9.IAD8.ALTER.NET (152.63.36.34)  5.820 ms 
> 0.xe-9-0-0.GW9.IAD8.ALTER.NET (152.63.36.18)  7.311 ms 
> 0.xe-11-2-1.GW9.IAD8.ALTER.NET (152.63.42.2)  6.568 ms
>  6  telefonica-gw.customer.alter.net (152.179.50.114)  3.767 ms  4.74 ms  
> 5.569 ms
>  7  Te0-7-0-5-grtmiana4.red.telefonica-wholesale.net (94.142.126.182)  48.345 
> ms  46.997 ms 
> Xe4-1-6-0-grtmiana2.red.telefonica-wholesale.net(94.142.123.145)  46.154 ms
>  8  176.52.251.197 (176.52.251.197)  44.747 ms 176.52.251.189 
> (176.52.251.189)  74.746 ms 176.52.249.241 (176.52.249.241)  49.805 ms
>  9  176.52.252.66 (176.52.252.66)  99.787 ms  98.471 ms  97.103 ms
> ^C
>  
> looks like it works now.
>  
>  
> Thank you for choosing Verizon,
>  
> Eric Sieg
> IP Non Managed Operations Support | IP/DNS/DNE Administration
> Tel: 248 728 5294 | Vnet: 443-5294
>  
> 
>   
>  
> From: Moore, Matthew S 
> Sent: Friday, October 04, 2013 2:43 PM
> To: Christopher Morrow; Gordon Cook
> Cc: Young, David E; Sieg, Eric W
> Subject: RE: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking 
> FLOKsociety.org by accident or on purpose?
>  
> Hi Chris,
> 
>  
> 
> Uncloaking. ;-)
> 
>  
> 
> It does look as though it's a matter of an un-updated prefix-filter for 
> telefonica.  The existing filter allows a bunch of /24's
> 
> close to the address in question but 200.10.150.0/24 is not among them, 
> whereas telefonica is announcing it to us. (shown, hidden, below)
> 
>  
> 
> scottm@GW9.IAD8> show route receive-protocol bgp 152.179.50.114 hidden | 
> match 200.10.150
> 
>   200.10.150.0/24 152.179.50.114   0  12956 12956 
> 12956 12956 12956 12956 12956 19169 27947 28027 I
> 
>  
> 
> I added the filter, and I'm cc'ng Eric in Customer Support to let him know.  
> It will make sense to update it across all 12956 sessions, as I only did this 
> one… no longer hidden… 
>  
> 
>  
> 
> scottm@GW9.IAD8> show route receive-protocol bgp 152.179.50.114 | match 
> 200.10.150
> 
> * 200.10.150.0/24 152.179.50.114   0  12956 12956 
> 12956 12956 12956 12956 12956 19169 27947 28027 I
> 
>  
> 
>  
> 
> Regards...Scott
> 
>  
> 
> -Original Message-
> From: christopher.mor...@gmail.com [mailto:christopher.mor...@gmail.com] On 
> Behalf Of Christopher Morrow
> Sent: Friday, October 04, 2013 1:39 PM
> To: Gord

Re: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking FLOKsociety.org by accident or on purpose?

[Gordon Cook]

Hi chris

really appreciate the help from ALL you guys

does what you just said mean that non reachability for version customer  may 
mean a config problem for a small bloc and not something intentional??
=
The COOK Report on Internet Protocol, (PSTN) 609 882-2572 
Back Issues: 
http://www.cookreport.com/index.php?option=com_docman&task=cat_view&gid=37&Itemid=61
  
 Cook's Collaborative Edge Blog 
 http://www.cookreport.com/wp/
  Subscription info: 
http://www.cookreport.com/index.php?option=com_content&view=article&id=54&Itemid=65
=










On Oct 4, 2013, at 12:54 PM, Christopher Morrow  wrote:

> err.. nothing in the /24 is reachable from 701's perspective (so it
> seems)... so I'd suspect that there's a routing problem with the /24,
> in fact the surrounding /24's also seem to be having the same problem.
> 
> On Fri, Oct 4, 2013 at 12:42 PM, Miles Fidelman
>  wrote:
>> Also inaccessible from FIOS Boston:
>> new-host-2:~ mfidelman$ traceroute floksociety.org
>> traceroute to floksociety.org (200.10.150.169), 64 hops max, 52 byte packets
>> 1  wireless_broadband_router (192.168.1.1)  1.534 ms  0.853 ms 0.724 ms
>> 2  l100.bstnma-vfttp-84.verizon-gni.net (96.252.37.1)  7.619 ms 6.855 ms
>> 7.304 ms
>> 3  200.10.150.169 (200.10.150.169)  10.482 ms !N *^C
>> 
>> But just fine from our datacenter via xo.net.  And the web server is up - at
>> least to a text browser (Lynx).
>> 
>> Also via Verizion cell network (Boston area).
>> 
>> Some kind of routing table glitch or peering issue, perhaps?
>> 
>> 
>> 
>> William Herrin wrote:
>>> 
>>> On Fri, Oct 4, 2013 at 12:09 PM, Gordon Cook  wrote:
>>>>> 
>>>>> traceroute to floksociety.org (200.10.150.169), 64 hops max, 72 byte
>>>>> packets
>>>>>  1  192.168.1.1 (192.168.1.1)  0.759 ms  0.309 ms  0.357 ms
>>>>>  2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  36.778 ms
>>>>> 17.508 ms  7.316 ms
>>>>>  3  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.482 ms
>>>>> !N *
>>>>>  4  * * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  7.101
>>>>> ms !N
>>>>>  5  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.239 ms
>>>>> !N *
>>>>>  6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.823 ms
>>>>> !N *  8.846 ms !N
>>> 
>>> Inaccessible via FIOS Washington DC too:
>>> 
>>> traceroute -T -p 80 200.10.150.169
>>> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 40 byte
>>> packets
>>>  1  L300.WASHDC-VFTTP-91.verizon-gni.net (173.73.47.1)  1.804 ms
>>> 1.595 ms  1.562 ms
>>>  2  G0-6-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.216.250)  5.321 ms !N
>>> * *
>>> 
>>> Correctly accessible via Cox, Qwest, Sprint and others, but the
>>> network path is really slow and really long.
>>> 
>>> The border is consistently with telefonica-wholesale.net and then
>>> telconet.net. Beyond the border there are badly behaving routers,
>>> including ones configured with RFC 1918 addresses. The addressable
>>> routers are reachable via Verizon, just not the last hop.
>>> 
>>> traceroute -T -p 80 200.10.150.169
>>> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 60 byte
>>> packets
>>>  1  sark.dirtside.com (70.182.189.216)  0.708 ms  0.689 ms  0.569 ms
>>>  2  10.1.192.1 (10.1.192.1)  9.957 ms  9.874 ms  9.725 ms
>>>  3  ip68-100-3-49.dc.dc.cox.net (68.100.3.49)  9.631 ms  9.507 ms  9.424
>>> ms
>>>  4  ip68-100-3-113.dc.dc.cox.net (68.100.3.113)  9.310 ms  9.226 ms
>>> 9.140 ms
>>>  5  mrfddsrj02gex070002.rd.dc.cox.net (68.100.0.145)  9.111 ms  9.019
>>> ms  8.929 ms
>>>  6  68.1.4.139 (68.1.4.139)  8.791 ms *  5.981 ms
>>>  7  209.48.42.61 (209.48.42.61)  5.748 ms  11.361 ms  10.948 ms
>>>  8  vb2000d2.rar3.washington-dc.us.xo.net (207.88.13.66)  58.454 ms
>>> 52.415 ms  52.421 ms
>>>  9  te-3-0-0.rar3.atlanta-ga.us.xo.net (207.88.12.9)  60.543 ms
>>> 60.397 ms  60.378 ms
>>> 10  te-3-0-0.rar3.dallas-tx.us.xo.net (207.88.12.2)  58.211 ms  58.407
>>> ms  58.392 ms
>>> 11  * * *
>>> 12  206.111.5.226.ptr.us.xo.net (206.111.5.226)  53.378 ms  49.080 ms
>>> 47.435 ms
>>> 13  Xe-8-1-0-0-grtmiabr3.red.telefonica-wholesale.net (9

Re: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking FLOKsociety.org by accident or on purpose?

[Gordon Cook]

Thank you Bill

extremely helpful

if via FiOS from DC you cannot get through does his look like an intentional 
move by verizobn to black hole this site

how to determine that?

would like to be sure before i start raising hell elsewhere


I have tried to connect all week long never once succeeded.

advise??

any verizon people here willing to help?
=
The COOK Report on Internet Protocol, (PSTN) 609 882-2572 
Back Issues: 
http://www.cookreport.com/index.php?option=com_docman&task=cat_view&gid=37&Itemid=61
  
 Cook's Collaborative Edge Blog 
 http://www.cookreport.com/wp/
  Subscription info: 
http://www.cookreport.com/index.php?option=com_content&view=article&id=54&Itemid=65
=










On Oct 4, 2013, at 12:30 PM, William Herrin  wrote:

> On Fri, Oct 4, 2013 at 12:09 PM, Gordon Cook  wrote:
>>> traceroute to floksociety.org (200.10.150.169), 64 hops max, 72 byte packets
>>> 1  192.168.1.1 (192.168.1.1)  0.759 ms  0.309 ms  0.357 ms
>>> 2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  36.778 ms  17.508 ms 
>>>  7.316 ms
>>> 3  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.482 ms !N *
>>> 4  * * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  7.101 ms !N
>>> 5  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.239 ms !N *
>>> 6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.823 ms !N *  
>>> 8.846 ms !N
> 
> Inaccessible via FIOS Washington DC too:
> 
> traceroute -T -p 80 200.10.150.169
> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 40 byte packets
> 1  L300.WASHDC-VFTTP-91.verizon-gni.net (173.73.47.1)  1.804 ms
> 1.595 ms  1.562 ms
> 2  G0-6-4-7.WASHDC-LCR-22.verizon-gni.net (130.81.216.250)  5.321 ms !N * *
> 
> Correctly accessible via Cox, Qwest, Sprint and others, but the
> network path is really slow and really long.
> 
> The border is consistently with telefonica-wholesale.net and then
> telconet.net. Beyond the border there are badly behaving routers,
> including ones configured with RFC 1918 addresses. The addressable
> routers are reachable via Verizon, just not the last hop.
> 
> traceroute -T -p 80 200.10.150.169
> traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 60 byte packets
> 1  sark.dirtside.com (70.182.189.216)  0.708 ms  0.689 ms  0.569 ms
> 2  10.1.192.1 (10.1.192.1)  9.957 ms  9.874 ms  9.725 ms
> 3  ip68-100-3-49.dc.dc.cox.net (68.100.3.49)  9.631 ms  9.507 ms  9.424 ms
> 4  ip68-100-3-113.dc.dc.cox.net (68.100.3.113)  9.310 ms  9.226 ms  9.140 ms
> 5  mrfddsrj02gex070002.rd.dc.cox.net (68.100.0.145)  9.111 ms  9.019
> ms  8.929 ms
> 6  68.1.4.139 (68.1.4.139)  8.791 ms *  5.981 ms
> 7  209.48.42.61 (209.48.42.61)  5.748 ms  11.361 ms  10.948 ms
> 8  vb2000d2.rar3.washington-dc.us.xo.net (207.88.13.66)  58.454 ms
> 52.415 ms  52.421 ms
> 9  te-3-0-0.rar3.atlanta-ga.us.xo.net (207.88.12.9)  60.543 ms
> 60.397 ms  60.378 ms
> 10  te-3-0-0.rar3.dallas-tx.us.xo.net (207.88.12.2)  58.211 ms  58.407
> ms  58.392 ms
> 11  * * *
> 12  206.111.5.226.ptr.us.xo.net (206.111.5.226)  53.378 ms  49.080 ms  47.435 
> ms
> 13  Xe-8-1-0-0-grtmiabr3.red.telefonica-wholesale.net (94.142.125.54)
> 76.006 ms Xe8-0-2-0-grtmiabr4.red.telefonica-wholesale.net
> (94.142.119.38)  60.181 ms
> Xe13-1-4-0-grtmiabr4.red.telefonica-wholesale.net (213.140.43.109)
> 125.888 ms
> 14  Te-0-2-0-0-grtmiana4.red.telefonica-wholesale.net (94.142.119.233)
> 67.105 ms Te0-1-0-0-grtmiana4.red.telefonica-wholesale.net
> (213.140.37.77)  63.435 ms
> Xe5-1-8-0-grtmiana2.red.telefonica-wholesale.net (213.140.36.89)
> 141.873 ms
> 15  Xe9-3-0-0-gramiana4.red.telefonica-wholesale.net (94.142.126.197)
> 62.450 ms 176.52.249.245 (176.52.249.245)  66.665 ms 176.52.249.241
> (176.52.249.241)  64.668 ms
> 16  176.52.252.66 (176.52.252.66)  118.619 ms  118.057 ms  117.934 ms
> 17  * * *
> 18  * * *
> 19  * * *
> 20  host-186-5-116-193.telconet.net (186.5.116.193)  122.586 ms
> 120.967 ms  115.040 ms
> 21  host-186-101-89-42.telconet.net (186.101.89.42)  122.801 ms
> 125.164 ms  119.520 ms
> 22  * * *
> 23  200.10.150.169 (200.10.150.169)  253.710 ms  246.684 ms  244.845 ms
> 
> 
> 
> 
> 
> -- 
> William D. Herrin  her...@dirtside.com  b...@herrin.us
> 3005 Crane Dr. .. Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004

verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking FLOKsociety.org by accident or on purpose?

[Gordon Cook]

Dear NANOG

The Ecuadoran government has via the FLOK society hired Michel Bauwens of the 
P2p foundation to lead a two year long efforts to revision the ecudoran economy 
along the lines of a commons oriented collaborative society.  I am very 
interested in the program yet i have NEVER been able to connect to their web 
site.   At the end of two hours of trouble shooting with apple i was advised to 
call verizon.  I am a FiOS customer on a two year contact.  The traceroute 
below confirmed that the fault is in verizons network.  The verizon tech agreed 
otherwise i never would have gotten the trouble ticket

my verizon trouble ticket is NJ DQ04PWR9.

Can someone tell me what number to call to pursue resolution of this trouble 
ticket?

as of 12:04 eastern time i still cannot connect

24 hours was the promise
14 of the 24 have elapsed

> traceroute to floksociety.org (200.10.150.169), 64 hops max, 72 byte packets
>  1  192.168.1.1 (192.168.1.1)  0.759 ms  0.309 ms  0.357 ms
>  2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  36.778 ms  17.508 ms  
> 7.316 ms
>  3  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.482 ms !N *
>  4  * * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  7.101 ms !N
>  5  * g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.239 ms !N *
>  6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  6.823 ms !N *  
> 8.846 ms !N
> 
> 
> 
> Traceroute has started…
> 
> traceroute to 200.10.150.169 (200.10.150.169), 64 hops max, 72 byte packets
>  1  192.168.1.1 (192.168.1.1)  0.622 ms  0.305 ms  0.361 ms
>  2  l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1)  6.633 ms  4.892 ms  
> 4.809 ms
>  3  * * *
>  4  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  10.441 ms !N * *
>  5  * * *
>  6  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.932 ms !N * *
>  7  * * *
>  8  * * *
>  9  * * *
> 10  * * *
> 11  g0-3-4-5.cmdnnj-lcr-21.verizon-gni.net (130.81.184.119)  9.765 ms !N * *
> 12  * * *
> 13  * * *=


Lookup has started…

Trying "floksociety.org"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13700
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;floksociety.org.  INANY

;; ANSWER SECTION:
floksociety.org.   600  INA 200.10.150.169
floksociety.org.   3600INMX  10 mail.floksociety.org.
floksociety.org.   3600INNS   ns57.domaincontrol.com.
floksociety.org.   3600INNS   ns58.domaincontrol.com.
floksociety.org.   3600INSOAns57.domaincontrol.com. 
dns.jomax.net. 2013092400 28800 7200 604800 600

Received 174 bytes from 8.8.8.8#53 in 139 ms
=
The COOK Report on Internet Protocol, (PSTN) 609 882-2572 
Back Issues: 
http://www.cookreport.com/index.php?option=com_docman&task=cat_view&gid=37&Itemid=61
  
 Cook's Collaborative Edge Blog 
 http://www.cookreport.com/wp/
  Subscription info: 
http://www.cookreport.com/index.php?option=com_content&view=article&id=54&Itemid=65
=

Re: Friday Hosing

[Gordon Cook]

> * Alex Rubenstein (a...@corp.nac.net) wrote:
>>> Ohh we had some of those at JVNCNet, a real piece of crap.
>> 
>> Wow. JVNCnet. Haven't heard that name in a long, long time.

Same here.  I worked there from September 1987 through the closure in june of 
1990.  Whatever happened to Sergio Heker?


> 
> RIP Sir Alec Guinness.
> 
>   Stephen

Re: airFiber (text of the 8 minute video)

[Gordon Cook]

On Mar 29, 2012, at 1:58 PM, Josh Baird wrote:

> Anyhow, check the
> video out on ubnt.com for an introduction and technical overview -
> it's worth watching.

The claim is a huge decline in the cost of backhaul bandwidth for wisps between 
10 and 100 times.  I have just finished the preparation of an extensive article 
on a nebraska wisp whose network is backhaul radios on towers about 5 miles 
apart.  he is on over 100 towers across a space of 150 miles by roughly 40 miles

here is the text of the video which indeed is very good

Robert Pera, CEO Ubiquity:  Ubiquity had a lot of strength.   We had hardware 
design software design, mechanical design, antenna design.   We had  firmware 
and protocol design but the one thing that we were missing  was really our own 
radio design at our old modem design.

Engineer 1:  The group of guys who are here have been working together for 
about 20 years.   we collectively have a lot of experience in the wireless data 
world -  probably more so than any other company. This team of people 
originally were all hired into Motorola,  some of us go back to  the late 
1980s. We actually worked on a program called altair.  Altair was one of the 
1st attempts at doing in building wireless networking. It was  the 1st wireless 
local area network product ever.   It was actually the 1st time that I am aware 
of that anyone had actually built a broadband wireless networking product.

What we did on altair continued on through Motorola and  eventually became a 
product called  canopy.   Canopy is a very popular product now. It is a 
wireless Internet distribution system  used to provide high-speed Internet 
people in houses where there typically is no access to cable or to DSL 

Gary Schulz:  we had kind of run the canopy product through its maturity and 
did not see a lot of additional room for growth there.  When the ubiquity 
management approached us, we were looking for the opportunity to continue to 
build new stuff and that's what made it very interesting to come over and work 
for Ubiquity  Because their focus is on the new stuff. It is on working on high 
speed and low cost.

The freedom to design at our level was just go and do it. What are you going to 
do?  it was like start with a clean sheet of paper.  start with nothing. We 
could build and design this product in any way we saw fit.   The idea was just 
to be the best we could.
air fiber is the start of the new product line within Ubiquity. It is the 1st 
of several products  that are highly efficient, high data rate,  wireless 
broadband products.

Greg Bedian:   Our design is something that is a little bit crazy. We are  
trying  to build a 0 IF radio at 24 GHz and do this for a 100 MHz bandwidth 
which  is something that I am not sure anyone else has been crazy enough to try.

Chuck Macenski:  As fast as you can send a packet on an ethernet wire we can 
receive it and transmit with no limitations.

Air fiber is designed to be mounted in a reasonably high location.  It is a 
point to point network where the 2 antennas see each other.  this is a system 
that under certain circumstances can work up to 10 miles.  It is going to be 
very easy to deploy and align.   It is a product that is going to require only 
one person to carry it up the tower and install it.   There is a display on the 
bottom that tells you what sort of power is being received as well as a very 
comprehensive web interface.

We designed all aspects of it. The modem, the radio,  the mechanical housing. 
This is a completely designed from scratch, purpose built solution just to 
deliver backhaul.  So it is not based on wi-fi or anybody else's standards.  As 
a result it does not suffer from any of the other overhead normally associated 
with that.

Built for speed -- if you want to compare the data rates of existing products 
to our product, other products on the market today would give you the expected 
data rate of the flow of water through a garden hose.   Our product will 
provide the flow rate of a firehose. This product will provide 1.4 Gb per 
second of data flow which is 300 times faster than you would normally be able 
to get from your own home Internet service provider.

Operators will be able to get  10 to 100 times more data throughput for the 
same dollar.   That is the big impact that this product is going to have.

Rick Keniuk:  we looked at 24 GHz.  We actually wanted to do something up in 
high frequency and that happens to be the next unlicensed band beyond six 
gigahertz.  You can put it out anywhere. You don't have to do anything. No 
special paperwork. No license fees.  Nobody to go get permission from to 
operate the radio.  The nice part is  that it him allows anyone to operate  the 
product and started up without any issues of having to get licenses or jump 
through certain hoops  of where you can place the product. It is a freedom 
thing.

Inside the air Fiber Design  -- As far as I know no one builds a modem with 
this le

Re: ARIN IP6 policy for those with legacy IP4 Space

[Gordon Cook]

David, in 1997 and 1998 I was spending about 25% of my time interview the 
principals and engaged in informal conversations with Ira Magaziner,Kim 
Hubbard, DonMitchell and others.  I was in Londone in late jan 1998 when Jon 
tried  to redirect the root.  Magaziner was there and daniel karenburg and 
others.  We did an entire day on these issues.

In addition to my published record, I have extensive electronic archives 
related to the manueverings in the founding of Arin.  Should it come to a court 
case i believe that arin will come court fine and i trust that  i will be able 
to asist the people involved in determining who did what to whom when and for 
what reasons.

Steve Wolff will remember attending with me a late afternoon meeting with 
magaziner in Ira office in mid december 1997 on the day that Ira took Jon to 
lunch and announced to Jon that he had put together funding to carry the IANA 
activities through Oct 1 of 1998 and the founding of newco.

Don Mitchel is Mr "cooperative agreement."  I  am quite confident that what 
John Curran is saying below is solid. Don did yeoman's work in ensuring the 
birth and independence of ARIN.

=
The COOK Report on Internet Protocol, 609 882-2572 (PSTN) 609 403-2067 (mjack) 
Back Issues: 
http://www.cookreport.com/index.php?option=com_docman&task=cat_view&gid=37&Itemid=61
  
 Cook's Collaborative Edge Blog http://gordoncook.net/wp/   Subscription info: 
http://www.cookreport.com/index.php?option=com_content&view=article&id=54&Itemid=65
=






On Apr 12, 2010, at 2:36 PM, David Conrad wrote:

> John,
> 
> On Apr 12, 2010, at 5:23 AM, John Curran wrote:
>> On this matter we do agree, since allocations prior to ARIN's formation were 
>> generally made pursuant to a US Government contract or cooperative 
>> agreement.  
> 
> As we're both aware, Jon was funded in part via the ISI Teranode Network 
> Technologies project. Folks who were directly involved have told me that 
> IANA-related activities weren't even identified in the original contracts 
> until the mid- to late-90s (around the time when lawsuits were being thrown 
> at Jon because of the domain name wars -- odd coincidence, that) when the 
> IANA activities were codified as "Task 4".  IANAL, but it seems a bit of a 
> stretch to me for ARIN to assert policy control over resources allocated 
> prior to ARIN's existence without any sort of documentation that explicitly 
> lists that policy control in ARIN's predecessor (ever).  Like I said, it'll 
> be an interesting court case.
> 
> Regards,
> -drc
> 
> 
> 
>