- NANOG - lists.nanog.org

Re: Out of date contact information
by Sean Donelan 02 May '96

02 May '96

Obviously biased towards English speaking network users, but here's my breakdown of common (more than one organization using) role-based e-mail contact addresses. I've grouped them based on my observations how sites seem to use them. Operations action noc root routing security trouble Protocol ftp gopher hostmaster mbone news ntp postmaster usenet webmaster Administrative admin abuse billing info moreinfo nic sales service support And one I wish existed Informational fyi - no action or response needed, but you might want to know about it. Or the "We know its broken, don't bother calling" address. If people agree on a common practice for naming role-based accounts, great. But since many sites still have trouble handling "postmaster" I won't hold my breath. An up-to-date "real" name, e-mail address, and telephone number somewhere for a network is still a necessity, even if just a last resort. I know we've messed up and dropped trouble tickets into a black hole. Its really tough to tell people their e-mail system isn't working when the only contact information you have is an e-mail address. When no one updates the role-base alias when the person leaves, if given the old contact's name the telephone receptionist can often tell callers the name of the new person in the position. Asking for the Postmaster may get you transferred to the shipping department instead of the computer department. Asking for the MBONE person might get you reported to the police as an obscene caller. While we're trying to agree on a common practice, may I suggest each NANO take a few minutes and do a little spring cleaning. Check at least the WHOIS contact information for your own Autonomous System Number(s) for people who no longer work there, out of date phone numbers or addresses. If you use role-based accounts, could you consider listing a person as an alternate contact. Maybe make this a twice a year event, change your clocks, change your smoke detector batteries and update your WHOIS information. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: Out of date contact information
by Sean Doran 02 May '96

02 May '96

Oops, sorry about that. Fat Fingers Sean. (trouble(a)sprint.net)

1 0

Re: Out of date contact information
by Sean Doran 02 May '96

02 May '96

1 0

that observation....
by bmanning＠isi.edu 02 May '96

02 May '96

Forwarded w/o attribution. (perhaps this is not appropriate but I do feel this way alot... :) -bill There are really only <n> discussions on NANOG/CIDRD, which occasionally flare up like spontaneously combusting drunks on rs-talk, iepg, and ietf as well. Herein, a kind of Meta-FAQ, a Field Guide to the Meta-Wars: 1. InterNIC-bashing, complete with loud revisitings of the legitimacy of the InterNIC in particular and the entire registry concept in general. Recently this is characterized also by thundering herds of lawyers explaining how the Internet must change to accommodate American trademark law and repeated threats to sue the IANA by various people with 386s and 56k lines who want to run top-level domain registries. Inevitable conclusion: We need a heavily regulated, global free market in DNS registries, as well as more root servers and the IANA to be shot or elected or crowned king or something. 2. The IP Address Allocation wars, complete with Noel Chiappa's brilliant explanations of the relevant graph theory, "Life is unfair" lectures from large (or non) ISPs, "The net is unfair" whines from small (or wannabe) ISPs, and many non-lawyers ranting about restraint of trade and other topics in antitrust law and public policy. Inevitable conclusion: We need a heavily regulated, global free market in address space and routing advertisements, as well as bigger routers and faster light. 3. ISP bashing, with elements of both the above plus much more, inevitably including Sprint bashing wrt route filtering and NAP policy. Inevitable conclusion: Sprint is Babylon and Sean Doran is the antiChrist. Inevitable conclusion: everybody should peer with the Route Servers, except for when everybody should blow them up and peer with everybody down to Bill's Bait & Sushi Shoppe for free. Coming attraction: Will MFuuSoftNet be an Even Bigger Threat to The Net As We Know It. Meta-conclusion: it's sort of reassuring. "Imminent collapse of the Internet, GIFs at 11:00".....

2 2

Re: that observation....
by Paul Ferguson 01 May '96

01 May '96

This definately a keeper for the personal archives. :-) - paul At 01:08 PM 5/1/96 -0700, bmanning(a)ISI.EDU wrote: >Forwarded w/o attribution. >(perhaps this is not appropriate but I do feel this way alot... :) > -bill > >There are really only <n> discussions on NANOG/CIDRD, which >occasionally flare up like spontaneously combusting drunks on rs-talk, >iepg, and ietf as well. Herein, a kind of Meta-FAQ, a Field Guide to >the Meta-Wars: >

3 2

Re: Sprints definition on NAPs (question)
by Justin W. Newton 01 May '96

01 May '96

At 09:14 AM 5/1/96 -0400, you wrote: >On Wed, 1 May 1996, Jeremy Porter wrote: > >> >|} > the Sherman Act (if memory serves). These types of problems can be quite >> >|} > nasty, involving treble punitive damages. >> >> Unfortunately for Nathan, this above is wrong. >> >> There are very real engineering reasons for not peering >> if someone is at one NAP/MAE. Also since Sprint and MCI >> do have published policies, if they made exceptions to them >> they could get sued for discriminating against some competators >> (not all, makes a big legal difference). > >Ok, so what about Interpath, CAIS, and a bunch more that are peering with >MCI and are at only 1 NAP? Probably because they were peering with MCI before the policy, but thats just a guess. Justin Newton * You have to change just to stay Internet Architect * caught up. Erol's Internet Services *

1 0

Re: Peering Policies and Route Servers
by Justin W. Newton 01 May '96

01 May '96

At 07:45 PM 4/30/96 -0400, you wrote: >> Heck, if all I needed was a connection to the MAE to get global routing, >> I'd run a ds-3 to my house and be done with it (its only about 3 miles >> from my house to MAE East, maybe 5). > >Hmm...how many PC's and workstations do you have at home to fill a DS3 >with? ;-) Well, it'd be good for IOS code downloads ;) > >> >(2) There is no connectivity gain for a national provider to peer >> > with a single-attached organizaiton as all these organizations have >> > transit providers that are present at multiple interconnects. >> This is a chicken and egg scenario. If CompanyX could get to everywhere >> without buying a link to an upstream as well as their connection to the MAE, >> well, then they wouldn't buy the connection to the upstream provider. The >> real point should be that losing connectivity to all whopping X,000 of their >> customers where X is between 1 and 9 is really not all that big a deal, >> netwise. > >Not a big deal to whom? It certainly is to those customers, and to >CompanyX. And probably to a percentage of the rest of the net.population, >who now can't get to Joe's Whiz-Bang homepage. And who's making a >decision on whether they have connectivity? > >(or what does this have to do with chickens and eggs?) Its no big deal to BigBackboneDude. That /seems/ to be the attitude that some of the larger backbone providers take, and I am not sure that I completely blame them. I.e. Is it worth this level of effort both for me and for my routers to add connectivity to this level of hosts? If the number of hosts is large it obviously is. If it is small it may not be. The problem is deciding where that line is. >[RS peering] >> As a representative of Erol's I can say that I would want to directly peer >> with MCI. Sprint, ANS, UUnet and a few others, all of the people annoucing >> one or two routes I would likely be better serverd as hearing through the RA >> until which time as I have lots of free processor/memory/everything else on >> my router doing the peering, at which point I would be more than willing to >> peer with anyone who I could be assured was technically competent. >> (Basical;ly I am not /dependant/ on getting to a lot of those smaller sites, >> so I don't very much care if I lose them somehow). > >This is a risky attitude. Simply because those sites are smaller than you >doesn't mean you can force them down by refusing to peer. You do have a >relatively large dialup customer base, but explaining to your customers >exactly why they can't get to <interesting route> from your service, but >can from GrumbleSmurf down the road, can be tricky when you burn bridges. >I'd place more emphasis on the "technically competent" aspect of your >policy than the "I don't much need your routes anyhow" motivation. You're misreading what I am saying, hopefully not intentionally. What I am saying is that Sprint, MCI et al are large snugh that they are absolutely critical that they work 100% of the time, or as close to 100% of the time as is possible. If the route server hiccups, or they start implementing wierd policies that cause me to lose connectivity to those people for /any/ amount of time I am in deep kimshee. If the route server screws up and decides I can no longer talk to JustinsTinyISP, I have a little time to ditch the route server and set up a private peering session with JustinsSmallISP before it becomes a critical issue. It is not that I don't want to hear the routes for that provider it is simply that it may not be worth the resources both on the router and in human manpower to setup a private peering session with them. The routers do have limits you know. There is no "I don't much need your routes anyhow" motivation anywhere. Justin Newton * You have to change just to stay Internet Architect * caught up. Erol's Internet Services *

1 0

re: Sprints definition on NAPs (question)
by John Scoggin 01 May '96

01 May '96

The other question that should be asked (and I hope some folks have looked at this) is whether this rule is in fact arbitrary. If there is no sound ENGINEERING reason, it may constitute "restraint of trade" under Chapter 2 of the Sherman Act (if memory serves). These types of problems can be quite nasty, involving treble punitive damages. I have never been a lawyer (or played one on TV :-), but I can recall handling disbursement of suit awards while a programmer in a bank Trust Department...

7 8

Re: Peering Policies and Route Servers
by Peter Lothberg 01 May '96

01 May '96

> > (2) Could anyone share opinions/facts regarding why organizations may or > > may not exchange routes via the Route Servers rather than direct peering > > relationships at the NAPs? > > I know of no case where an organization "may not" exchange routes > with the Route Servers. I do, AS1800.. --Peter

3 2

RE: MFS buys UUNET.
by Hank Nussbacher 01 May '96

01 May '96

On Tue, 30 Apr 1996 09:56:38 -0700 (PDT) Rob Gutierrez wrote: >As somebody mentioned today, an AP wire story came across this morning >that MFS is _buying_ UUNET for $2 billion. Shareholders are looking at >getting 1.78 shares of MFS for each of their shares. Apparently, they >got 62% of the voting shareholders to agree (ie: who owns a couple >of large chunks of UUNET?). > >Remember that Microsoft already has their claws into UUNET for 13% :) > According to the Internet Millionaire's Home Page: http://www.pulver.com/million/ Rick Adams, Chairman UUNT 4,875,000 $279,703,125 Microsoft UUNT 4,164,000 $238,909,500 Menlo Ventures, VC UUNT 3,229,698 $185,303,922 New Enterprise, VC UUNT 3,229,698 $185,303,922 Accel, VC UUNT 3,210,320 $184,192,110 New Enterprise/Barris, VC UUNT 3,229,698 $185,303,922 Menlo Ventures/Jarve, VC UUNT 3,229,698 $185,303,922 Accel/Patterson, VC UUNT 3,210,320 $184,192,110 John Sidgmore, Pres & CEO UUNT 1,244,100 $71,380,237 Ain't infotechnology fun :-) > > rob gutierrez / internex information services > ---------------------------------------------------------------------- Hank Nussbacher Manager, Internet Technology Programs Telephone: +972 3 6978852 Vnet: HANK at TELVM1 Fax: +972 3 6978115 Internet: hank(a)ibm.net.il ---------------------------------------------------------------------- IBM Israel 2, Weizmann St. Tel Aviv 61336 ====== ======= === === http://www.ibm.net.il/ ====== ======== ==== ==== Dialup registration: 177-022-3993 == == == ==== ==== Company services: 03-6978663 == ====== == === == Internet sales fax: 03-6978115 == == === == = == Enquiries: info(a)ibm.net.il ====== ======== === === Technical support: noc(a)ibm.net.il ====== ======= === === ----------------------------------------------------------------------

1 0