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

[Owen DeLong]

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


-------------- 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/bbcf1fe5/attachment.sig>