[ppml] Policy Proposal 2003-1: Human Point of Contact
william at elan.net
william at elan.net
Thu Mar 6 16:12:30 EST 2003
That was exactly my concern as well. Its one thing to tell that contact is
supposed to be valid (which is actually easy to check - invalid contact is
the one where email bounces or phone# is disconnected) but its another to
say how ISP should setup their phone system so you could reach somebody.
This kind of thing can be a recommendation, but I do not see it as being a
policy requirement.
However the current policy proposal is actually valid - it requires human POC
and ARIN does see a difference in ther database and on templates between
human and role contacts. So this is possible to implement as a policy,
I'm just not sure if its a good idea.
On Thu, 6 Mar 2003, Hyunseog Ryu wrote:
>
>
>
>
>
> 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
> > >>
> > >>
> > >
>
More information about the ARIN-PPML
mailing list