Chris,<br><br>It looks to me like this text would still require each and every dynamically assigned residential block to be SWIPped. I know we talked about several possible solutions to this at the meeting: do you think it would be useful to do something like change the first sentence of 6.5.5.1 to read "Each static IPv6 assignment" instead of "Each IPv6 assignment"?<br>
<br>-Scott<br><br><div class="gmail_quote">On Mon, Oct 11, 2010 at 4:08 PM, Chris Grundemann <span dir="ltr"><<a href="mailto:cgrundemann@gmail.com">cgrundemann@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Based on feedback during and after the presentation of 2010-14 at the<br>
public policy meeting last week; I have worked with the AC shepherds<br>
to fix the editorial issues raised.<br>
<br>
I believe that this new revision is conceptually identical to what was<br>
presented in Atlanta, that the changes are strictly editorial, have<br>
not changed the intent of the policy but have addressed all of the<br>
concerns raised at the meeting.<br>
<br>
There were two changes made:<br>
1) The text in section 4.2.3.7.3.1. "Residential Market Area" was<br>
replaced with a direct copy of the current "Cable Address Space<br>
Policy" to avoid any perceived change of intent. The only changes to<br>
this text are it's placement in the NRPM and that it now applies to<br>
all residential access networks, not just cable networks.<br>
2) The "Residential Market Area" section has been stricken from the<br>
IPv6 policy. It is not needed due to the application of the HD ratio<br>
to IPv6 allocations.<br>
<br>
The rest of the rational remains unchanged and is included below the<br>
policy text for completeness.<br>
<br>
--<br>
Draft Policy 2010-14<br>
Standardize IP Reassignment Registration Requirements<br>
<br>
Version/Date: 11 October, 2010<br>
<br>
Policy statement:<br>
<br>
## Definitions ##<br>
<br>
- Add:<br>
<br>
2.3. Organizational Information<br>
<br>
When required, organization Information must include at a minimum:<br>
Legal name, street address, city, state, zip code equivalent and at<br>
least one valid technical and one valid abuse POC. Each POC shall be<br>
designated by the organization and must include at least a verifiable<br>
email address and phone number.<br>
<br>
2.12. Residential Customer<br>
<br>
End-users who are individual persons and not organizations and who<br>
receive service at a place of residence for personal use only are<br>
considered residential customers.<br>
<br>
## IPv4 ##<br>
<br>
- Rename 4.2.3.7. "Reassignment information" to "Registration" and add text:<br>
<br>
ISPs are required to demonstrate efficient use of IP address space<br>
allocations by providing appropriate documentation, including but not<br>
limited to assignment histories, showing their efficient use.<br>
<br>
- Rename 4.2.3.7.1. "Customer organization information" to<br>
"Reassignment Information" and replace text with:<br>
<br>
Each IPv4 assignment containing a /29 or more addresses shall be<br>
registered in the WHOIS directory via SWIP or a distributed service<br>
which meets the standards set forth in section 3.2. Reassignment<br>
registrations shall include each client's organizational information,<br>
except where specifically exempted by this policy.<br>
<br>
- Strike sections 4.2.3.7.2., 4.2.3.7.4. and 4.2.3.7.5.<br>
<br>
- Renumber section 4.2.3.7.3. to 4.2.3.7.2., rename to "Assignments<br>
visible within 7 days" and replace text with:<br>
<br>
All assignments shall be made visible as required in section 4.2.3.7.1<br>
within seven calendar days of assignment.<br>
<br>
- Renumber and replace 4.2.3.7.6. Residential Customer Privacy with:<br>
<br>
4.2.3.7.3. Residential Subscribers<br>
<br>
4.2.3.7.3.1. Residential Market Area<br>
<br>
* In most cases, ISPs that have residential subscribers assign<br>
address space to their access infrastructure to which their customers<br>
connect rather than to individual subscribers. This assignment<br>
information regarding each market area holding an address block should<br>
be entered via SWIP (or by using RWhois) with the network name used to<br>
identify each market area. Initial allocations are based on total<br>
number of homes that could purchase the service in a given market<br>
area.<br>
* Using SWIP or RWhois, residential access ISPs must show that<br>
they have reassigned at least 80% of their current address space, with<br>
a 50 to 80% utilization rate, in order to request additional<br>
addresses.<br>
* Each assignment to a specific end-user (if holding /29 and<br>
larger blocks) requires the submission of a SWIP or use of an RWhois<br>
server. Requesters will also be asked to provide detailed plans for<br>
use of the newly requested space.<br>
<br>
4.2.3.7.3.2. Residential Customer Privacy<br>
<br>
To maintain the privacy of their residential customers, an<br>
organization with downstream residential customers holding /29 and<br>
larger blocks may substitute that organization's name for the<br>
customer's name, e.g. 'Private Customer - XYZ Network', and the<br>
customer's street address may read 'Private Residence'. Each private<br>
downstream residential reassignment must have accurate upstream Abuse<br>
and Technical POCs visible on the WHOIS directory record for that<br>
block.<br>
<br>
- Strike section 4.2.6. "Cable Address Space Policy"<br>
<br>
## IPv6 ##<br>
<br>
- Replace Section 6.5.5. with:<br>
<br>
6.5.5. Registration<br>
<br>
ISPs are required to demonstrate efficient use of IP address space<br>
allocations by providing appropriate documentation, including but not<br>
limited to assignment histories, showing their efficient use.<br>
<br>
6.5.5.1. Reassignment information<br>
<br>
Each IPv6 assignment containing a /64 or more addresses shall be<br>
registered in the WHOIS directory via SWIP or a distributed service<br>
which meets the standards set forth in section 3.2. Reassignment<br>
registrations shall include each client's organizational information,<br>
except where specifically exempted by this policy.<br>
<br>
6.5.5.2. Assignments visible within 7 days<br>
<br>
All assignments shall be made visible as required in section 4.2.3.7.1<br>
within seven calendar days of assignment.<br>
<br>
6.5.5.3. Residential Subscribers<br>
<br>
6.5.5.3.1. Residential Customer Privacy<br>
<br>
To maintain the privacy of their residential customers, an<br>
organization with downstream residential customers holding /64 and<br>
larger blocks may substitute that organization's name for the<br>
customer's name, e.g. 'Private Customer - XYZ Network', and the<br>
customer's street address may read 'Private Residence'. Each private<br>
downstream residential reassignment must have accurate upstream Abuse<br>
and Technical POCs visible on the WHOIS record for that block.<br>
<br>
## Resource Review ##<br>
<br>
- Move section 12.2. paragraph 2. bullet c. to bullet d. and insert<br>
the following:<br>
<br>
c. whenever ARIN has reason to believe that an organization is not<br>
complying with reassignment policies, or<br>
<br>
--<br>
Rationale:<br>
<br>
#Short Rational:<br>
This proposal intends to do several things:<br>
1) Bring IPv4 and IPv6 policy more in line with each other to make the<br>
NRPM easier to understand and comply with - at least as it relates to<br>
reassignment information.<br>
2) Specifically define what organizational information is required to<br>
be added to WHOIS when reassignments are made to client organizations.<br>
3) To specifically state that a client organization may designate the<br>
POC of their choice for any/all WHOIS entries in policy. This includes<br>
designating an upstream POC as their own preferred POC (which allows<br>
for simple reassignments).<br>
4) Expands the privileges previously reserved solely for IPv4 cable<br>
ISPs to all ISPs/LIRs with residential/dhcp-type subscribers.<br>
5) Specifically define the term "residential customer."<br>
6) Allow ARIN to conduct resource reviews based on failure to comply<br>
with registration / reassignment policies.<br>
<br>
#Expanded Rational:<br>
1) This policy restructures the reassignment and registration sections<br>
of the IPv4 and IPv6 policies.<br>
a) The IPv4 section is renamed "registration."<br>
b) The IPv4 policy is shortened and rewritten for clarity.<br>
c) The IPv6 policy is totally rewritten in a format that matches the<br>
IPv4 policy.<br>
* These structural changes are meant to make it easier to compare the<br>
two sections. I believe that having the IPv6 and IPv4 policies written<br>
in completely different formats and structures (as they are in many<br>
cases now) confuses the issues and makes it very hard to understand<br>
what is different and what is the same across the two sections.<br>
Bringing them into a similar format should help ease the migration to<br>
IPv6 as folks can quickly and easily understand the differences and<br>
the similarities.<br>
d) The IPv6 policy is altered from a /56 minimum needing to be<br>
registered to a /64. A /64 is a single IPv6 subnet where as a /56<br>
contains many subnets (that should all be recorded in the WHOIS<br>
directory if handed out to other organizations).<br>
<br>
2) This policy adds a definition of "organizational information" which<br>
is used in the existing policy but not currently defined anywhere in<br>
the NRPM.<br>
a) The definition states that legal name and physical address are<br>
required for client organizations.<br>
b) The definition states that POCs are required but can be designated<br>
by the client organization - it spells out that the client org can<br>
choose to use their upstream as a POC.<br>
c) The definition requires that each POC have a valid email address<br>
and phone number.<br>
<br>
3) This policy takes the privileges granted specifically to IPv4 cable<br>
operators in section 4.2.6. "Cable Address Space Policy" and grants<br>
them to all ISPs who serve residential areas.<br>
a) It allows all ISPs with residential coverage to<br>
register/swip/rwhois an entire market area.<br>
b) It retains the existing residential customer privacy policy for all<br>
customers with larger IP blocks.<br>
* This change removes the need for any ISP to enter residential<br>
customers into whois at all.<br>
<br>
4) This policy also extends the >50% utilization rate, currently<br>
granted only to IPv4 cable operators, to all ISPs with a residential<br>
footprint.<br>
* This change offsets the ability to register/swip/rwhois market<br>
areas. For all other allocation types, efficient utilization is based<br>
on SWIPs, not on actual utilization. When an organization is able to<br>
SWIP an entire market area, this must be checked against actual<br>
utilization. This policy maintains the current line set at >50%.<br>
**The 50% mark on the most recent allocation is because you can<br>
quickly distribute most of your address space across your provisioning<br>
footprint, leaving nothing left for growth while the lease count of<br>
the provisioned customers catches up to the blocks allocated. (Dan<br>
Alexander's words)<br>
<br>
5) Current policy references "residential customers" but there is no<br>
current definition of residential customers in the NRPM. This has<br>
reportedly been an on-going problem for ARIN and it’s customers.<br>
<br>
6) Not properly registering reassignment information could be a sign<br>
of other improper or illicit behavior and should justify a resource<br>
review (audit) by ARIN when necessary, regardless of when the last<br>
review took place.<br>
<br>
--<br>
<br>
<br>
Cheers,<br>
~Chris<br>
<br>
<br>
<br>
--<br>
@ChrisGrundemann<br>
<a href="http://weblog.chrisgrundemann.com" target="_blank">weblog.chrisgrundemann.com</a><br>
<a href="http://www.burningwiththebush.com" target="_blank">www.burningwiththebush.com</a><br>
<a href="http://www.coisoc.org" target="_blank">www.coisoc.org</a><br>
_______________________________________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
</blockquote></div><br>