[ppml] FW: 2006-7 IPV6 Initial Allocation suggested changes- InputRequested

[Azinger, Marla]

Hello-  The deadline for proposal submissions is getting close (Feb 22nd).  

In order to help Jordi decide just how he will modify his previously proposed policy 2006-7 IPV6 Initial Allocation, I am asking for one more round of feedback.  Below is the same email that went out back in November.  Within it are the modifications currently being considered.  A few people responded back in November, and Thank you to those who did.  Now we are looking for more input from anyone who hasnt yet voiced their opinion.

Thank you for your time
Marla Azinger

-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
Azinger, Marla
Sent: Monday, November 13, 2006 11:00 AM
To: ppml at arin.net
Subject: [ppml] 2006-7 IPV6 Initial Allocation suggested changes-
InputRequested


Hello-  In an effort to work with the community on changes to Policy Proposal 2006-7 Changes to IPV6 Initial Allocation Criteria, three different suggested revisions are in this email.  We would like the communities input on three separate suggested revisions.  What do you like about them, or what do you not like about them? Do you prefer one suggestion over the other?  I have given each suggestion a different color to make it easier to tell when one suggestion ands and another begins.  When reviewing the three suggested changes please note the following assumptions:

- New organizations who do not want to use IPv4 at all and start off using IPv6 addresses only, need a policy that gives them permission to do so. This is also valid for existing companies that may or may not have assigned IPv4 addresses and now want to start offering IPv6 services. These organizations may also wish to request IPv4 at the same time.
- One year is given as the sufficient time frame to actually implement usage of the IPv6 address space and reveal if the 'said organization' is truly using the IPv6 space granted.
-Every means of documentation that can reveal 'true intent of use' is not listed as this can be a very long list and should be left to the discretion of the RIR staff.
- Organization in this is defined as a Corporation, ISP, LLC et al.


Suggested Change #1 (deletes and replaces current text of item d and requires ASN)
Replace line item d. to 6.5.1.1 with the following:  
'To qualify for an initial allocation of IPV6 address space, an organization must':
d. be an existing, known ISP in the ARIN region OR be an organization which
can justify intent to announce the requested IPv6 address space within one
year and have/obtain and AS Number.

Rationale for ASN:
Someone providing this kind of service needs to run BGP.


Suggested Change #2 (deletes and replaces current text of item d but does not require ASN)
Replace line item d. to 6.5.1.1 with the following:
'To qualify for an initial allocation of IPv6 address space, an organization
must':
d. be an existing, known ISP in the ARIN region OR be an organization which
can justify intent to announce the requested IPv6 address space within one
year.

Rationale for no asn:
We should not require an ASN if they really don't need one? As long as they are statically routed to an upstream and don't want to run bgp/announce directly to the Internet, they don't need an ASN, therefore we shouldn't create policy that would contribute to ASN bloat. 


Suggested Change #3 (leaves item d in place with the 200 /48 text and adds a new item e but does not require ASN)
Insert line item e. to 6.5.1.1 with the following:
'To qualify for an initial allocation of IPV6 address space, an organization must':
e.  OR be an organization new to providing internet services, and can justify intent to announce the requested IPV6 address space within one year, through records such as contracts, inventory and/or other applicable documentation.  

Rationale for no asn:
We should not require an ASN if they really don't need one? As long as they are statically routed to an upstream and don't want to run bgp/announce directly to the Internet, they don't need an ASN, therefore we shouldn't create policy that would contribute to ASN bloat.  

Thank you for your time
Marla (ARIN AC) and Jordi (Proposal Author)

_______________________________________________
PPML mailing list
PPML at arin.net
http://lists.arin.net/mailman/listinfo/ppml