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

[Scott Beuker]

I oppose this proposal. It could have significant consequences for the
IPv4 free pool.

Furthermore, there's too much going on here in one proposal, these
changes should be broken out into multiple proposals based on what it is
they hope to accomplish so that we can address them individually.

The new '4.2.3.7.6.1. Residential Market Area', as I read it, lowers the
requirement for IPv4 address space from 80% utilization to 50%
utilization for all ISPs (if they so choose)... which means we could
suddenly see some of ARINs larger users of IPv4 addresses instantly
qualified to increase their unused space by ~60% overnight, without any
technical merit.

It also makes the NRPM self-contradictory, as I don't see what would
distinguish the applicability of this new utilization requirement versus
'4.2.4.1' to an ISP, other than an arbitrary decision by the ISP
themselves. Similarly for IPv6, '6.5.5.6.1' would seem to me to
contradict '6.5.2' and the HD-ratio concept for IPv6 (which is good
policy I might add).

It's too late in the game for moves like this that grant many large
organizations much more IP space; we can only afford to be more
restrictive. If you have an issue with 4.2.6, address it directly and in
its own policy proposal. And be up front about what it is you aim to
accomplish. Tip: assume it was put there for a reason, and start from
there.

If you force me to vote on a proposal like this that has changes I like,
and changes I do not like, I'm going to vote "no" and then wait for you
to correct the problem.

Thanks,
Scott Beuker


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of Member Services
> Sent: Tuesday, February 09, 2010 1:03 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment
> Registration Requirements - revised
> 
> 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.