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] 2010-02 New Draft Document Published (Allocations from the last /8)
- Previous message (by thread): [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8)
- Next message (by thread): [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Martin Hannigan
marty at akamai.com
Thu Jul 8 20:45:23 CEST 2010
On 7/8/10 2:30 PM, "Fredy Kuenzler" <kuenzler at init7.net> wrote: > Am 08.07.2010 18:22, schrieb Gert Doering: >> On Thu, Jul 08, 2010 at 04:58:00PM +0100, Andy Davidson wrote: >>> The spirit of the proposal appears to be to conserve v4 addressing, to >>> assist with v6 adoption. Fine. But, what about for multihomed end >>> sites that do not need a /22, or have ncc memebrship budget ? What's >>> the *real* difference between an LIR with one end user (their own >>> infrastructure), and a non-LIR with PI ? Other than ?1,300 a year... > > The $1300 won't matter anymore very soon. People will be willing to pay much > more to get a handful of /24. I'm not sure that a lot needs to change from status quo to accomplish the goals of supporting transition. Conservation concepts are late to the game and not useful from my perspective. Perhaps the proposal could have done something smaller but more comprehensive like link a requirement of dual stacking to allocations from the last /8 and defined a list of acceptable uses such as NAT64, router loopbacks, point to point links, peering, enough to keep us in business but enough to make sure that anything handed out at this point is directly supporting the transition? Holding space for "what if" is interesting, but possibly wasteful at this late stage and perhaps even creates contention as to "what" to use it for. I like the idea of raising the minimum allocation unit, but I would have defined it as a control measure, perhaps pushing up efficiency of utilization by pushing the envelope of availability to some extent? YMMV, and best, -M<
- Previous message (by thread): [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8)
- Next message (by thread): [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]