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

[Leo Bicknell]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050415/f3c11193/attachment.sig>