[arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8

[Owen DeLong]

I find this very interesting considering that both Stephen and I wrote NRPM 12 as an effort to prevent ARIN from over-reaching on enforcement and to provide reassurance to the community that ARIN was focused on providing appropriate protections of community resources and not merely bureaucracy for the sake of bureaucracy.

I do not believe that the existing provisions in NRPM 4 or NRPM 6 for the prevention of fraud and/or gaming of the system are unnecessary or obviated by what is contained in section 12. Indeed, in order to function at all, section 12 depends on those policies to provide guidance as to how and when the enforcement mechanisms defined in section 12 are to be used.

Owen

On Apr 4, 2014, at 9:57 AM, David Huberman <David.Huberman at microsoft.com> wrote:

> In my message you are replying to, I accidentally forgot to address the hijacking issue.  (Last message from me on list today, I promise!)
> 
> I think Owen DeLong and Stephen Sprunk did a really good job addressing the whole hijacking and scamming problem when they authored NRPM section 12.  Between ARIN's legal protections in the RSA and as a business incorporated in, and operating in, the United States, and the policy levers that NRPM 12 give, I think that whole issue is well covered by policy.   In general, I do not agree with section 4, 6, or 6 policy that tries to account for scammers.  We should make policy for the 99%, not the 1%.  Let ARIN as a business, and ARIN as an enforcer of NRPM 12, deal with that -- and report back to us any deficiencies in tools.
> 
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Morizot Timothy S
> Sent: Friday, April 4, 2014 8:47 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 106, Issue 8
> 
>> -----Original Message-----
>> From: David Huberman [mailto:David.Huberman at microsoft.com]
>> Sent: Friday, April 04, 2014 10:22 AM
>> 
>> With an exhausted IPv4 pool, there are no "pool limitations at the 
>> time of allocation" as there are no allocations.  ARIN's role in IPv4 
>> is primarily the third goal above: registry accuracy.
>> 
>> That's why I advocate removing needs-basis from transfers in a post- 
>> exhaustion world.  There's no pool to manage[1], so the only OFFICIAL 
>> mandate ARIN has from the network operator community is to run an 
>> accurate registry.
> 
> I've actually been consistently in favor of IPv4 policies over the past couple of years that seemed likely to exhaust the IPv4 free pool sooner rather than later, so I have no real objection to altering the existing rules. I'm not convinced that eliminating needs basis in a post-exhaustion world would lead to fairer utilization or more competitiveness, but I would probably favor such a change since it would likely make IPv4 less palatable more quickly. (Of course, I believe the global inter-rir policy has a needs basis aspect so I think removing all needs basis from transfers would mean ARIN could no longer do inter-rir transfers, but that's a separate issue.)
> 
> They still have to protect against hijacking, which is a process that requires active regulation, even without needs basis for IPv4 transfers.
> 
> And, of course, there will be a need for at least some sort of needs basis on the IPv6 side going forward.
> 
> So I'm not necessarily againt simplifying policy in rational ways or to achieve clearly expressed aims. I don't think there's very much that's going to convince legacy holders who aren't already actively engaged to improve their registry information, though. That part of the IPv4 registry is and will almost certainly remain a swamp. I think it's more productive to focus on an accurate IPv6 registry and move on.
> 
> Scott
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.