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

Owen DeLong owen at delong.com
Wed Feb 10 16:40:23 EST 2010


I oppose the wording in section 6.5.5.1. The database should be accessible
to more than just the RIRs, it should be accessible to the general internet.

Section 4.2.3.7.1 could use some wordsmithing and there is no reason not
to align the requirements for IPv4 and IPv6.

Suggested replacement:


4.2.3.7.1	Reassignment Information

Each IPv4 assignment containing a /29 or more addresses shall be maintained
in a directory via SWIP or a distributed service which meets the standards set
forth in section 3.2

6.5.5.1	Reassignment information

Each IPv6 assignment containing a /56 or more addresses shall be maintained
in a directory via SWIP or a distributed service which meets the standards set
forth in section 3.2

This would also allow you to delete section 6.5.5.4.

Additionally, I would suggest that we replace sections 4.2.3.7.3 and proposed
section 6.5.5.3 with the following:

4.2.3.7.3	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.4	Assignments visible within 7 days

All assignments shall be made visible as required in section 6.5.5.1 within
seven calendar days of assignment.

I believe that wording is simpler, provides greater clarity, and, more closely
matches the intent and desires of the community than the existing and proposed
language.

Owen

On Feb 9, 2010, at 12:03 PM, Member Services 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 109: Standardize IP Reassignment Registration
> Requirements
> 
> Proposal Version: 2.0
> 
> Date: 9 FEB 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.
> 
> ## 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 holding /29 and
> larger blocks still requires registration. In order to obtain additional
> IPv4 addresses, ISPs assigning addresses by market area must show, using
> reassignment information published in whois, that they have reassigned
> at least 80% of their current address space, with a >50% utilization rate.
> 
> 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
> properly registered.
> 
> 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 holding /56 and
> larger blocks still requires registration. In order to obtain additional
> IPv6 addresses, ISPs assigning addresses by market area must show, using
> reassignment information published in whois, that they have reassigned
> at least 80% of their current address space, with a >50% utilization rate.
> 
> 
> 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:
> 
> #Short Version:
> 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 IPv4 cable
> ISPs to all ISPs/LIRs with residential subscribers.
> 
> #Expanded version:
> 1) This policy restructures the reassignment and registration sections
> of the IPv4 and IPv6 policies.
>       a) The IPv4 section is renamed "registration."
>       b) The first section of the IPv4 policy is 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.
> 
> #Specific changes in this version:
> 1) Sections 4.2.3.7.6.1. and 6.5.5.6.1. have an added sentance: "In
> order to obtain additional IPvX addresses, ISPs assigning addresses by
> market area must show, using reassignment information published in
> whois, that they have reassigned at least 80% of their current address
> space, with a >50% utilization rate." Currently this >50% utilization
> rate is reserved solely for IPv4 cable operators, this addition
> spreads it to all residential ISPs, both IPv4 and IPv6 alike.
> 
> 2) The last line of section 6.5.5.2. was changed from "...is
> registered in an RIR database." to "...is properly registered." To
> reflect the fact that RWHOIS and other potential methods of publishing
> WHOIS information are not in fact RIR databases.
> 
> #Note: Specific mention of SWIP and RWHOIS has been left in the IPv4
> policy to avoid complicating this proposal further by rewriting the
> entire IPv4 section without any substantive change. The IPv6 policy
> has been written to be agnostic concerning the method of publishing
> WHOIS information.
> 
> 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.




More information about the ARIN-PPML mailing list