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

Tue Apr 6 17:07:00 EDT 2010

With the renewed conversations regarding draft policy 2010-3 I thought
it may be appropriate to remind everyone of the proposal that I wrote
in response to earlier debate surrounding this issue: policy proposal
109.

Unfortunately my proposal will not be up for adoption in Toronto,
however I will be presenting it along side the open policy hour on
Sunday afternoon (come throw tomatoes).

The reason I bring it up now is that I believe it strikes a fair
balance between the need for complete whois data, residential customer
privacy, and protecting corporate customer lists.

Specific to the third point: Under pp109, the legal name, city, state,
zip code equivalent and one POC is required for every SWIP'd block
(/29 or larger IPv4, /56 or larger IPv6). Street name and number are
optional as is POC telephone number (email address is required).

This means that the specific contact information most valuable to
competing sales teams (street address and phone number) is optional,
allowing you to protect your customer list if needed while still
allowing security and abuse personnel to understand who is (whois)
actually using any particular block of IPs.

There are other factors at play in this policy of course (as it is a
complete re-write of both IPv4 and IPv6 registration policy) and the
full text and rational is included below.
~Chris

On Thu, Mar 4, 2010 at 06:54, Member Services <info at arin.net> wrote:
> 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
> _______________________________________________
> 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.
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org