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

[Scott Leibrand]

I like it.

For IPv6, should the cutoff be "more
than a /56" or "/56 and larger blocks"? IMO more than /56 is better,  
but it needs to be made consistent.

Thanks,
Scott

On Feb 4, 2010, at 8:33 AM, Member Services <info at arin.net> wrote:

> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with Policy  
> Development
> Process.
>
> This proposal is in the first stage of the Policy Development Process.
> ARIN staff will perform the Clarity and Understanding step. Staff does
> not evaluate the proposal at this time, their goal is to make sure  
> that
> they understand the proposal and believe the community will as well.
> Staff will report their results to the ARIN Advisory Council (AC)  
> within
> 10 days.
>
> The AC will review the proposal at their next regularly scheduled
> meeting (if the period before the next regularly scheduled meeting is
> less than 10 days, then the period may be extended to the subsequent
> regularly scheduled meeting). The AC will decide how to utilize the
> proposal and announce the decision to the PPML.
>
> In the meantime, the AC invites everyone to comment on the proposal on
> the PPML, particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their  
> deliberations.
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Mailing list subscription information can be found
> at: https://www.arin.net/mailing_lists/
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Policy Proposal 109: Standardize IP Reassignment Registration  
> Requirements
>
> Proposal Originator: Chris Grundemann
>
> Proposal Version: 1.0
>
> Date: 4 FEB 2010
>
> Proposal type: Modify
>
> 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.
>
> ## IPv4 ##
>
> - Rename 4.2.3.7. "Reassignment information" to "Registration"
>
> - Rename 4.2.3.7.1. "Customer organization information" to
> "Reassignment Information" and replace text with:
>
> When an organization holding an IPv4 address allocation makes IPv4
> address assignments, it must register reassignment information via
> SWIP or RWHOIS server. SWIP and RWHOIS reassignments shall include
> each client's organizational information, except where specifically
> exempted by this policy.
>
> - Replace 4.2.3.7.6. Residential Customer Privacy with:
>
> 4.2.3.7.6. Residential Subscribers
>
> 4.2.3.7.6.1. Residential Market Area
>
> In most cases, ISPs that have residential subscribers assign address
> space to the infrastructure to which their customers connect rather
> than to individual subscribers. This assignment information regarding
> each market area holding an address block should be registered 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. Each assignment to specific end-users
> of /29 and larger blocks still requires individual registration.
>
> 4.2.3.7.6.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 record for that block.
>
> - Strike section 4.2.6. "Cable Address Space Policy"
>
> ## IPv6 ##
>
> - Replace Section 6.5.5. with:
>
> 6.5.5. Registration
>
> 6.5.5.1. Reassignment information
>
> When an organization holding an IPv6 address allocation makes IPv6
> address assignments, it must register reassignment information in a
> database, accessible by RIRs as appropriate (information registered by
> an RIR may be replaced by a distributed database for registering
> address management information in future). These reassignment
> registrations shall include each client's organizational information,
> except where specifically exempted by this policy.
>
> 6.5.5.2. /56 registered unit
>
> Information is registered in units of assigned /56 networks. When more
> than a /56 is assigned to a client organization, the assigning
> organization is responsible for ensuring that the address space is
> registered in an RIR database.
>
> 6.5.5.3. Submit within 7 days
>
> Any time an LIR receives a new block of address space, reassignment
> information should be submitted within 7 days of issuance of the new
> space.
>
> 6.5.5.4. Visible via WHOIS
>
> This information must be visible via WHOIS prior to submitting a
> request for a new allocation. For further information on reassigning
> IP address space, please see RFC 2050.
>
> 6.5.5.6. Residential Subscribers
>
> 6.5.5.6.1. Residential Market Area
>
> In most cases, ISPs that have residential subscribers assign address
> space to the infrastructure to which their customers connect rather
> than to individual subscribers. This assignment information regarding
> each market area holding an address block should be registered 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. Each assignment to specific end-users
> of /56 and larger blocks still requires individual registration.
>
> 6.5.5.6.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:
>
> 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. This includes
> designating an upstream POC as their own prefered POC.
> 4) Expands the priviledges previously reserved solely for cable ISPs
> to all ISPs/LIRs with residential subscribers. Namely the ability to
> SWIP/RWHOIS an entire residential market area as one reassignment. It
> also expands this priviledge to IPv6 reasignments, instead of just
> IPv4 as it is now.
>
> 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.