[arin-ppml] 8.2 Transfers at ARIN

Eric Oosting eric.oosting at gmail.com
Tue Dec 10 12:16:50 EST 2013


On Tue, Dec 10, 2013 at 11:07 AM, Martin Hannigan <hannigan at gmail.com>wrote:

>
> Hi Eric!
>

Marty "freak'n" Hannigan!


>
> On Tue, Dec 10, 2013 at 10:43 AM, Eric Oosting <eric.oosting at gmail.com>wrote:
>
>>
>> On Tue, Dec 10, 2013 at 9:58 AM, Martin Hannigan <hannigan at gmail.com>wrote:
>>
>>>
>>>
>>> On Mon, Dec 9, 2013 at 5:53 PM, John Curran <jcurran at arin.net> wrote:
>>>
>>>> On Dec 10, 2013, at 5:52 AM, David Huberman <
>>>> David.Huberman at microsoft.com> wrote:
>>>>
>>>> > John,
>>>> >
>>>> > Thank you for the stats.  They mostly tell the story I was thinking
>>>> they would:  a very low approval and completion rate.  And from that data,
>>>> PPML can build (and ask) for solutions so that Whois can be made more
>>>> accurate, and transfer requests can perhaps enjoy a much higher approval
>>>> and completion percentage.
>>>>
>>>> It's not often that I see >50% characterized as a "very low" percentage
>>>> rate.
>>>>
>>>
>>> I'd call anything < 90% failure.
>>>
>>
>> This is a bit like being concerned about lower then 100% ATM withdrawal
>> completion percentages when the KPI includes attempts where an invalid pin
>> is used and where users canceled the transaction, perhaps because of the $3
>> fee or perhaps because of some other reason.
>>
>
> The failure measurements would be telling as well with respect to the
> "policy". Instinct tells me that it's interpretation of "need", which has
> no relevance to registry accuracy and should be abandoned as a transfer
> requirement IMHO.
>

My $day_job is often to assist organizations with negotiating the ARIN
processes, which often boils down to properly documenting "need"; I,
therefor, could be considered to have an interest in maintaining status
quo. That isn't my position, however. You'll not hear an argument from me
when people talk about rearranging the deck chairs.

But, afaik, "need" isn't anywhere in 8.2, though it is in 8.3.

If you want to bring policy that strikes need from 8.3, you probably will
not hear an argument from me. I just need time to spin up a broker arm in
my consulting practice. (as if there aren't enough already)


> Unless we can absolutely tell which Abandoned or Rejected requests are in
>> bad faith (and I don't know that we can), I don't see how these statistics
>> are at all useful. Instead, I suggest we stop focusing on the completion
>> rates.
>>
>
> Well, they're useful in that we can see how deficient they are.
>

That's my point. I don't think the statistics, as measured, are useful in
determining deficiency. The number counts "failures", but some of those
"failures" are desirable outcomes, and we don't know how many.

Let's focus on what we want to actually fix:

1) do we want to make 8.2 transfers more transparent and straight forward,
thus improving and supporting "good" actors in their efforts to update
records?
2) do we want to discourage and detect "bad" actors from hijacking
resources that aren't legitimately theirs? Are we doing enough today?
3) do we want to remove "need" from 8.3? I'm unsure how this will be
received by the community.
4) do we want to strike "need" from elsewhere/everywhere in the NRPM? I
suspect I know how this would be received.
5) do we need more meaningful statistics on why transfers aren't going
through? (caution: intent is important here, and not necessarily easy to
determine or trust)

I'm happy to argue for or against these initiatives, or more accurately the
policy proposal in support of them, I just don't think the statistics are
useful as motivation. And I'm not sure we need them as a motivation,
anyways.

-e


> This doesn't mean that we shouldn't strive for a better process. Most are
>> agreed we could make this better. The line that must be waked is to prevent
>> and discourage bad actors while making it easier for good actors.
>>
>
>
> +1
>
>
>
> Best,
>
> -M<
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131210/b26a197b/attachment-0001.html>


More information about the ARIN-PPML mailing list