From emadaio at ripe.net Wed Jul 7 09:32:47 2010 From: emadaio at ripe.net (Emilio Madaio) Date: Wed, 07 Jul 2010 09:32:47 +0200 Subject: [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8) Message-ID: <20100707073247.76DB06A013@postboy.ripe.net> PDP Number: 2010-02 Allocations from the last /8 Dear Colleagues, The text of the policy proposal 2010-02 has been revised based on the community feedback received on the mailing list. The draft policy document and the impact analysis for the proposal have also been published. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2010-02.html and the draft document at: http://www.ripe.net/ripe/draft-documents/ripe-492-draft2010-02.html We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 4 August. Regards Emilio Madaio Policy Development Officer RIPE NCC From president at ukraine.su Wed Jul 7 12:36:09 2010 From: president at ukraine.su (Max Tulyev) Date: Wed, 07 Jul 2010 13:36:09 +0300 Subject: [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8) In-Reply-To: <20100707073247.76DB06A013@postboy.ripe.net> References: <20100707073247.76DB06A013@postboy.ripe.net> Message-ID: <4C345899.6020609@ukraine.su> Hi All, I see the policy proposal now deny PI at all. Why? Those who requsted PI (through us) usually are not so big to become a LIR and request /20. They even don't need it. By this proposal, you will stimulate small companies become a LIR and get /22 instead of for example /24 PI. For my point of view, there should not be a difference between PA and PI distribution in the policy. Better is to make some actions to allow de-aggregate prefixes to more than /24. Then those who need /29 will ask for /29, not for /24 PI (now) or even /22 PA (if 2010-02 will be in power). Emilio Madaio ???????(??): > PDP Number: 2010-02 > Allocations from the last /8 > > Dear Colleagues, > > The text of the policy proposal 2010-02 has been revised based on the > community feedback received on the mailing list. > > The draft policy document and the impact analysis for the proposal > have also been published. > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2010-02.html > > and the draft document at: > > http://www.ripe.net/ripe/draft-documents/ripe-492-draft2010-02.html > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 4 August. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From agv100 at gmail.com Wed Jul 7 12:54:17 2010 From: agv100 at gmail.com (Gennady A.) Date: Wed, 7 Jul 2010 14:54:17 +0400 Subject: [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8) In-Reply-To: <4C345899.6020609@ukraine.su> References: <20100707073247.76DB06A013@postboy.ripe.net> <4C345899.6020609@ukraine.su> Message-ID: Max, /29 in the global routing table is a bad thing. Those who need multihoming may use PA address space. Now, when contracts to support address space are necessery, there isn't much dfference between PI and PA. 2010/7/7 Max Tulyev : > Hi All, > > I see the policy proposal now deny PI at all. Why? > > Those who requsted PI (through us) usually are not so big to become a LIR > and request /20. They even don't need it. By this proposal, you will > stimulate small companies become a LIR and get /22 instead of for example > /24 PI. > > For my point of view, there should not be a difference between PA and PI > distribution in the policy. Better is to make some actions to allow > de-aggregate prefixes to more than /24. Then those who need /29 will ask for > /29, not for /24 PI (now) or even /22 PA (if 2010-02 will be in power). > > Emilio Madaio ???????(??): >> >> PDP Number: 2010-02 >> Allocations from the last /8 >> >> Dear Colleagues, >> >> The text of the policy proposal 2010-02 has been revised based on the >> community feedback received on the mailing list. >> >> The draft policy document and the impact analysis for the proposal >> have also been published. >> >> >> You can find the full proposal at: >> >> ? ?http://www.ripe.net/ripe/policies/proposals/2010-02.html >> ? ?and the draft document at: >> >> ? ?http://www.ripe.net/ripe/draft-documents/ripe-492-draft2010-02.html >> >> We encourage you to read the draft document text and send any comments >> to address-policy-wg at ripe.net before 4 August. >> >> Regards >> >> Emilio Madaio >> Policy Development Officer >> RIPE NCC >> >> > > > -- > WBR, > Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) > > -- Regards, Gennady Abramov From tore.anderson at redpill-linpro.com Wed Jul 7 15:01:14 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 07 Jul 2010 15:01:14 +0200 Subject: [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8) In-Reply-To: <20100707073247.76DB06A013@postboy.ripe.net> References: <20100707073247.76DB06A013@postboy.ripe.net> Message-ID: <4C347A9A.8030703@redpill-linpro.com> >From the analysis: > This address space may not be a single aggregated /8 and can contain > prefixes as long as a /29 or more. Therefore it is possible that at > some point the RIPE NCC will be unable to allocate a single /22 > block to an LIR and will have to allocate multiple prefixes that > total 1,024 IP addresses. Because of this situation, there will > effectively no longer be a minimum allocation size within the RIPE > NCC service region when this happens. As I understand it, RIPE NCC is guaranteed to receive one last contiguous /8 from IANA (cf. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm section 2.1). I think it would be prudent to reserve this particular /8 for the implementation of this policy, instead of specifying ?a threshold of a total of one /8?. That way the potential problem with fragmentation will only occur once the entire /8 has been allocated and the only thing that is remaining in the pool is returned allocations smaller than /22. >From the proposed policy: > a. LIRs may only receive one allocation from this /8. The size of the > allocation made under this policy will be no larger than a /22. This obviously conflicts with the current minimum allocation size (/21). Does the proposed policy intend to change the minimum allocation size to /22 so that all LIRs are eligible to receive a /22 (no more, no less), or to remove the minimum allocation size completely as suggested by the analysis - even when contiguous /22s are available in the unallocated pool? The language of the policy seems to imply the latter, as it says specifically ?no larger? and ?at most? (but makes no mention of ?no smaller? and/or ?at minimum?). I can easily see that being perceived as unfair, as one RIR might only be allocated a /23 at first and then be unable to come back later for another /23 (due to the one allocation only rule). So I'd favour it being a /22, no more, no less (until fragmentation makes that impossible). Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From president at ukraine.su Wed Jul 7 15:38:16 2010 From: president at ukraine.su (Max Tulyev) Date: Wed, 07 Jul 2010 16:38:16 +0300 Subject: [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8) In-Reply-To: References: <20100707073247.76DB06A013@postboy.ripe.net> <4C345899.6020609@ukraine.su> Message-ID: <4C348348.1040406@ukraine.su> Gennady, for now it is bad. But when there will be a lack of IPv4, we have to sacrifice aggregation in favour to conservation. The difference is the independence. PA is not. Gennady A. ???????(??): > Max, > /29 in the global routing table is a bad thing. > > Those who need multihoming may use PA address space. Now, when > contracts to support address space are necessery, there isn't much > dfference between PI and PA. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From pfs at cisco.com Thu Jul 8 00:16:54 2010 From: pfs at cisco.com (Philip Smith) Date: Thu, 08 Jul 2010 08:16:54 +1000 Subject: [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8) In-Reply-To: <4C345899.6020609@ukraine.su> References: <20100707073247.76DB06A013@postboy.ripe.net> <4C345899.6020609@ukraine.su> Message-ID: <4C34FCD6.3060901@cisco.com> Hi Max, The proposal has *never* been about PI, ever. Alain and I were requested to include specific wording to that effect. So we did. :-) Best wishes, philip -- Max Tulyev said the following on 7/07/10 20:36 : > Hi All, > > I see the policy proposal now deny PI at all. Why? > > Those who requsted PI (through us) usually are not so big to become a > LIR and request /20. They even don't need it. By this proposal, you will > stimulate small companies become a LIR and get /22 instead of for > example /24 PI. > > For my point of view, there should not be a difference between PA and PI > distribution in the policy. Better is to make some actions to allow > de-aggregate prefixes to more than /24. Then those who need /29 will ask > for /29, not for /24 PI (now) or even /22 PA (if 2010-02 will be in power). > > Emilio Madaio ???????(??): >> PDP Number: 2010-02 >> Allocations from the last /8 >> >> Dear Colleagues, >> >> The text of the policy proposal 2010-02 has been revised based on the >> community feedback received on the mailing list. >> >> The draft policy document and the impact analysis for the proposal >> have also been published. >> >> >> You can find the full proposal at: >> >> http://www.ripe.net/ripe/policies/proposals/2010-02.html >> and the draft document at: >> >> http://www.ripe.net/ripe/draft-documents/ripe-492-draft2010-02.html >> >> We encourage you to read the draft document text and send any comments >> to address-policy-wg at ripe.net before 4 August. >> >> Regards >> >> Emilio Madaio >> Policy Development Officer >> RIPE NCC >> >> > > From pfs at cisco.com Thu Jul 8 00:21:41 2010 From: pfs at cisco.com (Philip Smith) Date: Thu, 08 Jul 2010 08:21:41 +1000 Subject: [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8) In-Reply-To: <4C347A9A.8030703@redpill-linpro.com> References: <20100707073247.76DB06A013@postboy.ripe.net> <4C347A9A.8030703@redpill-linpro.com> Message-ID: <4C34FDF5.1020507@cisco.com> Hi Tore, Tore Anderson said the following on 7/07/10 23:01 : > > This obviously conflicts with the current minimum allocation size (/21). > Does the proposed policy intend to change the minimum allocation size > to /22 so that all LIRs are eligible to receive a /22 (no more, no > less), or to remove the minimum allocation size completely as suggested > by the analysis - even when contiguous /22s are available in the > unallocated pool? As you observe, minimum allocation of /21 makes no sense for a policy proposing maximum allocation of /22. Alain and I hadn't intended to document a minimum allocation size, but I certainly feel that it is very unlikely we'll see requests for allocations smaller than a /22 (I could be wrong of course). My preference is to leave it open so that folks wanting a smaller allocation can get it. philip -- From tore.anderson at redpill-linpro.com Thu Jul 8 08:10:42 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 08 Jul 2010 08:10:42 +0200 Subject: [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8) In-Reply-To: <4C34FDF5.1020507@cisco.com> References: <20100707073247.76DB06A013@postboy.ripe.net> <4C347A9A.8030703@redpill-linpro.com> <4C34FDF5.1020507@cisco.com> Message-ID: <4C356BE2.8080605@redpill-linpro.com> * Philip Smith > Tore Anderson said the following on 7/07/10 23:01 : >> >> This obviously conflicts with the current minimum allocation size (/21). >> Does the proposed policy intend to change the minimum allocation size >> to /22 so that all LIRs are eligible to receive a /22 (no more, no >> less), or to remove the minimum allocation size completely as suggested >> by the analysis - even when contiguous /22s are available in the >> unallocated pool? > > As you observe, minimum allocation of /21 makes no sense for a policy > proposing maximum allocation of /22. Alain and I hadn't intended to > document a minimum allocation size, but I certainly feel that it is very > unlikely we'll see requests for allocations smaller than a /22 (I could > be wrong of course). My preference is to leave it open so that folks > wanting a smaller allocation can get it. Hi Philip, my concern is not with LIRs that for some reason or another want a longer prefix than a /22, but with LIRs that cannot justify an immediate assignment of a /22. Remember that 12 months from now, LIRs will be allocated space to cover the needs for a period to up to three months only (cf. ripe-492, section 5.0). I don't see anything in the current proposal that allows the NCC to disregard this rule. Not all LIRs will go through a /22 in three months. As I understand it, with no minimum allocation size in place, the NCC would have no choice but to deny any requests for /22 coming from these LIRs. And because of the one allocation only rule, they will be unable to come back and request more space after they've gone through the /23 (or longer) they were able to immediately justify. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From emadaio at ripe.net Thu Jul 8 16:37:38 2010 From: emadaio at ripe.net (Emilio Madaio) Date: Thu, 08 Jul 2010 16:37:38 +0200 Subject: [address-policy-wg] 2010-01 New Draft Document Published (Temporary Internet Number Assignment Policies) Message-ID: <20100708143739.6D4F36A021@postboy.ripe.net> PDP Number: 2010-01 Temporary Internet Number Assignment Policies Dear Colleagues, The text of the policy proposal 2010-01 has been revised based on the community feedback received. The draft policy document and the impact analysis for the proposal have also been published. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2010-01.html and the draft document at: http://ripe.net/ripe/draft-documents/ripe-new-draft-2010-01.html We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 5 August 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC From president at ukraine.su Thu Jul 8 17:16:22 2010 From: president at ukraine.su (Max Tulyev) Date: Thu, 08 Jul 2010 18:16:22 +0300 Subject: [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8) In-Reply-To: References: <20100707073247.76DB06A013@postboy.ripe.net> <4C345899.6020609@ukraine.su> <4C348348.1040406@ukraine.su> Message-ID: <4C35EBC6.5050709@ukraine.su> I'm about independence from upstream provider or other telecom-engaged entity, not about payments. Gennady A. ???????(??): > Which independency you are talking about? > Currently, PIs are not actually independent. To keep them running, PI > user also have to pay support fee, like if he uses PA address space. > > 2010/7/7 Max Tulyev : >> Gennady, >> >> for now it is bad. But when there will be a lack of IPv4, we have to >> sacrifice aggregation in favour to conservation. >> >> The difference is the independence. PA is not. >> >> Gennady A. ???????(??): >>> Max, >>> /29 in the global routing table is a bad thing. >>> >>> Those who need multihoming may use PA address space. Now, when >>> contracts to support address space are necessery, there isn't much >>> dfference between PI and PA. >> -- >> WBR, >> Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) >> >> > > > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From president at ukraine.su Thu Jul 8 17:20:12 2010 From: president at ukraine.su (Max Tulyev) Date: Thu, 08 Jul 2010 18:20:12 +0300 Subject: [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8) In-Reply-To: <4C34FCD6.3060901@cisco.com> References: <20100707073247.76DB06A013@postboy.ripe.net> <4C345899.6020609@ukraine.su> <4C34FCD6.3060901@cisco.com> Message-ID: <4C35ECAC.6070609@ukraine.su> Hi Philip, there is "Under the current policies, when this proposed policy is triggered, the RIPE NCC will no longer assign ASSIGNED PI and ASSIGNED ANYCAST space." right now at the proposal page. I (and not only me) mean after the policy is in power, RIPE NCC will stop assign PI/ANYCAST at all. I can imagine why it can be with PI, but why ANYCAST? ;) Philip Smith ???????(??): > Hi Max, > > The proposal has *never* been about PI, ever. Alain and I were requested > to include specific wording to that effect. So we did. :-) > > Best wishes, > > philip > -- > > Max Tulyev said the following on 7/07/10 20:36 : >> Hi All, >> >> I see the policy proposal now deny PI at all. Why? >> >> Those who requsted PI (through us) usually are not so big to become a >> LIR and request /20. They even don't need it. By this proposal, you will >> stimulate small companies become a LIR and get /22 instead of for >> example /24 PI. >> >> For my point of view, there should not be a difference between PA and PI >> distribution in the policy. Better is to make some actions to allow >> de-aggregate prefixes to more than /24. Then those who need /29 will ask >> for /29, not for /24 PI (now) or even /22 PA (if 2010-02 will be in power). >> >> Emilio Madaio ???????(??): >>> PDP Number: 2010-02 >>> Allocations from the last /8 >>> >>> Dear Colleagues, >>> >>> The text of the policy proposal 2010-02 has been revised based on the >>> community feedback received on the mailing list. >>> >>> The draft policy document and the impact analysis for the proposal >>> have also been published. >>> >>> >>> You can find the full proposal at: >>> >>> http://www.ripe.net/ripe/policies/proposals/2010-02.html >>> and the draft document at: >>> >>> http://www.ripe.net/ripe/draft-documents/ripe-492-draft2010-02.html >>> >>> We encourage you to read the draft document text and send any comments >>> to address-policy-wg at ripe.net before 4 August. >>> >>> Regards >>> >>> Emilio Madaio >>> Policy Development Officer >>> RIPE NCC >>> >>> >> > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From andy at nosignal.org Thu Jul 8 17:58:00 2010 From: andy at nosignal.org (Andy Davidson) Date: Thu, 8 Jul 2010 16:58:00 +0100 Subject: [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8) In-Reply-To: <4C34FCD6.3060901@cisco.com> References: <20100707073247.76DB06A013@postboy.ripe.net> <4C345899.6020609@ukraine.su> <4C34FCD6.3060901@cisco.com> Message-ID: <270F6D72-1CCF-4B13-B5EC-7EB688607E60@nosignal.org> On 7 Jul 2010, at 23:16, Philip Smith wrote: > The proposal has *never* been about PI, ever. Alain and I were requested to include specific wording to that effect. So we did. :-) I'm not sure the words have been picked though. :-) What is the rationale to stop assigning PI ? The PI ban appears to have been introduced between v1 and v2 of this draft, where was the discussion that led to this wording ? 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... Andy From gert at space.net Thu Jul 8 18:22:41 2010 From: gert at space.net (Gert Doering) Date: Thu, 8 Jul 2010 18:22:41 +0200 Subject: [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8) In-Reply-To: <270F6D72-1CCF-4B13-B5EC-7EB688607E60@nosignal.org> References: <20100707073247.76DB06A013@postboy.ripe.net> <4C345899.6020609@ukraine.su> <4C34FCD6.3060901@cisco.com> <270F6D72-1CCF-4B13-B5EC-7EB688607E60@nosignal.org> Message-ID: <20100708162241.GH73473@Space.Net> Hi, 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... Well, the basic question is "what do we want to do with the last /8"? So far, the only proposal that had any chance of coming near consensus was "chop it in small pieces, give every existing and possible future LIR a *single* piece, and nothing more, ever". The intent is "those that roll out new networks will use IPv6, but are likely to need a few addresses for their translation services" - and since it's very hard to formulate RS-applicable criteria for that, simplicity is our friend here: "a single chunk, done". Let's not forget that IPv4 is running out. So a debate about IPv4 PI space from the last /8 is somewhat moot - basing business decisions on the availability of IPv4 address space is a very very bad idea. It *will* run out, no matter what we do - the only question remaining is "will we able to lessen the pain (especially for future entrants into this arena) a bit with this policy, or not". If you all think that this policy should look different, please voice specific proposals how to change it... but hurry up, because if we spend a year discussing it, there is no IPv4 space left to haggle about. Gert Doering, Address Policy WG Chair -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From kuenzler at init7.net Thu Jul 8 20:30:35 2010 From: kuenzler at init7.net (Fredy Kuenzler) Date: Thu, 08 Jul 2010 20:30:35 +0200 Subject: [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8) In-Reply-To: <20100708162241.GH73473@Space.Net> References: <20100707073247.76DB06A013@postboy.ripe.net> <4C345899.6020609@ukraine.su> <4C34FCD6.3060901@cisco.com> <270F6D72-1CCF-4B13-B5EC-7EB688607E60@nosignal.org> <20100708162241.GH73473@Space.Net> Message-ID: <4C36194B.6030708@init7.net> 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. > Well, the basic question is "what do we want to do with the last /8"? > > So far, the only proposal that had any chance of coming near consensus > was "chop it in small pieces, give every existing and possible future > LIR a *single* piece, and nothing more, ever". > > The intent is "those that roll out new networks will use IPv6, but are > likely to need a few addresses for their translation services" - and > since it's very hard to formulate RS-applicable criteria for that, > simplicity is our friend here: "a single chunk, done". > > Let's not forget that IPv4 is running out. So a debate about IPv4 PI > space from the last /8 is somewhat moot - basing business decisions on > the availability of IPv4 address space is a very very bad idea. It should contain a statement about PI space nevertheless, something like "once the first block of last /8 is given out, only /24 PI blocks are given out from the remaining PI aggregation, as long as available". My $0.02 F. From marty at akamai.com Thu Jul 8 20:45:23 2010 From: marty at akamai.com (Martin Hannigan) Date: Thu, 08 Jul 2010 14:45:23 -0400 Subject: [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8) In-Reply-To: <4C36194B.6030708@init7.net> Message-ID: On 7/8/10 2:30 PM, "Fredy Kuenzler" 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< From randy at psg.com Fri Jul 9 04:42:39 2010 From: randy at psg.com (Randy Bush) Date: Fri, 09 Jul 2010 11:42:39 +0900 Subject: [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8) In-Reply-To: <20100708162241.GH73473@Space.Net> References: <20100707073247.76DB06A013@postboy.ripe.net> <4C345899.6020609@ukraine.su> <4C34FCD6.3060901@cisco.com> <270F6D72-1CCF-4B13-B5EC-7EB688607E60@nosignal.org> <20100708162241.GH73473@Space.Net> Message-ID: > So far, the only proposal that had any chance of coming near consensus > was "chop it in small pieces, give every existing and possible future LIR > a *single* piece, and nothing more, ever". and that was the consensus reached in apnic. > The intent is "those that roll out new networks will use IPv6, but are > likely to need a few addresses for their translation services" - and > since it's very hard to formulate RS-applicable criteria for that, > simplicity is our friend here: "a single chunk, done". 'zactly > It *will* run out, no matter what we do - the only question remaining > is "will we able to lessen the pain (especially for future entrants > into this arena) a bit with this policy, or not". for a long while, we have used conserving routing table space to place a barrier to entry to the market. this proposal removes that for future entrants who need a teensie bit of v4 to front to the legacy v4 part of the dual stack network. randy From bensons at queuefull.net Fri Jul 9 18:16:09 2010 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 9 Jul 2010 11:16:09 -0500 Subject: [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8) In-Reply-To: References: <20100707073247.76DB06A013@postboy.ripe.net> <4C345899.6020609@ukraine.su> <4C34FCD6.3060901@cisco.com> <270F6D72-1CCF-4B13-B5EC-7EB688607E60@nosignal.org> <20100708162241.GH73473@Space.Net> Message-ID: <11BABD28-FEB1-4161-AC48-E43FA0953A92@queuefull.net> On 8 Jul 10, at 9:42 PM, Randy Bush wrote: > >> It *will* run out, no matter what we do - the only question remaining >> is "will we able to lessen the pain (especially for future entrants >> into this arena) a bit with this policy, or not". > > for a long while, we have used conserving routing table space to place a > barrier to entry to the market. this proposal removes that for future > entrants who need a teensie bit of v4 to front to the legacy v4 part of > the dual stack network. As implied, this proposal enables future entrants at the expense of routing table conservation. To what extent should the RIR community be concerned about enabling access / competition, versus the ongoing operation of existing networks? Whether we're discussing an IPv4 market or the market for transitionary network services, there are organizations prepared to facilitate new entrants. A "chop it in small pieces" policy would not extend the life of IPv4 indefinitely; we will run out, and these markets will be the only option. Until then, these markets would be artificially devalued. Further, this policy may lead to wasted IPv4 resources if new organizations do not emerge to consume the remaining space. Existing networks may struggle due to inadequate IPv4 resources, while the reserved pool sits unclaimed. The worst case is where all of the above exists together: wasted IPv4 resources in an unclaimed pool, devalued transitionary markets, and network providers unable to grow their services while facing the operational impact of a growing routing table. I would feel much better about this policy if it allowed for subsequent /22 assignments over time. Perhaps a limit of 1 assignment per 90 days, or something along those lines. -Benson From dave.wilson at heanet.ie Wed Jul 14 18:17:01 2010 From: dave.wilson at heanet.ie (Dave Wilson) Date: Wed, 14 Jul 2010 17:17:01 +0100 Subject: [address-policy-wg] 2010-03 New Policy Proposal (Global Policy State in RIPE PDP) In-Reply-To: <20100420091443.5BEED6A005@postboy.ripe.net> References: <20100420091443.5BEED6A005@postboy.ripe.net> Message-ID: <4C3DE2FD.4020505@heanet.ie> Hello all, > http://www.ripe.net/ripe/policies/proposals/2010-03.html The objective of this policy proposal is to modify the PDP in a way specific to global policies. Global Policies (which, by definition, affect IANA), may not take effect until they have gained consensus in all five regions. In the case where RIPE adopts a global policy proposal but the proposal later changes in another region, this modification would make it explicit that RIPE may consider the changed text despite having already adopted an earlier text. Since RIPE 60, it's become clear to me that this is a more complex proposition than it looks. As I said at the meeting, the current Global Policy Development Process is very good at doing one thing: where a policy has consensus in all five regions, it is very good at determining this. By changing the RIPE PDP to try to make it easier to reach consensus where it does not yet exist, a number of complexities are introduced. In particular, on this list there have already been some questions about the cases enumerated where a GPP might not reach consensus. I think now that by changing the PDP in this way, we would have to enumerate many such cases, at various points of the PDP, and I fear we would not successfully cover them all. So while the goal is a laudable one, as I said at RIPE 60, I am not satisfied that this is an elegant way to solve it. The problem is not urgent, and we already have a way to deal with such a problem when it arises. So I do not think there is much to be gained by pushing forward in this way. On this basis, I would like to withdraw this proposal and, as suggested at RIPE 60, consider more generic alternatives. Best regards, Dave -- Dave Wilson, Senior Network Engineer HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/ Calendar & PGP: http://people.heanet.ie/~davew/ From filiz at ripe.net Thu Jul 15 16:38:16 2010 From: filiz at ripe.net (Filiz Yilmaz) Date: Thu, 15 Jul 2010 16:38:16 +0200 Subject: [address-policy-wg] New Draft Document: Autonomous System (AS) Number Assignment Policies Message-ID: Dear Colleagues, At the RIPE 59 Meeting in Lisbon in October 2009, the RIPE NCC announced that it would undertake a project to improve the language of various RIPE Policy Documents, without changing their substance or meaning. This project is aimed at improving the clarity and readability of RIPE Documents. For more information, see: http://www.ripe.net/ripe/updated-documents A draft of the first RIPE Document to be revised, ripe-463, "Autonomous System (AS) Number Assignment Policies and Procedures", was then published. The status of the project was presented at the RIPE 60 Meeting in Prague in May 2010, and new discussions and decisions ensued. The development of the project led to a second version of the draft. We have published this draft document in two layouts. The first layout contains only the proposed text, in full, and is available at: http://www.ripe.net/ripe/updated-documents/ASN-inc-v2.html The second layout contains both the current text and the proposed text side by side, and it?s available at: http://www.ripe.net/ripe/updated-documents/ASN-comp-v2.html At the top of both draft documents, there is a summary of the proposed changes. There are three changes we would like to highlight because they differ from the previous version of the draft. Abstract The abstract was edited to be more precise and comprehensive. Paragraph 5.0: Validity of an Assignment This paragraph was removed as per feedback from the RIPE community. Paragraph 8.0: Attribution This paragraph was added to note the participation of the people who made AS Number-related proposals through the RIPE Policy Development Process and who therefore contributed to the wording of the AS Number policy documents over time. During RIPE 60, the RIPE community agreed to use this method of attribution for all future RIPE Policy Documents. Other smaller changes are listed at the top of document. Please review the text and send any feedback you might have to the Address Policy Working Group mailing list. The period for review is two weeks and lasts until 29 July 2010. After the review period, the Address Policy Working Group Chairs will conclude whether or not there is consensus on the draft document. Kind regards, Filiz Yilmaz Policy Development Manager RIPE NCC From emadaio at ripe.net Tue Jul 20 13:18:36 2010 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 20 Jul 2010 13:18:36 +0200 Subject: [address-policy-wg] 2010-03 Policy Proposal Withdrawn (Global Policy State in RIPE PDP) Message-ID: <20100720111836.6C2B26A003@postboy.ripe.net> PDP Number: 2010-03 Global Policy State in RIPE PDP Dear Colleagues, The proposal has been withdrawn. It is now archived and can be found at: http://www.ripe.net/ripe/policies/proposals/2010-03.html The reason for withdrawal is: proposer decided to withdraw the proposal based on the feedback received at RIPE 60. Regards Emilio Madaio Policy Development Officer RIPE NCC From webmaster at ripe.net Mon Jul 26 12:32:34 2010 From: webmaster at ripe.net (RIPE NCC Document Announcement Service) Date: Mon, 26 Jul 2010 12:32:34 +0200 Subject: [address-policy-wg] New Document available: RIPE-495 Message-ID: <20100726103234.E64B86A00A@postboy.ripe.net> New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE Document store: Ref: ripe-495 Title: Principles for Number Resource Registration Policies Author: Rob Blokzijl & Daniel Karrenberg Format: HTML & PDF Date: July 2010 Short content description ------------------------- This document sets out the principles for IPv4 address registration after the unallocated pool of addresses has run out. The purpose of this document is to expose the thinking of the authors, and encourage a discussion in the community. This is not a policy proposal. Once there is community consensus about these principles, the authors intend to instigate the development of appropriate policies. Accessing the RIPE Document store --------------------------------- You can access the RIPE Document in HTML format from our website at the following URL: http://www.ripe.net/docs/ripe-495.html The RIPE Document Store is also available over anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URL for the new document on the FTP-server is: ftp://ftp.ripe.net/ripe/docs/ripe-495.pdf Regards Adrian Bedford Web Services Team Leader RIPE NCC