[arin-ppml] RIPE/ITU

[McTim]

Hi,

On Sat, Feb 27, 2010 at 4:43 AM, Skeeve Stevens <Skeeve at eintellego.net> wrote:
> Do you have any reference to where the APNIC community is suggesting phasing out the NIR model?

I don't this recollection is based on private conversations over the
last 5 years.

Now that I am thinking about it, perhaps "phasing out" is too strong a
term, I think that what they have decided is more like "no more new
NIRs".

-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel





>
> ...Skeeve
>
> --
> Skeeve Stevens, CEO/Technical Director
> eintellego Pty Ltd - The Networking Specialists
> skeeve at eintellego.net / www.eintellego.net
> Phone: 1300 753 383, Fax: (+612) 8572 9954
> Cell +61 (0)414 753 383 / skype://skeeve
> www.linkedin.com/in/skeeve ; facebook.com/eintellego
> --
> NOC, NOC, who's there?
>
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of McTim
>> Sent: Saturday, 27 February 2010 9:51 AM
>> To: Milton L Mueller
>> Cc: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] RIPE/ITU
>>
>> Hi Milton,
>>
>> On Sat, Feb 27, 2010 at 1:15 AM, Milton L Mueller <mueller at syr.edu>
>> wrote:
>> >
>> > > -----Original Message-----
>> > > You might want to look into APNIC's NIR model which is exactly
>> > > that, and then make a formal proposal.
>> >
>> > My understanding is that the people at APNIC are not exactly
>> delighted with the NIR model;
>>
>> My understanding is that the people who make up the APNIC community
>> are not exactly delighted with the NIR model, and the model is being
>> phased out as not viable.
>>
>> >
>> > it was a concession to some of the same political pressures that are
>> now leading to the call for CIRs. Indeed, it is a bit inconsistent for
>> this community to argue against the Ramadass proposal for CIRs and then
>> propose NIRs instead.
>>
>> agreed, but the community hasn't endorsed this idea AFAICS.
>>
>> >
>> > I prefer McTim's approach of supporting the principle that addresses
>> should be allocated to users (ASs) and not to governments or other
>> entities who want to interpose themselves as intermediaries.
>> >
>> > If it comes down to a choice between NIRs and CIRs, then the only
>> relevant difference is whether the RIRs retain a monopoly on higher-
>> level allocations or not. I think that's a weak position to be in. Here
>> we need to frankly realize that the issues are fundamentally political.
>> >
>> > Note that the ITU proposal for CIRs does not propose to make them
>> exclusive, but rather proposes that an ITU-mediated CIR be an
>> additional option. If one supports competing ISPs, why not alternative
>> address registries?
>>
>> RFC2050
>>
>> "Service areas will be of continental dimensions."
>>
>> In addition there are various other reasons outlined in the Circleid
>> post I sent earlier.
>>
>> >
>> > One cannot argue against this option on the grounds that we don't
>> have enough ipv6 addresses to make it viable; we do. One cannot argue
>> against it on the grounds that it messes up the efficiency of routing,
>>
>> You can actually.
>>
>> >because new, RIR-sanctioned NIRs or new RIRs carved out of existing
>> ones would have basically the same effects on routing.
>>
>> perhaps, or perhaps not, depending on the policies they adopt.
>>
>> >
>> > The only way to viably challenge this proposal is to face squarely
>> the political issues and question whether states who gain control of ip
>> addresses will truly allow competitive alternatives, or instead try to
>> leverage their control of the resource to gain more control over
>> internet supply and usage, or to favor incumbent, national champion
>> network operators.
>>
>>
>> or to boost government revenue, or use IP address revenue to feather
>> individual nests, or not develop policies in an open, transparent
>> manner, etc, etc.
>>
>>
>> >
>> > One can also try to question the need for this proposal (solution in
>> search of a problem). There is merit in this argument, but the issue is
>> not quite as simple as it may seem. Developing countries aware of the
>> landrush for ipv4 addresses that took place in the early stages of the
>> internet's development have a legitimate reason to worry about whether
>> history will repeat itself. An inherent feature of needs-based
>> allocations is that developed economies will be able to show "need"
>> well before undeveloped ones. The ITU is basically arguing for a system
>> of reservations that guarantees each nation-state a substantial chunk
>> of address resources just in case that happens. Naturally enough, given
>> its basis in an intergovernmental organization, the ITU considers
>> nation-states the appropriate stewards for these reservations.
>>
>>
>> Speaking of "reservations" I am under the impression that it is the
>> IETF that instructs the IANA to reserve IP blocks.  If this is
>> correct, then the ITU and the RIR policy lists are not the correct
>> fora to discuss this proposal.  The ITU should write a draft RFC and
>> submit it to the IETF.  Perhaps I am mistaken.
>>
>> >
>> > If setting aside address block reservations were the ONLY price we
>> had to pay to assuage these political concerns, I would say, "do it."
>> But other prices could be extracted - as I explained above, linking ip
>> address allocations to the nation state system so closely could have
>> serious political and regulatory repercussions. That price is not worth
>> paying.
>>
>>
>> I hope you plan to say this to the ITU in March!
>>
>>
>> --
>> Cheers,
>>
>> McTim
>> "A name indicates what we seek. An address indicates where it is. A
>> route indicates how we get there."  Jon Postel
>> _______________________________________________
>> 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.
>