[UPDATE 27-SEP-2011: Draft Policy ARIN-2010-14 has been implemented in ARIN NRPM 2011.4!]
The History
I first submitted policy proposal 109 in early February. After discussion and feedback on PPML, I revised the draft twice; ending up with v3 in early March. Apparently, that revision was submitted too late to make it onto the draft policy docket for ARIN XXV in Toronto. So I presented it during the open policy hour instead.
During and immediately following the meeting, I was contacted by various individuals who conveyed strong support for the proposed policy and it’s intentions. Based on this support and some great feedback from a few key individuals, I worked with the AC and a handful of members of the ARIN community (particularly Special Agent Bobby Flaim) to produce a 4th version of the proposed policy.
I submitted the final text to the AC Shepherds on June 14th.
The Situation
Last week the ARIN AC met and decided not to select pp109 as a draft policy. This means that without further action, the proposal will not be discussed for adoption at ARIN XXVI in Atlanta this October. I think that this is unacceptable considering that it will delay the adoption of the proposed policy by at least another 6 months (at least until it could be discussed at ARIN XXVII next April).
The ACs decision is based in very sound logic:
Regarding Proposal 109, the AC would really like to see the sentiments in this proposal re-surface in bite-size pieces. SWIP requirements, both IPv4 and IPv6, the distinction of residential customers, the utilization requirements for subsequent allocations, and customer privacy are all good topics, but agreement in some will be held up by any disagreements on the others when trying to address them as one.
I agree that policy changes should be kept as simple and succinct as possible. I have often been a proponent of splitting unnecessarily combined changes into a single proposal. The reason that I don’t agree fully in this instance is that pp109 weaves a tapestry that makes more sense as a whole. No doubt it is a large and relatively sweeping proposal with a number of moving parts. The distinction here is that those parts are interdependent and would not paint as clear a picture if analyzed independent of one another.
Furthermore, as the title declares, pp109 deals mostly with IP Reassignment Registration Requirements – aka WHOIS data. I feel very strongly that time is of the essence in this matter and that it is in the communities best interests to address the problems that this proposal deals with sooner rather than later. IPv4 WHOIS is somewhat of a mess and we are heading into a time where IPv4 addresses may become very valuable; we need clear and definitive rules around reassignment registration before we enter the likely chaotic times ahead. IPv6 is still new so now is the time to lay down the same clear requirements before IPv6 WHOIS succumbs to the same ills we battle with IPv4 registrations.
The Response
To address all of this I have decided to petition the AC’s decision and formally request that policy proposal 109 be moved forward as a draft policy for discussion at the next public policy meeting, ARIN XXVI.
If you would like to support my petition and join me in asking that this proposal be put forward for discussion as a draft policy in Atlanta, please “sign” the petition. You can do this in two ways:
- If you are subscribed to the ARIN PPML; reply to my petition thread stating “I support the petition of proposal 109.” and including your name, organization, and contact info.
- If you are not a PPML participant, or if you don’t want your contact information posted their; send an email to [email protected] stating “I support the petition of proposal 109.” and including your name, organization, and contact info.
[EDIT: You must post support publicly to the ARIN-PPML but you can send your contact info in a separate email to [email protected] if you like.]
Time is short, only 5 days [after the meeting minutes are posted] are granted for the petition to garner support – please act now!
[UPDATE: Thanks to everyone who supported this important policy!]
The Proposal
Since the final version 4 text of pp109 has not been posted by ARIN, I will include it here:
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
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 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 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 /64 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 /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
Along with the updated rational:
Rationale:
#Changes in this version:
After many conversations both at and following the last public policy meeting in Toronto, some revisions have been made. These all address specific concerns raised by multiple interested parties:
1) Organizational Information – Phone number, street address and abuse POC now required.
2) Residential Customer – Added “for personal use only” to the definition.
3) Registration (4.2.3.7 & 6.5.5) – Added “but not limited to” WRT assignment histories.
4) IPv6 – Requires all /64 and larger blocks to be registered.
5) Resource Review – Added this section.#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.
Thanks to everyone who helped with this proposal and thanks in advance to all who support the petition!
Regarding Proposal 109, the AC would really like to see the sentiments in this proposal re-surface in bite-size pieces. SWIP requirements, both IPv4 and IPv6, the distinction of residential customers, the utilization requirements for subsequent allocations, and customer privacy are all good topics, but agreement in some will be held up by any disagreements on the others when trying to address them as one.
