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

[Scott Leibrand]

After getting a chance to read through the sections of the NRPM that 
would be removed by this policy, I have some additional feedback inline 
below...

On 2/4/2010 8:41 AM, Scott Leibrand wrote:
> 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:
>
>>
>> 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"

Most of 4.2.6 has been moved to the new 4.2.3.7.6 above.  However, this 
portion has not:

"Using SWIP or RWHOIS, cable 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."

I think we need to preserve that, somehow, in order to allow cable ISPs 
to continue obtaining space as they do today.  The intent of your 
proposal seems to be to provide the same standard to any org providing 
service to an entire market area.  If that's what you want to do, then 
perhaps something like this should go into your 4.2.3.7.6 as well:

"In order to obtain additional IPv4 addresses, ISPs assigning addresses 
by market area must show, using SWIP or RWHOIS, that they have 
reassigned at least 80% of their current address space, with a >50% 
utilization rate."

-Scott

>>
>> ## 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.