I hate to interrupt the ongoing discussion about peering, but I'd like to bring up another perennial topic, out-of-date network contact information. The larger, and older the company the harder it is to find the right contact person. Sure there are lots, and lots of lists; WHOIS at the InterNIC, lists kept by various NAP operators, even in in-addr.arpa TXT records. So many lists people have difficulty knowing what to update when people's responsibilities change. Suppose I wanted to find out Sprint's real policy this week, or a government agency network such as ESnet's Internet policy; who would I contact? The listed contact names don't seem to work, or are out-of-date. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation
I have found that, with only one unnamed exception, if you write to support@isp.net it will get forwarded to the appropriate people. Some places it takes a while, while others (I must plug ANS here.. they are very well organized with regards to email delegations) are very quick. Writing directly to anyone with regards to network issues is not a good thing. Some NSPs have a specific person that only handles peering contracts. Rob Sr. Hole Plugger Exodus Communications Inc. (408) 522-8473 rob@exodus.net
I hate to interrupt the ongoing discussion about peering, but I'd like to bring up another perennial topic, out-of-date network contact information. The larger, and older the company the harder it is to find the right contact person.
Sure there are lots, and lots of lists; WHOIS at the InterNIC, lists kept by various NAP operators, even in in-addr.arpa TXT records. So many lists people have difficulty knowing what to update when people's responsibilities change.
Suppose I wanted to find out Sprint's real policy this week, or a government agency network such as ESnet's Internet policy; who would I contact? The listed contact names don't seem to work, or are out-of-date. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation
I have found that, with only one unnamed exception, if you write to support@isp.net
How about folks use: routing@isp.net to reach people? [Is there any consensus on various support aliases that an ISP 'should' have? noc, help, hostmaster, support, postmaster, routing, info, sales, trouble, others?] --asp@partan.com (Andrew Partan)
We here like trouble@ans.net. It's an all-purpose group, like support, but has a sense of urgency to it. Nevin -Nevin Williams ANS Network Operations Andrew Partan writes:
I have found that, with only one unnamed exception, if you write to support@isp.net
How about folks use: routing@isp.net to reach people?
[Is there any consensus on various support aliases that an ISP 'should' have? noc, help, hostmaster, support, postmaster, routing, info, sales, trouble, others?] --asp@partan.com (Andrew Partan)
This would be something we could probably standardize. I wonder how many folks have mail aliases like routing@xxx.net, noc@xxx.net, etc to bounce messages right ways. At the ver least, it'll make /etc/alias file shorter for good number of people. :) -dorian (trouble@cic.net) On Thu, 2 May 1996, Nevin Williams wrote:
We here like trouble@ans.net. It's an all-purpose group, like support, but has a sense of urgency to it.
Nevin
-Nevin Williams ANS Network Operations
Andrew Partan writes:
I have found that, with only one unnamed exception, if you write to support@isp.net
How about folks use: routing@isp.net to reach people?
[Is there any consensus on various support aliases that an ISP 'should' have? noc, help, hostmaster, support, postmaster, routing, info, sales, trouble, others?] --asp@partan.com (Andrew Partan)
This would be something we could probably standardize. I wonder how many folks have mail aliases like routing@xxx.net, noc@xxx.net, etc to bounce messages right ways. At the ver least, it'll make /etc/alias file shorter for good number of people. :)
-dorian (trouble@cic.net)
BITGOD (back in the good old days) Gene had an IETF wg that attempted to deal with network operations issues; the NJM wg. One of the things that came out of that august body was the use of role accounts. If I remember correctly, trouble@site.tld was recommended as the shotgun address. This, along with hostmaster & noc floated to the top. http was a long way off.. :) -- --bill
Suggestion: It would be a good idea to pick up on the ASnnn aliases used in the days of the NSFnet. The suitable place to host these aliases would be the registries, since they are the ones handing out ASNs and are in the position of being able to enforce a pretty obvious requirement: Anybody injecting routes into the Net -must- have functioning trouble email addresses. (Some months ago, somebody (apparently both global and international) were leaking some of our routes. No normal alias worked and the problem didn't get resolved until given-name@... came back after the weekend.) To avoid wasted efforts, the registries should preferably coordinate to mirror the aliases, so that everybody would be reachable as ASnnn@any-registry.net Thus, all of AS286@ripe.net AS286@internic.net AS286@apnic.net would reach the trouble(some) folks in EUnet. This would place an extra burden on the registries, but ASN assignment shouldn't be taken lightly anyway. -- ------ ___ --- Per G. Bilse, Mgr Network Operations Ctr ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL --- /___ /__/ / / /__ / ------ tel: +31 20 6233803, fax: +31 20 6224657 --- ------- 24hr emergency number: +31 20 421 0865 --- Connecting Europe since 1982 --- http://www.EU.net; e-mail: bilse@EU.net
Dear Per,
Per Gregers Bilse writes :
To avoid wasted efforts, the registries should preferably coordinate to mirror the aliases, so that everybody would be reachable as
ASnnn@any-registry.net
Thus, all of
AS286@ripe.net AS286@internic.net AS286@apnic.net
would reach the trouble(some) folks in EUnet.
For a short term solution: Daniel wrote a short script (source & example included) that you can use to gather the contact information from the RIPE database (and databases that we mirror). You can use his script from within your editor to directly put the contact addresses in the 'To:' field. The RIPE NCC tries to mirror all major registry databases. We currently mirror: APNIC, MCI, RADB, ANS, CANET. (The InterNIC uses another format and is therefore really difficult to mirror for us). You can flag me if you want me to mirror other databases that are not on the list. This method should give you most of the functionality that you are asking for. For the long term: Yes, mirroring doesn't scale (if the number of registries will continue to grow). We are aware of this problem and have already developed some ideas in the RIPE database and RPSL working group to cope with this but this will take time to implement (and our customers need to express that we should use our scarce resources to actually do this). I hope this helps you, David Kessens --- Example usage: $ db2mad -a as3333 "Daniel Karrenberg" <dfk@ripe.net>, "Geert Jan de Groot" <GeertJan.deGroot@ripe.net> ---- #!/usr/local/bin/perl # db2mad - extract an rfc822 mail address from a db person object # # Daniel Karrenberg <dfk@ripe.net> # # %I% %D% if ($ARGV[0] eq "-a") { $opt_a = shift(@ARGV); } if ($ARGV[0]) { $i=0; while ($ARGV[$i]) { $args = $args . " " . $ARGV[$i]; $i++; } open (STDIN, "whois $args |") || die "whois $args: $!"; } while (<STDIN>) { $name = $1 if (/^person:\s+(.*)/); $address = $1 if (/^address:\s+(.*)/ && !$address); $mail = $1 if (/^e-mail:\s+(.*)/ && !$mail); $fax = $1 if (/^fax-no:\s+(.*)/ && !$fax); &printmad if (/^\s*$/ && ($opt_a||$name)); } &printmad if $opt_a || $name; exit(0); sub printmad { if ($name && $mail) { print " \"$name\" <$mail>,\n"; } elsif ($mail) { print " <$mail>,\n"; } $name = 0; $mail = 0; $fax = 0; } ----
Jonathan Heileger and myself are doing some work on issues similar and inclusive to this, having to do w/ inter-NOC communication, and we are planning a presentation at the next NANOG. FYI... -alan ......... Dorian Kim is rumored to have said: ] ] This would be something we could probably standardize. I wonder how many folks ] have mail aliases like routing@xxx.net, noc@xxx.net, etc to bounce messages ] right ways. At the ver least, it'll make /etc/alias file shorter for good ] number of people. :) ] ] -dorian (trouble@cic.net) ] ] On Thu, 2 May 1996, Nevin Williams wrote: ] ] > We here like trouble@ans.net. It's an all-purpose group, like ] > support, but has a sense of urgency to it. ] > ] > Nevin ] > ] > ] > -Nevin Williams ] > ANS Network Operations ] > ] > ] > ] > Andrew Partan writes: ] > > ] > > > I have found that, with only one unnamed exception, if you write ] > > > to support@isp.net ] > > ] > > How about folks use: ] > > routing@isp.net ] > > to reach people? ] > > ] > > [Is there any consensus on various support aliases that an ISP 'should' ] > > have? noc, help, hostmaster, support, postmaster, routing, info, sales, ] > > trouble, others?] ] > > --asp@partan.com (Andrew Partan) ] > > ] > ] > ] > ] > ] ]
You know that all this stuff was standardized long ago at an IETF working group? The group was called Network Joint Management. We all agreed that there should be a trouble mailing list for each NOC and I believe we agreed on AS mailing lists as well. It is a shame, but I don't believe that that group ever put out an RFC specifying this. There was also a group that worked on inter-NOC communications and sharing trouble tickets, etc. ---Cathy From: Alan Hannan <alan@gi.net> Subject: Re: Out of date contact information Jonathan Heileger and myself are doing some work on issues similar and inclusive to this, having to do w/ inter-NOC communication, and we are planning a presentation at the next NANOG. FYI... -alan ......... Dorian Kim is rumored to have said: ] ] This would be something we could probably standardize. I wonder how many folks ] have mail aliases like routing@xxx.net, noc@xxx.net, etc to bounce messages ] right ways. At the ver least, it'll make /etc/alias file shorter for good ] number of people. :) ] ] -dorian (trouble@cic.net) ] ] On Thu, 2 May 1996, Nevin Williams wrote: ] ] > We here like trouble@ans.net. It's an all-purpose group, like ] > support, but has a sense of urgency to it. ] > ] > Nevin ] > ] > ] > -Nevin Williams ] > ANS Network Operations ] > ] > ] > ] > Andrew Partan writes: ] > > ] > > > I have found that, with only one unnamed exception, if you write ] > > > to support@isp.net ] > > ] > > How about folks use: ] > > routing@isp.net ] > > to reach people? ] > > ] > > [Is there any consensus on various support aliases that an ISP 'should' ] > > have? noc, help, hostmaster, support, postmaster, routing, info, sales, ] > > trouble, others?] ] > > --asp@partan.com (Andrew Partan) ] > > ] > ] > ] > ] > ] ]
Cathy wrote:
You know that all this stuff was standardized long ago at an IETF working group? The group was called Network Joint Management. We all agreed that there should be a trouble mailing list for each NOC and I believe we agreed on AS mailing lists as well. It is a shame, but I don't believe that that group ever put out an RFC specifying this. There was also a group that worked on inter-NOC communications and sharing trouble tickets, etc.
Because (a) Randy has taught me that drafts speak louder than words, and because (b) BIND is eating my face today and I needed a distraction, and because (c) it's been several hours and bmanning hasn't written a new draft to cover this conversation, I hereby submit the following. If it seems like the right approach (that is, all I get back are editorial nits, "good idea please continue"'s and "you forgot to mention"'s), I will send this to the Ops A-D's and see what they want to do with it. Operational Requirements Area Paul Vixie (ISC) INTERNET-DRAFT May, 1996 <draft-vixie-ops-stdaddr-00.txt> Standard Electronic Mail Addresses For Internet Operations Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This draft enumerates and describes standard electronic mail addresses to be used when contacting the operations personnel of an arbitrary domain. As an operational standard, the recommendations herein pertain to vendors only inasmuch as their end user documentation should recommend that these mail addresses be aliased to appropriate end user personnel. This document should be advanced as a recommended standard, since some of the behaviour it advocates is not prevalent enough to be called the ``best current practice.'' Expires November 1996 [Page 1] INTERNET-DRAFT STD ADDR May 1996 1 - Rationale and Scope 1.1. Several previous RFC documents have specified electronic mail addresses to be used when reaching the operators of the new service; for example, [RFC822 6.3, C.6] requires the presence of a <POSTMASTER@domain> address on all hosts that have an SMTP server. 1.2. Other protocols have defacto standards for well known addresses, such as <USENET@domain> for NNTP (see [RFC977]), and <WEBMASTER@domain> for HTTP (see [HTTP]). 1.3. Defacto standards also exist for well known addresses which have nothing to do with a particular protocol, e.g., <ABUSE@domain> and <TROUBLE@domain>. 1.4. The purpose of this draft is to collect all of these well known addresses in one place, add a few new ones, and ultimately recommend that IANA carry these addresses in future editions of its Defined Numbers periodical. 2 - Definitions and Invariants 2.1. The scope of a well known mail address is its domain name. Thus, the mail exchangers (see [RFC974]) for a domain must handle well known addresses even though some of these addresses might pertain to services not offered by the mail exchanger hosts. So, for example, if an NNTP server advertises the organization's top level domain in ``Path:'' headers (see [RFC977]), the mail exchangers for that top level domain must accept mail to <USENET@domain> even if the mail exchanger hosts do not serve the NNTP protocol. 2.2. A host is not required to run its own SMTP server, but every host that implements a protocol covered by a well known mail address should have an MX RRset (see [RFC974]) and the mail exchangers specified by this RRset should recognize this host's domain name as ``local'' for the purpose of accepting mail bound for a well known address. Note that this is true even if the advertised domain name is not the same as the host's domain name; for example, if an NNTP server's host name is DATA.RAMONA.VIX.COM yet it advertises the domain name VIX.COM in its ``Path:'' headers, then mail must be deliverable to both <USENET@VIX.COM> and <USENET@DATA.RAMONA.VIX.COM>. Expires November 1996 [Page 2] INTERNET-DRAFT STD ADDR May 1996 2.3. For well known addresses that are not related to protocols, only the organization's top level domain name need be valid. For example, if an Internet service provider's domain name is NETCOM.COM, then the <ABUSE@NETCOM.COM> address must be deliverable, even though the customers whose activity generates complaints use hosts with more specific domain names like SHELL1.NETCOM.COM. 2.4. Well known addresses ought to be recognized independent of character case. For example, POSTMASTER, postmaster, Postmaster, PostMaster, and even PoStMaStEr should all be deliverable and should all be delivered to the same mailbox. 3 - Well Known Addresses 3.1. Protocol Related Addresses Address Protocol Standard(s) ------------------------------------------- postmaster SMTP [RFC821], [RFC822] usenet NNTP [RFC977] webmaster HTTP [HTTP] uucp UUCP [RFC976] 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 4 - Other Well Known Addresses 4.1. Many mailing lists have an administrative address to which add/drop requests and other metaqueries can be sent. For a mailing list whose submission address is <LIST@DOMAIN>, the usual administrative address is <LIST-REQUEST@DOMAIN>. With the advent of list management software such as MajorDomo, this convention is becoming less common and its absence for any given mailing list should be treated as an inconvenience rather than as an error or standards violation. Expires November 1996 [Page 3] INTERNET-DRAFT STD ADDR May 1996 4.2. Several Internet Registries implement mailing lists for Autonomous System contacts. So, for example, mail sent to <AS3557@RA.NET> will at the time of this writing reach the technical contact for Autonomous System 3557 in the BGP4 (see [RFC1654], [RFC1655] and [RFC1656]). Not all Autonomous Systems are registered with all registries, however, and so undeliverable addresses under this scheme should be treated as an inconvenience rather than as an error or a standards violation. 5 - Security Considerations Denial of service attacks (flooding a mailbox with junk) will be easier after this document becomes a standard. 6 - References [RFC821] J. Postel, "Simple Mail Transfer Protocol", RFC 821, Information Sciences Institute, 08/01/1982 [RFC822] D. Crocker, "Standard for the format of ARPA Internet text messages", RFC 822, University of Delaware, 08/13/1982. [RFC974] C. Partridge, "Mail routing and the domain system", RFC 974, CSNET CIC BBN Laboratories Inc, 01/01/1986. [RFC976] M. Horton, "UUCP mail interchange format standard", RFC 976, Bell Laboratories, 02/01/1986. [RFC977] B. Kantor (et al), "Network News Transfer Protocol: A Proposed Standard for the Stream-Based Transmission of News", RFC 977, University of California, February 1986. [RFC1654] Y. Rekhter (et al), "A Border Gateway Protocol 4 (BGP-4)", RFC 1654, T.J. Watson Research Center, IBM Corp., 07/21/1994. [RFC1655] Y. Rekhter (et al), "Application of the Border Gateway Protocol in the Internet", RFC 1655, T.J. Watson Research Center, IBM Corp., 07/21/1994. Expires November 1996 [Page 4] INTERNET-DRAFT STD ADDR May 1996 [RFC1656] P. Traina, "BGP-4 Protocol Document Roadmap and Implementation Experience", RFC 1656, cisco Systems, July 1994. [HTTP] T. Berners-Lee (et al), "Hypertext Transfer Protocol -- HTTP/1.0", <draft-ietf-http-v10-spec-05.txt>. 7 - Author's Address Paul Vixie Internet Software Consortium Star Route Box 159A Woodside, CA 94062 +1 415 747 0204 <paul@vix.com> Expires November 1996 [Page 5]
In message <9605030534.AA13791@wisdom.home.vix.com> Paul Vixie wrote:
3 - Well Known Addresses
3.1. Protocol Related Addresses
Address Protocol Standard(s) ------------------------------------------- postmaster SMTP [RFC821], [RFC822] usenet NNTP [RFC977] webmaster HTTP [HTTP] uucp UUCP [RFC976]
This list should probably also contain `hostmaster' as the contact for DNS-related matters. Although *in principle* this contact information should be obtainable from the SOA RR for the zone, standardising it here should make things easier. James ======= ___ === James Aldridge, Network Engineer, ====== / / / ___ ____ _/_ ==== EUnet Communications Services BV ===== /--- / / / / /___/ / ===== Singel 540, 1017 AZ Amsterdam, NL ==== /___ /___/ / / /___ /_ ====== Tel. +31 20 6233803; Fax. +31 20 6224657 === ======= [ 24hr emergency number +31 20 4210865 ]
On Thu, 2 May 1996, Paul A Vixie wrote:
Standard Electronic Mail Addresses For Internet Operations
I like it overall -- definately needed right around now. Just a few comments....
4 - Other Well Known Addresses
4.1. Many mailing lists have an administrative address to which add/drop requests and other metaqueries can be sent. For a mailing list whose submission address is <LIST@DOMAIN>, the usual administrative address is <LIST-REQUEST@DOMAIN>. With the advent of list management software such as MajorDomo, this convention is becoming less common and its absence for any given mailing list should be treated as an inconvenience rather than as an error or standards violation.
A list of some of these might not be a bad idea, since many users will be unfamiliar with more standard addresses. I'd suggest including (in no particular order) the following: 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
5 - Security Considerations
Denial of service attacks (flooding a mailbox with junk) will be easier after this document becomes a standard.
Would it be appropriate to mention Procmail here as a partial solution, or would that be better suited to a seperate document? ---------========== J.D. Falk <jdfalk@cybernothing.org> =========--------- | "He who waits for the sword to fall upon his neck | | will surely lose his head." -Stephen R. Donaldson | ----========== http://www.cybernothing.org/jdfalk/home.html ==========----
[...] I'd suggest including (in no particular order) the following:
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
hostmaster was done in the -01 draft, sent shortly ago. security seems reasonable but is this current practice anywhere you know of? www and news are current practice, i'll add those but note that these are used for internal errors in those services and may point to different folks than the ones for external queries. listowner is new to me. i've seen listserv. i think this is slippery enough to warrant a blanket "use *-REQUEST or POSTMASTER" which is what -01 says. comments on this are welcome. routing is a current practice. i'll add it. nic should probably be a synonym for hostmaster rather than noc. help for support seems reasonable. should the document state which of these are recommended for new sites and which are listed only for backward compatibility with random older nonstandardized sites? i think so.
5 - Security Considerations
Denial of service attacks (flooding a mailbox with junk) will be easier after this document becomes a standard.
Would it be appropriate to mention Procmail here as a partial solution, or would that be better suited to a seperate document?
totally inappropriate for this document, thanks for asking though.
On Fri, 3 May 1996, Paul A Vixie wrote:
[...] I'd suggest including (in no particular order) the following:
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
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. [various other comments munged]
should the document state which of these are recommended for new sites and which are listed only for backward compatibility with random older nonstandardized sites? i think so.
Agreed. ---------========== J.D. Falk <jdfalk@cybernothing.org> =========--------- | "Whatever thy hand findest to do, do it with all thy heart." | | -- Jesus of Nazareth | ----========== http://www.cybernothing.org/jdfalk/home.html ==========----
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
[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.
Paul A Vixie
[...] I'd suggest including (in no particular order) the following:
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
hostmaster was done in the -01 draft, sent shortly ago. security seems reasonable but is this current practice anywhere you know of? www and news are current practice, i'll add those but note that these are used for internal errors in those services and may point to different folks than the ones for external queries.
don't know if security is a standard alias anywhere else but mci uses it extensively. it would seem a *good* practice for everyone to use that alias.
listowner is new to me. i've seen listserv. i think this is slippery enough to warrant a blanket "use *-REQUEST or POSTMASTER" which is what -01 says. comments on this are welcome.
i've seen list owner a quite a few provider type domains. at least in places where someone runs a bunch of lists from majordomo. actually i guess i've seen it aliased to majordomo, or synonamous with. -brett
I've added SECURITY since we need something like it and this is the name most people who have it now are using. I've added ROUTING to do what TROUBLE is often used to do. Since I agree with Randy than a minimum useful set seems ideal, I've added a new section ("optional, less well known addresses") with NIC, WWW, NEWS, LISTOWNER, TROUBLE (no longer "recommended", in favour of ROUTING and NOC), and HELP.
From: kaminski@nanospace.com (Peter Kaminski)
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
I'll add INFO as a general contact point. SALES is outside our scope (this is a technology document after all). Rather than FTP-ADMIN how about FTP? I'll make FTP-ADMIN an "optional, less well known address".
From: David Stoddard <dgs@us.net>
On our net, we have developed a series of role accounts based on various ways our customers have tried to reach us over the past three years. This list is intentionally comprehensive in order to reach the widest possible audience. Some folks may find these useful. Some of these, including billing, info, and sales, are used commonly by many providers.
Role Account Aliases Description ------------ ------------ -------------------------------------- postmaster maiser SMTP Administration hostmaster Domain Contact gophermaster Gopher Server Administration webmaster Web Server Administration uucp UUCP Administration usenet news NNTP Administration news-request news-requests News Group Requests root operator System Administrator ops abuse security Security Administrator secure decode dns dnsadmin Domain Administration noc trouble Network Operations routes routing Routing Administrator admin manager Administrative Management office asNNNN AS Contact (where NNNN is AS number) billing bills Customer Billing account accounts Account Administration subscribe subscription info information Automated Info Reply Server info-request sales marketing Sales and Marketing support supports Customer Support service services help bounce test Mail Test Reflector
Some of those choices are amazing to me, like ABUSE->SECURITY. I will add ROOT to the less-well-known table. I briefly considered adding asNNNN but I think ROUTING will serve adequately for the purpose of this document. With this feedback, I believe the document is ready to go to Cynthia. I'll send it to the OPS AD's, both of whom have said this thing is reasonable. Remember that although this started on NANOG, that was because NANOG hosted a discussion thread that inspired me to write this common knowledge down. Once IETF gets it, the document's scope becomes international. Thus, there will probably be some more addresses added in the first post-Cynthia rev.
On Fri, 3 May 1996, Paul A Vixie wrote:
I've added SECURITY since we need something like it and this is the name most people who have it now are using.
I've added ROUTING to do what TROUBLE is often used to do.
Since I agree with Randy than a minimum useful set seems ideal, I've added a new section ("optional, less well known addresses") with NIC, WWW, NEWS, LISTOWNER, TROUBLE (no longer "recommended", in favour of ROUTING and NOC), and HELP.
Just one nitpick. As best as I can tell, usage of trouble@xxx.net is still very current and prevalent. -dorian
(I'm removing all addresses but "nanog@merit.edu" from the headers when I reply to someone I know is on the list -- I hope everyone else starts doing this also, so that I'll stop getting two copies of everything...)
Just one nitpick. As best as I can tell, usage of trouble@xxx.net is still very current and prevalent.
-dorian
This is another gray area. I don't consider this address name to have been well chosen, since TROUBLE doesn't say much about what kind of trouble one is experiencing. If my car won't start after I interview at xxx.net, and I'm stuck in the parking lot, should I send mail to TROUBLE@xxx.NET from my little Radiomail HP200? Probably not. But the name doesn't say. Therefore the document recommends ROUTING and NOC, and makes TROUBLE into an optional "backward compatibility" address. This is because I'm trying to describe the BEST current practice rather than ALL current practices. This won't be universally easy for folks to implement, but I believe the 'net will be a better place after that necessary pain than it is now.
Paul, While I agree with your effort, this has moved to prospective namespace design as opposed to documenting a very few current practices. randy
In message <9605031731.AA14579@wisdom.home.vix.com> you write:
I've added SECURITY since we need something like it and this is the name most people who have it now are using.
You might want to consider adding CERT as a common alias for SECURITY (or vice versa). James ======= ___ === James Aldridge, Network Engineer, ====== / / / ___ ____ _/_ ==== EUnet Communications Services BV ===== /--- / / / / /___/ / ===== Singel 540, 1017 AZ Amsterdam, NL ==== /___ /___/ / / /___ /_ ====== Tel. +31 20 6233803; Fax. +31 20 6224657 === ======= [ 24hr emergency number +31 20 4210865 ]
From: James Aldridge <jhma@EU.net>
You might want to consider adding CERT as a common alias for SECURITY (or vice versa).
I don't think so. CERT has passed from the relative to the absolute; in my mind there is only one CERT, not one per site as originally recommended.
......... James Aldridge is rumored to have said: ] ] In message <9605031731.AA14579@wisdom.home.vix.com> you write: ] > I've added SECURITY since we need something like it and this is the name ] > most people who have it now are using. ] ] You might want to consider adding CERT as a common alias for SECURITY (or ] vice versa). And while you're at it, add SPRINT for routing policy information at all the sites. -a tongue-near-cheek
You wrote:
security Network Operations System security or hacking
hostmaster was done in the -01 draft, sent shortly ago. security seems reasonable but is this current practice anywhere you know of? www and news are current practice, i'll add those but note that these are used for internal errors in those services and may point to different folks than the ones for external queries.
security is currently in use at NETCOM, although it doesn't go anywhere near Network Operations. :-) +j -- Jeff Rizzo
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
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
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.
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
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
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
participants (20)
-
Alan Hannan -
Alex.Bligh -
Andrew Partan -
bmanning＠isi.edu -
brett＠tta.com -
cathy＠home.net -
Curtis Villamizar -
David.Kessens＠ripe.net -
Dorian Kim -
Ed Morin -
J.D. Falk -
James Aldridge -
Michael Dillon -
Nevin Williams -
Paul A Vixie -
Per Gregers Bilse -
randy＠psg.com -
Robert Bowman -
Sean Donelan -
the Riz