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

Fri Jan 26 07:50:04 EST 2007

Hi Andrew,

See below, in-line.

Regards,
Jordi

> De: Andrew Dul <andrew.dul at quark.net>
> Responder a: <ppml-bounces at arin.net>
> Fecha: Thu, 25 Jan 2007 14:56:53 -0800
> Para: <ppml at arin.net>
> Asunto: Re: [ppml] FW: 2006-7 IPV6 Initial Allocation suggested
> changes-InputRequested
> 
> 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.

So do you think is not possible an ISP to have a few customer and make
profitable business ?

Do you think is reasonable to stop people that are willing or already doing
business this way ?

In fact, when I introduced my idea about this possible policy proposal at
the last meeting, I recall at least a couple of people in the room being in
this situation, so is something real.

> 
> I generally only support change #1

The only trouble I see with this is that may be to obtain an ASN is mandated
that the ISP is multihomed ? Is this the case in ARIN ?

My view is that there may be small ISPs that aren't multihomed, but still
need PA space in order to avoid depending on its upstream addressing space
(avoid renumbering all customer networks, etc.).

>  
> Change #2 would allow almost any organization to qualify as a LIR,

Only if they plan to provide service to others, and I read that as perfectly
valid for an ISP, not "any organization".

> 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.

The idea is to keep existing policy and add as OR in between d/e. Same
comment regarding is intended for ISPs (providing service to other
organizations).

> 
> 
> 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
>> 
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.