This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] 2015-01 New Policy Proposal (Alignment of Transfer Requirements for IPv4 Allocations)
- Previous message (by thread): [address-policy-wg] 2015-01 New Policy Proposal (Alignment of Transfer Requirements for IPv4 Allocations)
- Next message (by thread): [address-policy-wg] 2015-01 New Policy Proposal (Alignment of Transfer Requirements for IPv4 Allocations)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Martin Millnert
millnert at gmail.com
Fri Feb 20 13:24:28 CET 2015
Jim, On Fri, 2015-02-20 at 11:58 +0000, Jim Reid wrote: > Could you please try to focus on providing counterproposals which are > technically sound and deal with clearly identifiable problems or gaps > in the current proposal? Thanks. Yes, although a counterproposal should probably go in its own thread / actual PDP submission. > A new entrant who wants lots of IPv4 is going to have problems. [Not > least of which will be acquiring enough clue to understand how to > design and operate a network in the 21st century or later.] Maybe > they'll buy that space from a reseller. Maybe they don't. Maybe they > find reseller prices or T&Cs to be unacceptable and walk away, maybe > they won't. Maybe they adopt IPv6. Maybe they don't. Maybe they do > Stupid Things (tm) with NAT or ALG. Maybe they don't. Maybe they > acquire an LIR or legacy holder who has a spare /8 stuffed down the > back of the sofa, maybe they don't. Completely agree with this. It's messy. Messy is bad. This is a clearly identified problem. Agreed? When it comes to what to do, I believe the markets need clear and very transparent rules to reduce friction, but restrain abuse. This is the mainly important policy aspect of future IPv4 management. I'll go study the policies from this aspect - I have nothing to add currently. > They'll have lots of options to choose from and they are free to pick > from whatever combination of these best meets their needs or business > case at that point. Prevailing RIR policy would be just one probably > small aspect of those deliberations. Indeed that is the full reality today, that RIR's role as a IPv4 supplier has vastly diminished. > > For all other use cases, assistance to entry by the RIPE NCC is banned. > > Nope. Nobody is banning anything. > > The NCC is implementing policies which have consensus from the community and are broadly fair and reasonable. For some definition of those terms. Anyone who does not like those policies has access to an open and transparent mechanism for changing them. If their ideas have merit or the community can be persuaded that the new proposals are better (for some definition of "better"), they will get support. Semantics, and also not completely true. The NCC has lately increasingly been implementing policies without any deliberation at all in the community. But that's another topic. I will agree with you that it was the way things originally worked in the RIPE region, before, when there was v4 space available. :] The relevant point here is that the policies implemented have consequences, and the community is responsible for these consequences. Legally, I guess it's the NCC. /M -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: </ripe/mail/archives/address-policy-wg/attachments/20150220/3386eadd/attachment.sig>
- Previous message (by thread): [address-policy-wg] 2015-01 New Policy Proposal (Alignment of Transfer Requirements for IPv4 Allocations)
- Next message (by thread): [address-policy-wg] 2015-01 New Policy Proposal (Alignment of Transfer Requirements for IPv4 Allocations)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]