[arin-ppml] Policy Proposal 109: Standardize IP Reassignment Registration Requirements - Revised

Member Services info at arin.net
Thu Mar 4 07:54:44 EST 2010


The proposal originator submitted a revised version of the proposal.

The AC will review this proposal at their next regularly scheduled
meeting and decide how to utilize the proposal. Their decision will be
announced to the PPML.

Regards,

Member Services
American Registry for Internet Numbers (ARIN)

## * ##

Policy Proposal Name: Standardize IP Reassignment Registration Requirements

Proposal Originator: Chris Grundemann

Proposal Version: 3.0

Date: 03-MAR-2010

Proposal type: New

Policy term: Permanent

Policy statement:

## Definitions ##

- Add:

2.3. Organizational Information

When required, organization Information must include at a minimum: Legal 
name, city, state, zip code equivalent and at least one valid technical 
or abuse POC; inclusion of street address is highly encouraged. The POC 
shall be designated by the organization and must include at least one 
verifiable email address, inclusion of a phone number is highly encouraged.

2.12. Residential Customer

End-users who are individual persons and not organizations and who 
recieve service at a place of residence are considered residential 
customers.

## IPv4 ##

- Rename 4.2.3.7. "Reassignment information" to "Registration" and add 
text:

ISPs are required to demonstrate efficient use of IP address space 
allocations by providing appropriate documentation, including assignment 
histories, showing their efficient use.

- Rename 4.2.3.7.1. "Customer organization information" to "Reassignment 
Information" and replace text with:

Each IPv4 assignment containing a /29 or more addresses shall be 
registered in the WHOIS directory via SWIP or a distributed service 
which meets the standards set forth in section 3.2. Reassignment 
registrations shall include each client's organizational information, 
except where specifically exempted by this policy.

- Strike sections 4.2.3.7.2., 4.2.3.7.4. and 4.2.3.7.5.

- Renumber section 4.2.3.7.3. to 4.2.3.7.2., rename to "Assignments 
visible within 7 days" and replace text with:

All assignments shall be made visible as required in section 4.2.3.7.1 
within seven calendar days of assignment.

- Renumber and replace 4.2.3.7.6. Residential Customer Privacy with:

4.2.3.7.3. Residential Subscribers

4.2.3.7.3.1. Residential Market Area

ISPs that assign address space to the infrastructure to which their 
customers connect rather than to individual subscribers must register 
assignment information regarding each market area holding such an 
address block. Market area reassignments shall be registered with the 
network name used to identify each market area. Any assignment to 
specific end-users holding /29 and larger blocks still requires 
registration. A >50% utilization rate shall be considered efficient for 
market area reassignments from the ISPs most recent allocation.

4.2.3.7.3.2. Residential Customer Privacy

To maintain the privacy of their residential customers, an organization 
with downstream residential customers holding /29 and larger blocks may

substitute that organization's name for the customer's name, e.g. 
'Private Customer - XYZ Network', and the customer's street address may 
read 'Private Residence'. Each private downstream residential 
reassignment must have accurate upstream Abuse and Technical POCs 
visible on the WHOIS directory record for that block.

- Strike section 4.2.6. "Cable Address Space Policy"

## IPv6 ##

- Replace Section 6.5.5. with:

6.5.5. Registration

ISPs are required to demonstrate efficient use of IP address space 
allocations by providing appropriate documentation, including assignment 
histories, showing their efficient use.

6.5.5.1. Reassignment information

Each IPv6 assignment containing a /56 or more addresses shall be 
registered in the WHOIS directory via SWIP or a distributed service 
which meets the standards set forth in section 3.2. Reassignment 
registrations shall include each client's organizational information, 
except where specifically exempted by this policy.

6.5.5.2. Assignments visible within 7 days

All assignments shall be made visible as required in section 4.2.3.7.1 
within seven calendar days of assignment.

6.5.5.3. Residential Subscribers

6.5.5.3.1. Residential Market Area

ISPs that assign address space to the infrastructure to which their 
customers connect rather than to individual subscribers must register 
assignment information regarding each market area holding such an 
address block. Market area reassignments shall be registered with the 
network name used to identify each market area. Any assignment to 
specific end-users holding /56 and larger blocks still requires 
registration. A >50% utilization rate shall be considered efficient for 
market area reassignments from the ISPs most recent allocation.


6.5.5.3.2. Residential Customer Privacy

To maintain the privacy of their residential customers, an organization 
with downstream residential customers holding /56 and larger blocks may 
substitute that organization's name for the customer's name, e.g. 
'Private Customer - XYZ Network', and the customer's street address may 
read 'Private Residence'. Each private downstream residential 
reassignment must have accurate upstream Abuse and Technical POCs 
visible on the WHOIS record for that block.


Rationale:

#New and Improved! Specific changes in this version (based on Staff and 
PPML comments):
1) Added section 2.12. to define residential customers. There is no 
current definition of residential customers and this has reportedly been 
an on-going problem for ARIN and it’s customers.
2) 4.2.3.7. and 6.5.5. were re-written to include current text in order 
to aid ARIN staff when requesting detailed utilization information as 
part of the normal request process.
3) 4.2.3.7.1. and 6.5.5.1. were re-written to simplify policy by 
combining the /29 and /56 rules as well as the WHOIS directory 
visibility requirements directly in a single statement (thanks to Owen 
DeLong for the suggestion).
3) Several sections were struck do to the clarity and detail gained in 
revision 3, above.
4) The "7-day" provision was renamed and rewritten for clarity (thanks 
again to Owen DeLong for the wording).
5) 4.2.3.7.3.1 & 6.5.5.3.1 were re-written for clarity based on many 
comments on and off list.

#Short Rational:
This proposal intends to do several things:
1) Bring IPv4 and IPv6 policy more in line with each other to make the 
NRPM easier to understand and comply with - at least as it relates to 
reassignment information.
2) Specifically define what organizational information is required to be 
added to WHOIS when reassignments are made to client organizations.
3) To specifically state that a client organization may designate the 
POC of their choice for any/all WHOIS entries in policy. This includes 
designating an upstream POC as their own prefered POC (which allows for 
simple reassignments).
4) Expands the priviledges previously reserved solely for IPv4 cable 
ISPs to all ISPs/LIRs with residential/dhcp-type subscribers.
5) Specifically define the term "residential customer."

#Expanded Rational:
1) This policy restructures the reassignment and registration sections
of the IPv4 and IPv6 policies.
a) The IPv4 section is renamed "registration."
b) The IPv4 policy is shortened and rewritten for clarity.
c) The IPv6 policy is totally rewritten in a format that matches the 
IPv4 policy.
* These structural changes are meant to make it easier to compare the 
two sections. I believe that having the IPv6 and IPv4 policies written 
in completely different formats and structures (as they are in many 
cases now) confuses the issues and makes it very hard to understand what 
is different and what is the same across the two sections. Bringing them 
into a similar format should help ease the migration to IPv6 as folks 
can quickly and easily understand the differences and the similarities.

2) This policy adds a definition of "organizational information" which 
is used in the existing policy but not currently defined anywhere in the 
NRPM.
a) The definition states that specific addresses are not required for 
client organizations but asks that they be included when possible.
b) The definition states that a POC is required but can be designated by 
the client organization - it spells out that the client org can choose 
to use their upstream as a POC.
c) The definition requires that the POC have a valid email address but 
only suggests that it include a phone number.
* This definition is meant to address the customer confidentiality 
concerns that have been brought up recently (by specifically removing 
the requirement to publish client addresses and telephone numbers), with 
the smallest negative impact to whois usefulness (retains a valid POC w/ 
email contact).

3) This policy takes the privileges granted specifically to IPv4 cable 
operators in section 4.2.6. "Cable Address Space Policy" and grants them 
to all ISPs who serve residential areas.
a) It allows all ISPs with residential coverage to register/swip/rwhois 
an entire market area.
b) It retains the existing residential customer privacy policy for all 
customers with larger IP blocks.
* This change removes the need for any ISP to enter residential 
customers into whois at all.

4) This policy also extends the >50% utilization rate, currently granted 
only to IPv4 cable operators, to all ISPs with a residential footprint.
* This change will make it easier for ISPs serving residential areas to 
get the addresses they need - this is key for FTTH operators as well as 
fixed-wireless and other residential ISPs.
*The 50% mark on the most recent allocation is because you can quickly 
distribute most of your address space across your provisioning 
footprint, leaving nothing left for growth while the lease count of the 
provisioned customers catches up to the blocks allocated. (Dan 
Alexander's words)

5) Current policy references "residential customers" but there is no 
current definition of residential customers in the NRPM. This has 
reportedly been an on-going problem for ARIN and it’s customers.


Timetable for implementation: Immediate



More information about the ARIN-PPML mailing list