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

Thu Mar 6 17:49:13 EST 2003

Hi there,

I missed some of emails regarding this thread because of my busy schedule.
So if I say same thing which other people said already, please forgive me.
^.^

In my point, what will be the penalty for this policy?
And how does ARIN check this policy implementation?
Somebody from ARIN call POC every year - maybe renewal time for membership
fee - to check whether ARIN members are following this or not?
I believe this is a kind of ISP or Enterprise internal policy to keep their
contact point as current as possible.
I had some difficulty to reach somebody for ISP contact when I had some
security issue or something like that.
But if we do make policy for organization internal policy like this, we
will have policy after policy, and without  mechanism to check whether
somebody is following this policy or not, I think this policy will be dead
policy, and that's not a good practice for overall policy concept.

If we have something like similar policy for yellow page or website contact
information by FCC or some government agency for validation of contact
point information, I may think this might be good policy.
But I don't think this will be a good policy for everybody.

Maintaining contact point to be reachable by ARIN Whois database will be
ISP's or End-user's responsibility, not ARIN's.
If we want to keep this as much as detailed, I believe it's enough to put
"recommendation" in ARIN's template to state this.

Hyun

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hyunseog Ryu / CCDA, MCSE, CCIE candidate(written test passed)
Senior Network Engineer/Applications Engineering
Norlight Telecommunications, Inc.
275 North Corporate Drive
Brookfield, WI 53045-5818
Tel. +1.262.792.7965
Fax. +1.262.792.7733
email: hryu at norlight.com

                      william at elan.net                                                                                          
                      Sent by:                 To:       Owen DeLong <owen at delong.com>                                          
                      owner-ppml at arin.n        cc:       ppml at arin.net, (bcc: Hyunseog Ryu/Brookfield/Norlight)                 
                      et                       Fax to:                                                                          
                                               Subject:  RE: [ppml] Policy Proposal 2003-1: Human Point of Contact              

                      03/06/2003 02:32                                                                                          
                      PM                                                                                                        

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