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

Jeff Williams jwkckid1 at ix.netcom.com
Mon Apr 18 05:33:30 EDT 2005


Qwen and all,

> --On Sunday, April 17, 2005 23:37 -0700 Jeff Williams
> <jwkckid1 at ix.netcom.com> wrote:
>
> > Owen and all,
> >
> >   It is often true that hard and fast policies once established can
> > be wrong or become wrong.  Hence I can understand your
> > propensity for allowing ARIN staff to exercise some discretionary
> > authority.  However, that said, I am sorry your thought processes
> > are so indelibly limited to anything I or Glenn has said.  Such seems
> > a bit myopic in nature.  So I hope you will try to be more open
> > minded or broad minded.
> >
> I think you misunderstood my statement, sir.  My decision is not inexorably
> linked to what you have said, I merely gave the two of you credit for
> convincing me.

  Understood of course.  And I didn't not say or even intimate that
I or Glenns' remarks or expressed thoughts here, were *inexorably*
linked to convincing your decision..  Hence I believe you may have
misunderstood me and/or Glenn...

>  My mind remains very open to additional debate, but, the
> case the two of you have presented has, thus far, convinced me to
> shift my thoughts from skeptical consideration believing this policy was
> a flawed step in the correct direction to believing that the policy actually
> does address my objections fairly well and is a good starting point for
> dealing with the issues at hand.
>
> >   The many obvious reasons why having any staff of any organization
> > to have discretionary authority over any limited resource are usually
> > considered obvious.  Hence in part my previous remarks.  As we
>
> You are correct, except... That statement applies when the discretion is
> the discretion to inflict additional harm. a

  Yes and harm has already been inflicted on too many occasions for me
to have kept count...

> When the discretion is strictly
> limited to the discretion to prevent harm, said discretion is usually in
> the public interest, especially with new policies with minimal operational
> experience.

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

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

>  You and Glenn have convinced me that is the case through your
> arguments.  If someone presents compelling evidence this is not the case,
> I am open to that, but, the evidence you two have presented so far leads
> me to that conclusion, and, I am giving you appropriate credit for that.
>
> > all should have by now learned, such discretion in the past has lead
> > to a number of already discussed and debated problems with
> > allocation and use of Ipv4 address space.  I don't believe that
> > these lessons need to be learned again.  I hope no one else does
> > either.  So Owen, I hope you will reconsider your reason for your
> > decision based on a more broad thoughtful way.  Of course you
> > may still arrive at the same decision.  >:)
> >
> Indeed, I believe that is what I did in the first place.  I was already
> leaning towards support for this policy based on much broader consideration.
> Finally, I included the arguments put forth by you and Glenn as additional
> input, and, became convinced that the majority of the opposition to the
> policy was based on a misinterpretation of the harm this particular form
> of discretion could do.  As a result, I concluded that support for this
> policy was the right thing to do.
>
> Owen
>
>   ------------------------------------------------------------------------
>
>    Part 1.2       Type: application/pgp-signature
>               Encoding: 7bit

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





More information about the ARIN-PPML mailing list