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

[Andrew Dul]

First I don't necessarily see the need to change the existing policy.  I'd
don't see the 200 /48s plan as a real hinderance to a legitimate LIR. 

I generally only support change #1
 
Change #2 would allow almost any organization to qualify as a LIR, 
Change #3 while having a good intent seems oddly worded. I'm not sure if
the intent is for requirements a-c to still apply and for there to be an OR
between d/e?  If that is the intent I would make it clear that a-c are
still required and then you can choose either d/e to qualify.  I also worry
#3 opens the option for non-LIR entities (endsites) to claim to be LIRs to
qualify under these LIR rules.


At 11:52 AM 1/23/2007 -0500, Azinger, Marla wrote:
>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
>_______________________________________________
>PPML mailing list
>PPML at arin.net
>http://lists.arin.net/mailman/listinfo/ppml
>