OK, perhaps, then, we should consider two contacts:
Complaints contact (the destination for complaints about
SPAMMERS and such) (SPAM)
Enforcement contact (the destination for people who can respond
to real-time hacking concerns) (SMURF, FLOOD, HACKING)
Tech contact would still be my bet for Bad BGP, as this is usually
accidental and not malicious.
Bottom line, the Tech. contact for alot of these providers is an address
that gets reviewed once a day or such and doesn't provide anything more
effective than a secretary putting a post-it on the door. The Admin
contact is supposed to be just that, and usually is. The billing contact,
as I see it would only be used by InterNIC and possibly people who want
to seek reparations for SPAM.
I don't pretend that the names I chose above are necessarily the best terms
that can be applied, and I am flexible about what to call them. However,
I do think they are needed at this point.
rfc2142 only deals with email addresses, what if the host is conducting a
denial of service attack and you need to call someone. email addresses are
rather less useful then. a quick whois and ring up is usually more
effective in getting an attack shut down.
May I humbly suggest that we extend RFC2142 in the following fashion:
All domain names should include a host named LDAP at which an LDAP server
is operational which will answer queries for specific contact information
for that domain. For example, if the domain name is example.com then the
host named ldap.example.com would have a publicly accessible LDAP server
available.
The intent is for this server to make available up to date contact
information for network operations people that deal with various types of
emergency and non-emergency operational issues. An ongoing SMURF attack
would be an example of an emergency issue whereas a peering request would
be an example of a non-emergency issue.
The contact information that is made available is intended only for use by
operations people at other network providers. Because the servers are
publicly accessible, the information may be
shielded by suppling contact info for a "dispatch" person who acts as a
gatekeeper for the real information. However this dispatcher must be able
to promptly forward calls on a 24/7 basis in order to properly handle
emergency issues.
The LDAP server will make available the following objects:
index
security
abuse
peering
smurf
... (and the list goes on)
At a minimum, each emergency contact must contain an internationally
accessible phone number including area/city codes and country code. And
each non-emergency contact must include at least an email address.
It is expected that man network operators will use a backend server that
supports dynamic information so that contact info can be easily changed to
reflect shift schedules, etc.
P.S. This is pretty rough but I think you get the idea. Obviously it
relies on having a working network connection to retrieve the information
but because the info is published in a standard format, it wouldn't be too
hard for some people (DRA?) to suck in copies from everyone with an AS
number and make that available along with a few mirrors for robustness.