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

[Scott Leibrand]

Chris,

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"?

-Scott

On Mon, Oct 11, 2010 at 4:08 PM, Chris Grundemann <cgrundemann at gmail.com>wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101011/f36095e3/attachment.htm>