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

[Owen DeLong]

A hard and fast policy is only preferable to discretion if the hard and
fast policy limits the power of the staff to reclaim resources.  In this
case, the leeway or discretion being given is the option of NOT reclaiming
resources in circumstances which would otherwise fit the policy if the
staff believes this to be wrong.  I believe that form of discretion is
not only desirable, but, necessary at least until we have had some
experience and opportunity to fine tune such a policy.

Between you and Glenn, you have now convinced me to fully support 2005-2 as
it is currently written.

Owen


--On Sunday, April 17, 2005 21:15 -0700 Jeff Williams 
<jwkckid1 at ix.netcom.com> wrote:

> 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 actually
>> 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 gotA LOTT 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 thriTuesdayay 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
>> >publiclyly 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 potentially a HUGE
>> > > amount of work for ARIN and for ISPs with large amounts of
>> > > re-assignment information. I think this is way tooaggressivee 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 howaggressiveve" 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
>
>



-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050417/7cfa797b/attachment.sig>