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

[Chris Grundemann]

On Fri, Feb 5, 2010 at 06:12,  <michael.dillon at bt.com> wrote:
>
>> Policy Proposal 109: Standardize IP Reassignment Registration
>> Requirements
>
> Huh!?
>
>>   - Add:
>>   - 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:
>>   - Replace 4.2.3.7.6. Residential Customer Privacy with:
>>   - Strike section 4.2.6. "Cable Address Space Policy"
>>   - Replace Section 6.5.5. with:
>
> I'm still not sure what this policy proposal is trying to do
> or what is being changed. Clearly, the only way to figure
> this out is to compare the existing copious verbiage in the NRPM
> with the copious verbiage in this policy and I haven't time
> to do this right now.

Yes, reading the NRPM may be a prerequisite to understanding proposed
changes to it.

> I am opposed to this proposal on the grounds of its complexity
> and the lack of clarity around what, if any, kind of problem
> it attempts to solve.

I will expound a bit on the rational for clarification:

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) In the text that Scott pointed out (and that will be added), this
policy will also extend 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.

Cheers,
~Chris

>
> --Michael Dillon
> _______________________________________________
> 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