- Test - lists.nanog.org

Re: I-D (Re: Out of date contact information )
by Sean Donelan 05 May '96

05 May '96

Since an amazing number of sites can't even implement "Postmaster" I don't think expanding the number of aliases improves things. Also, I think some people may have the problem statement reversed. It isn't the "newbie" sites with the worst problem (Ok, they can be a problem), but the older, established sites. Information entropy sets in. When people move on to new jobs, old aliases don't get updated. With dozens of mailing lists, the probability all the lists get updated correctly approches zero. "Postmaster" (or any of the dozen more aliases Vixie's document sets out) will end up pointing to someone's mailbox who left years ago. The more specific the aliases, the less it will get used, and the less anyone will notice it isn't working until its too late (the smoke detector battery problem). I'd much rather concentrate on getting *ONE* point of contact working, following the axiom, put all your eggs in one basket and watch the basket. The other more specific aliases are nice, but things break. And when those other aliases break, who are you going to contact? If folks like Vixie's I-D, all I would add is an opening paragraph which says.... Before doing anything else, make sure POSTMASTER works, we mean it this time. BTW, whatever happened to Dan Long's second-edition of the NOC telephone book? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: I-D (Re: Out of date contact information )
by kaminski＠nanospace.com 04 May '96

04 May '96

On Thu, 2 May 1996, J.D. Falk lists some other typical aliases: > Address Operations Area Example Usage > -------------------------------------------------------------- > hostmaster Network Operations DNS issues > security Network Operations System security or hacking > www Customer Support Same as webmaster > listowner Customer Support Mailing list administrator > routing Network Operations Network routing issues > nic Network Operations Same as noc > news Customer Support Same as usenet > help Customer Support Same as support Here are a couple more in a similar vein: info Customer Support automated response sales Customer Support directed to sales dept. ftp-admin Customer Support FTP administrator Hmm, it'd be cool if there was an automated mailbot for publishing NOC contact information, too -- something like "noc-info"? Pete

3 2

Re: Inter-exchange media types
by Havard.Eidnes＠runit.sintef.no 03 May '96

03 May '96

> > smaller packets than they otherwise could. Some hosts get > > noticeably higher performance when they are able to use FDDI- > > sized packets compared to Ethernet-sized packets, and restricting > > the packet size to 1500 bytes will put a limit on the maximum > > Some hard figures on this would be interesting. Ie, % of packets > with > 1500 MTU, % performance degradation if fragmented, etc. I > suspect that other backbone design issues (like congestion) > dominate any fragmentation issue. I'm not in a position to give you that figure, sorry (I couldn't even if I would). Do however note that this is not so much an issue about (IP) fragmentation happening in routers as it is about efficiency of host interfaces, since most of these guys use (or should use, anyway) path MTU discovery. (It is conceivable that this argument also has weakened over time.) > I'm not sure a few people trying to get a little extra throughput > should dictate the design of a NAP (unless they want to pay for it). In some instances that would be a fair trade-off. But do note that the "packet size" issue is a side issue -- the main argument for using FDDI-style switches with "backpressure" via token stealing is appropriate amounts and handling of buffering. - Havard

1 0

Re: Peering Policies and Route Servers
by Steven J. Richardson 03 May '96

03 May '96

Actually, only changes to the RADB and ANS DB will be caught by _every_ 4 hr update; the other databases (RIPE, MCI DB, CA*Net DB) are currently obtained 1x/day (usually in the morning, Brian Renaud says). Work re: synchronization and distribution of IRR data is, as they say, ongoing. Steve Richardson/Merit >From nanog-owner(a)merit.edu Tue Apr 30 13:16:30 1996 >Message-Id: <199604301712.KAA03518(a)lint.cisco.com> >X-Sender: pferguso(a)lint.cisco.com >Date: Tue, 30 Apr 1996 13:13:36 -0400 >To: Cengiz Alaettinoglu <cengiz(a)isi.edu> >From: Paul Ferguson <pferguso(a)cisco.com> >Subject: Re: Peering Policies and Route Servers >Cc: Ali Marashi <amarashi(a)interglobe.com>, bmanning(a)isi.edu, nanog(a)merit.edu >Sender: owner-nanog(a)merit.edu >At 10:12 AM 4/30/96 -0700, Cengiz Alaettinoglu wrote: > >> >>Route Servers are dynamic, they process upto 6000 routing updates a >>minute (see http://compute.merit.edu/stats/mae-east/instability) >> >>Route Servers are reconfigured with up to date policy 6 times a day, >>i.e. every four hours. Hence, a brand new route registered in IRR may >>not be announced by the route servers to the NSPs whose policies are >>prefix based for up to at most 4 hours. I think this is what you are >>referring to. >> > >Cengiz, thanks for the clarification. > >- paul

2 1

Re: Peering Policies and Route Servers
by Paul Ferguson 02 May '96

02 May '96

At 04:11 PM 5/2/96 -0400, Steven J. Richardson wrote: >Actually, only changes to the RADB and ANS DB will be >caught by _every_ 4 hr update; the other databases (RIPE, >MCI DB, CA*Net DB) are currently obtained 1x/day (usually >in the morning, Brian Renaud says). Work re: synchronization >and distribution of IRR data is, as they say, ongoing. > > >Steve Richardson/Merit > Steve, thanks for verifying my previous point. :-) - paul

1 0

Re: Peering Policies and Route Servers
by Paul Ferguson 02 May '96

02 May '96

At 10:48 AM 5/2/96 -0400, Marten Terpstra wrote: > >But the question is whether there will be more NBMA type NAPs in the >future. Point to MultiPoint for BGP, I like it ;-) > Marten, you are one sick puppy. ;-) - paul

1 0

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