[arin-ppml] Post-Meeting Revision of 2010-14

[Jay Deckness]

Is there any support in registering a residential market as a single large registration similar to the process under discussion in RIPE:

	RIPE region is discussing IPv6 registration to
	customer areas, for example, registering a
	DSL customer area [Example, "v6xxxx::/36
	DSL pool in North London(assignment size
	/56)"]

It is my understanding that under existing policy, if an ISP assigns a /56 to each of its residential customers, it will be required to enter a generic ('Private Customer - XYZ Network') SWIP for each one. 

Justin Deckness


-----Original Message-----
From: Chris Grundemann [mailto:cgrundemann at gmail.com] 
Sent: Monday, October 11, 2010 3:09 PM
To: arin-ppml at arin.net
Cc: Azinger, Marla
Subject: [arin-ppml] Post-Meeting Revision of 2010-14

Based on feedback during and after the presentation of 2010-14 at the public policy meeting last week; I have worked with the AC shepherds to fix the editorial issues raised.

I believe that this new revision is conceptually identical to what was presented in Atlanta, that the changes are strictly editorial, have not changed the intent of the policy but have addressed all of the concerns raised at the meeting.

There were two changes made:
1) The text in section 4.2.3.7.3.1. "Residential Market Area" was replaced with a direct copy of the current "Cable Address Space Policy" to avoid any perceived change of intent. The only changes to this text are it's placement in the NRPM and that it now applies to all residential access networks, not just cable networks.
2) The "Residential Market Area" section has been stricken from the
IPv6 policy. It is not needed due to the application of the HD ratio to IPv6 allocations.

The rest of the rational remains unchanged and is included below the policy text for completeness.

--
Draft Policy 2010-14
Standardize IP Reassignment Registration Requirements

Version/Date: 11 October, 2010

Policy statement:

## Definitions ##

- Add:

2.3. Organizational Information

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

2.12. Residential Customer

End-users who are individual persons and not organizations and who receive service at a place of residence for personal use only 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 but not limited to 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

    * In most cases, ISPs that have residential subscribers assign address space to their access infrastructure to which their customers connect rather than to individual subscribers. This assignment information regarding each market area holding an address block should be entered via SWIP (or by using RWhois) with the network name used to identify each market area. Initial allocations are based on total number of homes that could purchase the service in a given market area.
    * Using SWIP or RWhois, residential access ISPs must show that they have reassigned at least 80% of their current address space, with a 50 to 80% utilization rate, in order to request additional addresses.
    * Each assignment to a specific end-user (if holding /29 and larger blocks) requires the submission of a SWIP or use of an RWhois server. Requesters will also be asked to provide detailed plans for use of the newly requested space.

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 but not limited to assignment histories, showing their efficient use.

6.5.5.1. Reassignment information

Each IPv6 assignment containing a /64 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 Customer Privacy

To maintain the privacy of their residential customers, an organization with downstream residential customers holding /64 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.

## Resource Review ##

- Move section 12.2. paragraph 2. bullet c. to bullet d. and insert the following:

c. whenever ARIN has reason to believe that an organization is not complying with reassignment policies, or

--
Rationale:

#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 preferred POC (which allows for simple reassignments).
4) Expands the privileges previously reserved solely for IPv4 cable ISPs to all ISPs/LIRs with residential/dhcp-type subscribers.
5) Specifically define the term "residential customer."
6) Allow ARIN to conduct resource reviews based on failure to comply with registration / reassignment policies.

#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.
d) The IPv6 policy is altered from a /56 minimum needing to be registered to a /64. A /64 is a single IPv6 subnet where as a /56 contains many subnets (that should all be recorded in the WHOIS directory if handed out to other organizations).

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 legal name and physical address are required for client organizations.
b) The definition states that POCs are 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 each POC have a valid email address and phone number.

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 offsets the ability to register/swip/rwhois market areas. For all other allocation types, efficient utilization is based on SWIPs, not on actual utilization. When an organization is able to SWIP an entire market area, this must be checked against actual utilization. This policy maintains the current line set at >50%.
**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.

6) Not properly registering reassignment information could be a sign of other improper or illicit behavior and should justify a resource review (audit) by ARIN when necessary, regardless of when the last review took place.

--


Cheers,
~Chris



--
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org
_______________________________________________
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.