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/[email protected]/
[address-policy-wg] The final /8 policy proposals, part 2
- Previous message (by thread): [address-policy-wg] The final /8 policy proposals, part 2
- Next message (by thread): [#MLT-583232]: RE: [address-policy-wg] The final /8 policy proposals, part 2
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Marco Hogewoning
marcoh at marcoh.net
Tue Jul 7 01:03:25 CEST 2009
On Jul 6, 2009, at 10:07 AM, Per Heldal wrote: > On Sun, 2009-07-05 at 11:12 +0200, Sander Steffann wrote: >> Hello WG, >> >> I want to continue the discussion about the Final /8 proposals >> (2008-06 and 2009-04). The responses to my last question ("Do we >> (this >> working group) want to put IPv6 related requirements in the policy?") >> were 100% negative: We don't want IPv6 related requirements in the >> Final /8 policy. > > I think APNIC has got it mostly right. To reserve some space for > transition-services is the only suggestion I've seen that can have a > lasting effect throughout the transition period. Everything else has > been/is about skewing the balance to change who gets most out of the > remaining chunks. > > Keep it simple. One single fixed-size block for each new registrant > that > qualify for or already has a v6 block, and no prior v4 allocation. > > A whole /8 for might be more than necessary for this though. How > many /20 - /22 -size allocations does RIPE-NCC make each year where > the > registrant has no prior allocation? > > The intention of such a policy is IMHO primarily to protect new > innovative players from abuse (extortion) by the V4 powerhouses. Once > established they should seek expansion elsewhere (v6) or compete for > the > same resources as everyone else. One-size-fits all is therefore > appropriate, as it would be near impossible for the NCC to > differentiate. This more or less makes sense, you might define these blocks as "PI" to circumvent the whole membership discussion and wether or not a reciver of such block should need to be PI. MarcoH
- Previous message (by thread): [address-policy-wg] The final /8 policy proposals, part 2
- Next message (by thread): [#MLT-583232]: RE: [address-policy-wg] The final /8 policy proposals, part 2
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]