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

[william at elan.net]

Ok, so to summarize you do not actually want human contact poc but want 
human reachable via poc information. This I'm not sure is really up to 
ARIN to tell their subscriber members how to setup their telephone system 
or email server (comes again as operational issue), nor does there seem to 
be clear way to test and punish if its not done so.

Rather better would be to actually have policy that says they must have 
valid contact (i.e phone# and email are valid and ARIN can send email and 
get reply for example) and specify as recomendation that as an option it 
must be possible to talk to somebody on the phone or get human response 
(as recomendation it might well be ok).

On Thu, 6 Mar 2003, Owen DeLong wrote:

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