[ppml] Policy Proposal 2003-1: Human Point of Contact

Thu Mar 6 16:22:41 EST 2003

Thanks for your comments.  I hope to publish an amended draft which should
address most of your concerns.  Please seem my inline comments below.

--On Thursday, March 6, 2003 11:13 AM -0800 william at elan.net wrote:

> I did not yet comments on 2003-1 and I'm not entirely made up my mind
> yet,  but I have to say I'v not been conviced by either side and I see
> problems  with it for both ISP that is listing its contacts and for
> community  itself that wants to use the contact info:
> I. ISP
>  1. Some companies have charn with their employees changing quickly
>     and some often change assignments/roles within companies, its easier
>     to keep "role contact", its more up to date.

Agreed.  This wasn't so much about having a specific human contact (at first
I thought it was, but my position has changed some) as it is about having
a contact which is:
	1.	A phone number that reaches a live human being capable of
		resolving problems or getting the caller to someone who can
		resolve their problem.  Not an automaton or voice jail.
		The human should only be required to be reachable during
		normal business hours in the timezone applicable to the POC
		address on file, although 24x7 is strongly encouraged
		where practicable.

and

	2.	An email address which, may send a receipt acknolwedgement
		automatically, but which maintains a committment that the
		received mail will be read by a human within 48 hours of
		receipt.

>  2. People do not like to be listed in public whois information because
>     they inevitibly begin to get contacted for issues not related to
>     do and called names, etc.

Agreed.

>  3. People do not like to be listed in public whois because that
> information is     harvested by advertisers.
>

I have a little less sympathy here, as I think we should be working harder
to prosecute this type of violation in the harvesting.

> II. Contact to ISP
>  1. If person is not available and its the only contact listed (as its
>     the only contact required!), you have a real problem.

It is _NOT_ the only contact required.  The standard requirements for
Tech and Admin contacts remain.  This contact could either be one of them,
or could be an additional contact.  The requirement is to list at least
one admin or tech contact.  I believe it is possible to list multiple
contacts in any category.  In the amended proposal, I will suggest the
creation of a category of ABUSE contact, with the requirement that it
be possible to:

	1.	List multiple ABUSE contacts
	2.	The contact should have a Comment Field which can be used
		to specify types of abuse handled by a particular contact.

Further, at least one ABUSE contact should list a phone number which, during
normal business hours in the timezone applicable to the address listed on
said POC is answered by one or more live human beings capable of addressing
network abuse.  Further, that contact's Comment field should contain the
phrase "Live Contact" followed by the hours in 24hr format with timezone,
such as "Live Contact 0800-1700 US/Pacific Time".  The timezone should
be a POSIX timezone name.

>  2. For emergency situation its a lot more important to reach ANYBODY in
>     the say tech support or NOC then particular somebody.

Yes, and as such, it's important that at least one contact in the database
allow you to do exactly that, rather than a voice jail or a bouncing auto-
responder.

>  3. Human contacts are not available 24/7, role contacts are sometimes
>     (same as #2 really)
>
Same answer as 2.

> I do think its important to keep correct reachable info for at least one
> contact and most likely both abuse and noc if they are listed (as is with
> 2003-2), though 2003-2 I'll not support in its current form - it goes way
> way too far on the abuse prevention (I guess I'm moderate...) and to
> actions ARIN can not do (like control over routing table).
>
I agree.  I like most of the intenet of 2003-2, but I think the majority
of it is more of an IETF subject than an ARIN topic.  However, as it relates
to contacts, I'd like to find a common ground that allows Dr. Race and I
to say there is a contact-related proposal we both support and feel 
addresses
the issues within the scope of ARIN.

> In all, human contact does not hurt, but only as option to be decided by
> ISP and not necessarily as the only option of contact. I think new
> redisign of the database, solves most of it allowing multiple contacts to
> be listed as ISP desires (instead of only one contact as it was before).
> And its my understand (please correct me if I'm wrong, I'v not see it
> yet in real whois output yet!) that you can have multiple TECH, ABUSE,
> NOC  contacts for the same ORG or NET, allowing for both human and role
> contacts if ISP wants to do so.
>
It was never intended as the only option of contact.  It was intended to
require that AT LEAST ONE POC be listed that is not handled through purely
automatic means.  (Who do you call when the automatic systems you call to
report something broken are what's broken?)  That is the primary intent
behind this policy.

I believe you are correct about the multiple contacts.  That is why this
policy was worded with "At least one" and not "The...".

Thanks again,

Owen

> On Thu, 6 Mar 2003, Lee Howard wrote:
>
>> On Thu, 6 Mar 2003, McBurnett, Jim wrote:
>>
>> > Date: Thu, 06 Mar 2003 14:46:38 -0500
>> > From: "McBurnett, Jim" <jmcburnett at msmgmt.com>
>> > To: Lee Howard <lee.howard at wcom.com>
>> > Cc: ppml at arin.net
>> > Subject: RE: [ppml] Policy Proposal 2003-1: Human Point of Contact
>> >
>> >
>> > > pick an IP address, look up the ARIN record for that IP address, and
>> > > report it to the Abuse POC given in ARIN's records.  Only the latter
>> > > case is on topic for ARIN PPML.
>> >
>> > The later PPML topic is the one that confuses me sometimes, and hence
>> > the RFC ignorant.  A few ISP's I have been spammed from
>> > don't accept abuse@ secuirty@ etc.. And the ARIN POC is often
>> > inaccurate for the <fill in your choice word(s) here> people on
>> > purpose. And as of late,  many spammers are forging most of the header
>> > anyway....
>>
>> Somewhat separate issues, still, I think.
>> Enforcing ABUSE at domain isn't something I can imagine ARIN doing.
>> Requiring valid POC information is the subject of a current policy
>> proposal, 2003-2.
>>
>> > > or one of my domain names?  I'm not asking about the email address
>> > > ABUSE at domain, which is described in the RFC, I'm asking about
>> > > the Abuse
>> > > POC given in ARIN's WHOIS database.
>> >
>> > Good Point.. I guess my answer is let's push the POC Policy to get the
>> > POC's  to a higher level of accuracy...
>>
>> Excellent, I understand your position now.
>>
>>
>> > > In summary, I am asking if there is a proposal to require
>> > > something more
>> > > than reachability for the Abuse POC.  If there is, I am asking for
>> > > clarification, and whether this should be part of proposal 2003-1 or
>> > > a separate proposal.  If there is no such proposal, then there  is
>> > > no debate.
>> >
>> > Correction if there is no such proposal we need to create one...
>> > AND if it takes it, send the idea to the IETF..
>>
>> Here's the text of 2003-2:
>> http://www.arin.net/policy/2003_2.html
>> Excerpt:
>>
>>   2. All networks should [regardless of geographical location] provide a
>>   valid e-mail contact for network [NOC@] and abuse [Abuse@] contact.
>>   Make  it standard.
>>
>> It goes further to establish methods for verification and penalties for
>> non-compliance.  Are your concerns addressed by this policy proposal, or
>> do you have a new policy to propose?
>>
>> > Jim
>>
>> Thank you for taking the time to discuss the policies.  I must say that
>> it's good to see so much participation on the list; it definitely helps
>> clarify the proposals being considered at the meeting.
>>
>>
>> Lee
>>
>>
>