[arin-ppml] Clarify /29 assignment identification requirement

[Jimmy Hess]

On 4/26/12, Cameron Byrne <cb.list6 at gmail.com> wrote:
> In many cases, this data is so transient it has no audit value.
> Smartphones, for example, seldom have ip assignments that last longer than
> 12 hours and are so unsticky they are likely to never have the same ip
[snip]

If you are an LIR, you don't assign an IP "for 12 hours" to a smart phone.
You assign a range of IPs to the customer's  DHCP-served LAN,  or you
assign a range of IPs to your own organization for providing
DHCP-based access.  Your documentation requirement is the range of IPs
assigned to that customer for their LAN.      If you are the end user,
your documentation requirement is the DHCP LAN range identification in
your rfc2050 Network Engineering Plan,  and the number of devices
(or number of customers served by that range).

You need to document /32s,  when the /32 is actually what's been re-assigned.
Not when the /32 is a member of a dynamically assigned pool on your LAN,
or when you have assigned a pool of IPs to a customer;  you document the pool.

> Furthermore, folks who interface with arin && gear may only know a custimer
> via a customer id or phone number.  The asociated personally identifiable
> information (pii ) of such a subscriber may be in a protected data
> warehouse that network folks dont have access too.

The application for additional resources from ARIN is to be done by a person
whom has the ability to gather the information required for the application.

Some organizations  may have implemented special security controls around PII
that prevent network staff from routinely accessing it,  but that is
an internal issue --
if obtaining additional IP address space is a business requirement,
the security
controls will surely be adapted to meet the organization's business requirement.

The network staff most certainly have some way of accessing the
contact details of their customer's network manager, however,
otherwise they would not be able to contact the  customer about
network-related issues such as abuse.

Its really not a good reason for reducing the documentation requirements
for obtaining IPv4 sources near runout

--
-JH