[ppml] Proposed Policy: Changes to IPv6 initialallocationcriteria
JORDI PALET MARTINEZ
jordi.palet at consulintel.es
Thu Oct 12 14:14:00 EDT 2006
Not sure if I'm getting your point here.
In my opinion those industry groups may be considered ISPs and then will
fall into the existing allocation criteria (with or w/o the proposed
modifications). Otherwise, they will fall into the IPv6 PI category ?
> De: "Davis, Terry L" <terry.l.davis at boeing.com>
> Responder a: <terry.l.davis at boeing.com>
> Fecha: Thu, 12 Oct 2006 10:55:27 -0700
> Para: <jordi.palet at consulintel.es>, <ppml at arin.net>
> Conversación: [ppml] Proposed Policy: Changes to IPv6
> Asunto: RE: [ppml] Proposed Policy: Changes to IPv6 initialallocationcriteria
> As you consider your address allocation planning, consider that there
> will be industry groups asking for allocations that will region-wide or
> global for inter-industry communications that are not ISP's.
> Take care
>> -----Original Message-----
>> From: JORDI PALET MARTINEZ [mailto:jordi.palet at consulintel.es]
>> Sent: Thursday, October 12, 2006 10:10 AM
>> To: ppml at arin.net
>> Subject: Re: [ppml] Proposed Policy: Changes to IPv6
>> Hi Stephen,
>> My comments below, in-line.
>>> De: Stephen Sprunk <stephen at sprunk.org>
>>> Responder a: <ppml-bounces at arin.net>
>>> Fecha: Thu, 12 Oct 2006 11:29:54 -0500
>>> Para: Andrew Dul <andrew.dul at quark.net>, ARIN PPML <ppml at arin.net>
>>> Asunto: Re: [ppml] Proposed Policy: Changes to IPv6 initial
>>> Thus spake "Andrew Dul" <andrew.dul at quark.net>
>>>>> Policy statement:
>>>>> Delete section 184.108.40.206 d. of NRPM
>>>>> d: be an existing, known ISP in the ARIN region or have a plan
>>>>> making at least 200 /48 assignments to other organizations within
>>>> My main understanding of why this policy might be needed is that
>>>> some feel that the 200 /48 assignments is an arbitrary requirement.
>>>> Some feel that this type of requirement would encourage a smaller
>>>> LIR to provide false information to ARIN in order to obtain PA
>>>> If the problem is with the 200 /48 requirements, I would suggest
>>>> striking the words "at least 200" from the policy rather than
>>>> the entire requirement.
>>> The requirement, as I understand it, is to prevent allocations to
>>> in the pan" startups who have no track record or orgs who are not
>>> LIRs from getting a routing table slot; the latter was a major
>>> before the PI policy was adopted (e.g. WTF did Cisco, IBM, et al
>>> as LIRs and get /32s?).
>> This requirement comes from an historical perspective of the original
>> developed jointly by APNIC, ARIN and RIPE NCC.
>> Any allocation may "flash in the pan", but this is another issue, and
>> why we have recovery processes.
>>> A lot of this hinges on the ARIN staff's interpretation of "have a
>>> plan". I would hope that any startup ISP with a reasonable business
>>> model would be accepted as "having a plan", and virtually no ISP is
>>> going to be economically viable without at least 200 customers.
>>> may be some specialized orgs that cater to specific niches which
>>> be under 200 users, but those would likely qualify under the "known
>>> category, or their customers may be large enough to get PI space now
>> A problem frequently raised by several RIRs with different policy
>> is that how a RIR staff "interprets" wordings as "have a plan". A plan
>> be good enough for them, but not for the community. It seems to me
>> there is a subtle line here ...
>> I disagree in your vision that having less than 200 customers is not
>> economically viable. There are many ISPs all around the world that
>> a dozen of "big" customers, enough the be on business. And if that ISP
>> new business, will not qualify as per the "known ISP" category.
>>> The other thing is that a small ISP is most likely to start up as a
>>> customer of another ISP; asking them to accumulate N customers
>>> getting their own routing table slot seems reasonable, though
>>> room for debate on what N should be.
>> I think a small or new ISP doesn't necessarily going to have just one
>> upstream provider.
>> Even if has a single upstream, what about the cost of renumbering the
>> and its customers if he decides to change the upstream or just add a
>> upstream in a second stage ?
>> How do you define that N is reasonable for 200 or any other number ?
>> always absolutely subjective, and I don't think we do the right thing,
>> community, setting up policies that are subjective in their terms or
>> their implementation by the RIR staff.
>>> I'd like to see stats on how many ISPs have been _denied_ an
>>> under the existing rules, and why. I'd also be curious if ARIN's
>>> counsel has any comments on the anti-trust implications mentioned in
>>> rationale. If neither of those turns up a motivation for change,
>>> against this proposal by default on the grounds it's a solution in
>>> search of a problem.
>>>> I do not think that small ISPs should use the PI address space
>>>> to a bootstrap to getting PA address space later.
>>> Agreed; I'd rather have LIRs lying about their customer counts to
> get PA
>>> space than have them using PI space, which is specifically intended
>>> direct assignment to end users.
>>> Stephen Sprunk "God does not play dice." --Albert Einstein
>>> CCIE #3723 "God is an inveterate gambler, and He throws the
>>> K5SSS dice at every possible opportunity." --Stephen Hawking
>>> PPML mailing list
>>> PPML at arin.net
>> The IPv6 Portal: http://www.ipv6tf.org
>> Bye 6Bone. Hi, IPv6 !
>> This electronic message contains information which may be privileged
>> confidential. The information is intended to be for the use of the
>> individual(s) named above. If you are not the intended recipient be
>> that any disclosure, copying, distribution or use of the contents of
>> information, including attached files, is prohibited.
>> PPML mailing list
>> PPML at arin.net
The IPv6 Portal: http://www.ipv6tf.org
Bye 6Bone. Hi, IPv6 !
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.
More information about the ARIN-PPML