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

[Jeff Williams]

Glenn and all,

  I don't like the idea that the ARIN staff has significant leeway with
regard to discretion.  Discretion is a very nebulous thing and can be
easily inappropriately or improperly applied for any number of
reasons.  Hence a hard and fast policy for reclaiming resources
is unfortunately necessary.

Glenn Wiltse wrote:

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

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1 at ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827