Mailing List Archive

Paul,

While I agree with your effort, this has moved to prospective namespace
design as opposed to documenting a very few current practices.

randy
- - - - - - - - - - - - - - - - -

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

Paul Steiger
>
> Paul A Vixie wrote:
>
> > > I would suggest adding "hostmaster" for DNS issues (and suggesting that
> > > this be the address listed as the contact in DNS SOA records).
> >
> > Done.
>
> With ISP's assigning addresses to their customers rather than the Internic, would customer IP
> address request be included in hostmaster@isp.net or would this warrent a new name.

anyone for 'ipadmin'? seriously.

-brett

- - - - - - - - - - - - - - - - -

> anyone for 'ipadmin'? seriously.

I'm against that. I am striving to limit the level of ``invention'' in this
document and really just substantially cover the best of current practices.
If InterNIC can cope with a single address (HOSTMASTER) for both domain and
address allocation issues, I suspect that the rest of us can do the same.

I am considering the proposal of a CERT address per domain. While SECURITY
and others are more _prevalent_, I'm not sure that they represent the _best_
of current practices. Since "The CERT" has recommended per-domain CERT
addresses, I think that the next public draft will recommend a CERT address
and relegate SECURITY to "less well known" status. Comments are of course
welcome on this change.

The "less well known" table is perilously close to overflow already. I have
resisted adding everything that anybody knows of or can imagine, since what
I really want to do is (a) codify the minimum useful address set, and (b) do
some lip service to existing end-user expectations of things I don't think
we ought to be recommending.

Due to those same concerns, I resisted (mightily, and I won) the temptation
to add sections talking about well known whois.<domain> servers, DNS RP RR's,
current international and national registry lists, how to use Alta Vista to
locate folks, a little ditty about the old (dead?) whois phone book, and so
on. If _I_ (of all people!) can resist the temptation to borrow GNU Emacs'
"kitchen sink" logo for the first page of the postscript version of this
document, then I expect the rest of you (who presumably have better sense and
more self control) can also avoid asking this document to expand to the size
of the Encyclopaedia Britannica.
- - - - - - - - - - - - - - - - -

In message <9605030534.AA13791@wisdom.home.vix.com>, Paul A Vixie writes:
>
> 3.2. Protocol Independent Addresses
>
> Address Operations Area Example Usage
> --------------------------------------------------------------
> abuse Customer Relations Inappropriate public behaviour
> noc Network Operations Network infrastructure problem
> trouble Network Operations Synonym for ``noc''
> support Customer Support Product or service not working


At least with ANS "trouble" and "noc" are not synonymous. NOC is lots
of people involved in network operations and normal trouble reporting
(can't get there from here reporting) need not bother the whole group.
Trouble is the current NOC staff on duty and are supposed to respond
immediately to mail in the trouble mailbox, usually openning a trouble
ticket and diagnosing the problem, in doing so starting the 15 minute
escallation timer for the oncall engineer. They also in practice
respond immediately to mail in the NOC mailbox, but then a lot of
people not on duty have to delete the mail when they come on call
which just makes more work.

If other providers have the same conventions or agree that these
conventions are usefull, then write them up however you like (more
briefly than I have done would be nice).

Another common mailing list is routing@provider. This is intended
more for technical routing questions or to resolve routing issues
between providers. This is more for routing design issues so
immediate response should not be expected on this list. Any "routing
is broken" messages should go to trouble, so they need to they can
page the people that can fix it rather than let it sit in some
engineer's mailbox.

It would be great if later you could include some of the NIC and IRR
mailboxes. Maybe next revision. For example:

auto-dbm Automated Registry Register routing objects
except MCI - auto-rr@mci.net

Only problem is I don't think there is consistency in the address
registries and routing registries use of mail aliases. Maybe this
could go on the RA web page and when there is better consistency, put
this in an RFC.

Curtis
- - - - - - - - - - - - - - - - -

In message <Pine.BSI.3.91.960503073302.5078C-100000@cais.cais.com>, "J.D. Falk"
writes:
> >
> > hostmaster was done in the -01 draft, sent shortly ago. security seems
> > reasonable but is this current practice anywhere you know of?
>
> I beleive that SprintLink uses it, but I've got permanent routing
> anomalies in my memory so I can't be sure.

As with anything else, report fires to trouble for fastest response.
It might be worth putting security down to serve a similar role as
routing (for questions or coordination not requiring immediate
response).

BTW - do we want to mention "root" as the system administration of a
specific host to report things like "your multicast implementation is
broken and spewing ICMP packets" or other "fix that beast" messages.

Curtis
- - - - - - - - - - - - - - - - -

The issue of "response time" is a good one to consider. It might be nice
if "best current practice" for expected response times on each alias is
part of the documented list/table. This helps the providers to alias the
addresses to appropriate parties that would, hopefully, be able to provide
a response within a commonly expected timeframe. I suspect a lot of the
frustration experienced with inter-ISP communications has a lot to do with
different response time standards/expectations/understandings.

My $.02; YMMV,

Ed

On Mon, 6 May 1996, Curtis Villamizar wrote:

>
> In message <9605030534.AA13791@wisdom.home.vix.com>, Paul A Vixie writes:
> >
> > 3.2. Protocol Independent Addresses
> >
> > Address Operations Area Example Usage
> > --------------------------------------------------------------
> > abuse Customer Relations Inappropriate public behaviour
> > noc Network Operations Network infrastructure problem
> > trouble Network Operations Synonym for ``noc''
> > support Customer Support Product or service not working
>
>
> At least with ANS "trouble" and "noc" are not synonymous. NOC is lots
> of people involved in network operations and normal trouble reporting
> (can't get there from here reporting) need not bother the whole group.
> Trouble is the current NOC staff on duty and are supposed to respond
> immediately to mail in the trouble mailbox, usually openning a trouble
> ticket and diagnosing the problem, in doing so starting the 15 minute
> escallation timer for the oncall engineer. They also in practice
> respond immediately to mail in the NOC mailbox, but then a lot of
> people not on duty have to delete the mail when they come on call
> which just makes more work.
>
> If other providers have the same conventions or agree that these
> conventions are usefull, then write them up however you like (more
> briefly than I have done would be nice).
>
> Another common mailing list is routing@provider. This is intended
> more for technical routing questions or to resolve routing issues
> between providers. This is more for routing design issues so
> immediate response should not be expected on this list. Any "routing
> is broken" messages should go to trouble, so they need to they can
> page the people that can fix it rather than let it sit in some
> engineer's mailbox.
>
> It would be great if later you could include some of the NIC and IRR
> mailboxes. Maybe next revision. For example:
>
> auto-dbm Automated Registry Register routing objects
> except MCI - auto-rr@mci.net
>
> Only problem is I don't think there is consistency in the address
> registries and routing registries use of mail aliases. Maybe this
> could go on the RA web page and when there is better consistency, put
> this in an RFC.
>
> Curtis
>

Ed Morin
Northwest Nexus Inc. (206) 455-3505 (voice)
Professional Internet Services
edm@nwnexus.WA.COM

- - - - - - - - - - - - - - - - -

In message <9605031754.AA14659@wisdom.home.vix.com>, Paul A Vixie writes:
> > > I've added ROUTING to do what TROUBLE is often used to do.
> >
> > I question whether this is a good idea -- some providers have a
> > "routing" mailing list that isn't really intended for public
> > dissemination and use. For instance, routing@uunet.uu.net and
> > routing@es.net both bypass their respective NOCs and go straight to
> > engineering types -- perhaps we need to pick a new name for those
> > sorts of lists, but I really don't see what having a "routing"
> > buys us over "noc".
>
> This is the kind of collision that makes this "standard" expensive to
> implement. Folks elsewhere use ROUTING as a way to reach the folks
> who want to hear about externally visible routing problems; NETCOM
> for example advertises this address in its RADB elements. I think
> that folks like UUNET and ESNET will have to pick new addresses if
> they don't want their engineers getting spammed. Sorry about that.


ANS uses routing the same way uunet and esnet do. I think MCI does
the same. Netcom is in the minority.

Curtis
- - - - - - - - - - - - - - - - -

On Mon, 6 May 1996, Curtis Villamizar wrote:

> At least with ANS "trouble" and "noc" are not synonymous. NOC is lots
> of people involved in network operations and normal trouble reporting
> (can't get there from here reporting) need not bother the whole group.
> Trouble is the current NOC staff on duty and are supposed to respond
> immediately to mail in the trouble mailbox, usually openning a trouble
> ticket and diagnosing the problem, in doing so starting the 15 minute
> escallation timer for the oncall engineer. They also in practice
> respond immediately to mail in the NOC mailbox, but then a lot of
> people not on duty have to delete the mail when they come on call
> which just makes more work.
>
> If other providers have the same conventions or agree that these
> conventions are usefull, then write them up however you like (more
> briefly than I have done would be nice).

Perhaps someone could collect the NOC practices and contact points for the
major NSP's and write it up as an informational RFC.


Michael Dillon Voice: +1-604-546-8022
Memra Software Inc. Fax: +1-604-546-3049
http://www.memra.com E-mail: michael@memra.com

- - - - - - - - - - - - - - - - -

[Curtis]
> As with anything else, report fires to trouble for fastest response.
> It might be worth putting security down to serve a similar role as
> routing (for questions or coordination not requiring immediate
> response).
...
> ANS uses routing the same way uunet and esnet do. I think MCI does
> the same. Netcom is in the minority.

OK, SECURITY and CERT are now different. TROUBLE and NOC and ROUTING
are now all different.

[Curtis]
> BTW - do we want to mention "root" as the system administration of a
> specific host to report things like "your multicast implementation is
> broken and spewing ICMP packets" or other "fix that beast" messages.

No. This is particular to UNIX. For this kind of thing, use TROUBLE.
To report it per host, use TROUBLE@host. To report per domain, use
TROUBLE@domain.

[Curtis]
> It would be great if later you could include some of the NIC and IRR
> mailboxes. Maybe next revision. For example:
>
> auto-dbm Automated Registry Register routing objects
> except MCI - auto-rr@mci.net
>
> Only problem is I don't think there is consistency in the address
> registries and routing registries use of mail aliases. Maybe this
> could go on the RA web page and when there is better consistency, put
> this in an RFC.

Thank you for finishing with what was going to be my objection and my
recommendation. I think that the RADB concept is sufficiently complex
and well advanced that it deserves its own standard-contacts documents,
which would contain a lot more information than just e-mail addresses.
- - - - - - - - - - - - - - - - -

> From: Ed Morin <edm@halcyon.com>
>
> The issue of "response time" is a good one to consider. It might be nice
> if "best current practice" for expected response times on each alias is
> part of the documented list/table. This helps the providers to alias the
> addresses to appropriate parties that would, hopefully, be able to provide
> a response within a commonly expected timeframe. I suspect a lot of the
> frustration experienced with inter-ISP communications has a lot to do with
> different response time standards/expectations/understandings.

Done, for the next draft.
- - - - - - - - - - - - - - - - -

> BTW - do we want to mention "root" as the system administration of a
> specific host to report things like "your multicast implementation is
> broken and spewing ICMP packets" or other "fix that beast" messages.

I don't think it's a good idea to mention "root". I've seen far too
many cases of email to root being read very seldom, or not at all.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no
- - - - - - - - - - - - - - - - -

> > noc Network Operations Network infrastructure problem
> > trouble Network Operations Synonym for ``noc''
...
>
> At least with ANS "trouble" and "noc" are not synonymous. NOC is lots

It seems to me the aliases should be defined by the content of the mail,
not the group of recipients. Which group get which mail is obviously going
to be a matter for the ISP and depend on internal structure and size.
So 'trouble' for network trouble, 'peering' for peering requests,
'security' for security issues, and 'noc' for something you would want
to reach the whole NOC (can't think of that right now :-) ). Aliases as listed
can remain unchanged, just change the definition on the right.

Alex Bligh
Xara Networks



- - - - - - - - - - - - - - - - -

>
> On Mon, 6 May 1996, Curtis Villamizar wrote:
>
> > At least with ANS "trouble" and "noc" are not synonymous. NOC is lots
> > of people involved in network operations and normal trouble reporting
> > (can't get there from here reporting) need not bother the whole group.
> > Trouble is the current NOC staff on duty and are supposed to respond
> > immediately to mail in the trouble mailbox, usually openning a trouble
> > ticket and diagnosing the problem, in doing so starting the 15 minute
> > escallation timer for the oncall engineer. They also in practice
> > respond immediately to mail in the NOC mailbox, but then a lot of
> > people not on duty have to delete the mail when they come on call
> > which just makes more work.
> >
> > If other providers have the same conventions or agree that these
> > conventions are usefull, then write them up however you like (more
> > briefly than I have done would be nice).
>
> Perhaps someone could collect the NOC practices and contact points for the
> major NSP's and write it up as an informational RFC.

The problem with this, as I see it, is the updating factor. By the time
someone, whomever it may be, gets done getting the original information,
half of the contact people will have changed.

The idea of a reliable alias at each ISP/NSP is the best approach I think.

Robert Bowman
Sr. Hole Plugger
Exodus Communications Inc.
(408) 522-8473
rob@exodus.net

- - - - - - - - - - - - - - - - -

In message <199605081441.HAA10750@elite.exodus.net>, Robert Bowman writes:
> >
> > On Mon, 6 May 1996, Curtis Villamizar wrote:
> >
> > > At least with ANS "trouble" and "noc" are not synonymous. NOC is lots
> > > of people involved in network operations and normal trouble reporting
> > > (can't get there from here reporting) need not bother the whole group.
> > > Trouble is the current NOC staff on duty and are supposed to respond
> > > immediately to mail in the trouble mailbox, usually openning a trouble
> > > ticket and diagnosing the problem, in doing so starting the 15 minute
> > > escallation timer for the oncall engineer. They also in practice
> > > respond immediately to mail in the NOC mailbox, but then a lot of
> > > people not on duty have to delete the mail when they come on call
> > > which just makes more work.
> > >
> > > If other providers have the same conventions or agree that these
> > > conventions are usefull, then write them up however you like (more
> > > briefly than I have done would be nice).
> >
> > Perhaps someone could collect the NOC practices and contact points for the
> > major NSP's and write it up as an informational RFC.
>
> The problem with this, as I see it, is the updating factor. By the time
> someone, whomever it may be, gets done getting the original information,
> half of the contact people will have changed.
>
> The idea of a reliable alias at each ISP/NSP is the best approach I think.
>
> Robert Bowman
> Sr. Hole Plugger
> Exodus Communications Inc.
> (408) 522-8473
> rob@exodus.net


I don't see the problem with this. If mail is sent to trouble just
prior to a shift change the shift coming on inherits the open trouble
tickets and the oncall engineer gets the escallation if the status
isn't updated within 15 minutes from the TT going open.

Part of changing shifts is changing the mail aliases for real time
response. I don't think there is an interim window where mail to
trouble or to the internal escallation gets dropped.

How is this anything but the most reliable contact information you can
get? Not the same person each time, but real time response from the
organization around the clock.

Curtis
- - - - - - - - - - - - - - - - -