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

Jeff Williams jwkckid1 at ix.netcom.com
Mon Apr 18 08:01:30 EDT 2005

Owen and all,

  I did NOT say ARIN had caused ANY harm.  I DID say that
harm has already occurred, AND that this proposed policy can
ONLY address one avenue by which harm can be caused.

  So I believe it is you that did not understand what I said, Owen.
And perhaps in part that is my fault.  I hope now you and/or
anyone else is clear as to what, why and how this proposed
policy is insufficient IF harm is to be dealt with given lack
of policy directives as well as unchecked discretion by the
ARIN staff.  Else, the same result Jon caused will undoubtedly
reoccur all be it to a lessor degree and/or possibly over a longer
time frame...

Owen DeLong wrote:

> Apologies to all if this seems like mostly rehash.  I will try not to
> respond again publicly unless there is significant new information.
> However, since Jeff still seems to be misunderstanding some of what I
> intended to say, I felt posting this last clarification was worth
> the effort.
> Owen
> [snip]
> >   Yes and harm has already been inflicted on too many occasions for me
> > to have kept count...
> >
> I don't see how:
>         1.      Harm can have been inflicted under a policy which does not
>                 yet exist.
>         2.      This policy grants any discretion which would allow staff
>                 to cause harm.  The discretion granted in this policy is
>                 strictly limited to the ability to prevent harm where it
>                 would otherwise be allowed under the policy.  In such a new
>                 type of policy with such potential to do harm, this seems
>                 a reasonable safety valve, IMO.
> If you are talking about harm done under other policies, then, that is not
> particularly germane to this discussion unless you can point to some place
> in this policy that I have missed where the discretion exists for ARIN staff
> to do additional harm rather than merely prevent it.
> >   Agreed, except if harm has already occurred on multiple occasions, than
> > the discretion exercised is either not good enough, improperly determined
> > far to often, or has other motivations for such discretion to be
> > exercised...
> >
> Again, I don't see how this makes sense in the context of discussing this
> policy.  Harm has not already occurred under this policy because this policy
> does not yet exist.
> >>  The only reason this is a bad idea in law enforcement is that
> >> it encourages corruption.  While, in the long run, it might be possible
> >> that people would "bribe corrupt ARIN officials to allow them to keep
> >> their inaccurate data in spite of refusal to correct it.", I don't think
> >> that is an issue in the immediate future.  As such, by the time such
> >> an issue came up, I think we would have sufficient operational experience
> >> to deal with that and modify the policy accordingly.  I also think that
> >> the oversight by the BOT and their emergency authority could be used to
> >> address any such situation that was detected or brought to their
> >> attention. As such, I think this is reasonably safe discretion to give
> >> to the staff under the current circumstances.  They have much wider
> >> discretion WRT the issuance of ASNs and IP addresses than this policy
> >> would give them in preventing the revocation.  The point here is that
> >> since this policy, as written, gives staff only the ability to prevent
> >> revocation and not the ability to cause revocation through their
> >> discretion, I believe this is very safe.
> >
> >   I disagree, the carrot without the stick is only a prelude to more
> > carrots, and future transgressions..  Yet the stick when not used
> > spoils the child, hence leaving latitude for further abuses to
> > occur or existing abusers to continue unchecked..  However,
> > if the stick has not policy that is strictly and exactly defined,
> > than as you indicate, the stick becomes to often used.  Hence
> > my original suggestion that hard and fast rules in the form of
> > a detailed policy is unfortunately necessary...
> >
> 1.      I don't really understand your meaning here.  Generally, I try
>         to avoid viewing the government has having anything close to a
>         parental role in my life.  Not that they don't try to usurp such
>         a role on a regular basis, but, it's just not a good place to go.
> 2.      This policy has no carrot and a very limited "stick".  If the POC
>         for a resource is completely non-responsive, then, it is quite likely
>         that the resource itself does not remain in legitimate use and should
>         be reclaimed.  The discretion granted in this policy is the ability
>         for staff to recognize and prevent an unwarranted revocation that
>         would otherwise occur in this policy.  That is, IMO, a prudent safety
>         valve for such an experiment.  I could not support such a policy
>         at this time without it.
> 3.      This is about public policy, not disciplining children.  If you do
>         not believe that there is a difference, then, we are much further
>         apart in our views than I had hoped, and, I believe we should simply
>         agree to disagree on this matter.
> Owen
>   ------------------------------------------------------------------------
>    Part 1.2       Type: application/pgp-signature
>               Encoding: 7bit


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

More information about the ARIN-PPML mailing list