[arin-ppml] Clarify /29 assignment identification requirement

[Tim Gimmel]

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jack Bates
Sent: Thursday, April 26, 2012 9:14 PM
To: Jimmy Hess
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Clarify /29 assignment identification requirement

On 4/26/2012 8:44 PM, Jimmy Hess wrote:
>
> While ARIN's  auditing and review practices are and internal procedure 
> issue, and therefore out of scope of the PDP or the number resource 
> policy,
Only in the fact that it doesn't limit auditing. The NRPM does provide for auditing, so it could be clarified.

> What I feel should happen is ARIN should actually publish guidance, 
> and specific forms, stating what will routinely be requested in 
> standard resource reviews and application for resources, information 
> such that ISPs are appropriately prepared.
> Or  "examples"  of the documentation that ARIN will request.
>

I believe their fear here is that people will just write script kits to forge such information.


Of course this is possible.  It's also possible all the data could be fraudulent! But you cannot have all polices revolve around the few bad apples; they will show up.  Polices should apply the most organizations universally.
  Now that we are in runout and can only receive 3 month supply of IP addresses, ISPs must now watch their IP usage at the most granular level as possible.  So when it time to request more resources we want to be able to give the ARIN representatives exactly what they need to make an informed decision quickly.  If it is not stated in policy what will be requested then delays will ensue as the ISP tries to figure out how to fulfill the request, i.e. write scripts to read DHCP pools, then then link with customer databases etc.  This is very inefficient.  Our experience is when we hit 80% we have to get moving quickly to request resources, because by the time we get past the allocation procedure, get all upstream providers to open prefixes, get our own systems opened for the new prefix we are down to our last /24.
  I am curious as the issue with tracking /32's, this seems like the easiest to track.  Now I am referring to STATIC /32.  DHCP pools are a different animal; systems must be put into place to read leases files and then pull customer information to match with each address.  If ISP SWIP's per NPRM 4.2.3.7.3, and then asks for specifics for each individual customer in DHCP pools, this needs to be explicitly stated.  Otherwise there will always be delays in processing resource requests as the ISP goes and fetches the information requested.  It will never be ideal, but knowing  what is expected is the best path to success.

--Tim


I believe it would be better to strictly push for meeting sessions and direct viewing of information upon request in collaboration with the ISP when there is a question concerning the standard forms and the desire to verify.

Benefits:

1. The ARIN representative is viewing the information and signing off on it. No actual data is being stored by ARIN. This allows the ISP to guide and restrict what is being viewed to a degree to safeguard against any unauthorized activity an ARIN representative might engage in. It also reduces the amount of private data ARIN does store.

2. Except for the smallest requests, it allows ARIN to be very random on what they want to view and by questioning the ISP, view a variety of datapoints for verification like dhcp pools, snooping pools, ppp sessions, dslam screens showing connected ports, data traffic loads/counters for a variety of interface types. In some cases, ISP might not be against showing live flow data at PE, which could be verified against data sent in real time from ARIN representative (see, this is a real router!). Or, because not everyone is a connectivity provider, I presume one could view a few commands on a server to see mass usage of address space for X reason (although I'd think most SSL/IP setups just generate a quick scan of those sites by ARIN).

3. Makes it much more difficult for someone to make a fraudulent request without creating what equates to a full ISP.

Cons:

1. Representatives may spend more time in a meeting than they would analyzing "paper" which is submitted.

2. Representatives would need to understand ISP technologies to be versatile in what information to ask for.


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