[ppml] Policy Proposal 2005-2: Directory Services Overhaul

[Glenn Wiltse]

  I'm really not comfortable aproving this policy without knowing many
of these deffinitions and procedures. I may be willing to support most
of this as a sort of trial policy that would not become 'offical' without
some future vote at anohter ARIN policy meeting. By offical, I guess what
I'm saying is I don't like the idea of ARIN reclaiming any address space
before we all know exactly what the deffinitions and procedures are. The
deffintions and procedures should also not be allowed to change without
future aproval at a policy meeting.

 After ariving in Orlando and getting my registration packets, I read
Raymond Plzak's 'observations' related to ARIN directory Services &
Data...  I noticed some interesting stuff that made me think more
about what drives some of my underlying feelings of being uncomfortable
with the proposed policy (2005-2). From Section 4.1 of that document...

 What should be the consquence of failing to maintain accurate data?
 What should be the conequence of inserting fraudulent data?

  Let me give you my own personal opion... Relating to this policy
discussion...  I feel the only valid reason to 'reclaim' a ARIN resource
should be FRAUD. Failing to maintain accurate data, should at worst result
in the removal or flaging of the data, not in reclimation of resources.
Now, if you could prove that the inaccurate data is actualy fraudulent
data, then reclimation would be reasonable. Now you may think that this is
somewhat like spliting hairs as to when in-accurate data becomes
fraudulent data, however I see this a a critical item, and quite frankly
should be left to the the actual legal system and not ARIN policy or
staff.

  Let me get back to a specific part of this policy proposal that I don't
like...

 "Third parties may report the inability to make contact with a party via
information in the APID. In this case ARIN shall attempt the contact
verification procedure for that contact immediately. If a response is
received, ARIN should document that a problem occurred, and the response
from the resource holder. Offenders who fail to respond to third parties
more than 4 times per month for three months may have their resources
reclaimed at the discretion of ARIN staff." I belive that there are

   I suggest to you that there can be valid re-assignments of ARIN
resources, that may for a varitey of reasons become non-responsive for
preiods of a month or longer, and should not constitute anything close to
being grounds for reclaimation or maybe not even be grounds for
'suspension'(depending on how that is defined).  Consider something such
as a seasonal business, or a very small busines where possibly the entire
staff is gone for a month or more. (possibly a small family based
business, etc...) Well, you say ARIN staff can use there 'discretion' to
determin that this is something that doesn't constitute a offense.  I say
that there shouldn't be room for ARIN staffs descretion... The only reason
for reclaiming resources based on 'inaccurate' or 'non responsive'
contacts, is FRAUD, which is legaly defined.

  Glenn Wiltse

On Fri, 15 Apr 2005, Leo Bicknell wrote:

> In a message written on Fri, Apr 15, 2005 at 10:34:02AM -0400, Glenn Wiltse wrote:
> >    I've got ALOT of concerns about this proposal. More then I do with
> > 2005-3.  Ed Lewis rasied several good points that I too am concerned about
> > relating to this proposal. Many of these terms such as SUSPEND, reclaim,
> > offenders, or even non-responsive, don't seem to be defined very well if
> > at all. The problems I have with this proposal are too numerous to go into
> > in every detail right now.
>
> They are not defined in the /policy/, which is not to say they are
> not defined.  For instance with regards to "non-responsive", I
> quote:
>
> ]         The ARIN staff shall publish the time thresholds and procedural
> ]         details to implement this policy on the ARIN web site.
>
> So before ARIN staff can call someone non-responsive they must
> publish the procedure they will use to contact people, and the
> amount of time to repspond before considered non-responsive.
>
> The reason the methods and timeframes are not spelled out in the
> policy is rooted in ARIN's own history of such things.  They never
> go as planned.  Perhaps they start with e-mail, but find as they
> do it phone always works better.  Perhaps they start out with 3
> months, but find out that makes the workload too hard so it's better
> to go to 6 months.  At the end of the day, what's important is that
> these are implementation details, not policy details.  We don't
> want policies that say "ARIN Staff will call the listed phonenumber
> on the thrid tuesday of the month at 2:30PM to see if you answer."
> They don't work.
>
> So yes, non-responsive is not defined in this policy, but it must
> be defined and published by staff prior to the implementation of
> the policy, and may be modified from time to time by the staff as
> approproate without having to go through a 2+year policy cycle.
> Sticking the staff, and ARIN members with bad methods or timeframes
> for 2+ years because that's how long it takes to change a policy
> is not a good course of action.
>
> >  Let me just ask about 'reclaim' a resource... Does that mean if a
> > ISP should assign a /24 to a customer, and that customer should commit
> > these 'offenses', do you then reclaim a whole /14 or larger resorce that
> > the /24 is part of?
>
> The policy allows for that possibility, however, in practice I don't see
> how it could ever occur.
>
> To get to a reclaim state, you have to go through the following steps:
>
> 1) Someone gets a resource.
>
> 2) ARIN attempts to verify the contact information.
>
> 3) Verification fails.
>
> 4) ARIN notifies the upstream.  (Note, there is a branch here in the
>    policy depending on if it is a verification problem with an ARIN
>    allocation, or with suballocation information.  I'm considering the
>    suballocation case as you asked about the "/24 to a customer" version).
>
> 5) The upstream does not correct the problem in a reasonable amount of
>    time.
>
> 6) The resource becomes suspended.
>
> 7) ARIN recontacts the upstream, asking them again to fix the problem.
>
> 8) The upstream does not correct the problem in a reasonable amount of
>    time again.
>
> 9) The resource (eg, the /14) can be reclaimed.
>
> Now, for #5 and #8, the upstream has several choices to correct the
> problem.  First, they can update the name/address/phone/e-mail that
> is wrong.  Since this is a customer I see no reason why the ISP
> wouldn't have that information, after all they are probably billing
> the person.  Second, if that's too hard for some reason under this
> policy they can simply remove the record.  No record is required
> (publically viewable), so no record is ok.  No record, no bad info,
> problem corrected.
>
> Given both of these corrections are boardline trivial, and the
> upstream gets two shots with a "reasonable amount of time" (which
> I would think would be some number of weeks) to make the fixes, I
> don't really see how it could ever happen.  However, an interesting
> case is the company that goes belly up completely, closing the doors
> never to be heard from again.  In that case it might get there, and
> ARIN would be right to reclaim the resource.
>
> >  Aside from these concerns... If ARIN staff don't have time to track down
> > 'lame delegation' offenders... how are they ever going to tackle this job
> > being proposed here? This is potentialy a HUGE amount of work for ARIN and
> > for ISPs with large amounts of re-assignment information. I think this is
> > way too agressive of a aproach.
>
> Well, first, we don't have the ARIN staff impact analysis, something I
> am eager to see myself.  They do have some experience in this area
> (mainly from the lame delegation work) so their estimates will be very
> interesting.
>
> As for how "agressive" it is, I'm not sure how you can make that
> statement.  There's no timeline in this document, specifically so
> if does take a lot of man hours they can set a verification time
> of "once a year" or similarly long time to reduce the workload.
> There's no requirement this happen once a week, or even anything
> approching "frequently".
>
> In terms of wasting staff time, I'm more concerned right now that
> we're spending man hours on both ARIN's side and the ISP's side to
> enter data that is worthless.  That's the real waste.  It's not
> hard to find thousands of records which are no good.  While getting
> over the hump and removing the old data is going to be a huge amount
> of work, waiting will only make that task larger later as we're
> still adding to the mess.  Once the data is cleaned up, the overall
> work load for ARIN staff and for customers should be significantly
> reduced.
>
> --
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
> 	PGP keys at http://www.ufp.org/~bicknell/
> Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
>