From goz at idecogateway.com Thu Apr 1 13:13:26 2010 From: goz at idecogateway.com (Sergey Gotsulyak) Date: Thu, 1 Apr 2010 17:13:26 +0600 Subject: [address-policy-wg] Easy to remember IP-address In-Reply-To: <20100329105830.GL69383@Space.Net> References: <144276706.20100329164135@idecogateway.com> <20100329105830.GL69383@Space.Net> Message-ID: <1761055829.20100401171326@idecogateway.com> > Now, there's of course a catch - the PDP takes a while to run through > (a couple of months at best, some times much longer), and you need > *consensus* for a proposed policy change to become policy - so you need > to convince the RIPE community that it's of common interest to change > this. Thank you for the information about PDP. I guess the process will take much longer than we expected. Is it probable that an agreement could be reached regarding an assignment of a block of IP-addresses from the yet unallocated ranges? Has this question ever been raised before? For example, we?d like to get address 2.2.2.2 ? but if a similar *easy to rmemeber address* is available from a allocatable space, we?ll be satisfied with that too. Should we send a request for a policy change or is it most likely not going to help reach a consensus? > Since we're running out of addresses quickly, even if you succeed in > changing the policy, the subnet containing 2.2.2.2 might already be > handed out to someone else. So I wouldn't bet the success of my > company on the chance of receiving 2.2.2.2 - you might succeed, but > you might as well not. Ok, I see. Is it technically possible to get address 2.2.2.2 when this range 2.*.*.* becomes publicly available for assignment? -- Kind regards, Sergey Gotsulyak Ideco Sales Team 280 Madison Ave, Suite 912 New York, NY 10016 Phone: (800) 715-3502 Email: goz at idecogateway.com Web: www.idecogateway.com From goz at idecogateway.com Thu Apr 1 13:13:35 2010 From: goz at idecogateway.com (Sergey Gotsulyak) Date: Thu, 1 Apr 2010 17:13:35 +0600 Subject: [address-policy-wg] Easy to remember IP-address In-Reply-To: <4BB089CD.3020305@baycix.de> References: <144276706.20100329164135@idecogateway.com> <20100329105830.GL69383@Space.Net> <4BB089CD.3020305@baycix.de> Message-ID: <131796116.20100401171335@idecogateway.com> > If we would have such a policy, all nice vanity addresses would have > been "sold out" (mind the quotes) by now already anways. And you might > not have the budget to "buy" a nice address either because it would cost > a fortune like sex.com or so :-) > But, fortunately, IP addresses are not Domain Names.... This is not bad on one side. But on the other ? let?s picture a situation when a company gets randomly assigned for example domain dju48d.com instead of clear and simple domain company.com... For many this situation is even worse than the first one :-) -- Kind regards, Sergey Gotsulyak Ideco Sales Team 280 Madison Ave, Suite 912 New York, NY 10016 Phone: (800) 715-3502 Email: goz at idecogateway.com Web: www.idecogateway.com From goz at idecogateway.com Thu Apr 1 14:18:56 2010 From: goz at idecogateway.com (Sergey Gotsulyak) Date: Thu, 1 Apr 2010 18:18:56 +0600 Subject: [address-policy-wg] Easy to remember IP-address In-Reply-To: References: <144276706.20100329164135@idecogateway.com> <20100329105830.GL69383@Space.Net> <4BB089CD.3020305@baycix.de> <131796116.20100401171335@idecogateway.com> Message-ID: <326607897.20100401181856@idecogateway.com> Gennady, are you trying to say that Google doensn't know the best marketing techniques? P.S: Google has chosen for their DNS-service an easy to remember 8.8.8.8 address ;-) > Remembering domain names and IP addressess are absolutely different > things. Domain names are on the user level, IP addressess are not. > Let's not make such "dirty hacks" to multi-level networking model :) > (I avoid "7-level OSI model" phrase here). > So, it's bad idea to build PR/marketing campaign based on "beautifull" > IP-address. It's something like beautifull (from user, not engineer > view) design of motherboards, gearboxes, etc.. It may be fine, but not > more, there is a lot of more important things user should consider > about. > I completely can't understand, why you so need "easy-to-remember" > addressess and don't you have a better way to make your services more > user-friendly and PRable. From michael.dillon at bt.com Thu Apr 1 14:34:04 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 1 Apr 2010 13:34:04 +0100 Subject: [address-policy-wg] Easy to remember IP-address In-Reply-To: <326607897.20100401181856@idecogateway.com> Message-ID: <28E139F46D45AF49A31950F88C49745805A8C011@E03MVZ2-UKDY.domain1.systemhost.net> > Gennady, are you trying to say that Google doensn't know the best > marketing techniques? If you refer to this page http://code.google.com/speed/public-dns/ it appears that Google's service is free. Not much marketing is needed to offer a free service. > P.S: Google has chosen for their DNS-service an easy to remember > 8.8.8.8 address ;-) Wrong! Google did not *CHOOSE* that address. Instead they negotiated with Level 3 Communications who had been allocated that address range by ARIN. I suggest that you do the same. Find a memorable address that has already been allocated and negotiate with the company to use it for your DNS service. In fact, I suggest that you investigate 8.9.9.9 and 8.9.10.11 because I know for a fact that the company who has been allocated those addresses, is willing to consider a deal. I don't think that RIPE should change its policy to accomodate this type of request, and I don't think that RIPE should accept requests for specific non-allocated addresses. --Michael Dillon From nick at inex.ie Thu Apr 1 14:36:10 2010 From: nick at inex.ie (Nick Hilliard) Date: Thu, 01 Apr 2010 13:36:10 +0100 Subject: [address-policy-wg] 2010-02 New Policy Proposal (Revoke and Re-assign Fairly) Message-ID: <4BB4933A.1020406@inex.ie> Number: 2010-01 Policy Proposal Name: Revoke and Re-assign Fairly Author: Nick Hilliard, INEX Proposal Version: 1.0 Submission Date: 1 April 2010 Current Phase: Discussion - Open for Discussion Phase ends/ended: 1 April 2010 Latest Status: Initial Community Discussion Suggested WG for Discussion and Publication: Address Policy Proposal Type: New Policy Term: Indefinite Policy Documents to be Affected: * IPv4 Address Allocation and Assignment Procedures for the RIPE NCC Service Region (ripe-492) Summary of Proposal: This proposal revokes all previous IPv4 LIR allocations and direct / LIR assignments, returning all ERX and RIPE NCC-assigned IPv4 address space back to the RIPE NCC, where it can be re-assigned fairly, using new policies and guidelines. The RIPE NCC has been acting as RIR in the European / Middle-East geographical areas since 1989. Due to egregiously lenient policies and gross end-user address wastage, in combination with a more recent tendency to horde IPv4 addresses in anticipation of a future shortage, recent research has suggested that approximately 97% of IPv4 address assigned and allocated through the RIPE NCC aren't actually used at all, and never were. Furthermore, this research suggests that if all this address space were returned to the RIR for re-assignment, this would create enough slack space in the IPv4 address pool to service all future requests in the RIPE NCC service region for approximately 100-150 years, based on current actual run-rate, rather than the current fantasy figures published by the RIPE NCC. Also included as part of this policy is a future restriction to limit all future direct assignments to 640 IPv4 address, because that should be enough for anyone. Policy Text: a. Old text Remove sections 5, 6 and 7 in RIPE 492. b. New policy text Insert new section 5 in RIPE 492: -- 5.0 Policies and Guidelines for Allocations and Assignments An allocation is a block of IPv4 addresses from which assignments are taken. All allocations and assignments made prior to April 1, 2010 are hereby revoked, cancelled, and made null and void. LOL!!11!!!1! The RIPE NCC will allocate 640 IPv4 addresses to each LIR, because that that should be more than enough for anyone. PI assignments requests will be greeted with even more giggles than they currently are. -- a. Arguments supporting the proposal Every LIR and PI holder is hoarding address space like there's no tomorrow. By forcing a reboot of the entire registry system, every holder will be equally wrong-footed, and will realise that there's no need to hoarde address space after all. This policy will have the side effect of ensuring that this insane rush to IPv6 is entirely unnecessary, proving beyond all doubt that the ITU seriously has no clue when it comes to Internet resource assignment. b. Arguments Opposing the Proposal It is likely that nay-sayers and other party-poopers will come out of the wood-work to bleat about how this proposal is unfair. The author advises that they get a life and stop hoarding numbers. After all, they're only numbers. And if they really need more, they can contact me directly (see contact details above). Some companies will attempt to claim that they have more than 640 customers. Clearly, this can't be true because any company with more than 640 customers would be making a profit, which everyone knows to be a ridiculous claim. From gert at space.net Thu Apr 1 14:43:22 2010 From: gert at space.net (Gert Doering) Date: Thu, 1 Apr 2010 14:43:22 +0200 Subject: [address-policy-wg] 2010-02 New Policy Proposal (Revoke and Re-assign Fairly) In-Reply-To: <4BB4933A.1020406@inex.ie> References: <4BB4933A.1020406@inex.ie> Message-ID: <20100401124322.GZ69383@Space.Net> Hi, On Thu, Apr 01, 2010 at 01:36:10PM +0100, Nick Hilliard wrote: > Number: 2010-01 > Policy Proposal Name: Revoke and Re-assign Fairly > Author: Nick Hilliard, INEX > Proposal Version: 1.0 > Submission Date: 1 April 2010 > Current Phase: Discussion - Open for Discussion > Phase ends/ended: 1 April 2010 > Latest Status: Initial Community Discussion > Suggested WG for Discussion and Publication: Address Policy > Proposal Type: New > Policy Term: Indefinite > Policy Documents to be Affected: > * IPv4 Address Allocation and Assignment Procedures for the RIPE NCC > Service Region (ripe-492) There was a small editing mistake here, the "Number:" should be 2010-02, and the timelines are a bit shorter than the PDP demands. But besides that, this is obviously address policy related matter, and I've seen worse proposals. So we, the APWG chairs, are now going to conspire in some well-documented and open place with the RIPE NCC, on whether we can accept this as a formal proposal for the address polic working group (if we come to the conclusion that we cannot take it, I'm sure the Secret WG would be happy to have it). Gert Doering -- APWG 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 james.blessing at despres.co.uk Thu Apr 1 14:53:38 2010 From: james.blessing at despres.co.uk (James Blessing) Date: Thu, 01 Apr 2010 13:53:38 +0100 Subject: [address-policy-wg] 2010-02 New Policy Proposal (Revoke and Re-assign Fairly) In-Reply-To: <4BB4933A.1020406@inex.ie> References: <4BB4933A.1020406@inex.ie> Message-ID: <4BB49752.1020207@despres.co.uk> On 01/04/2010 13:36, Nick Hilliard wrote: > Number: 2010-01 > Policy Proposal Name: Revoke and Re-assign Fairly > The RIPE NCC will allocate 640 IPv4 addresses to each LIR, because that > that should be more than enough for anyone. PI assignments requests will > be greeted with even more giggles than they currently are. Why 640, surely an allocation on a bit boundry would be more suitable? The fact that many people get stuck with CIDR addressing I would like to see that the first allocation be made on the /24 boundry. Organisations required a second (or maybe even a third) could always apply for one *after* all the other existing LIRs have completed their requests. J -- James Blessing http://www.despres.co.uk/ 07989 039 476 Superbia in Proelio From jim at rfc1035.com Thu Apr 1 14:54:47 2010 From: jim at rfc1035.com (Jim Reid) Date: Thu, 1 Apr 2010 13:54:47 +0100 Subject: [address-policy-wg] 2010-02 New Policy Proposal (Revoke and Re-assign Fairly) In-Reply-To: <4BB4933A.1020406@inex.ie> References: <4BB4933A.1020406@inex.ie> Message-ID: <034E8880-84FB-4791-99FB-6BCE7D3E11D9@rfc1035.com> Nick, this proposal is far-reaching and deserves the fullest consideration by the WG. I trust there will be plenty of time to discuss it at RIPE60 before it passes to the other RIRs because of its global implications. [Perhaps an ad-hoc study group is needed to thoroughly research this topic?] However I feel implementation of this policy proposal will have to wait until the NCC has been able to support RFC1437. From trejrco at gmail.com Thu Apr 1 15:03:08 2010 From: trejrco at gmail.com (TJ) Date: Thu, 1 Apr 2010 09:03:08 -0400 Subject: [address-policy-wg] 2010-02 New Policy Proposal (Revoke and Re-assign Fairly) In-Reply-To: <034E8880-84FB-4791-99FB-6BCE7D3E11D9@rfc1035.com> References: <4BB4933A.1020406@inex.ie> <034E8880-84FB-4791-99FB-6BCE7D3E11D9@rfc1035.com> Message-ID: Personally, I am STILL waiting for RFC1776 support as well; I find both the 32b and 128b constraints to be unacceptably small for use as address fields. 1696B is far more appropriate ... On Thu, Apr 1, 2010 at 08:54, Jim Reid wrote: > Nick, this proposal is far-reaching and deserves the fullest consideration > by the WG. I trust there will be plenty of time to discuss it at RIPE60 > before it passes to the other RIRs because of its global implications. > [Perhaps an ad-hoc study group is needed to thoroughly research this topic?] > However I feel implementation of this policy proposal will have to wait > until the NCC has been able to support RFC1437. > > -- /TJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ms at man-da.de Thu Apr 1 15:17:32 2010 From: ms at man-da.de (Marcus Stoegbauer) Date: Thu, 01 Apr 2010 15:17:32 +0200 Subject: [address-policy-wg] 2010-02 New Policy Proposal (Revoke and Re-assign Fairly) In-Reply-To: <4BB4933A.1020406@inex.ie> References: <4BB4933A.1020406@inex.ie> Message-ID: <4BB49CEC.5040505@man-da.de> On 01.04.10 14:36, Nick Hilliard wrote: > Number: 2010-01 > Policy Proposal Name: Revoke and Re-assign Fairly > Author: Nick Hilliard, INEX > Proposal Version: 1.0 > Submission Date: 1 April 2010 > Current Phase: Discussion - Open for Discussion > Phase ends/ended: 1 April 2010 > Latest Status: Initial Community Discussion > Suggested WG for Discussion and Publication: Address Policy > Proposal Type: New > Policy Term: Indefinite > Policy Documents to be Affected: > * IPv4 Address Allocation and Assignment Procedures for the RIPE NCC > Service Region (ripe-492) this proposal is typical of the over-regulation in recent RIPE policies and adds unnecessary complexity to the working environment of network operators. Since network operators cannot remember what they had for breakfast or which shoe fits on which foot, let alone numbers larger than 10, revoking all IPv4 allocations and assignments would create confusion and hurting brains at LIRs all over Europe and Japan because network operators would need to learn new numbers. I for one oppose this proposal, especially since IPv4 will never run out now that we have end to end transparent NAT. And now excuse me, I have to attend to my pony and my helmet. Marcus -- man-da.de GmbH, AS8365 Phone: +49 6151 16-6956 Petersenstr. 30 Fax: +49 6151 16-3050 D-64287 Darmstadt e-mail: ms at man-da.de Gesch?ftsf?hrer Marcus St?gbauer AG Darmstadt, HRB 94 84 From jim at rfc1035.com Thu Apr 1 15:31:07 2010 From: jim at rfc1035.com (Jim Reid) Date: Thu, 1 Apr 2010 14:31:07 +0100 Subject: [address-policy-wg] 2010-02 New Policy Proposal (Revoke and Re-assign Fairly) In-Reply-To: <4BB49CEC.5040505@man-da.de> References: <4BB4933A.1020406@inex.ie> <4BB49CEC.5040505@man-da.de> Message-ID: <14579F34-99B8-447E-9C15-2563B7254939@rfc1035.com> On 1 Apr 2010, at 14:17, Marcus Stoegbauer wrote: > Since network operators cannot remember what they had for breakfast or > which shoe fits on which foot, let alone numbers larger than 10, > revoking all IPv4 allocations and assignments would create confusion > and > hurting brains at LIRs all over Europe and Japan because network > operators would need to learn new numbers. Why would that be a problem? There's another thread on this list which suggests there's a need for a policy about allocating easy to remember numbers. This will dovetail rather well with Nick's proposal. From zsako at banknet.net Thu Apr 1 15:08:36 2010 From: zsako at banknet.net (Janos Zsako) Date: Thu, 01 Apr 2010 15:08:36 +0200 Subject: [address-policy-wg] 2010-02 New Policy Proposal (Revoke and Re-assign Fairly) In-Reply-To: <4BB4991B.7040602@3c-hungary.hu> References: <4BB4933A.1020406@inex.ie> <4BB49752.1020207@despres.co.uk> <4BB4991B.7040602@3c-hungary.hu> Message-ID: <4BB49AD4.1050203@banknet.net> James Blessing wrote: >Why 640 I had the same question. But I think I found the answer: 640 = 512+128 = 5*/25 = 5*/(5*5). The magic number 5 is between 4 an 6. It suggests that it is more than IPv4, but it is not IPv6 yet. Janos (sorry for possible duplicates, I first posted from the wrong e-mail address) From zsako at 3c-hungary.hu Thu Apr 1 15:01:15 2010 From: zsako at 3c-hungary.hu (Janos Zsako) Date: Thu, 01 Apr 2010 15:01:15 +0200 Subject: [address-policy-wg] 2010-02 New Policy Proposal (Revoke and Re-assign Fairly) In-Reply-To: <4BB49752.1020207@despres.co.uk> References: <4BB4933A.1020406@inex.ie> <4BB49752.1020207@despres.co.uk> Message-ID: <4BB4991B.7040602@3c-hungary.hu> James Blessing wrote: > Why 640 I had the same question. But I think I found the answer: 640 = 512+128 = 5*/25 = 5*/(5*5). The magic number 5 is between 4 an 6. It suggests that it is more than IPv4, but it is not IPv6 yet. Janos From marc.neuckens at belgacom.be Thu Apr 1 17:01:08 2010 From: marc.neuckens at belgacom.be (marc.neuckens at belgacom.be) Date: Thu, 1 Apr 2010 17:01:08 +0200 Subject: [address-policy-wg] 2010-02 New Policy Proposal (Revoke and Re-assign Fairly) In-Reply-To: <4BB4933A.1020406@inex.ie> References: <4BB4933A.1020406@inex.ie> Message-ID: Nick, all, I'm totally against this new proposal 2010-02. I just checked the release notes of the latest software version of our Firewall vendor. There is no support for subnets of 640 addresses today. Even worse, there is no sign of it in the latest roadmap we received. Another problem I see is that very few IP address management databases support a /22,678 as subnet mask. Marc > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > admin at ripe.net] On Behalf Of Nick Hilliard > Sent: 01 April 2010 14:36 > To: Address Policy Working Group > Subject: [address-policy-wg] 2010-02 New Policy Proposal (Revoke and > Re-assign Fairly) > > Number: 2010-01 > Policy Proposal Name: Revoke and Re-assign Fairly > Author: Nick Hilliard, INEX > Proposal Version: 1.0 > Submission Date: 1 April 2010 > Current Phase: Discussion - Open for Discussion > Phase ends/ended: 1 April 2010 > Latest Status: Initial Community Discussion > Suggested WG for Discussion and Publication: Address Policy > Proposal Type: New > Policy Term: Indefinite > Policy Documents to be Affected: > * IPv4 Address Allocation and Assignment Procedures for the RIPE > NCC > Service Region (ripe-492) > > > Summary of Proposal: > > This proposal revokes all previous IPv4 LIR allocations and direct / > LIR > assignments, returning all ERX and RIPE NCC-assigned IPv4 address space > back to the RIPE NCC, where it can be re-assigned fairly, using new > policies and guidelines. > > The RIPE NCC has been acting as RIR in the European / Middle-East > geographical areas since 1989. Due to egregiously lenient policies and > gross end-user address wastage, in combination with a more recent > tendency > to horde IPv4 addresses in anticipation of a future shortage, recent > research has suggested that approximately 97% of IPv4 address assigned > and > allocated through the RIPE NCC aren't actually used at all, and never > were. > Furthermore, this research suggests that if all this address space > were > returned to the RIR for re-assignment, this would create enough slack > space > in the IPv4 address pool to service all future requests in the RIPE NCC > service region for approximately 100-150 years, based on current actual > run-rate, rather than the current fantasy figures published by the RIPE > NCC. > > Also included as part of this policy is a future restriction to limit > all > future direct assignments to 640 IPv4 address, because that should be > enough for anyone. > > Policy Text: > a. Old text > > Remove sections 5, 6 and 7 in RIPE 492. > > b. New policy text > > Insert new section 5 in RIPE 492: > > -- > 5.0 Policies and Guidelines for Allocations and Assignments > > An allocation is a block of IPv4 addresses from which assignments are > taken. > > All allocations and assignments made prior to April 1, 2010 are hereby > revoked, cancelled, and made null and void. LOL!!11!!!1! > > The RIPE NCC will allocate 640 IPv4 addresses to each LIR, because that > that should be more than enough for anyone. PI assignments requests > will > be greeted with even more giggles than they currently are. > -- > > a. Arguments supporting the proposal > > Every LIR and PI holder is hoarding address space like there's no > tomorrow. > By forcing a reboot of the entire registry system, every holder will > be > equally wrong-footed, and will realise that there's no need to hoarde > address space after all. > > This policy will have the side effect of ensuring that this insane rush > to > IPv6 is entirely unnecessary, proving beyond all doubt that the ITU > seriously has no clue when it comes to Internet resource assignment. > > b. Arguments Opposing the Proposal > > It is likely that nay-sayers and other party-poopers will come out of > the > wood-work to bleat about how this proposal is unfair. The author > advises > that they get a life and stop hoarding numbers. After all, they're > only > numbers. And if they really need more, they can contact me directly > (see > contact details above). > > Some companies will attempt to claim that they have more than 640 > customers. Clearly, this can't be true because any company with more > than > 640 customers would be making a profit, which everyone knows to be a > ridiculous claim. **** DISCLAIMER **** http://www.belgacom.be/maildisclaimer From cagri.yucel at adaptplc.com Thu Apr 1 16:49:57 2010 From: cagri.yucel at adaptplc.com (Cagri Yucel) Date: Thu, 1 Apr 2010 15:49:57 +0100 Subject: [address-policy-wg] 2010-02 New Policy Proposal (Revoke and Re-assign Fairly) In-Reply-To: <4BB4933A.1020406@inex.ie> References: <4BB4933A.1020406@inex.ie> Message-ID: <1B251361BAF6F64F9F299AD16F188F95438414@gbnbshexch01.as24867.intra> May I assume this was an April Fool's Day joke ? If it was not, we are talking about enormous amount of man-hours to renumber every single network in RIPE region. The same amount of time can be spent on IPv6 reconfiguration instead. Cheers, Cagri Yucel Adapt -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Nick Hilliard Sent: 01 April 2010 13:36 To: Address Policy Working Group Subject: [address-policy-wg] 2010-02 New Policy Proposal (Revoke and Re-assign Fairly) Number: 2010-01 Policy Proposal Name: Revoke and Re-assign Fairly Author: Nick Hilliard, INEX Proposal Version: 1.0 Submission Date: 1 April 2010 Current Phase: Discussion - Open for Discussion Phase ends/ended: 1 April 2010 Latest Status: Initial Community Discussion Suggested WG for Discussion and Publication: Address Policy Proposal Type: New Policy Term: Indefinite Policy Documents to be Affected: * IPv4 Address Allocation and Assignment Procedures for the RIPE NCC Service Region (ripe-492) Summary of Proposal: This proposal revokes all previous IPv4 LIR allocations and direct / LIR assignments, returning all ERX and RIPE NCC-assigned IPv4 address space back to the RIPE NCC, where it can be re-assigned fairly, using new policies and guidelines. The RIPE NCC has been acting as RIR in the European / Middle-East geographical areas since 1989. Due to egregiously lenient policies and gross end-user address wastage, in combination with a more recent tendency to horde IPv4 addresses in anticipation of a future shortage, recent research has suggested that approximately 97% of IPv4 address assigned and allocated through the RIPE NCC aren't actually used at all, and never were. Furthermore, this research suggests that if all this address space were returned to the RIR for re-assignment, this would create enough slack space in the IPv4 address pool to service all future requests in the RIPE NCC service region for approximately 100-150 years, based on current actual run-rate, rather than the current fantasy figures published by the RIPE NCC. Also included as part of this policy is a future restriction to limit all future direct assignments to 640 IPv4 address, because that should be enough for anyone. Policy Text: a. Old text Remove sections 5, 6 and 7 in RIPE 492. b. New policy text Insert new section 5 in RIPE 492: -- 5.0 Policies and Guidelines for Allocations and Assignments An allocation is a block of IPv4 addresses from which assignments are taken. All allocations and assignments made prior to April 1, 2010 are hereby revoked, cancelled, and made null and void. LOL!!11!!!1! The RIPE NCC will allocate 640 IPv4 addresses to each LIR, because that that should be more than enough for anyone. PI assignments requests will be greeted with even more giggles than they currently are. -- a. Arguments supporting the proposal Every LIR and PI holder is hoarding address space like there's no tomorrow. By forcing a reboot of the entire registry system, every holder will be equally wrong-footed, and will realise that there's no need to hoarde address space after all. This policy will have the side effect of ensuring that this insane rush to IPv6 is entirely unnecessary, proving beyond all doubt that the ITU seriously has no clue when it comes to Internet resource assignment. b. Arguments Opposing the Proposal It is likely that nay-sayers and other party-poopers will come out of the wood-work to bleat about how this proposal is unfair. The author advises that they get a life and stop hoarding numbers. After all, they're only numbers. And if they really need more, they can contact me directly (see contact details above). Some companies will attempt to claim that they have more than 640 customers. Clearly, this can't be true because any company with more than 640 customers would be making a profit, which everyone knows to be a ridiculous claim. This message has been scanned for viruses by Mail Control - www.adaptplc.com This message has been scanned for viruses by Mail Control - www.adaptplc.com The information in this internet email is confidential and is intended solely for the addressee. If you are not the intended recipient please contact Adapt Group, London, 020 3009 3300. Adapt, Adapt Managed Services and Centric Telecom are all trading names of operating companies wholly owned by Adapt Group Limited (Company No. 05275131) which is registered in England and Wales. Its registered office is 35 New Broad Street, London, EC2M 1NH. From remi.despres at free.fr Thu Apr 1 17:41:45 2010 From: remi.despres at free.fr (=?iso-8859-1?Q?R=E9mi_Despr=E9s?=) Date: Thu, 1 Apr 2010 17:41:45 +0200 Subject: [address-policy-wg] 2010-02 New Policy Proposal (Revoke and Re-assign Fairly) In-Reply-To: <4BB4933A.1020406@inex.ie> References: <4BB4933A.1020406@inex.ie> Message-ID: Full support for maintaining the April Foools' Day tradition ;-). RD Le 1 avr. 2010 ? 14:36, Nick Hilliard a ?crit : > Number: 2010-01 > Policy Proposal Name: Revoke and Re-assign Fairly > Author: Nick Hilliard, INEX > Proposal Version: 1.0 > Submission Date: 1 April 2010 > Current Phase: Discussion - Open for Discussion > Phase ends/ended: 1 April 2010 > Latest Status: Initial Community Discussion > Suggested WG for Discussion and Publication: Address Policy > Proposal Type: New > Policy Term: Indefinite > Policy Documents to be Affected: > * IPv4 Address Allocation and Assignment Procedures for the RIPE NCC > Service Region (ripe-492) > > > Summary of Proposal: > > This proposal revokes all previous IPv4 LIR allocations and direct / LIR > assignments, returning all ERX and RIPE NCC-assigned IPv4 address space > back to the RIPE NCC, where it can be re-assigned fairly, using new > policies and guidelines. > > The RIPE NCC has been acting as RIR in the European / Middle-East > geographical areas since 1989. Due to egregiously lenient policies and > gross end-user address wastage, in combination with a more recent tendency > to horde IPv4 addresses in anticipation of a future shortage, recent > research has suggested that approximately 97% of IPv4 address assigned and > allocated through the RIPE NCC aren't actually used at all, and never were. > Furthermore, this research suggests that if all this address space were > returned to the RIR for re-assignment, this would create enough slack space > in the IPv4 address pool to service all future requests in the RIPE NCC > service region for approximately 100-150 years, based on current actual > run-rate, rather than the current fantasy figures published by the RIPE NCC. > > Also included as part of this policy is a future restriction to limit all > future direct assignments to 640 IPv4 address, because that should be > enough for anyone. > > Policy Text: > a. Old text > > Remove sections 5, 6 and 7 in RIPE 492. > > b. New policy text > > Insert new section 5 in RIPE 492: > > -- > 5.0 Policies and Guidelines for Allocations and Assignments > > An allocation is a block of IPv4 addresses from which assignments are taken. > > All allocations and assignments made prior to April 1, 2010 are hereby > revoked, cancelled, and made null and void. LOL!!11!!!1! > > The RIPE NCC will allocate 640 IPv4 addresses to each LIR, because that > that should be more than enough for anyone. PI assignments requests will > be greeted with even more giggles than they currently are. > -- > > a. Arguments supporting the proposal > > Every LIR and PI holder is hoarding address space like there's no tomorrow. > By forcing a reboot of the entire registry system, every holder will be > equally wrong-footed, and will realise that there's no need to hoarde > address space after all. > > This policy will have the side effect of ensuring that this insane rush to > IPv6 is entirely unnecessary, proving beyond all doubt that the ITU > seriously has no clue when it comes to Internet resource assignment. > > b. Arguments Opposing the Proposal > > It is likely that nay-sayers and other party-poopers will come out of the > wood-work to bleat about how this proposal is unfair. The author advises > that they get a life and stop hoarding numbers. After all, they're only > numbers. And if they really need more, they can contact me directly (see > contact details above). > > Some companies will attempt to claim that they have more than 640 > customers. Clearly, this can't be true because any company with more than > 640 customers would be making a profit, which everyone knows to be a > ridiculous claim. > From marcoh at marcoh.net Thu Apr 1 19:33:51 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 1 Apr 2010 19:33:51 +0200 Subject: [address-policy-wg] 2010-02 New Policy Proposal (Revoke and Re-assign Fairly) In-Reply-To: <4BB4933A.1020406@inex.ie> References: <4BB4933A.1020406@inex.ie> Message-ID: > > The RIPE NCC will allocate 640 IPv4 addresses to each LIR, because that > that should be more than enough for anyone. PI assignments requests will > be greeted with even more giggles than they currently are. Why 640 ? A /32 should be enough for everybody. MarcoH From agv100 at gmail.com Fri Apr 2 13:18:31 2010 From: agv100 at gmail.com (Gennady Abramov) Date: Fri, 2 Apr 2010 15:18:31 +0400 Subject: [address-policy-wg] 2010-02 New Policy Proposal (Revoke and Re-assign Fairly) In-Reply-To: <4BB49752.1020207@despres.co.uk> References: <4BB4933A.1020406@inex.ie> <4BB49752.1020207@despres.co.uk> Message-ID: May be because of some kind of "640kbytes" limitation? On Thu, Apr 1, 2010 at 4:53 PM, James Blessing wrote: > On 01/04/2010 13:36, Nick Hilliard wrote: >> >> Number: ? ? ? ? ? ? ? ? 2010-01 > > Why 640, > J > > -- > > James Blessing > http://www.despres.co.uk/ > 07989 039 476 > Superbia in Proelio > > -- Regards, Gennady Abramov From agv100 at gmail.com Fri Apr 2 13:17:25 2010 From: agv100 at gmail.com (Gennady Abramov) Date: Fri, 2 Apr 2010 15:17:25 +0400 Subject: [address-policy-wg] 2010-02 New Policy Proposal (Revoke and Re-assign Fairly) In-Reply-To: <1B251361BAF6F64F9F299AD16F188F95438414@gbnbshexch01.as24867.intra> References: <4BB4933A.1020406@inex.ie> <1B251361BAF6F64F9F299AD16F188F95438414@gbnbshexch01.as24867.intra> Message-ID: Cagri, On the other hand, "enormous amount of man-hours" makes a lot of work space and job offers for anyone. It may help to fix social problems caused by crisis and by mistakes of different goverments. On Thu, Apr 1, 2010 at 6:49 PM, Cagri Yucel wrote: > May I assume this was an April Fool's Day joke ? > > If it was not, we are talking about enormous amount of man-hours to renumber every single network in RIPE region. The same amount of time can be spent on IPv6 reconfiguration instead. > > Cheers, > > Cagri Yucel > Adapt > > > > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Nick Hilliard > Sent: 01 April 2010 13:36 > To: Address Policy Working Group > Subject: [address-policy-wg] 2010-02 New Policy Proposal (Revoke and Re-assign Fairly) > > Number: ? ? ? ? ? ? ? ? 2010-01 > Policy Proposal Name: ? Revoke and Re-assign Fairly > Author: ? ? ? ? ? ? ? ? Nick Hilliard, INEX > Proposal Version: ? ? ? 1.0 > Submission Date: ? ? ? ?1 April 2010 > Current Phase: ? ? ? ? ?Discussion - Open for Discussion > Phase ends/ended: ? ? ? 1 April 2010 > Latest Status: ? ? ? ? ?Initial Community Discussion > Suggested WG for Discussion and Publication: Address Policy > Proposal Type: ? ? ? ? ?New > Policy Term: ? ? ? ? ? ?Indefinite > Policy Documents to be Affected: > ? ?* IPv4 Address Allocation and Assignment Procedures for the RIPE NCC > Service Region (ripe-492) > > > Summary of Proposal: > > This proposal revokes all previous IPv4 LIR allocations and direct / LIR > assignments, returning all ERX and RIPE NCC-assigned IPv4 address space > back to the RIPE NCC, where it can be re-assigned fairly, using new > policies and guidelines. > > The RIPE NCC has been acting as RIR in the European / Middle-East > geographical areas since 1989. ?Due to egregiously lenient policies and > gross end-user address wastage, in combination with a more recent tendency > to horde IPv4 addresses in anticipation of a future shortage, recent > research has suggested that approximately 97% of IPv4 address assigned and > allocated through the RIPE NCC aren't actually used at all, and never were. > ?Furthermore, this research suggests that if all this address space were > returned to the RIR for re-assignment, this would create enough slack space > in the IPv4 address pool to service all future requests in the RIPE NCC > service region for approximately 100-150 years, based on current actual > run-rate, rather than the current fantasy figures published by the RIPE NCC. > > Also included as part of this policy is a future restriction to limit all > future direct assignments to 640 IPv4 address, because that should be > enough for anyone. > > Policy Text: > a. Old text > > Remove sections 5, 6 and 7 in RIPE 492. > > b. New policy text > > Insert new section 5 in RIPE 492: > > -- > 5.0 Policies and Guidelines for Allocations and Assignments > > An allocation is a block of IPv4 addresses from which assignments are taken. > > All allocations and assignments made prior to April 1, 2010 are hereby > revoked, cancelled, and made null and void. ?LOL!!11!!!1! > > The RIPE NCC will allocate 640 IPv4 addresses to each LIR, because that > that should be more than enough for anyone. ?PI assignments requests will > be greeted with even more giggles than they currently are. > -- > > a. Arguments supporting the proposal > > Every LIR and PI holder is hoarding address space like there's no tomorrow. > ?By forcing a reboot of the entire registry system, every holder will be > equally wrong-footed, and will realise that there's no need to hoarde > address space after all. > > This policy will have the side effect of ensuring that this insane rush to > IPv6 is entirely unnecessary, proving beyond all doubt that the ITU > seriously has no clue when it comes to Internet resource assignment. > > b. Arguments Opposing the Proposal > > It is likely that nay-sayers and other party-poopers will come out of the > wood-work to bleat about how this proposal is unfair. ?The author advises > that they get a life and stop hoarding numbers. ?After all, they're only > numbers. ?And if they really need more, they can contact me directly (see > contact details above). > > Some companies will attempt to claim that they have more than 640 > customers. ?Clearly, this can't be true because any company with more than > 640 customers would be making a profit, which everyone knows to be a > ridiculous claim. > > > > This message has been scanned for viruses by Mail Control - www.adaptplc.com > > > This message has been scanned for viruses by Mail Control - www.adaptplc.com > > The information in this internet email is confidential and is intended solely for the addressee. If you are not the intended recipient please contact Adapt Group, London, 020 3009 3300. > > Adapt, Adapt Managed Services and Centric Telecom are all trading names of operating companies wholly owned by Adapt Group Limited (Company No. 05275131) which is registered in England and Wales. Its registered office is 35 New Broad Street, London, EC2M 1NH. > > -- Regards, Gennady Abramov From goz at idecogateway.com Mon Apr 5 12:46:38 2010 From: goz at idecogateway.com (Sergey Gotsulyak) Date: Mon, 5 Apr 2010 16:46:38 +0600 Subject: [address-policy-wg] Re: Easy to remember IP-address Message-ID: <595279953.20100405164638@idecogateway.com> Shane Kerr wrote: > As for actually getting the RIPE NCC to issue a resource based on a > request... I think there are two ways to go about this. One is making it > a POLICY matter, and going through the PDP and updating the relevant > documents. The other is solving it PROCEDURALLY, which basically means > convincing the RIPE NCC to accept special requests and handle them when > possible. Very interesting idea. If there is a way to solve our issue PROCEDURALLY, that means there's no need to alter the present POLICY. > In summary: > * I support allowing people to request specific unused resources > * I hope that can be done without a policy change In fact we originally hoped to solve our issue in this manner, when we addressed RIPE directly. Do you know of any similar requests in the past? How were they solved? Who can we refer to in RIPE NCC with this request? -- Kind regards, Sergey Gotsulyak Ideco Sales Team 280 Madison Ave, Suite 912 New York, NY 10016 Phone: (800) 715-3502 Email: goz at idecogateway.com Web: www.idecogateway.com From goz at idecogateway.com Mon Apr 5 13:32:58 2010 From: goz at idecogateway.com (Sergey Gotsulyak) Date: Mon, 5 Apr 2010 17:32:58 +0600 Subject: [address-policy-wg] Easy to remember IP-address Message-ID: <19610355679.20100405173258@idecogateway.com> Shane Kerr wrote: > To be clear, we're not talking about anyone getting more or less address > space, or allocating in a way that makes aggregation more difficult. I > thought those were the two basic goals of IP allocation policy, right? > The RIPE NCC does not have any restrictions on which particular > resources it allocates or assigns. In fact, I am pretty sure that any > sensible person would argue that the RIPE NCC should have as much > freedom as possible to do things in the most efficient way. So I think > the RIPE NCC already has the power to issue "vanity addresses" in the > rare case where someone asks for these. As far as we're concerned we're going to follow all the necessary requirements and formalities needed for assignment of a block of IP-addreesses. We're ready to apply throught a standard procedure from the name of our company, or through one of the present LIRs. We could even get a status of a LIR for our company if needed and pay the initial fee and yearly fees. We hope that an assignment of the minimal IP block of addresses 2.2.2.0/24 (or 2.2.2.0/21) will not cause any routing problems, because the availability of this address from any part of the world will be achieved throught BGP Anycast. > Mostly I find it a pity that the NCC wasn't more accommodating and that > we're having this discussion at all. Maybe the software used for this > process does not have a manual override or something? Oh well, compared > to the horror stories I hear about the bad old days, I guess we have no > complaints.... > In the end I suppose we can just let the addresses fall wherever and let > "the market" sort it out, now that there is a "trading" policy. While > the desire for vanity addresses might accelerate the process of IP > addresses becoming property, that is probably inevitable, so it won't > change the big picture too much. -- Kind regards, Sergey Gotsulyak Ideco Sales Team 280 Madison Ave, Suite 912 New York, NY 10016 Phone: (800) 715-3502 Email: goz at idecogateway.com Web: www.idecogateway.com From goz at idecogateway.com Tue Apr 6 08:49:59 2010 From: goz at idecogateway.com (Sergey Gotsulyak) Date: Tue, 6 Apr 2010 12:49:59 +0600 Subject: [address-policy-wg] Re: Easy to remember IP-address Message-ID: <34733737.20100406124959@idecogateway.com> Shane Kerr wrote: > To be clear, we're not talking about anyone getting more or less address > space, or allocating in a way that makes aggregation more difficult. I > thought those were the two basic goals of IP allocation policy, right? > The RIPE NCC does not have any restrictions on which particular > resources it allocates or assigns. In fact, I am pretty sure that any > sensible person would argue that the RIPE NCC should have as much > freedom as possible to do things in the most efficient way. So I think > the RIPE NCC already has the power to issue "vanity addresses" in the > rare case where someone asks for these. As far as we're concerned we're going to follow all the necessary requirements and formalities needed for assignment of a block of IP-addreesses. We're ready to apply throught a standard procedure from the name of our company, or through one of the present LIRs. We could even get a status of a LIR for our company if needed and pay the initial fee and yearly fees. We hope that an assignment of the minimal IP block of addresses 2.2.2.0/24 (or 2.2.2.0/21) will not cause any routing problems, because the availability of this address from any part of the world will be achieved throught BGP Anycast. > Mostly I find it a pity that the NCC wasn't more accommodating and that > we're having this discussion at all. Maybe the software used for this > process does not have a manual override or something? Oh well, compared > to the horror stories I hear about the bad old days, I guess we have no > complaints.... We're trying to figure out if there are any reasons that make an assignment of the requested range technically challenged, but apparently there are any restrictions. According to this experiment of APNIC, described in the RIPE blog: http://labs.ripe.net/content/pollution-18, engineers from the APNIC or RIPE NCC have a certain freemdom in experimenting with undistributed addresses like 1.1.1.1 (2.2.2.2) ? That means that theoretically it is possible to manually enter data in the RIPE database and manually distribute address 2.2.2.2 for it to find a really beneficial application for the internet community, and not just go away to another company that sets up something like DSL-connection pool, because for them vanity addresses are totally irrelevant. I'd like to point it out one more time that we're talking about a very useful and free DNS service for the end-users, that will allow millions of people from Russia and Europe to speed up DNS-requests and filter out untrustful websites like with malware and phishing content... Besides, we hope to provide services for parents preventing children from accessing forbidden websites. This alone will benefit millions of internet users too. -- Kind regards, Sergey Gotsulyak Ideco Sales Team 280 Madison Ave, Suite 912 New York, NY 10016 Phone: (800) 715-3502 Email: goz at idecogateway.com Web: www.idecogateway.com From goz at idecogateway.com Tue Apr 6 10:51:36 2010 From: goz at idecogateway.com (Sergey Gotsulyak) Date: Tue, 6 Apr 2010 14:51:36 +0600 Subject: [address-policy-wg] Re: Easy to remember IP-address Message-ID: <1210371747.20100406145136@idecogateway.com> Jim Reid wrote: > I'm not sure Shane that an allocation of vanity addresses would fit > with these goals. If it does, then fine. Though I'm doubtful. If > there were "too many" vanity assignments, that may well fragment the > unused space in a way that prevents another LIR getting a contiguous > allocation that's big enough for their genuine technical needs. It > might also encourage a land-grab by people gobbling up vanity space > that they don't actually need in the hope that they could sell it on > later. Jim, I fully understand this concern. An overly large number of assignments might fragment the address space and lead to people trying take advantage of an opportunity to resell addresses. Something like Cybersquatting that is practiced with domain names. However I think that the RIPE community is capable of stopping that. That would require formal and very serious requirements for requesting vanity addresses for certain projects that will benefit the people. Honestly, I'm not even sure that there will be so many people interested in getting such ip-addresses if the process is a formal and not a simple one. Besides, we would very much like for our request to be reviewed by the committee from RIPE NCC in a speacial manner. Because we're requesting these addresses not for resale or direct monetary benefit and think that if we're given them all parties are going to win. We're trying to make the internet a safer place for millions of people and improve the present technical infrastructure at the same time by creating a distributed network of available and effective DNS-servers in Russia and Europe. I can't speak for Europe but in Russia and its neighboring countries the existing DNS-structure has a lot of problems such as slow channels and outdated equipment, lack of DNSSEC support and protection from attacks. All this we want to change. -- Kind regards, Sergey Gotsulyak From jim at rfc1035.com Tue Apr 6 12:42:43 2010 From: jim at rfc1035.com (Jim Reid) Date: Tue, 6 Apr 2010 11:42:43 +0100 Subject: [address-policy-wg] Re: Easy to remember IP-address In-Reply-To: <1210371747.20100406145136@idecogateway.com> References: <1210371747.20100406145136@idecogateway.com> Message-ID: <4C27BBFF-1A3F-4E2A-A5FA-19511F5A4BDD@rfc1035.com> On 6 Apr 2010, at 09:51, Sergey Gotsulyak wrote: > We're trying to make the internet a safer > place for millions of people and improve the present technical > infrastructure at the same time by creating a distributed network of > available and effective DNS-servers in Russia and Europe. I can't > speak for Europe but in Russia and its neighboring countries the > existing DNS-structure has a lot of problems such as slow channels > and outdated equipment, lack of DNSSEC support and protection from > attacks. Sergey, these are Noble Things that hopefully everyone can agree on. I wish you well in those efforts. However I simply don't see what that has to do with easily remembered IP addresses or how these could matter to the services you propose to offer. It seems very unlikely these services or their intended customers would care whether they were provided on memorable addresses or not. For some definition of memorable... BTW, your plans for a (global?) DNS service sound interesting. Perhaps you could come along to the DNS WG to discuss your ideas? From nick at inex.ie Tue Apr 6 13:01:44 2010 From: nick at inex.ie (Nick Hilliard) Date: Tue, 06 Apr 2010 12:01:44 +0100 Subject: [address-policy-wg] Re: Easy to remember IP-address In-Reply-To: <34733737.20100406124959@idecogateway.com> References: <34733737.20100406124959@idecogateway.com> Message-ID: <4BBB1498.6000409@inex.ie> On 06/04/2010 07:49, Sergey Gotsulyak wrote: > We're trying to figure out if there are any reasons that make an > assignment of the requested range technically challenged, but > apparently there are any restrictions. According to this experiment > of APNIC, described in the RIPE blog: > > http://labs.ripe.net/content/pollution-18, > > engineers from the APNIC or RIPE NCC have a certain freemdom in > experimenting with undistributed addresses like 1.1.1.1 (2.2.2.2) ? Yes, they need to do this to ensure that the address space which is assigned is generally reachable from a variety of locations on the internet and that it isn't widely filtered in bgp. > That means that theoretically it is possible to manually enter data > in the RIPE database and manually distribute address 2.2.2.2 for it > to find a really beneficial application for the internet community, All RIRs have the ability to choose what address space is assigned from what pool. The question you're asking is whether they would be prepared to single you out for preferential treatment by assigning you address space which has what you perceive to be higher commercial value than arbitrary addresses. I don't think there's any policy which states that the RIPE NCC can't do this. On the other hand, there may be operational reasons why they wouldn't: preferential treatment and assignment of potentially polluted address ranges being two that immediately spring to mind. Nick From jess.kitchen at adjacentnetworks.net Tue Apr 6 14:50:02 2010 From: jess.kitchen at adjacentnetworks.net (Jess Kitchen) Date: Tue, 6 Apr 2010 13:50:02 +0100 (BST) Subject: [address-policy-wg] Re: Easy to remember IP-address In-Reply-To: <4BBB1498.6000409@inex.ie> References: <34733737.20100406124959@idecogateway.com> <4BBB1498.6000409@inex.ie> Message-ID: [snip] > I don't think there's any policy which states that the RIPE NCC can't do > this. On the other hand, there may be operational reasons why they > wouldn't: preferential treatment and assignment of potentially polluted > address ranges being two that immediately spring to mind. For Sergey really, sorry Nick This whole vanity address idea is complete nonsense and shouldn't be entertained for a second. You'll get what you're given allocation-wise, though it's possible you'd be fortunate and get something memorable from the swamp I guess if someone's feeling nice- and then 'normal' space for the rest of your PA As far as I can gather there was cold hard cash exchanging hands for 8.8.8.8 and 4.4.4.4 - fine for some people and in the ARIN region it's a lot more liberal in that sense, but really I should think that RIPE have more pressing matters to deal with instead of trying to find a perhaps nonexistent clause that prevents you from wasting good peoples time It's a bad idea to set a precedent here, surely? From michael.dillon at bt.com Tue Apr 6 15:08:52 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 6 Apr 2010 14:08:52 +0100 Subject: [address-policy-wg] Re: Easy to remember IP-address In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C49745805AF099E@E03MVZ2-UKDY.domain1.systemhost.net> > This whole vanity address idea is complete nonsense and > shouldn't be entertained for a second. In particular, it does not protect you from typographical errors. People can stil type in 22.2.2.2 and 2.2.32.2 and other variations. A far better way to protect against typos is to copy and paste the address. This could be done with any address at all displayed on a web page. If you really want a simple install experience you would do this with a downloadable application. > As far as I can gather there was cold hard cash exchanging hands for > 8.8.8.8 and 4.4.4.4 - fine for some people and in the ARIN > region it's a lot more liberal in that sense, To be clear, nobody paid ARIN for those addresses. They were already allocated to an ISP who agreed to let the DNS provider use them. Ideco's goals could be met by simply using Google's DNS service, unless they have some other goal that they haven't told us yet. --Michael Dillon From james.blessing at despres.co.uk Tue Apr 6 15:16:13 2010 From: james.blessing at despres.co.uk (James Blessing) Date: Tue, 06 Apr 2010 14:16:13 +0100 Subject: [address-policy-wg] Re: Easy to remember IP-address In-Reply-To: References: <34733737.20100406124959@idecogateway.com> <4BBB1498.6000409@inex.ie> Message-ID: <4BBB341D.80303@despres.co.uk> On 06/04/2010 13:50, Jess Kitchen wrote: > As far as I can gather there was cold hard cash exchanging hands for > 8.8.8.8 and 4.4.4.4 - fine for some people and in the ARIN region it's a > lot more liberal in that sense, but really I should think that RIPE have > more pressing matters to deal with instead of trying to find a perhaps > nonexistent clause that prevents you from wasting good peoples time I have no issue with cold hard cash being exchanged for this, as long as the right part of the value chain gets the money and as long as the NCC follow policy when giving addresses (where address are taken from the appropriate pool based on size) to LIRs. How those LIRs then monetise that resource (as long as they also follow policy) is up to them. If Someone really wants 2.2.2.0/24 (or similar) then they need to wait until an LIR is given that address and approach them about buying a suitable service from that LIR that allows them access to that resource. That LIR *MUST* then follow the appropriate procedures and policies and as long as its justified then the allocation can be made. To be honest I can't see that 2.2.2.0/24 is any more attractive than 12.34.45.0/24 or 126.23.4.0/24 you are still going to have to give the details to a person via email or on a website so making the process of finding that information must surely be the most important part of the process. Remember that for DNS it really is a one of change of numbers during the setup of a PC/Device How long does it take to find the really memorable OpenDNS dns addresses with google? J -- James Blessing http://www.despres.co.uk/ 07989 039 476 Superbia in Proelio From jess.kitchen at adjacentnetworks.net Tue Apr 6 15:29:26 2010 From: jess.kitchen at adjacentnetworks.net (Jess Kitchen) Date: Tue, 6 Apr 2010 14:29:26 +0100 (BST) Subject: [address-policy-wg] Re: Easy to remember IP-address In-Reply-To: <28E139F46D45AF49A31950F88C49745805AF099E@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745805AF099E@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: On Tue, 6 Apr 2010, michael.dillon at bt.com wrote: >> As far as I can gather there was cold hard cash exchanging hands for >> 8.8.8.8 and 4.4.4.4 - fine for some people and in the ARIN >> region it's a lot more liberal in that sense, > > To be clear, nobody paid ARIN for those addresses. They were already > allocated to an ISP who agreed to let the DNS provider use them. Sure - but if you were Level(3)/BBN/bla (not sure of specific history off the top of my head) would you do the SWIP or whatever for free, keeping the hole properly defined in filters/registry, etc? And for Google no less? :) From thabet at gmail.com Tue Apr 6 15:11:39 2010 From: thabet at gmail.com (Thabet) Date: Tue, 6 Apr 2010 17:11:39 +0400 Subject: [address-policy-wg] Re: Easy to remember IP-address In-Reply-To: <28E139F46D45AF49A31950F88C49745805AF099E@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745805AF099E@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <98EC54A3-D014-46EE-8BD1-CE60408BD244@gmail.com> I agree Sent from my iPhone On Apr 6, 2010, at 5:08 PM, wrote: >> This whole vanity address idea is complete nonsense and >> shouldn't be entertained for a second. > > In particular, it does not protect you from typographical errors. > People can stil type in 22.2.2.2 and 2.2.32.2 and other variations. > A far better way to protect against typos is to copy and paste > the address. This could be done with any address at all displayed > on a web page. > > If you really want a simple install experience you would do this > with a downloadable application. > >> As far as I can gather there was cold hard cash exchanging hands for >> 8.8.8.8 and 4.4.4.4 - fine for some people and in the ARIN >> region it's a lot more liberal in that sense, > > To be clear, nobody paid ARIN for those addresses. They were already > allocated to an ISP who agreed to let the DNS provider use them. > > Ideco's goals could be met by simply using Google's DNS service, > unless they have some other goal that they haven't told us yet. > > --Michael Dillon > From nihb at wheel.dk Wed Apr 7 12:18:51 2010 From: nihb at wheel.dk (Nina Hjorth Bargisen) Date: Wed, 7 Apr 2010 12:18:51 +0200 Subject: [address-policy-wg] 80% rule, based on feedback from the NCC RS department In-Reply-To: <20100226142807.GB56228@Space.Net> References: <20100226142807.GB56228@Space.Net> Message-ID: <20100407101851.GA2428@freesbee.wheel.dk> On 26.02.2010 15:28:07 +0100, Gert Doering wrote: > Hi APWG, > > one of the issues pointed out by Alex le Heugh from the RIPE NCC RS > department at the last RIPE meeting was the "80% rule" for additional > IPv4 allocations, which has multiple, contradictory definitions in the > current address policy documents. > > See here: > > http://www.ripe.net/ripe/meetings/ripe-59/presentations/leheux-rough-edges-of-policies.pdf > > on page 17-21 > > and http://www.ripe.net/ripe/docs/ripe-484.html, section 5.3 and 5.4 > > > The different sections of the policy text both describe the rule > slightly differently. This makes it unclear how the 80% rule should be > applied. Let me explain by example: > > - a LIR has a /16, which is at 95% utilization, and a /19 that is at 40% > utilization. Over all their address space, the utilization would be 88%. > > - interpretation 1: "if a LIR holds multiple allocations, every *single* > of them needs to be filled by 80%" would result in "the LIR will not get > a new allocation, because the /19 is only at 40%" > > - interpretation 2: "if a LIR holds multiple allocations, the grand total > of them needs to be filled by 80%" would result in "the LIR *will* get > another allocation, because they have used 88%". > > > Personally, I think that the interpretation according to 5.3 of the > IPv4 address policy document ("interpretation 2") is the intention of > the policy. I agree. It may be that some feel that we need to make the policy more strict but I strongly feel that the interpretation 2 is the correct interpretation of the current policy. I think interpretation 1 is stricter than it should be, according to the writing and to what LIR's may reasonably expect when they read the policy and judge whether it is suitable to make a request or not. Rgds Nina Bargisen TDC NET From will at harg.net Wed Apr 7 13:03:11 2010 From: will at harg.net (Will Hargrave) Date: Wed, 07 Apr 2010 12:03:11 +0100 Subject: [address-policy-wg] 80% rule, based on feedback from the NCC RS department In-Reply-To: <20100407101851.GA2428@freesbee.wheel.dk> References: <20100226142807.GB56228@Space.Net> <20100407101851.GA2428@freesbee.wheel.dk> Message-ID: <4BBC666F.1030602@harg.net> On 07/04/10 11:18, Nina Hjorth Bargisen wrote: >> - interpretation 1: "if a LIR holds multiple allocations, every *single* >> of them needs to be filled by 80%" would result in "the LIR will not get >> a new allocation, because the /19 is only at 40%" >> >> - interpretation 2: "if a LIR holds multiple allocations, the grand total >> of them needs to be filled by 80%" would result in "the LIR *will* get >> another allocation, because they have used 88%". >> Personally, I think that the interpretation according to 5.3 of the >> IPv4 address policy document ("interpretation 2") is the intention of >> the policy. > I agree. It may be that some feel that we need to make the policy more > strict but I strongly feel that the interpretation 2 is the correct > interpretation of the current policy. I think interpretation 1 is stricter > than it should be, according to the writing and to what LIR's may > reasonably expect when they read the policy and judge whether it is suitable > to make a request or not. I also agree. "... may receive an additional allocation when about eighty percent of all the address space currently allocated to it... " In this context "address space" is a mass noun (we say 'a /24 of address space') and it only seems sensible to interpret this as an aggregate. The presence of 'all' only reinforces this point. On the separate issue of what the policy should read (as opposed to 'how to interpret it'): The fact is rarely do larger LIRs operate as a single business unit or entity, and so there is greater internal complexity inside the organisation. While some may choose to operate a single large LIR and business structure others operate LIRs on a per-country or per-business unit basis. If we are talking about creating policies to provide address space on an equitable basis it doesn't seem relevant to consider 'one LIR' vs 'lots of LIRs'. In extremis, someone starting 100 LIRs to gain a commercial advantage is clearly not a desirable situation. Will From andy at nosignal.org Wed Apr 7 13:15:11 2010 From: andy at nosignal.org (Andy Davidson) Date: Wed, 7 Apr 2010 12:15:11 +0100 Subject: [address-policy-wg] 80% rule, based on feedback from the NCC RS department In-Reply-To: <20100407101851.GA2428@freesbee.wheel.dk> References: <20100226142807.GB56228@Space.Net> <20100407101851.GA2428@freesbee.wheel.dk> Message-ID: <7BF9AE53-0F93-4DBF-9470-A095655BA561@nosignal.org> On 7 Apr 2010, at 11:18, Nina Hjorth Bargisen wrote: >> - interpretation 2: "if a LIR holds multiple allocations, the grand total >> of them needs to be filled by 80%" would result in "the LIR *will* get >> another allocation, because they have used 88%". >> Personally, I think that the interpretation according to 5.3 of the >> IPv4 address policy document ("interpretation 2") is the intention of >> the policy. > I agree. It may be that some feel that we need to make the policy more > strict but I strongly feel that the interpretation 2 is the correct > interpretation of the current policy. I agree with Gert and Nina. The total number of addresses allocated to an LIR "just feels" like a fairer yardstick than treating the organisation as a series of disconnected islands of addresses, for the purposes of this policy. Thanks Andy, uk.dev From Woeber at CC.UniVie.ac.at Wed Apr 7 14:07:28 2010 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 07 Apr 2010 12:07:28 +0000 Subject: [address-policy-wg] Re: Easy to remember IP-address In-Reply-To: <4C27BBFF-1A3F-4E2A-A5FA-19511F5A4BDD@rfc1035.com> References: <1210371747.20100406145136@idecogateway.com> <4C27BBFF-1A3F-4E2A-A5FA-19511F5A4BDD@rfc1035.com> Message-ID: <4BBC7580.4060006@CC.UniVie.ac.at> Jim Reid wrote: [...] > Sergey, these are Noble Things that hopefully everyone can agree on. I would be very reluctant to do so, after reading: "that will allow millions of people from Russia and Europe to speed up DNS-requests and filter out untrustful websites like with malware and phishing content... Besides, we hope to provide services for parents preventing children from accessing forbidden websites. This alone will benefit millions of internet users too." That rather sounds like a single point of failure or a "red button". In principle, my personal opinion here is OT, too, but I'd like to make the case that it shouldn't be the NCC's business to assess the "value" or "benefit" or "merit" of a particular (planned) service or application. The NCC should never get into the nasty business of vanity numbers, imho! If a need for resources is properly documented, then the applicant gets the next free junk of available resources; according to the NCC's internal and technically and administratively sound procedures. Full stop. Wilfried. From david.freedman at uk.clara.net Wed Apr 7 14:42:31 2010 From: david.freedman at uk.clara.net (David Freedman) Date: Wed, 07 Apr 2010 13:42:31 +0100 Subject: [address-policy-wg] 80% rule, based on feedback from the NCC RS department In-Reply-To: <4BBC666F.1030602@harg.net> References: <20100226142807.GB56228@Space.Net> <20100407101851.GA2428@freesbee.wheel.dk> <4BBC666F.1030602@harg.net> Message-ID: <4BBC7DB7.5050105@uk.clara.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > seem relevant to consider 'one LIR' vs 'lots of LIRs'. In extremis, someone > starting 100 LIRs to gain a commercial advantage is clearly not a desirable > situation. Also agree, but on this paragraph feel I must state that we don't have a good framework to my knowledge which allows multiple LIRs to be considered together for policy purposes (controlled by same entity or not) so have to accept that best we can do here is to apply on a per-LIR basis. Dave. - -- - ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAku8fbcACgkQtFWeqpgEZrJbtgCgyYKGrLxOTON1oQsflae6kk5g j08AnAhKy/bZwpzuWcTzZsPYJtKqoD87 =w9Ov -----END PGP SIGNATURE----- From gert at space.net Mon Apr 12 15:26:21 2010 From: gert at space.net (Gert Doering) Date: Mon, 12 Apr 2010 15:26:21 +0200 Subject: [address-policy-wg] Draft Agenda for upcoming APWG meeting at RIPE 60 Message-ID: <20100412132621.GA16729@Space.Net> Hi APWG folks, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Prague in the following three time slots: Wednesday, May 5, 09:00 - 10:30 Wednesday, May 5, 11:00 - 12:30 Thursday, May 6, 14:00 - 15:30 The exact time lines depend a bit on how much discussion is going on, so we might move items one time slot "up" or "down". If you have anything else you want to see on the agenda, or of we need to change anything, please let us know. regards, Gert Doering, APWG chair ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. Current Policy Topics - Filiz Yilmaz - overview over concluded proposals 2009-03 [run out fairly] - accepted [withdrawn proposals, if any] - common policy topics in all regions (end of IPv4, transfers, ...) C. New Proposals since RIPE 59 -> Discussion of open policy proposals, Part 1 (new proposals) 2010-01 Temporary Internet Number Assignment Policy (Nick Hilliard) ????-?? Global Policy State in RIPE PDP (Dave Wilson) [work in progress, no formal number assigned yet] ????-?? Wording Cleanup regarding 80% rule for PA allocations (Gert Doering) [to be submitted in the next days] ????-?? Allocations from the last /8 (new combined proposal from Philip Smith and Alain Bidron, just presented here, to be discussed on Thursday) [work in progress, formal number to be assigned next week] ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- K. Document Cosmetic Surgeries Project - Filiz Yilmaz - feedback received on the first set of changes - how to go forward? L. "Authorship of RIPE Policy Documents" - Filiz Yilmaz This presentation seeks to reach community agreement on how to document and acknowledge the role of people that propose changes to RIPE Internet Resource Allocation and Assignment policies. M. Ideas how to tackle any problems that have been experienced by the NCC Registration Services Department. (open discussion, based on the report and comments on Wednesday) - try to come up with consensus on what we think "IPv6 PI" should be used for, and should not be used for, and then start a PDP proposal to adjust the policy according to it (if needed) - data-center operators and their customers - the "IPv4 loophole" -> customer access links considered infra (and thus, single-address customers with NAT can be numbered from IPv4 PI, but not from IPv6 PI) ---------------------------------------------------------------------- Thursday, 12:30-14:00 ---------------------------------------------------------------------- T. Discussion of open policy proposals (old proposals) ---- old policy proposals ---- 2006-05 PI Assignment Size 2008-07 Ensuring Efficient Use of Historical IPv4 Resources (Philip Smith) 2008-08 Initial Certification Policy for PA Space Holders (Nigel Titley, CA TF - update what happened since RIPE 59) 2009-01 Global Policy for the allocation of IPv4 blocks to RIRs (5 RIR design team) ---- directly related to IPv4 run-out --- 2008-06 Use of Final /8 (Philip Smith) 2009-04 IPv4 Allocation and Assignments to Facilitate IPv6 Deployment (Alain Bidron) these two proposals will be dropped, and replaced by a new combined proposal: ????-?? Last /8 (new combined proposal from Philip Smith and Alain Bidron) Y. Open Policy Hour "The Open Policy Hour (OPH) is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity." (Idea from ARIN policy meeting) Z. AOB -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From ingrid at ripe.net Tue Apr 13 14:53:04 2010 From: ingrid at ripe.net (Ingrid Wijte) Date: Tue, 13 Apr 2010 14:53:04 +0200 Subject: [address-policy-wg] 2008-06 (Use of final /8) and 2009-04 (IPv4 Allocation and Assignments to Facilitate IPv6 Deployment) Policy Proposals Withdrawn Message-ID: <20100413125304.A03386A002@postboy.ripe.net> PDP Number: 2008-06 Use of final /8 PDP Number: 2009-04 IPv4 Allocation and Assignments to Facilitate IPv6 Deployment Dear Colleagues These proposals have been withdrawn. They are now archived and can be found at: http://www.ripe.net/ripe/policies/proposals/2008-06.html http://www.ripe.net/ripe/policies/proposals/2009-04.html The authors decided that they want to make a new proposal (see proposal 2010-02). Regards Ingrid Wijte Policy Development Officer RIPE NCC From ingrid at ripe.net Tue Apr 13 14:55:30 2010 From: ingrid at ripe.net (Ingrid Wijte) Date: Tue, 13 Apr 2010 14:55:30 +0200 Subject: [address-policy-wg] 2010-02 New Policy Proposal (Allocations from the last /8) Message-ID: <20100413125530.699846A00C@postboy.ripe.net> PDP Number: 2010-02 Allocations from the last /8 Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2010-02.html We encourage you to review this proposal and send your comments to before 11 May 2010. Regards Ingrid Wijte Policy Development Officer RIPE NCC From james.blessing at despres.co.uk Tue Apr 13 15:54:12 2010 From: james.blessing at despres.co.uk (James Blessing) Date: Tue, 13 Apr 2010 14:54:12 +0100 Subject: [address-policy-wg] 2010-02 New Policy Proposal (Allocations from the last /8) In-Reply-To: <20100413125530.699846A00C@postboy.ripe.net> References: <20100413125530.699846A00C@postboy.ripe.net> Message-ID: <4BC47784.9040104@despres.co.uk> On 13/04/2010 13:55, Ingrid Wijte wrote: > PDP Number: 2010-02 Suggest Revised Text, just tweaking no real impact Allocations from the last /8 The distribution of the last /8 held by the RIPE NCC will be done as follows: 1. Unforeseen circumstances pool Once RIPE NCC recieves the final /8 from IANA, a /16 will be held in reserve for some future uses, as yet unforeseen. The Internet is a disruptive technology and we cannot predict what might happen. Therefore it is prudent to keep a /16 in reserve, just in case some future requirement makes a demand of it. 2. Allocations for LIRs from the last /8 On application for IPv4 resources when the RIPE NCC the final /8 has been allocated by IANA to RIPE, LIRs will receive IPv4 addresses according to the following: - LIRs may only receive one allocation from the final /8. The size of the allocation made under this policy will be no larger than a /22. Other space may be provided to the LIR should additional space outside of the final /8 be available at the point of the request. - LIRs may apply for and receive this allocation once they meet the criteria to receive IPv4 address space according to the allocation policy in effect in the RIPE NCC service region at the time of application. - Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC. 3. Final Exhaustion In the event that the unforeseen circumstances pool /16 remains unused in the time the final /8 covered by this policy has been distributed, a /15 will be returned to the main pool to be distributed as per clause 2. Once this /15 has been used then the final /15 will also be returned to the pool s should an unforeseen usage have not been found. J -- James Blessing http://www.despres.co.uk/ 07989 039 476 Superbia in Proelio From nigel at titley.com Tue Apr 13 15:31:20 2010 From: nigel at titley.com (Nigel Titley) Date: Tue, 13 Apr 2010 14:31:20 +0100 Subject: [address-policy-wg] Policy proposal 2009-01 Message-ID: <1271165480.3392.82.camel@ntitley-laptop> Folks, As one of the authors of this proposal I'd like to get some sort of consensus together in the RIPE region so that we can move forward. All other regions have reached consensus and we are the last to do so. All other regions with the exception of Arin have adopted the policy in it's original form. Arin has modified the policy to remove the mandatory return of recovered address space to IANA, which effectively makes it a different policy. 2009-01 is a global policy which means that the same policy has to be agreed in all regions, so to all practical purposes it is doomed already. However, we still need to decide what to do with it in the RIPE region. To my mind there are four possibilities: 1. We adopt it in its original form thus demonstrating solidarity with the other regions, apart from Arin. 2. We adopt the Arin form of the proposal, thus demonstrating solidarity with Arin, but with no one else 3. We reject the proposal outright, thus demonstrating that we can't make up our minds or that we think it will never work, or something... 4. We ask the regional authors (in this case myself and Axel) to withdraw the proposal in this region. Some background may be helpful here. No one seriously expected that any address space would actually be returned as a result of this policy. It was intended as a statement that should IPv4 address space become available then it would be used for the greater good of all the registries rather than those who had already had the majority of the space already. I realise that this was a rather pious hope, but we felt that it was worth making a statement about. The Arin region's position has made it impossible to make this statement globally, but we still have the opportunity to make it here. I would like to solicit the opinions of this working group in order to try and put the matter to bed once and for all. I realise I'm making rather contentious statements here, but I'm hoping to provoke a bit of discussion. Please can the working group indicate how they would like to move this forward. All the best Nigel From rhe at nosc.ja.net Tue Apr 13 20:12:51 2010 From: rhe at nosc.ja.net (Rob Evans) Date: Tue, 13 Apr 2010 19:12:51 +0100 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: <1271165480.3392.82.camel@ntitley-laptop> References: <1271165480.3392.82.camel@ntitley-laptop> Message-ID: <4BC4B423.3060107@nosc.ja.net> As an old fogey with somewhat nostalgic views on how things work... > 1. We adopt it in its original form thus demonstrating solidarity with > the other regions, apart from Arin. ...I suggest we do this. It took me a while to come around to this view because I wasn't entirely sure that 'demonstrating solidarity' was the right phrase to use, but on reflection it is spot on. Withdrawing or rejecting the policy puts us in the same position as ARIN -- we can claim space from the mythical returned pool, but don't have to return any for the common good ourselves, whereas AfriNIC, LACNIC and APNIC, having passed their versions of the policy, do have to do that. What is really needed is a lock on global policies until they are approved by all the RIRs, and I note from the APWG agenda for Prague there is an enticing item (well, I find it interesting) called "????-?? Global Policy State in RIPE PDP (Dave Wilson)." In the meantime, we work with what we have, and I support 2009-1. I look forward to hearing other opinions. :) Best regards, Rob -- Rob Evans JANET(UK) Development Team Twitter: https://twitter.com/JANETDev/team Work tweets: https://twitter.com/internetplumber JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From randy at psg.com Wed Apr 14 00:40:34 2010 From: randy at psg.com (Randy Bush) Date: Wed, 14 Apr 2010 07:40:34 +0900 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: <4BC4B423.3060107@nosc.ja.net> References: <1271165480.3392.82.camel@ntitley-laptop> <4BC4B423.3060107@nosc.ja.net> Message-ID: > As an old fogey with somewhat nostalgic views on how things work... > >> 1. We adopt it in its original form thus demonstrating solidarity with >> the other regions, apart from Arin. > > ...I suggest we do this. It took me a while to come around to this view > because I wasn't entirely sure that 'demonstrating solidarity' was the > right phrase to use, but on reflection it is spot on. > > Withdrawing or rejecting the policy puts us in the same position as ARIN > -- we can claim space from the mythical returned pool, but don't have to > return any for the common good ourselves, whereas AfriNIC, LACNIC and > APNIC, having passed their versions of the policy, do have to do that. arin's position would be embarrassing to them if they had a sense of social responsibility. randy From axel.pawlik at ripe.net Wed Apr 14 08:25:56 2010 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Wed, 14 Apr 2010 08:25:56 +0200 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: <1271165480.3392.82.camel@ntitley-laptop> References: <1271165480.3392.82.camel@ntitley-laptop> Message-ID: <4BC55FF4.2020007@ripe.net> Thank you Nigel for kicking this off. > 1. We adopt it in its original form thus demonstrating solidarity with > the other regions, apart from Arin. > > 2. We adopt the Arin form of the proposal, thus demonstrating solidarity > with Arin, but with no one else > > 3. We reject the proposal outright, thus demonstrating that we can't > make up our minds or that we think it will never work, or something... > > 4. We ask the regional authors (in this case myself and Axel) to > withdraw the proposal in this region. Speaking as one of the original authors, I would support going through with the original proposal. The requirement to return space was essential to the idea behind the policy draft in the first place. Taking this requirement out renders the policy pointless. I don't want to load the discussion with notions of "solidarity", but rather focus on the utility of policies. Which in my view has disappeared from the ARIN policy text. cheers, Axel From cfriacas at fccn.pt Wed Apr 14 09:18:33 2010 From: cfriacas at fccn.pt (Carlos Friacas) Date: Wed, 14 Apr 2010 08:18:33 +0100 (WEST) Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: <1271165480.3392.82.camel@ntitley-laptop> References: <1271165480.3392.82.camel@ntitley-laptop> Message-ID: Hello, Going forward with (1.) means that potentially recovered space within RIPE-land can end up in the hands of someone inside ARIN-land ??? Imho, those who wish not to contribute should not have access to the recovered resources. Solidarity (even if it's about a legacy resource...) sounds like a positive thing, however, if it's possible for non-contributors to benefit, another word comes to mind. And in that case i would be in favour of (3.) or (4.). Regards, Carlos On Tue, 13 Apr 2010, Nigel Titley wrote: > Folks, > > As one of the authors of this proposal I'd like to get some sort of > consensus together in the RIPE region so that we can move forward. > > All other regions have reached consensus and we are the last to do so. > > All other regions with the exception of Arin have adopted the policy in > it's original form. Arin has modified the policy to remove the mandatory > return of recovered address space to IANA, which effectively makes it a > different policy. 2009-01 is a global policy which means that the same > policy has to be agreed in all regions, so to all practical purposes it > is doomed already. However, we still need to decide what to do with it > in the RIPE region. To my mind there are four possibilities: > > 1. We adopt it in its original form thus demonstrating solidarity with > the other regions, apart from Arin. > > 2. We adopt the Arin form of the proposal, thus demonstrating solidarity > with Arin, but with no one else > > 3. We reject the proposal outright, thus demonstrating that we can't > make up our minds or that we think it will never work, or something... > > 4. We ask the regional authors (in this case myself and Axel) to > withdraw the proposal in this region. > > Some background may be helpful here. No one seriously expected that any > address space would actually be returned as a result of this policy. It > was intended as a statement that should IPv4 address space become > available then it would be used for the greater good of all the > registries rather than those who had already had the majority of the > space already. I realise that this was a rather pious hope, but we felt > that it was worth making a statement about. > > The Arin region's position has made it impossible to make this statement > globally, but we still have the opportunity to make it here. I would > like to solicit the opinions of this working group in order to try and > put the matter to bed once and for all. > > I realise I'm making rather contentious statements here, but I'm hoping > to provoke a bit of discussion. Please can the working group indicate > how they would like to move this forward. > > All the best > > Nigel > > From bmanning at vacation.karoshi.com Wed Apr 14 09:48:14 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 14 Apr 2010 07:48:14 +0000 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: References: <1271165480.3392.82.camel@ntitley-laptop> Message-ID: <20100414074814.GA30413@vacation.karoshi.com.> I believe you are correct Carlos. (1.) would potentially move legacy IPv4 resource into the ARIN region from everywhere else in the world. (*) * Except some places which have their own legal restrictions on movement of IP space outside thier politicial boundaries. When I was on the ARIN BoT, I seem to remember a few countries which placed such laws on their respective books. It was generally considered to be a bad idea ... and yet ARIN seems to have followed suit. --bill On Wed, Apr 14, 2010 at 08:18:33AM +0100, Carlos Friacas wrote: > > Hello, > > Going forward with (1.) means that potentially recovered space within > RIPE-land can end up in the hands of someone inside ARIN-land ??? > > Imho, those who wish not to contribute should not have access to the > recovered resources. Solidarity (even if it's about a legacy resource...) > sounds like a positive thing, however, if it's possible for > non-contributors to benefit, another word comes to mind. And in that case > i would be in favour of (3.) or (4.). > > > Regards, > Carlos > > > On Tue, 13 Apr 2010, Nigel Titley wrote: > > >Folks, > > > >As one of the authors of this proposal I'd like to get some sort of > >consensus together in the RIPE region so that we can move forward. > > > >All other regions have reached consensus and we are the last to do so. > > > >All other regions with the exception of Arin have adopted the policy in > >it's original form. Arin has modified the policy to remove the mandatory > >return of recovered address space to IANA, which effectively makes it a > >different policy. 2009-01 is a global policy which means that the same > >policy has to be agreed in all regions, so to all practical purposes it > >is doomed already. However, we still need to decide what to do with it > >in the RIPE region. To my mind there are four possibilities: > > > >1. We adopt it in its original form thus demonstrating solidarity with > >the other regions, apart from Arin. > > > >2. We adopt the Arin form of the proposal, thus demonstrating solidarity > >with Arin, but with no one else > > > >3. We reject the proposal outright, thus demonstrating that we can't > >make up our minds or that we think it will never work, or something... > > > >4. We ask the regional authors (in this case myself and Axel) to > >withdraw the proposal in this region. > > > >Some background may be helpful here. No one seriously expected that any > >address space would actually be returned as a result of this policy. It > >was intended as a statement that should IPv4 address space become > >available then it would be used for the greater good of all the > >registries rather than those who had already had the majority of the > >space already. I realise that this was a rather pious hope, but we felt > >that it was worth making a statement about. > > > >The Arin region's position has made it impossible to make this statement > >globally, but we still have the opportunity to make it here. I would > >like to solicit the opinions of this working group in order to try and > >put the matter to bed once and for all. > > > >I realise I'm making rather contentious statements here, but I'm hoping > >to provoke a bit of discussion. Please can the working group indicate > >how they would like to move this forward. > > > >All the best > > > >Nigel > > > > From axel.pawlik at ripe.net Wed Apr 14 11:07:44 2010 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Wed, 14 Apr 2010 11:07:44 +0200 Subject: Fwd: Re: [address-policy-wg] Policy proposal 2009-01 Message-ID: <4BC585E0.4000900@ripe.net> On 14/04/2010 09:48, bmanning at vacation.karoshi.com wrote: > I believe you are correct Carlos. (1.) would potentially move > legacy IPv4 resource into the ARIN region from everywhere else > in the world. (*) Just a clarification... As this is a global policy proposal, all RIR regions would have to be in agreement for it to be implemented. In that case, yes, resources returned to IANA would later be re-allocated, possibly to other regions than they came from. As things stand today, with the ARIN community having agreed on a different text than the other RIRs' communities, this proposal fails as a global policy; which means that it will not be implemented. cheers, Axel > > * Except some places which have their own legal restrictions on > movement of IP space outside thier politicial boundaries. When > I was on the ARIN BoT, I seem to remember a few countries which > placed such laws on their respective books. It was generally > considered to be a bad idea ... and yet ARIN seems to have > followed suit. > > --bill > > > On Wed, Apr 14, 2010 at 08:18:33AM +0100, Carlos Friacas wrote: >> >> Hello, >> >> Going forward with (1.) means that potentially recovered space within >> RIPE-land can end up in the hands of someone inside ARIN-land ??? >> >> Imho, those who wish not to contribute should not have access to the >> recovered resources. Solidarity (even if it's about a legacy resource...) >> sounds like a positive thing, however, if it's possible for >> non-contributors to benefit, another word comes to mind. And in that case >> i would be in favour of (3.) or (4.). >> >> >> Regards, >> Carlos >> >> >> On Tue, 13 Apr 2010, Nigel Titley wrote: >> >>> Folks, >>> >>> As one of the authors of this proposal I'd like to get some sort of >>> consensus together in the RIPE region so that we can move forward. >>> >>> All other regions have reached consensus and we are the last to do so. >>> >>> All other regions with the exception of Arin have adopted the policy in >>> it's original form. Arin has modified the policy to remove the mandatory >>> return of recovered address space to IANA, which effectively makes it a >>> different policy. 2009-01 is a global policy which means that the same >>> policy has to be agreed in all regions, so to all practical purposes it >>> is doomed already. However, we still need to decide what to do with it >>> in the RIPE region. To my mind there are four possibilities: >>> >>> 1. We adopt it in its original form thus demonstrating solidarity with >>> the other regions, apart from Arin. >>> >>> 2. We adopt the Arin form of the proposal, thus demonstrating solidarity >>> with Arin, but with no one else >>> >>> 3. We reject the proposal outright, thus demonstrating that we can't >>> make up our minds or that we think it will never work, or something... >>> >>> 4. We ask the regional authors (in this case myself and Axel) to >>> withdraw the proposal in this region. >>> >>> Some background may be helpful here. No one seriously expected that any >>> address space would actually be returned as a result of this policy. It >>> was intended as a statement that should IPv4 address space become >>> available then it would be used for the greater good of all the >>> registries rather than those who had already had the majority of the >>> space already. I realise that this was a rather pious hope, but we felt >>> that it was worth making a statement about. >>> >>> The Arin region's position has made it impossible to make this statement >>> globally, but we still have the opportunity to make it here. I would >>> like to solicit the opinions of this working group in order to try and >>> put the matter to bed once and for all. >>> >>> I realise I'm making rather contentious statements here, but I'm hoping >>> to provoke a bit of discussion. Please can the working group indicate >>> how they would like to move this forward. >>> >>> All the best >>> >>> Nigel >>> >>> > > From nigel at titley.com Wed Apr 14 11:12:30 2010 From: nigel at titley.com (Nigel Titley) Date: Wed, 14 Apr 2010 10:12:30 +0100 Subject: Fwd: Re: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: <4BC585E0.4000900@ripe.net> References: <4BC585E0.4000900@ripe.net> Message-ID: <1271236350.3392.242.camel@ntitley-laptop> On Wed, 2010-04-14 at 11:07 +0200, Axel Pawlik wrote: > On 14/04/2010 09:48, bmanning at vacation.karoshi.com wrote: > > I believe you are correct Carlos. (1.) would potentially move > > legacy IPv4 resource into the ARIN region from everywhere else > > in the world. (*) > > Just a clarification... > > As this is a global policy proposal, all RIR regions would have to > be in agreement for it to be implemented. In that case, yes, resources > returned to IANA would later be re-allocated, possibly to other > regions than they came from. But at least in an even handed way. > As things stand today, with the ARIN community having agreed > on a different text than the other RIRs' communities, this proposal > fails as a global policy; which means that it will not be implemented. Yes, I think I made this point clear in my original email. The policy, as a global policy, is doomed anyway. What I am trying to ascertain is how we tidy up the chairs and put the lights out in the RIPE region. Nigel From nick at inex.ie Wed Apr 14 11:13:59 2010 From: nick at inex.ie (Nick Hilliard) Date: Wed, 14 Apr 2010 10:13:59 +0100 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: <1271165480.3392.82.camel@ntitley-laptop> References: <1271165480.3392.82.camel@ntitley-laptop> Message-ID: <4BC58757.7010100@inex.ie> On 13/04/2010 14:31, Nigel Titley wrote: > 1. We adopt it in its original form thus demonstrating solidarity with > the other regions, apart from Arin. > > 2. We adopt the Arin form of the proposal, thus demonstrating solidarity > with Arin, but with no one else > > 3. We reject the proposal outright, thus demonstrating that we can't > make up our minds or that we think it will never work, or something... > > 4. We ask the regional authors (in this case myself and Axel) to > withdraw the proposal in this region. There are two other options. 5. We adopt the proposal but make its commencement dependent on all other RIRs adopting it. or: 6. We adopt a slightly modified form of the proposal, which would allow RIPE to return address space to IANA with a proviso that this address space was returned on the basis that it may only be re-assigned to other RIRs who have adopted mandatory address space return. Nick From cfriacas at fccn.pt Wed Apr 14 11:27:19 2010 From: cfriacas at fccn.pt (Carlos Friacas) Date: Wed, 14 Apr 2010 10:27:19 +0100 (WEST) Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: <4BC58757.7010100@inex.ie> References: <1271165480.3392.82.camel@ntitley-laptop> <4BC58757.7010100@inex.ie> Message-ID: On Wed, 14 Apr 2010, Nick Hilliard wrote: > On 13/04/2010 14:31, Nigel Titley wrote: >> 1. We adopt it in its original form thus demonstrating solidarity with >> the other regions, apart from Arin. >> >> 2. We adopt the Arin form of the proposal, thus demonstrating solidarity >> with Arin, but with no one else >> >> 3. We reject the proposal outright, thus demonstrating that we can't >> make up our minds or that we think it will never work, or something... >> >> 4. We ask the regional authors (in this case myself and Axel) to >> withdraw the proposal in this region. > > There are two other options. > > 5. We adopt the proposal but make its commencement dependent on all other > RIRs adopting it. > > or: > > 6. We adopt a slightly modified form of the proposal, which would allow > RIPE to return address space to IANA with a proviso that this address space > was returned on the basis that it may only be re-assigned to other RIRs who > have adopted mandatory address space return. I tend to like this one... however, AFRINIC, LACNIC and APNIC would probably need to ammend their already aproved policy on this subject too... Regards, Carlos > Nick > From nigel at titley.com Wed Apr 14 11:53:41 2010 From: nigel at titley.com (Nigel Titley) Date: Wed, 14 Apr 2010 10:53:41 +0100 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: References: <1271165480.3392.82.camel@ntitley-laptop> <4BC58757.7010100@inex.ie> Message-ID: <1271238821.3392.267.camel@ntitley-laptop> On Wed, 2010-04-14 at 10:27 +0100, Carlos Friacas wrote: > > 6. We adopt a slightly modified form of the proposal, which would allow > > RIPE to return address space to IANA with a proviso that this address space > > was returned on the basis that it may only be re-assigned to other RIRs who > > have adopted mandatory address space return. > > I tend to like this one... however, AFRINIC, LACNIC and APNIC would > probably need to ammend their already aproved policy on this subject > too... Yes, adoption of a modified form of the proposal just bangs another nail into the coffin. Can I reiterate? This proposal is dead. I'm just trying to make the funeral arrangements and give it a decent burial before people start to wrinkle their noses and remark how stuffy it's getting. Nigel From sander at steffann.nl Wed Apr 14 11:23:34 2010 From: sander at steffann.nl (Sander Steffann) Date: Wed, 14 Apr 2010 11:23:34 +0200 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: <4BC58757.7010100@inex.ie> References: <1271165480.3392.82.camel@ntitley-laptop> <4BC58757.7010100@inex.ie> Message-ID: <94596D5A-8D33-457C-8DB7-F8C41560B322@steffann.nl> Hi Nick, > 5. We adopt the proposal but make its commencement dependent on all other > RIRs adopting it. Because this is a Global Policy that is already the case. Even if we declare consensus on the original version it would only be implemented if/when ARIN also accepts the original version. - Sander From alain.bidron at orange-ftgroup.com Wed Apr 14 11:59:07 2010 From: alain.bidron at orange-ftgroup.com (alain.bidron at orange-ftgroup.com) Date: Wed, 14 Apr 2010 11:59:07 +0200 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: <1271165480.3392.82.camel@ntitley-laptop> References: <1271165480.3392.82.camel@ntitley-laptop> Message-ID: <2373_1271239149_4BC591ED_2373_6942_1_7358953E06B3044F81495D7AE8F6F6B7495EF1C908@PMEXCB1A.intranet-paris.francetelecom.fr> With the understanding that this is a global policy that has to be approved in the same terms by all regions and have after that a public consultation period at ICANN level before final approval by the ICANN Board, I would strongly support the option 1. Given the fact that a significant part of legacy resources are in the ARIN region, the option where we could allow the RIPE-NCC to return address space to IANA with re-assignment being only be possible to other RIRS having adopted the mandatory address space return process could very well be accepted by ARIN, but doesn't address the issue in a fair way. In my view all RIRs should participate the same way in the process or none of them, and if one RIR community do not accept to be part of of process it should be clearly publicised to the global community and stakeholders. I also suggest that this issue which is a global issue is addressed publicly during the next ICANN meeting in Brussels in an open information Session of the ASO. Alain Alain Bidron FT/PRESIDENCE/NCPI/NAD/EAS/NAN Head of Naming Addressing Numbering Unit tel. + 33 1 57 36 17 24 mob. + 33 6 87 65 90 94 alain.bidron at orange-ftgroup.com -----Message d'origine----- De : address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] De la part de Nigel Titley Envoy? : mardi 13 avril 2010 15:31 ? : address-policy-wg at ripe.net Objet : [address-policy-wg] Policy proposal 2009-01 Folks, As one of the authors of this proposal I'd like to get some sort of consensus together in the RIPE region so that we can move forward. All other regions have reached consensus and we are the last to do so. All other regions with the exception of Arin have adopted the policy in it's original form. Arin has modified the policy to remove the mandatory return of recovered address space to IANA, which effectively makes it a different policy. 2009-01 is a global policy which means that the same policy has to be agreed in all regions, so to all practical purposes it is doomed already. However, we still need to decide what to do with it in the RIPE region. To my mind there are four possibilities: 1. We adopt it in its original form thus demonstrating solidarity with the other regions, apart from Arin. 2. We adopt the Arin form of the proposal, thus demonstrating solidarity with Arin, but with no one else 3. We reject the proposal outright, thus demonstrating that we can't make up our minds or that we think it will never work, or something... 4. We ask the regional authors (in this case myself and Axel) to withdraw the proposal in this region. Some background may be helpful here. No one seriously expected that any address space would actually be returned as a result of this policy. It was intended as a statement that should IPv4 address space become available then it would be used for the greater good of all the registries rather than those who had already had the majority of the space already. I realise that this was a rather pious hope, but we felt that it was worth making a statement about. The Arin region's position has made it impossible to make this statement globally, but we still have the opportunity to make it here. I would like to solicit the opinions of this working group in order to try and put the matter to bed once and for all. I realise I'm making rather contentious statements here, but I'm hoping to provoke a bit of discussion. Please can the working group indicate how they would like to move this forward. All the best Nigel ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ******************************** From jim at rfc1035.com Wed Apr 14 12:26:00 2010 From: jim at rfc1035.com (Jim Reid) Date: Wed, 14 Apr 2010 11:26:00 +0100 Subject: [address-policy-wg] The emacs, X windows and Linux approach to policy making In-Reply-To: <4BC58757.7010100@inex.ie> References: <1271165480.3392.82.camel@ntitley-laptop> <4BC58757.7010100@inex.ie> Message-ID: <87D9EC06-A5B7-48F6-BDD7-23A3466F2AA5@rfc1035.com> It's tempting to consider tweaking our policy for the IPv4 dregs to show our displeasure at the path ARIN has adopted. However I hope we can rise above that. I'm also beginning to wonder if policy-making is being unconsciously shaped by the Linux/emacs/X-windows approach to software design. If that can be called "design". [The only thing wrong with these bits of code is they don't have enough options or configuration variables to tweak. :-)] I would like to see fewer options on what to do about 2009-01. Ideally it should be reduced to a binary choice. With that in mind and Nigel's comments that the proposal is dead and starting to have a bad smell, I suggest we reduce the discussion of 2009-01 to a simple choice of whether to withdraw it or not. IMO, withdrawing this proposal makes the most sense. Continuing with it would only be worthwhile if the same approach to recovered space was being followed by the other RIRs. Since that's no longer possible, I think we should just stop flogging this dead horse. If there's support for keeping 2009-01 alive, I'd like to suggest we focus the discussion to a choice between two mutually exclusive positions: 1) recovered space goes back to IANA for it to redistribute somehow 2) recovered space stays with the NCC for redistribution according to RIPE policy From nigel at titley.com Wed Apr 14 12:40:02 2010 From: nigel at titley.com (Nigel Titley) Date: Wed, 14 Apr 2010 11:40:02 +0100 Subject: [address-policy-wg] Re: The emacs, X windows and Linux approach to policy making In-Reply-To: <87D9EC06-A5B7-48F6-BDD7-23A3466F2AA5@rfc1035.com> References: <1271165480.3392.82.camel@ntitley-laptop> <4BC58757.7010100@inex.ie> <87D9EC06-A5B7-48F6-BDD7-23A3466F2AA5@rfc1035.com> Message-ID: <1271241602.3392.293.camel@ntitley-laptop> On Wed, 2010-04-14 at 11:26 +0100, Jim Reid wrote: > It's tempting to consider tweaking our policy for the IPv4 dregs to > show our displeasure at the path ARIN has adopted. However I hope we > can rise above that. We would not be tweaking the policy to show displeasure. Option 1 (which "shows displeasure with ARIN") is actually the original proposal. Option 2 which doesn't, tweaks the policy. Sorry to be pedantic. > I'm also beginning to wonder if policy-making is being unconsciously > shaped by the Linux/emacs/X-windows approach to software design. If > that can be called "design". [The only thing wrong with these bits of > code is they don't have enough options or configuration variables to > tweak. :-)] I would like to see fewer options on what to do about > 2009-01. Ideally it should be reduced to a binary choice. I'm happy with that. > With that in mind and Nigel's comments that the proposal is dead and > starting to have a bad smell, I suggest we reduce the discussion of > 2009-01 to a simple choice of whether to withdraw it or not. In my original terms we decide either to adopt option #1 (go with the existing proposal) or option #4. I'm very happy with offering just these choices. > IMO, withdrawing this proposal makes the most sense. Continuing with > it would only be worthwhile if the same approach to recovered space > was being followed by the other RIRs. Since that's no longer possible, > I think we should just stop flogging this dead horse. This is a fair point... and I'm happy to accept it if the community decides this is the consensus position. > If there's support for keeping 2009-01 alive, I'd like to suggest we > focus the discussion to a choice between two mutually exclusive > positions: > > 1) recovered space goes back to IANA for it to redistribute somehow This is 2009-01 in essence. > 2) recovered space stays with the NCC for redistribution according to > RIPE policy This is a new policy and outside scope for the present discussion. Nigel From michael.dillon at bt.com Wed Apr 14 12:40:24 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 14 Apr 2010 11:40:24 +0100 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: <4BC585E0.4000900@ripe.net> Message-ID: <28E139F46D45AF49A31950F88C49745805C3F2E8@E03MVZ2-UKDY.domain1.systemhost.net> > As things stand today, with the ARIN community having agreed > on a different text than the other RIRs' communities, this > proposal fails as a global policy; which means that it will > not be implemented. Unless ARIN changes their mind. If RIPE accepts this policy text, then RIPE is no longer blocking it as a global policy. Whether ARIN will respond to that situation or not, is unknown. --Michael Dillon From michael.dillon at bt.com Wed Apr 14 12:42:17 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 14 Apr 2010 11:42:17 +0100 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C49745805C3F2EC@E03MVZ2-UKDY.domain1.systemhost.net> > > 6. We adopt a slightly modified form of the proposal, which would > > allow RIPE to return address space to IANA with a proviso that this > > address space was returned on the basis that it may only be > > re-assigned to other RIRs who have adopted mandatory > address space return. > > I tend to like this one... however, AFRINIC, LACNIC and APNIC > would probably need to ammend their already aproved policy on > this subject too... If it turns out that ARIN does not change their mind, and this policy has some negative effects in that scenario, then RIPE can always rescind the policy at any future time. --Michael Dillon From nigel at titley.com Wed Apr 14 12:49:11 2010 From: nigel at titley.com (Nigel Titley) Date: Wed, 14 Apr 2010 11:49:11 +0100 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: <28E139F46D45AF49A31950F88C49745805C3F2E8@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745805C3F2E8@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <1271242151.3392.299.camel@ntitley-laptop> On Wed, 2010-04-14 at 11:40 +0100, michael.dillon at bt.com wrote: > If RIPE accepts this policy text, then RIPE is no longer > blocking it as a global policy. Whether ARIN will respond > to that situation or not, is unknown. You have a good point there. Perhaps the corpse can be reanimated. Nigel From michael.dillon at bt.com Wed Apr 14 12:49:43 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 14 Apr 2010 11:49:43 +0100 Subject: [address-policy-wg] The emacs, X windows and Linux approach to policy making In-Reply-To: <87D9EC06-A5B7-48F6-BDD7-23A3466F2AA5@rfc1035.com> Message-ID: <28E139F46D45AF49A31950F88C49745805C3F311@E03MVZ2-UKDY.domain1.systemhost.net> > IMO, withdrawing this proposal makes the most sense. > Continuing with it would only be worthwhile if the same > approach to recovered space was being followed by the other > RIRs. Since that's no longer possible, I think we should just > stop flogging this dead horse. A global policy was proposed. Three RIRs accepted it. ARIN did not and proposed a different text. Now it is RIPE's turn. Do we accept ARIN's bid, and approve the same text as ARIN, or do we accept the same text as the other 3 RIRS, or do we reject the global policy outright. Those are the three choices. To continue the global policy proposal, RIPE should accept the text. At that point it is up to ARIN whether or not to change their mind. To reject the global policy, RIPE can simply reject this text and that will likely be the end of it. Or, RIPE could accept ARIN's bid, and adopt the ARIN text. That keeps the global policy in play and puts the onus on the other 3 RIRs to either accept the ARIN/RIPE text or leave the proposal in a stalemate. There is a fourth way, which is to modify this text, but that is really a form of rejection, coupled with a local policy proposal and only makes sense if it does not require other RIRs to act in accord. --Michael Dillon From jim at rfc1035.com Wed Apr 14 13:14:38 2010 From: jim at rfc1035.com (Jim Reid) Date: Wed, 14 Apr 2010 12:14:38 +0100 Subject: [address-policy-wg] what to do about 2009-01? In-Reply-To: <28E139F46D45AF49A31950F88C49745805C3F311@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745805C3F311@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <880DCAA0-97AF-4417-814D-75A254876D69@rfc1035.com> Michael, I was hoping we could reduce the number of options to consider for 2009-01, not add to them. Oh well... So how about just having these two possibilities: 1) Withdraw 2009-01. It's dead. Heroic measures to revive it and achieve a global policy are not going to have a happy outcome. So accept that situation and give up. 2) Continue with 2009-01 with a view to aligning things with the other RIRs except ARIN. Perhaps that might persuade ARIN to reconsider. It's also good PR because we're committing to making recovered space available for the greater good, even if that recovered space will probably just exist as an abstract concept. Does anyone here have a spare /8 to hand over? From kurtis at kurtis.pp.se Wed Apr 14 13:16:11 2010 From: kurtis at kurtis.pp.se (Lindqvist Kurt Erik) Date: Wed, 14 Apr 2010 13:16:11 +0200 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: <1271165480.3392.82.camel@ntitley-laptop> References: <1271165480.3392.82.camel@ntitley-laptop> Message-ID: <10EEEDEE-FBA2-445D-98AE-06D98C7F6500@kurtis.pp.se> On 13 apr 2010, at 15.31, Nigel Titley wrote: > Folks, > > As one of the authors of this proposal I'd like to get some sort of > consensus together in the RIPE region so that we can move forward. > > All other regions have reached consensus and we are the last to do so. > > All other regions with the exception of Arin have adopted the policy in > it's original form. Arin has modified the policy to remove the mandatory > return of recovered address space to IANA, which effectively makes it a > different policy. 2009-01 is a global policy which means that the same > policy has to be agreed in all regions, so to all practical purposes it > is doomed already. However, we still need to decide what to do with it > in the RIPE region. To my mind there are four possibilities: > > 1. We adopt it in its original form thus demonstrating solidarity with > the other regions, apart from Arin. > > 2. We adopt the Arin form of the proposal, thus demonstrating solidarity > with Arin, but with no one else > > 3. We reject the proposal outright, thus demonstrating that we can't > make up our minds or that we think it will never work, or something... > > 4. We ask the regional authors (in this case myself and Axel) to > withdraw the proposal in this region. > > Some background may be helpful here. No one seriously expected that any > address space would actually be returned as a result of this policy. It > was intended as a statement that should IPv4 address space become > available then it would be used for the greater good of all the > registries rather than those who had already had the majority of the > space already. I realise that this was a rather pious hope, but we felt > that it was worth making a statement about. > > The Arin region's position has made it impossible to make this statement > globally, but we still have the opportunity to make it here. I would > like to solicit the opinions of this working group in order to try and > put the matter to bed once and for all. > > I realise I'm making rather contentious statements here, but I'm hoping > to provoke a bit of discussion. Please can the working group indicate > how they would like to move this forward. My highly personal opinion is that the proposal has merit so should therefor go forward. That said, as long as there is not global acceptation the policy will not apply - which is a shame but protect the rest of us from potentially returning space to IANA just to see it reallocated to ARIN... Best regards, - kurtis - -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From nick at inex.ie Wed Apr 14 13:22:29 2010 From: nick at inex.ie (Nick Hilliard) Date: Wed, 14 Apr 2010 12:22:29 +0100 Subject: [address-policy-wg] what to do about 2009-01? In-Reply-To: <880DCAA0-97AF-4417-814D-75A254876D69@rfc1035.com> References: <28E139F46D45AF49A31950F88C49745805C3F311@E03MVZ2-UKDY.domain1.systemhost.net> <880DCAA0-97AF-4417-814D-75A254876D69@rfc1035.com> Message-ID: <4BC5A575.6080305@inex.ie> On 14/04/2010 12:14, Jim Reid wrote: > Michael, I was hoping we could reduce the number of options to consider > for 2009-01, not add to them. Oh well... > > So how about just having these two possibilities: > > 1) Withdraw 2009-01. It's dead. Heroic measures to revive it and achieve > a global policy are not going to have a happy outcome. So accept that > situation and give up. > > 2) Continue with 2009-01 with a view to aligning things with the other > RIRs except ARIN. Perhaps that might persuade ARIN to reconsider. It's > also good PR because we're committing to making recovered space > available for the greater good, even if that recovered space will > probably just exist as an abstract concept. Does anyone here have a > spare /8 to hand over? The UK MoD and the "UK Government Department for Work and Pensions" appear to be the only /8s assigned to individual End Users in this RIR area. I would like to see the proposal go ahead as-is. ARIN's refusal to implement it is unfortunate, but that should not deter the RIPE community from aspiring to do what is best. Nick From marcoh at marcoh.net Wed Apr 14 13:28:07 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 14 Apr 2010 14:28:07 +0300 Subject: [address-policy-wg] what to do about 2009-01? In-Reply-To: <880DCAA0-97AF-4417-814D-75A254876D69@rfc1035.com> References: <28E139F46D45AF49A31950F88C49745805C3F311@E03MVZ2-UKDY.domain1.systemhost.net> <880DCAA0-97AF-4417-814D-75A254876D69@rfc1035.com> Message-ID: On Apr 14, 2010, at 2:14 PM, Jim Reid wrote: > Michael, I was hoping we could reduce the number of options to consider for 2009-01, not add to them. Oh well... > > So how about just having these two possibilities: > > 1) Withdraw 2009-01. It's dead. Heroic measures to revive it and achieve a global policy are not going to have a happy outcome. So accept that situation and give up. > > 2) Continue with 2009-01 with a view to aligning things with the other RIRs except ARIN. Perhaps that might persuade ARIN to reconsider. It's also good PR because we're committing to making recovered space available for the greater good, even if that recovered space will probably just exist as an abstract concept. Does anyone here have a spare /8 to hand over? I personally would favor option 2, at least have it ready and waiting just in case ARIN is going to change their mind on it. Marco From dogwallah at gmail.com Wed Apr 14 13:29:29 2010 From: dogwallah at gmail.com (McTim) Date: Wed, 14 Apr 2010 14:29:29 +0300 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: <28E139F46D45AF49A31950F88C49745805C3F2E8@E03MVZ2-UKDY.domain1.systemhost.net> References: <4BC585E0.4000900@ripe.net> <28E139F46D45AF49A31950F88C49745805C3F2E8@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: On Wed, Apr 14, 2010 at 1:40 PM, wrote: >> As things stand today, with the ARIN community having agreed >> on a different text than the other RIRs' communities, this >> proposal fails as a global policy; which means that it will >> not be implemented. > > Unless ARIN changes their mind. It might be useful to give them a chance to do so. I'm leaning towards Nigel's option #1. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From slz at baycix.de Wed Apr 14 13:40:27 2010 From: slz at baycix.de (Sascha Lenz) Date: Wed, 14 Apr 2010 13:40:27 +0200 Subject: [address-policy-wg] what to do about 2009-01? In-Reply-To: References: <28E139F46D45AF49A31950F88C49745805C3F311@E03MVZ2-UKDY.domain1.systemhost.net> <880DCAA0-97AF-4417-814D-75A254876D69@rfc1035.com> Message-ID: <4BC5A9AB.9010307@baycix.de> Hi, >> Michael, I was hoping we could reduce the number of options to consider for 2009-01, not add to them. Oh well... >> >> So how about just having these two possibilities: >> >> 1) Withdraw 2009-01. It's dead. Heroic measures to revive it and achieve a global policy are not going to have a happy outcome. So accept that situation and give up. >> >> 2) Continue with 2009-01 with a view to aligning things with the other RIRs except ARIN. Perhaps that might persuade ARIN to reconsider. It's also good PR because we're committing to making recovered space available for the greater good, even if that recovered space will probably just exist as an abstract concept. Does anyone here have a spare /8 to hand over? > > I personally would favor option 2, at least have it ready and waiting just in case ARIN is going to change their mind on it. ok i think i don't want to go too deep into the politics of that proposal and having read some comments on it - again, i think "option 2" is the least stupid one to go with, so i would support this one now. Having said that - i still want to mention that i PERSONALLY (not professionally!) still don't see why we need any of those last-minute-IPv4-policy-changes at all. Just let it [IPv4] die already. (Again, please no discussions on this here, it's not my professional opinion anyways) -- ===================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Design & Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ===================================================================== From kpn-ip-office at kpn.com Wed Apr 14 13:28:30 2010 From: kpn-ip-office at kpn.com (kpn-ip-office at kpn.com) Date: Wed, 14 Apr 2010 13:28:30 +0200 Subject: [address-policy-wg] what to do about 2009-01? In-Reply-To: <4BC5A575.6080305@inex.ie> References: <28E139F46D45AF49A31950F88C49745805C3F311@E03MVZ2-UKDY.domain1.s ystemhost.net> <880DCAA0-97AF-4417-814D-75A254876D69@rfc1035.com> <4BC5A575.6080305@inex.ie> Message-ID: <81D36F4CA788E041922BF0E4F3C7C93FFC38EDEFB6@W2055.kpnnl.local> I'm in favour of accepting the policy as-is. With kind regards, ir. A.W. (Andries) Hettema KPN IP-Office kpn-ip-office at kpn.com +31 70 45 13398 -----Oorspronkelijk bericht----- Van: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] Namens Nick Hilliard Verzonden: woensdag 14 april 2010 13:22 Aan: address-policy-wg at ripe.net Onderwerp: Re: [address-policy-wg] what to do about 2009-01? On 14/04/2010 12:14, Jim Reid wrote: > Michael, I was hoping we could reduce the number of options to consider > for 2009-01, not add to them. Oh well... > > So how about just having these two possibilities: > > 1) Withdraw 2009-01. It's dead. Heroic measures to revive it and achieve > a global policy are not going to have a happy outcome. So accept that > situation and give up. > > 2) Continue with 2009-01 with a view to aligning things with the other > RIRs except ARIN. Perhaps that might persuade ARIN to reconsider. It's > also good PR because we're committing to making recovered space > available for the greater good, even if that recovered space will > probably just exist as an abstract concept. Does anyone here have a > spare /8 to hand over? The UK MoD and the "UK Government Department for Work and Pensions" appear to be the only /8s assigned to individual End Users in this RIR area. I would like to see the proposal go ahead as-is. ARIN's refusal to implement it is unfortunate, but that should not deter the RIPE community from aspiring to do what is best. Nick From Niall.oReilly at ucd.ie Wed Apr 14 13:21:10 2010 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Wed, 14 Apr 2010 12:21:10 +0100 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: <10EEEDEE-FBA2-445D-98AE-06D98C7F6500@kurtis.pp.se> References: <1271165480.3392.82.camel@ntitley-laptop> <10EEEDEE-FBA2-445D-98AE-06D98C7F6500@kurtis.pp.se> Message-ID: <4BC5A526.2020602@ucd.ie> On 14/04/10 12:16, Lindqvist Kurt Erik wrote: > My highly personal opinion is that the proposal has merit so should > therefor go forward. That said, as long as there is not global > acceptation the policy will not apply - which is a shame but protect > the rest of us from potentially returning space to IANA just to see > it reallocated to ARIN... +1 /Niall From pk at DENIC.DE Wed Apr 14 14:03:43 2010 From: pk at DENIC.DE (Peter Koch) Date: Wed, 14 Apr 2010 14:03:43 +0200 Subject: [address-policy-wg] what to do about 2009-01? In-Reply-To: <880DCAA0-97AF-4417-814D-75A254876D69@rfc1035.com> References: <28E139F46D45AF49A31950F88C49745805C3F311@E03MVZ2-UKDY.domain1.systemhost.net> <880DCAA0-97AF-4417-814D-75A254876D69@rfc1035.com> Message-ID: <20100414120343.GD2045@unknown.office.denic.de> On Wed, Apr 14, 2010 at 12:14:38PM +0100, Jim Reid wrote: > 1) Withdraw 2009-01. It's dead. Heroic measures to revive it and > achieve a global policy are not going to have a happy outcome. So > accept that situation and give up. sounds reasonable, but it has the downside of not making an assessment of the merits of the proposal as well as delivering the second bullet. > 2) Continue with 2009-01 with a view to aligning things with the other > RIRs except ARIN. Perhaps that might persuade ARIN to reconsider. It's It's always easy to approve of something that you know doesn't come into effect. So, if the community really wants this option, we better assume it be implemented sooner or later _and_ emphasize the commitment by appropriate communication outside the PDP process. -Peter From Remco.vanMook at eu.equinix.com Wed Apr 14 13:55:41 2010 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Wed, 14 Apr 2010 13:55:41 +0200 Subject: [address-policy-wg] what to do about 2009-01? References: <28E139F46D45AF49A31950F88C49745805C3F311@E03MVZ2-UKDY.domain1.systemhost.net> <880DCAA0-97AF-4417-814D-75A254876D69@rfc1035.com> Message-ID: <25B76451F7215744AFD4195362E55A1C01EFBBFA@NLEN1EX1.eu.win.equinix.com> Option 2 would have my vote. No spare /8 to hand over myself, though, sorry. Best Remco -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Jim Reid Sent: woensdag 14 april 2010 13:15 To: michael.dillon at bt.com Cc: address-policy-wg at ripe.net Subject: [address-policy-wg] what to do about 2009-01? Michael, I was hoping we could reduce the number of options to consider for 2009-01, not add to them. Oh well... So how about just having these two possibilities: 1) Withdraw 2009-01. It's dead. Heroic measures to revive it and achieve a global policy are not going to have a happy outcome. So accept that situation and give up. 2) Continue with 2009-01 with a view to aligning things with the other RIRs except ARIN. Perhaps that might persuade ARIN to reconsider. It's also good PR because we're committing to making recovered space available for the greater good, even if that recovered space will probably just exist as an abstract concept. Does anyone here have a spare /8 to hand over? This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383. From Woeber at CC.UniVie.ac.at Wed Apr 14 14:52:48 2010 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 14 Apr 2010 12:52:48 +0000 Subject: [address-policy-wg] Re: The emacs, X windows and Linux approach to policy making In-Reply-To: <1271241602.3392.293.camel@ntitley-laptop> References: <1271165480.3392.82.camel@ntitley-laptop> <4BC58757.7010100@inex.ie> <87D9EC06-A5B7-48F6-BDD7-23A3466F2AA5@rfc1035.com> <1271241602.3392.293.camel@ntitley-laptop> Message-ID: <4BC5BAA0.7000405@CC.UniVie.ac.at> Well, allow me to step back a couple of and look back what happened... First of all, imho there has been a fundamental flaw in this proposal, from the very beginning (and this has only become apparent in retrospct, so no criticism here! If I would have noticed in time I would be much happier now): this proposal tried to combine a global policy - which by def. is meant to direct IANA'S operation! - with a "humanitarian" or "political" resource-re-distributio aspect for recovered address space (if any) to apply equally in all regions. So, actually, it combined a global policicy with regional policies. The latter aspect failed. I don't want to get into details, or what my personal opinion is, just stick to the facts and the process. >From what has happened already, wearing my hat as a member of the Address Council, I consider the current approach as doomed. Which is a Goog Thing, imho, because it makes the reasoning of "backing up" the position of *one* region or of *three* regions, by having RIPE accept a) or b), irrelevant. Because whatever the "result" is, either 4:1 or 3:2, it does not help in solving the basic problem: Give IANA a (global) policy how to re-distribute address space which happens to be returned. For whatever reason... So, my proposal would be to withdraw 2009-01 unconditionally, as being o.b.e. At the same time we c|should explore the possibility to start the process for a re-distribution policy for IANA. Taking off my AC hat now... Everything else should be left where I think it belongs: within the regions, to decide how to manage recovered/returned *legacy* resources, that have been "tagged" as being managed in one of the five regions by the ERX process. Wilfried Nigel Titley wrote: > On Wed, 2010-04-14 at 11:26 +0100, Jim Reid wrote: > >>It's tempting to consider tweaking our policy for the IPv4 dregs to >>show our displeasure at the path ARIN has adopted. However I hope we >>can rise above that. > > > We would not be tweaking the policy to show displeasure. Option 1 (which > "shows displeasure with ARIN") is actually the original proposal. Option > 2 which doesn't, tweaks the policy. Sorry to be pedantic. > > >>I'm also beginning to wonder if policy-making is being unconsciously >>shaped by the Linux/emacs/X-windows approach to software design. If >>that can be called "design". [The only thing wrong with these bits of >>code is they don't have enough options or configuration variables to >>tweak. :-)] I would like to see fewer options on what to do about >>2009-01. Ideally it should be reduced to a binary choice. > > > I'm happy with that. > > >>With that in mind and Nigel's comments that the proposal is dead and >>starting to have a bad smell, I suggest we reduce the discussion of >>2009-01 to a simple choice of whether to withdraw it or not. > > > In my original terms we decide either to adopt option #1 (go with the > existing proposal) or option #4. I'm very happy with offering just these > choices. > > >>IMO, withdrawing this proposal makes the most sense. Continuing with >>it would only be worthwhile if the same approach to recovered space >>was being followed by the other RIRs. Since that's no longer possible, >>I think we should just stop flogging this dead horse. > > > This is a fair point... and I'm happy to accept it if the community > decides this is the consensus position. > > >>If there's support for keeping 2009-01 alive, I'd like to suggest we >>focus the discussion to a choice between two mutually exclusive >>positions: >> >>1) recovered space goes back to IANA for it to redistribute somehow > > > This is 2009-01 in essence. > > >>2) recovered space stays with the NCC for redistribution according to >>RIPE policy > > > This is a new policy and outside scope for the present discussion. > > Nigel From Woeber at CC.UniVie.ac.at Wed Apr 14 15:08:18 2010 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 14 Apr 2010 13:08:18 +0000 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: <4BC4B423.3060107@nosc.ja.net> References: <1271165480.3392.82.camel@ntitley-laptop> <4BC4B423.3060107@nosc.ja.net> Message-ID: <4BC5BE42.7050703@CC.UniVie.ac.at> Rob Evans wrote: [...] > > What is really needed is a lock on global policies until they are > approved by all the RIRs, Indeed. And although some of us (personally) tried to point out the problems with unilterally (and partly for non-technical teasons) going ahead with a very specific text, at a time when the eventual problems were discussed and to be expected already(!), it didn't help. > and I note from the APWG agenda for Prague > there is an enticing item (well, I find it interesting) called "????-?? > Global Policy State in RIPE PDP (Dave Wilson)." :-) But even if *our* region would agreee on such a thing, it wouldn't have helped in other regions ;-) > In the meantime, we work with what we have, and I support 2009-1. > > I look forward to hearing other opinions. :) > > Best regards, > Rob Wilfried From Woeber at CC.UniVie.ac.at Wed Apr 14 15:14:52 2010 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 14 Apr 2010 13:14:52 +0000 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: References: <1271165480.3392.82.camel@ntitley-laptop> Message-ID: <4BC5BFCC.90500@CC.UniVie.ac.at> Carlos Friacas wrote: [...] > Imho, those who wish not to contribute should not have access to the > recovered resources. Solidarity (even if it's about a legacy > resource...) sounds like a positive thing, however, if it's possible for > non-contributors to benefit, another word comes to mind. And in that > case i would be in favour of (3.) or (4.). I think we should stop the mudslinging and name-calling. More so, as the actual behaviour of a particular region has been, and is, different from what is implied here. > Regards, > Carlos The folks from ARIN have very concisely explained what they believe are their legal boundary conditions to consider, and to respect. Whether we in RIPE-Land like those - or not - is a different story and outside the scope of a global policy discussion, imho... Thanks, Wilfried. From Woeber at CC.UniVie.ac.at Wed Apr 14 15:26:27 2010 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 14 Apr 2010 13:26:27 +0000 Subject: [address-policy-wg] what to do about 2009-01? In-Reply-To: <880DCAA0-97AF-4417-814D-75A254876D69@rfc1035.com> References: <28E139F46D45AF49A31950F88C49745805C3F311@E03MVZ2-UKDY.domain1.systemhost.net> <880DCAA0-97AF-4417-814D-75A254876D69@rfc1035.com> Message-ID: <4BC5C283.4040309@CC.UniVie.ac.at> Jim Reid wrote: > Michael, I was hoping we could reduce the number of options to consider > for 2009-01, not add to them. Oh well... > > So how about just having these two possibilities: > > 1) Withdraw 2009-01. It's dead. Heroic measures to revive it and > achieve a global policy are not going to have a happy outcome. So > accept that situation and give up. Personally, I'd opt for 1) > 2) Continue with 2009-01 with a view to aligning things with the other > RIRs except ARIN. Perhaps that might persuade ARIN to reconsider. It's > also good PR because we're committing to making recovered space > available for the greater good, even if that recovered space will > probably just exist as an abstract concept. So what's the point then? > Does anyone here have a > spare /8 to hand over? Looking at the global environmant, my feeling is that the communities of the RIRs should rather act as a body speaking with one voice to the outside world; rather than engaging in mental experiments of 3:2 or 4:1 scores. Being seen as having major differences or a "shoot-out" between RIRs (or their communities) will probably be used against our common interests. Wilfried. From randy at psg.com Wed Apr 14 15:56:17 2010 From: randy at psg.com (Randy Bush) Date: Wed, 14 Apr 2010 22:56:17 +0900 Subject: [address-policy-wg] Re: The emacs, X windows and Linux approach to policy making In-Reply-To: <4BC5BAA0.7000405@CC.UniVie.ac.at> References: <1271165480.3392.82.camel@ntitley-laptop> <4BC58757.7010100@inex.ie> <87D9EC06-A5B7-48F6-BDD7-23A3466F2AA5@rfc1035.com> <1271241602.3392.293.camel@ntitley-laptop> <4BC5BAA0.7000405@CC.UniVie.ac.at> Message-ID: > First of all, imho there has been a fundamental flaw in this proposal, > from the very beginning nope. the proposal is progressing precisely as intended. it was designed to show the arin policy weenies as anti-socual imperialists. it is doing so. randy From dave.wilson at heanet.ie Thu Apr 15 13:33:29 2010 From: dave.wilson at heanet.ie (Dave Wilson) Date: Thu, 15 Apr 2010 12:33:29 +0100 Subject: [address-policy-wg] Re: The emacs, X windows and Linux approach to policy making In-Reply-To: <4BC5BAA0.7000405@CC.UniVie.ac.at> References: <1271165480.3392.82.camel@ntitley-laptop> <4BC58757.7010100@inex.ie> <87D9EC06-A5B7-48F6-BDD7-23A3466F2AA5@rfc1035.com> <1271241602.3392.293.camel@ntitley-laptop> <4BC5BAA0.7000405@CC.UniVie.ac.at> Message-ID: <4BC6F989.1000600@heanet.ie> With my AC hat off - and, indeeed, open to correction on my interpretation of the process... > First of all, imho there has been a fundamental flaw in this proposal, > from the very beginning (and this has only become apparent in retrospct, > so no criticism here! If I would have noticed in time I would be much > happier now): this proposal tried to combine a global policy - which by > def. is meant to direct IANA'S operation! - with a "humanitarian" or > "political" resource-re-distributio aspect for recovered address space > (if any) to apply equally in all regions. > > So, actually, it combined a global policicy with regional policies. > > The latter aspect failed. I don't want to get into details, or what my > personal opinion is, just stick to the facts and the process. I've been struggling with this, because I had the question: is there really no such thing as a global policy which could reasonably be made contingient on regional policies? I think the answer is found by examining where consensus is achieved. In the RIPE region, we require consensus to implement a policy, and then we require consensus again to change it. So it is for global policies - all regions must ratify it, then all regions must ratify a change. But if you have a global policy that mixes with regional policy, or is in some way dependent on regional policy, then any one regional policy could change in the future, quite legitimately. At that moment the global policy has not been updated, and I assume that IANA operations are presumably still directed by it, but one of the assumptions on which it was based is no longer valid. So it just seems to me that making a global policy that affects, or is dependent on, regional policy, will have problems that aren't easy to predict or solve. > So, my proposal would be to withdraw 2009-01 unconditionally, as being o.b.e. I feel the same way. My memory is that RIPE held off ratification in the past to see which way the global consensus went. Since it hasn't materialised, I think that there's no benefit to "locking in" any given text in one more region. All the best, 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/ H323 GDS:0035301101738 PGP: 1024D/C757ADA9 From shane at time-travellers.org Thu Apr 15 14:31:49 2010 From: shane at time-travellers.org (Shane Kerr) Date: Thu, 15 Apr 2010 14:31:49 +0200 Subject: [address-policy-wg] Inter-RIR love as we approach IPv4 Stunde Null, was Re: [address-policy-wg] what to do about 2009-01? In-Reply-To: <4BC5A9AB.9010307@baycix.de> References: <28E139F46D45AF49A31950F88C49745805C3F311@E03MVZ2-UKDY.domain1.systemhost.net> <880DCAA0-97AF-4417-814D-75A254876D69@rfc1035.com> <4BC5A9AB.9010307@baycix.de> Message-ID: <4BC70735.4000503@time-travellers.org> Sascha, On 2010-04-14 13:40, Sascha Lenz wrote: > > Having said that - i still want to mention that i PERSONALLY (not > professionally!) still don't see why we need any of those > last-minute-IPv4-policy-changes at all. Just let it [IPv4] die already. > (Again, please no discussions on this here, it's not my professional > opinion anyways) In the case of this particular policy I kind of agree. I don't expect a lot of reclaimed space to appear as we approach and pass various milestones in IPv4 allocation (IANA done, first RIR done, and so on). There has been HUGE amount of discussion based on what seems to me to be largely a hypothetical situation. But... I do think this points to an area of possible concern. I have often thought that as IPv4 resources become more limited, people are going to start having problems. (What do you mean I can't have a /18 for my new POP?) At that point, questions will be raised. (Why wasn't I told?! Why didn't somebody *do* something?!?!) Fingers will be pointed. (Who's fault is this?!?!?!) People or organizations with little familiarity about the Internet and its governance will step in, either of they want to or because their constituents demand it. Certainly for local policies, each RIR can and should operate in local best interest. But for global policies, the RIRs should work together. If the Internet hopes to maintain its limited self-regulation, then the various policy making bodies *need* to stand together. I probably shouldn't mention it, but honestly ARIN has always been the "odd man out" from the RIRs. This is partially historical, since ARIN in in some ways old (coming from InterNIC) and in other ways new (arriving later than the RIPE NCC and APNIC). I think it is also partially because ARIN is very US-focused, rather than serving the interests of a broad area. So it won't surprise me if ARIN is the first to reject global policies to pursue local interests. I do know that it would make life generally more difficult for organizations on the Internet (for example, by complicating inter-regional address transfer). What I do not know is how to avoid a rift between the RIRs, or minimize the harm such a rift causes. -- Shane From michael.dillon at bt.com Thu Apr 15 16:52:16 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 15 Apr 2010 15:52:16 +0100 Subject: [address-policy-wg] Inter-RIR love as we approach IPv4 Stunde Null, was Re: [address-policy-wg] what to do about 2009-01? In-Reply-To: <4BC70735.4000503@time-travellers.org> Message-ID: <28E139F46D45AF49A31950F88C49745805C9D320@E03MVZ2-UKDY.domain1.systemhost.net> > I do think this points to an area of possible concern. I have > often thought that as IPv4 resources become more limited, > people are going to start having problems. (What do you mean > I can't have a /18 for my new > POP?) At that point, questions will be raised. (Why wasn't I > told?! ARIN has solved this issue by sending a letter in the post to the CEO of every LIR explaining about IPv4 runout and IPv6 availability. If RIPE has not done so, it would be a good idea to protect against lawsuits. > Why didn't somebody *do* something?!?!) It would be good for the RIPE web site to have a page explaining the history of IPv4 runout concerns leading to classful IPv4 addressing, then VLSM and CIDR, then the development and deployment of IPv6. Dates are essential to show that there was ample time for people to take action. > Fingers will > be pointed. (Who's fault is this?!?!?!) At some time, perhaps RIPE should start playing hardball in its messages. Wouldn't it illustrate management incompetence if a network operator has not already started their contingency plans for IPv4 runout, and IPv6 deployment? I'm sure that if RIPE held some free educational sessions for financial analysts in the major cities of Europe which host stock exchanges, that those analysts would start asking some pointed questions during the next quarterly reporting season. Frankfurt, Paris, Milan, London, Moscow, Geneva and so on. > People or > organizations with little familiarity about the Internet and > its governance will step in, either of they want to or > because their constituents demand it. Knowing that this wave of activity and concern is coming, RIPE would be wise to step in front of the wave and lead the discussions. On the one hand, there is no need to panic because lots of people and organizations have been working hard in preparation. But on the other hand, some percentage of organizations have their head in the sand and will suffer, perhaps even to the point of bankruptcy. We may have another telecoms collapse next year, due to the issues surrounding IPv4 runout and IPv6 readiness. Remember the big bank failures recently, that were triggered by a sharp drop in the value of credit default swaps that was the result of problems in the US mortgage market? Now, after the fact we know that some people did see this problem coming, that they prepared their companies for the crash, and/or tried to warn others what was happening. The IPv4 runout may not be such a major event, but we are in a similar position as knowledgeable insiders who are trying to get the message across. I think that as long as we make the attempt to get the message out there, nobody will shoot the messenger. The blame will correctly be placed on those who ignored the messages. --Michael Dillon From jcurran at arin.net Thu Apr 15 16:45:41 2010 From: jcurran at arin.net (John Curran) Date: Thu, 15 Apr 2010 10:45:41 -0400 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: <1271165480.3392.82.camel@ntitley-laptop> References: <1271165480.3392.82.camel@ntitley-laptop> Message-ID: <121DDC55-2C3B-4EE8-8E48-CEFACA2173C1@arin.net> On Apr 13, 2010, at 8:31 AM, Nigel Titley wrote: > ... > Some background may be helpful here. No one seriously expected that any > address space would actually be returned as a result of this policy. It > was intended as a statement that should IPv4 address space become > available then it would be used for the greater good of all the > registries rather than those who had already had the majority of the > space already. I realise that this was a rather pious hope, but we felt > that it was worth making a statement about. Nigel - The RIPE 2009-1/ARIN 2009-3 global policy proposal has also provisions which provide for a clear process for reallocation of recovered address space returned to the IANA, and these aspects of the global policy are quite likely useful independent of the policy as a "statement" of unity about returning recovered address space. It's important to note that the term "recovered address space" includes both voluntarily returned space as well as space reclaimed due to legal action or abuse determination, and hence it's not unreasonable to think that there will be resources put into the recovered address space pool if this policy is globally adopted (even in the absence of voluntarily returned space). The ARIN community identified that the decision to return recovered address space to the IANA is a local (not global) policy decision. ARIN's present practice has been to return to the IANA any significant address space which was voluntarily returned to ARIN (for examples, see the following writeup: ) and until a new ARIN policy is established, we will continue that practice. If the other regions adopt their respective policy proposals, we will have an outcome operationally very similar to the original proposal, but with regional policy control over what gets returned to IANA. As you note, that fails as a unified statement of greater good, but each region should also consider if the resulting global policy would result in a useful outcome despite this failing. /John John Curran President and CEO ARIN From nigel at titley.com Thu Apr 15 19:04:35 2010 From: nigel at titley.com (Nigel Titley) Date: Thu, 15 Apr 2010 18:04:35 +0100 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: <121DDC55-2C3B-4EE8-8E48-CEFACA2173C1@arin.net> References: <1271165480.3392.82.camel@ntitley-laptop> <121DDC55-2C3B-4EE8-8E48-CEFACA2173C1@arin.net> Message-ID: <1271351075.3392.630.camel@ntitley-laptop> On Thu, 2010-04-15 at 10:45 -0400, John Curran wrote: > The RIPE 2009-1/ARIN 2009-3 global policy proposal has also provisions > which provide for a clear process for reallocation of recovered address > space returned to the IANA, and these aspects of the global policy are > quite likely useful independent of the policy as a "statement" of unity > about returning recovered address space. This is indeed true, but would be a side-effect of the policy. And I'm not sure if IANA would feel bound by any policy that was not global. > It's important to note that the term "recovered address space" includes > both voluntarily returned space as well as space reclaimed due to legal > action or abuse determination, and hence it's not unreasonable to think > that there will be resources put into the recovered address space pool > if this policy is globally adopted (even in the absence of voluntarily > returned space). Agreed. > The ARIN community identified that the decision to return recovered > address space to the IANA is a local (not global) policy decision. > ARIN's present practice has been to return to the IANA any significant > address space which was voluntarily returned to ARIN (for examples, > see the following writeup: > ) > and until a new ARIN policy is established, we will continue that > practice. Excellent... and plaudits to ARIN for their selfless behaviour, modulo, of course, any definition of what constitutes "significant". > If the other regions adopt their respective policy proposals, we will > have an outcome operationally very similar to the original proposal, > but with regional policy control over what gets returned to IANA. As > you note, that fails as a unified statement of greater good, but each > region should also consider if the resulting global policy would result > in a useful outcome despite this failing. The problem is, of course, that this policy was proposed as a global policy and what I am trying to do here is tidy things up in the RIPE region. I'm perfectly open to the idea that we have individual regional policies, but this would surely require us to start the process again with new regional (as opposed to global) policies? Also, of course, the note above about regional policies possibly not being binding on IANA still stands. Nigel Chairman RIPE NCC Board From packetgrrl at gmail.com Thu Apr 15 19:18:15 2010 From: packetgrrl at gmail.com (cja@daydream.com) Date: Thu, 15 Apr 2010 11:18:15 -0600 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: <1271351075.3392.630.camel@ntitley-laptop> References: <1271165480.3392.82.camel@ntitley-laptop> <121DDC55-2C3B-4EE8-8E48-CEFACA2173C1@arin.net> <1271351075.3392.630.camel@ntitley-laptop> Message-ID: On Thu, Apr 15, 2010 at 11:04 AM, Nigel Titley wrote: > > > The ARIN community identified that the decision to return recovered > > address space to the IANA is a local (not global) policy decision. > > ARIN's present practice has been to return to the IANA any significant > > address space which was voluntarily returned to ARIN (for examples, > > see the following writeup: > > ) > > and until a new ARIN policy is established, we will continue that > > practice. > > Excellent... and plaudits to ARIN for their selfless behaviour, modulo, > of course, any definition of what constitutes "significant". > > Nigel would you not consider directly returning 4 entire /8s back to IANA not significant? Since there is no policy currently by which IANA can hand out anything less than a /8 it seems that returning smaller blocks to IANA so they can be stuck there might not be such a great idea? How about a global policy directing IANA how to hand out smaller blocks to the RIRs might be in order? That policy is here http://www.icann.org/en/general/allocation-IPv4-rirs.html *Allocation Principles* - The IANA will allocate IPv4 address space to the RIRs in /8 units. - The IANA will allocate sufficient IPv4 address space to the RIRs to support their registration needs for at least an 18 month period. - The IANA will allow for the RIRs to apply their own respective chosen allocation and reservation strategies in order to ensure the efficiency and efficacy of their work. Thanks! ----Cathy -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Thu Apr 15 19:37:47 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 15 Apr 2010 18:37:47 +0100 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C49745805C9D460@E03MVZ2-UKDY.domain1.systemhost.net> > Nigel would you not consider directly returning 4 entire /8s > back to IANA not significant? Hmmmm, 4 months supply? No, I don't think that is a significant amount. Sure, where there are low hanging fruit like that it makes sense to put in the effort and clean things up even if it is only 4 months supply. But step back and look at the big picture, and even IANA's issue with smaller blocks, probably won't make much difference one way or another. In fact, you could consider that to be a nice cushion so that when everybody says the cupboard is bare, IANA can raise their hand and say "here are a few sweepings from the back corner that we could hand out if anyone can use a few crumbs". --Michael Dillon From nigel at titley.com Thu Apr 15 19:40:55 2010 From: nigel at titley.com (Nigel Titley) Date: Thu, 15 Apr 2010 18:40:55 +0100 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: References: <1271165480.3392.82.camel@ntitley-laptop> <121DDC55-2C3B-4EE8-8E48-CEFACA2173C1@arin.net> <1271351075.3392.630.camel@ntitley-laptop> Message-ID: <1271353255.3392.644.camel@ntitley-laptop> On Thu, 2010-04-15 at 11:18 -0600, cja at daydream.com wrote: > > > Nigel would you not consider directly returning 4 entire /8s back to > IANA not significant? Since there is no policy currently by which 4 /8s is indeed nice. And my original compliment to ARIN still stands. > IANA can hand out anything less than a /8 it seems that returning > smaller blocks to IANA so they can be stuck there might not be such a > great idea? How about a global policy directing IANA how to hand out > smaller blocks to the RIRs might be in order? Well, that of course is what 2009-01 provided. > > > That policy is here > http://www.icann.org/en/general/allocation-IPv4-rirs.html > > > > Allocation Principles > > * The IANA will allocate IPv4 address space to the RIRs in /8 > units. > * The IANA will allocate sufficient IPv4 address space to the > RIRs to support their registration needs for at least an 18 > month period. > * The IANA will allow for the RIRs to apply their own respective > chosen allocation and reservation strategies in order to > ensure the efficiency and efficacy of their work. And this policy is going to be completely ineffective once IANA has less than a /8 in store... which is next year, remember. One of the goals of 2009-01 was to provide a means for IANA to accept and allocate smaller than /8s. But I re-iterate. I'm only trying to sort out the washup of 2009-01. It isn't ever likely to be a global policy now. All the best Nigel From packetgrrl at gmail.com Thu Apr 15 19:54:42 2010 From: packetgrrl at gmail.com (cja@daydream.com) Date: Thu, 15 Apr 2010 11:54:42 -0600 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: <1271353255.3392.644.camel@ntitley-laptop> References: <1271165480.3392.82.camel@ntitley-laptop> <121DDC55-2C3B-4EE8-8E48-CEFACA2173C1@arin.net> <1271351075.3392.630.camel@ntitley-laptop> <1271353255.3392.644.camel@ntitley-laptop> Message-ID: In my opinion it would be easy to get a global policy passed that enabled IANA to give out smaller blocks. It's the rest of the policy viewed as regional at least by folks in the ARIN region that is causing problems. ----Cathy On Thu, Apr 15, 2010 at 11:40 AM, Nigel Titley wrote: > On Thu, 2010-04-15 at 11:18 -0600, cja at daydream.com wrote: > > > > > > > Nigel would you not consider directly returning 4 entire /8s back to > > IANA not significant? Since there is no policy currently by which > > 4 /8s is indeed nice. And my original compliment to ARIN still stands. > > > IANA can hand out anything less than a /8 it seems that returning > > smaller blocks to IANA so they can be stuck there might not be such a > > great idea? How about a global policy directing IANA how to hand out > > smaller blocks to the RIRs might be in order? > > Well, that of course is what 2009-01 provided. > > > > > > That policy is here > > http://www.icann.org/en/general/allocation-IPv4-rirs.html > > > > > > > > Allocation Principles > > > > * The IANA will allocate IPv4 address space to the RIRs in /8 > > units. > > * The IANA will allocate sufficient IPv4 address space to the > > RIRs to support their registration needs for at least an 18 > > month period. > > * The IANA will allow for the RIRs to apply their own respective > > chosen allocation and reservation strategies in order to > > ensure the efficiency and efficacy of their work. > > And this policy is going to be completely ineffective once IANA has less > than a /8 in store... which is next year, remember. One of the goals of > 2009-01 was to provide a means for IANA to accept and allocate smaller > than /8s. > > But I re-iterate. I'm only trying to sort out the washup of 2009-01. It > isn't ever likely to be a global policy now. > > All the best > > Nigel > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From packetgrrl at gmail.com Thu Apr 15 20:00:24 2010 From: packetgrrl at gmail.com (cja@daydream.com) Date: Thu, 15 Apr 2010 12:00:24 -0600 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: <28E139F46D45AF49A31950F88C49745805C9D460@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745805C9D460@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: Well if all we're discussing is "crumbs" then what's the point? Writing a policy to force regions to give back "crumbs"? I do feel that it's a good idea to enable IANA to have a mechanism to hand out the crumbs. Soon that's all that will be left. What's wrong with making the returning of the crumbs to IANA a regional decision and giving IANA the ability to hand them out to RIRs if it gets them? Just a thought. ----Cathy On Thu, Apr 15, 2010 at 11:37 AM, wrote: > > Nigel would you not consider directly returning 4 entire /8s > > back to IANA not significant? > > Hmmmm, 4 months supply? > No, I don't think that is a significant amount. Sure, where there > are low hanging fruit like that it makes sense to put in the > effort and clean things up even if it is only 4 months supply. > > But step back and look at the big picture, and even IANA's > issue with smaller blocks, probably won't make much difference > one way or another. In fact, you could consider that to be > a nice cushion so that when everybody says the cupboard is > bare, IANA can raise their hand and say "here are a few sweepings > from the back corner that we could hand out if anyone can use > a few crumbs". > > --Michael Dillon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfs at cisco.com Fri Apr 16 01:49:29 2010 From: pfs at cisco.com (Philip Smith) Date: Fri, 16 Apr 2010 09:49:29 +1000 Subject: [address-policy-wg] 2010-02 New Policy Proposal (Allocations from the last /8) In-Reply-To: <4BC47784.9040104@despres.co.uk> References: <20100413125530.699846A00C@postboy.ripe.net> <4BC47784.9040104@despres.co.uk> Message-ID: <4BC7A609.10509@cisco.com> Hi James, James Blessing said the following on 13/04/10 23:54 : > On 13/04/2010 13:55, Ingrid Wijte wrote: >> PDP Number: 2010-02 > > Suggest Revised Text, just tweaking no real impact Actually, your suggestions are pretty major changes to the policy proposal. ;-) > Allocations from the last /8 > > The distribution of the last /8 held by the RIPE NCC will be done as > follows: > > 1. Unforeseen circumstances pool > > Once RIPE NCC recieves the final /8 from IANA, a /16 will be held in > reserve for some future uses, as yet unforeseen. In 2010-2, Alain and I proposed that once the RIPE NCC holds the *equivalent* of a /8 or less of IPv4 address space, the policy would apply. This is different from when RIPE NCC receives the final /8 from IANA, as there may well be still be some IPv4 address space remaining in other blocks. > 2. Allocations for LIRs from the last /8 > > On application for IPv4 resources when the RIPE NCC the final /8 has > been allocated by IANA to RIPE, LIRs will receive IPv4 addresses > according to the following: > > - LIRs may only receive one allocation from the final /8. The size of > the allocation made under this policy will be no larger than a /22. > Other space may be provided to the LIR should additional space outside > of the final /8 be available at the point of the request. We actually intended 2010-2 to apply to the remaining equivalent of a /8, not the last /8 that RIPE NCC receives from IANA. (For example, this could be two /11s from one /8 block, a /10 from another /8 block, and one /9 from a third /8 block.) There would be no other IPv4 space left at this stage. > 3. Final Exhaustion > > In the event that the unforeseen circumstances pool /16 remains unused > in the time the final /8 covered by this policy has been distributed, a > /15 will be returned to the main pool to be distributed as per clause 2. > > Once this /15 has been used then the final /15 will also be returned to > the pool s should an unforeseen usage have not been found. I think you mean /16 here, right? Thanks very much for your feedback! philip -- From Niall.oReilly at ucd.ie Fri Apr 16 09:41:47 2010 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Fri, 16 Apr 2010 08:41:47 +0100 Subject: [address-policy-wg] 2010-02 New Policy Proposal (Allocations from the last /8) In-Reply-To: <4BC7A609.10509@cisco.com> References: <20100413125530.699846A00C@postboy.ripe.net> <4BC47784.9040104@despres.co.uk> <4BC7A609.10509@cisco.com> Message-ID: <4BC814BB.8060607@ucd.ie> On 16/04/10 00:49, Philip Smith wrote: > Hi James, > > James Blessing said the following on 13/04/10 23:54 : [...] >> 3. Final Exhaustion >> >> In the event that the unforeseen circumstances pool /16 remains unused >> in the time the final /8 covered by this policy has been distributed, a >> /15 will be returned to the main pool to be distributed as per clause 2. >> >> Once this /15 has been used then the final /15 will also be returned to >> the pool s should an unforeseen usage have not been found. > > I think you mean /16 here, right? I expect he meant /17 (half of the /16). /Niall From james.blessing at despres.co.uk Fri Apr 16 15:11:44 2010 From: james.blessing at despres.co.uk (James Blessing) Date: Fri, 16 Apr 2010 14:11:44 +0100 Subject: [address-policy-wg] 2010-02 New Policy Proposal (Allocations from the last /8) In-Reply-To: <4BC7A609.10509@cisco.com> References: <20100413125530.699846A00C@postboy.ripe.net> <4BC47784.9040104@despres.co.uk> <4BC7A609.10509@cisco.com> Message-ID: <4BC86210.7060901@despres.co.uk> On 16/04/2010 00:49, Philip Smith wrote: > Hi James, > > James Blessing said the following on 13/04/10 23:54 : >> On 13/04/2010 13:55, Ingrid Wijte wrote: >>> PDP Number: 2010-02 >> >> Suggest Revised Text, just tweaking no real impact > > Actually, your suggestions are pretty major changes to the policy > proposal. ;-) > >> Allocations from the last /8 >> >> The distribution of the last /8 held by the RIPE NCC will be done as >> follows: >> >> 1. Unforeseen circumstances pool >> >> Once RIPE NCC recieves the final /8 from IANA, a /16 will be held in >> reserve for some future uses, as yet unforeseen. > > In 2010-2, Alain and I proposed that once the RIPE NCC holds the > *equivalent* of a /8 or less of IPv4 address space, the policy would > apply. This is different from when RIPE NCC receives the final /8 from > IANA, as there may well be still be some IPv4 address space remaining in > other blocks. Nice idea but I think the trigger point for the change in policy should be the receiving of the /8 as its a clear (and very easy to track) public point at which the policy changes. If you change policy at the point of reach on /8 left then there would be a public announcement that could be missed and arguments about RIPE's timing of the announcement. >> 2. Allocations for LIRs from the last /8 >> >> On application for IPv4 resources when the RIPE NCC the final /8 has >> been allocated by IANA to RIPE, LIRs will receive IPv4 addresses >> according to the following: >> >> - LIRs may only receive one allocation from the final /8. The size of >> the allocation made under this policy will be no larger than a /22. >> Other space may be provided to the LIR should additional space outside >> of the final /8 be available at the point of the request. > > We actually intended 2010-2 to apply to the remaining equivalent of a > /8, not the last /8 that RIPE NCC receives from IANA. (For example, this > could be two /11s from one /8 block, a /10 from another /8 block, and > one /9 from a third /8 block.) There would be no other IPv4 space left > at this stage. My problem is the same as with the previous timing issue, I think that a /22 'each' from the last /8 is fine and RIPE can still continue allocations from what space was left when the /8 was delivered. The alternative is a /22 each from the point at which the /8 is delivered, full stop >> 3. Final Exhaustion >> >> In the event that the unforeseen circumstances pool /16 remains unused >> in the time the final /8 covered by this policy has been distributed, a >> /15 will be returned to the main pool to be distributed as per clause 2. >> >> Once this /15 has been used then the final /15 will also be returned to >> the pool s should an unforeseen usage have not been found. > > I think you mean /16 here, right? I did indeed mean /17 J -- James Blessing http://www.despres.co.uk/ 07989 039 476 Superbia in Proelio From filiz at ripe.net Tue Apr 20 11:14:43 2010 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 20 Apr 2010 11:14:43 +0200 Subject: [address-policy-wg] 2010-03 New Policy Proposal (Global Policy State in RIPE PDP) Message-ID: <20100420091443.5BEED6A005@postboy.ripe.net> PDP Number: 2010-03 Global Policy State in RIPE PDP Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2010-03.html We encourage you to review this proposal and send your comments to before 18 May 2010. Regards Filiz Yilmaz Policy Development Manager RIPE NCC From gert at space.net Tue Apr 20 14:44:03 2010 From: gert at space.net (Gert Doering) Date: Tue, 20 Apr 2010 14:44:03 +0200 Subject: [address-policy-wg] Re: Draft Agenda (v2) for upcoming APWG meeting at RIPE 60 In-Reply-To: <20100412132621.GA16729@Space.Net> References: <20100412132621.GA16729@Space.Net> Message-ID: <20100420124403.GA49635@Space.Net> Hi APWG folks, hi RIPE meeting folks, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Prague in the following three time slots: Wednesday, May 5, 09:00 - 10:30 Wednesday, May 5, 11:00 - 12:30 Thursday, May 6, 14:00 - 15:30 The exact time lines depend a bit on how much discussion is going on, so we might move items one time slot "up" or "down". If you have anything else you want to see on the agenda, or of we need to change anything, please let us know. regards, Gert Doering, APWG chair ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. Current Policy Topics - Filiz Yilmaz - overview over concluded proposals 2009-03 [run out fairly] - accepted 2008-06 Use of final /8 - withdrawn 2009-04 IPv4 Allocation and Assignments to Facilitate - withdrawn IPv6 Deployment - common policy topics in all regions (end of IPv4, transfers, ...) C. New Proposals since RIPE 59 -> Discussion of open policy proposals, Part 1 (new proposals) 2010-01 Temporary Internet Number Assignment Policy (Nick Hilliard) 2010-03 Global Policy State in RIPE PDP (Dave Wilson) ????-?? Wording Cleanup regarding 80% rule for PA allocations (Gert Doering) [to be submitted in the next days] 2010-02 Allocations from the last /8 (new combined proposal from Philip Smith and Alain Bidron, just presented here, to be discussed on Thursday) ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- K. Document Cosmetic Surgeries Project - Filiz Yilmaz - feedback received on the first set of changes - how to go forward? L. "Authorship of RIPE Policy Documents" - Filiz Yilmaz This presentation seeks to reach community agreement on how to document and acknowledge the role of people that propose changes to RIPE Internet Resource Allocation and Assignment policies. M. "Update what's happening with ITU and the RIRs" - Axel Pawlik N. Ideas how to tackle any problems that have been experienced by the NCC Registration Services Department. (open discussion, based on Alex Le Heux' report at RIPE59) - try to come up with consensus on what we think "IPv6 PI" should be used for, and should not be used for, and then start a PDP proposal to adjust the policy according to it (if needed) - data-center operators and their customers - the "IPv4 loophole" -> customer access links considered infra (and thus, single-address customers with NAT can be numbered from IPv4 PI, but not from IPv6 PI) ---------------------------------------------------------------------- Thursday, 12:30-14:00 ---------------------------------------------------------------------- T. Discussion of open policy proposals (old proposals) ---- old policy proposals ---- 2006-05 PI Assignment Size (dead, up for grabs) 2008-07 Ensuring Efficient Use of Historical IPv4 Resources (Philip Smith) 2008-08 Initial Certification Policy for PA Space Holders (Nigel Titley, CA TF - update what happened since RIPE 59) 2009-01 Global Policy for the allocation of IPv4 blocks to RIRs (5 RIR design team, represented by Axel Pawlik (?)) ---- directly related to IPv4 run-out --- 2008-06 Use of Final /8 (Philip Smith) 2009-04 IPv4 Allocation and Assignments to Facilitate IPv6 Deployment (Alain Bidron) these two proposals have ben dropped and replaced by a new combined proposal: 2010-02 Allocations from the last /8 (new combined proposal from Philip Smith and Alain Bidron) Y. Open Policy Hour "The Open Policy Hour (OPH) is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity." (Idea from ARIN policy meeting) Z. AOB -- 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 nigel at titley.com Wed Apr 21 12:23:00 2010 From: nigel at titley.com (Nigel Titley) Date: Wed, 21 Apr 2010 11:23:00 +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: <4BCED204.7010902@titley.com> Filiz Yilmaz wrote: > PDP Number: 2010-03 > Global Policy State in RIPE PDP The aim of this proposal seems to be worthwhile but I have a question and a note of caution. The question is that reading through the rationale I came across this statement "The benefits are that the RIPE community may speedily adopt a global policy proposal if it wishes, and that doing so will not delay the process of establishing consensus if further modifications are requested in other RIR communities." I can't see how the addition of an extra holding state can allow the policy to be adopted. Probably I'm confused, but surely this proposal just allows a proposal to be held in the new proposed state until all regions are in step. It won't allow the policy to be adopted any earlier? The note of caution is that there is no timeout on this state so we potentially have a policy held here for ever. Nigel From dave.wilson at heanet.ie Wed Apr 21 14:45:57 2010 From: dave.wilson at heanet.ie (Dave Wilson) Date: Wed, 21 Apr 2010 13:45:57 +0100 Subject: [address-policy-wg] 2010-03 New Policy Proposal (Global Policy State in RIPE PDP) In-Reply-To: <4BCED204.7010902@titley.com> References: <20100420091443.5BEED6A005@postboy.ripe.net> <4BCED204.7010902@titley.com> Message-ID: <4BCEF385.6090303@heanet.ie> Hi Nigel, Good questions, thanks. > The question is that reading through the rationale I came across this > statement > > "The benefits are that the RIPE community may speedily adopt a global > policy proposal if it wishes, and that doing so will not delay the > process of establishing consensus if further modifications are requested > in other RIR communities." > > I can't see how the addition of an extra holding state can allow the > policy to be adopted. Probably I'm confused, but surely this proposal > just allows a proposal to be held in the new proposed state until all > regions are in step. It won't allow the policy to be adopted any earlier? I see what you mean. Let me characterise the problem like this: At this moment, if the RIPE community reaches consensus on a global policy, and it is adopted in our region before all other regions have adopted it, then there is still a risk that another region may propose a change that we want to adopt. This risk could, in principle, slow down the process of getting consensus in the RIPE region. The object of this proposal is to mitigate that risk, by allowing a proposal to be adopted in the RIPE region specifically, but ensuring that it can be revised if an alternative surfaces and reaches consensus. But a global policy of course can't be implemented until it has been adopted in all regions, and this proposal would not directly affect the speed at which that occurs. > The note of caution is that there is no timeout on this state so we > potentially have a policy held here for ever. Good point. There are two trapdoors though that can be "manually" triggered in the event that a policy seems to be stuck - one by the RIPE WG chairs, the other by the ASO AC. I have the feeling that adding a fixed timeout would probably not help the process, which can be lengthy. Does that sound reasonable? All the best, 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/ H323 GDS:0035301101738 PGP: 1024D/C757ADA9 From nigel at titley.com Wed Apr 21 15:09:46 2010 From: nigel at titley.com (Nigel Titley) Date: Wed, 21 Apr 2010 14:09:46 +0100 Subject: [address-policy-wg] 2010-03 New Policy Proposal (Global Policy State in RIPE PDP) In-Reply-To: <4BCEF385.6090303@heanet.ie> References: <20100420091443.5BEED6A005@postboy.ripe.net> <4BCED204.7010902@titley.com> <4BCEF385.6090303@heanet.ie> Message-ID: <4BCEF91A.5010602@titley.com> Dave Wilson wrote: > Hi Nigel, > > Good questions, thanks. > > I see what you mean. Let me characterise the problem like this: > > At this moment, if the RIPE community reaches consensus on a global > policy, and it is adopted in our region before all other regions have > adopted it, then there is still a risk that another region may propose a > change that we want to adopt. This risk could, in principle, slow down > the process of getting consensus in the RIPE region. > > The object of this proposal is to mitigate that risk, by allowing a > proposal to be adopted in the RIPE region specifically, but ensuring > that it can be revised if an alternative surfaces and reaches consensus. > But a global policy of course can't be implemented until it has been > adopted in all regions, and this proposal would not directly affect the > speed at which that occurs. So this allows a holding state, before the policy becomes instantiated in the RIPE region, from which it can be returned to a previous phase and allow changes (such as may have been made in another region), hence avoiding the startup delay? If so then I agree. Sounds like a fine idea. > Good point. There are two trapdoors though that can be "manually" > triggered in the event that a policy seems to be stuck - one by the RIPE > WG chairs, the other by the ASO AC. I have the feeling that adding a > fixed timeout would probably not help the process, which can be lengthy. > Does that sound reasonable? Yes, it does. Nigel From dave.wilson at heanet.ie Wed Apr 21 16:19:28 2010 From: dave.wilson at heanet.ie (Dave Wilson) Date: Wed, 21 Apr 2010 15:19:28 +0100 Subject: [address-policy-wg] 2010-03 New Policy Proposal (Global Policy State in RIPE PDP) In-Reply-To: <4BCEF91A.5010602@titley.com> References: <20100420091443.5BEED6A005@postboy.ripe.net> <4BCED204.7010902@titley.com> <4BCEF385.6090303@heanet.ie> <4BCEF91A.5010602@titley.com> Message-ID: <4BCF0970.70405@heanet.ie> > So this allows a holding state, before the policy becomes instantiated > in the RIPE region, from which it can be returned to a previous phase > and allow changes (such as may have been made in another region), hence > avoiding the startup delay? Precisely this! > If so then I agree. Sounds like a fine idea. All the best, 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/ H323 GDS:0035301101738 PGP: 1024D/C757ADA9 From rhe at nosc.ja.net Wed Apr 21 17:48:53 2010 From: rhe at nosc.ja.net (Rob Evans) Date: Wed, 21 Apr 2010 16:48:53 +0100 Subject: [address-policy-wg] Re: [policy-announce] 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: <4BCF1E65.3010504@nosc.ja.net> This is perhaps more wordsmithing rather than a fundamental comment on the proposal, which sounds like A Good Thing. (1): > If the global policy proposal does not reach consensus or a > substantial change is made on the proposal in one (or more) of the > other RIR communities after the proposal was put in "Accepted pending > consensus in other RIR communities" in RIPE, all the RIPE WG Chairs > as a group will determine how to proceed. They can decide to withdraw > the proposal or send it back to one of the previous phases of the > RIPE PDP with or without a new version of the proposal. (2): > If the global policy proposal fails to receive acceptance at the end > of the global policy development process that is evaluated by the ASO > Address Council (can be due to having substantial differences in the > proposed text in different RIR communities or due to that the > proposal failed to reach consensus in one of the RIR communities) > then the proposal will be withdrawn automatically in RIPE too. The > RIPE NCC will make the necessary announcements. Is the second of these paragraphs needed? (Alternatively, is the first one needed?) They appear to cover similar events, so for clarity shouldn't it either be up to the WG chairs 'collective' or the output of the ASO AC? (As an aside, I'd remove 'all' from the first paragraph...) Cheers, Rob -- Rob Evans JANET(UK) Development Team Twitter: https://twitter.com/JANETDev/team Work tweets: https://twitter.com/internetplumber JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From bmanning at vacation.karoshi.com Thu Apr 22 00:23:10 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 21 Apr 2010 22:23:10 +0000 Subject: [address-policy-wg] [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01 Message-ID: <20100421222310.GE2186@vacation.karoshi.com.> On Apr 20, 2010, at 9:34 PM, bmanning at vacation.karoshi.com wrote: > > and a very pleasant evening. > > a few questions. > > IPv6 on your radar? > Looking at options for addressing your future v6 needs? > > Have you looked at the IETF/ID in the subject line? > > if you think something like this is a good idea, worth > persuing, I'd like to hear from you. > and as Friend Bush reminds, if you think this idea is lunacy - I'd like to hear that as well. --bill From dave.wilson at heanet.ie Thu Apr 22 12:08:16 2010 From: dave.wilson at heanet.ie (Dave Wilson) Date: Thu, 22 Apr 2010 11:08:16 +0100 Subject: [address-policy-wg] Re: [policy-announce] 2010-03 New Policy Proposal (Global Policy State in RIPE PDP) In-Reply-To: <4BCF1E65.3010504@nosc.ja.net> References: <20100420091443.5BEED6A005@postboy.ripe.net> <4BCF1E65.3010504@nosc.ja.net> Message-ID: <4BD02010.6050509@heanet.ie> Hi Rob, Rob Evans wrote: > This is perhaps more wordsmithing rather than a fundamental comment on > the proposal, which sounds like A Good Thing. Thanks! > (1): >> If the global policy proposal does not reach consensus or a >> substantial change is made on the proposal in one (or more) of the >> other RIR communities after the proposal was put in "Accepted pending >> consensus in other RIR communities" in RIPE, all the RIPE WG Chairs >> as a group will determine how to proceed. They can decide to withdraw >> the proposal or send it back to one of the previous phases of the >> RIPE PDP with or without a new version of the proposal. > > (2): >> If the global policy proposal fails to receive acceptance at the end >> of the global policy development process that is evaluated by the ASO >> Address Council (can be due to having substantial differences in the >> proposed text in different RIR communities or due to that the >> proposal failed to reach consensus in one of the RIR communities) >> then the proposal will be withdrawn automatically in RIPE too. The >> RIPE NCC will make the necessary announcements. > > Is the second of these paragraphs needed? (Alternatively, is the first > one needed?) They appear to cover similar events, so for clarity > shouldn't it either be up to the WG chairs 'collective' or the output of > the ASO AC? I do see two subtly different circumstances here. The first is that a change has occurred during the process that gives the RIPE community reason to consider an amendment (or withdrawl) of the proposal. I think it's appropriate that this is triggered from inside the RIPE region. The second is something that I expect will only occur at the end of an unsuccessful process, and allows the RIPE NCC to tidy up once this has been established. We could certainly ask the WG chairs to rubber-stamp this, but I think it is a fairly clear state so I'm not sure there's much benefit to be gained from adding that step. All the best, 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/ H323 GDS:0035301101738 PGP: 1024D/C757ADA9 From zsako at 3c-hungary.hu Thu Apr 22 12:18:12 2010 From: zsako at 3c-hungary.hu (Janos Zsako) Date: Thu, 22 Apr 2010 12:18:12 +0200 Subject: [address-policy-wg] Re: [policy-announce] 2010-03 New Policy Proposal (Global Policy State in RIPE PDP) In-Reply-To: <4BCF1E65.3010504@nosc.ja.net> References: <20100420091443.5BEED6A005@postboy.ripe.net> <4BCF1E65.3010504@nosc.ja.net> Message-ID: <4BD02264.5050806@3c-hungary.hu> Rob Evans wrote: > This is perhaps more wordsmithing rather than a fundamental comment on > the proposal, which sounds like A Good Thing. I also feel the proposal is A Good Thing, and I support it. As far as the comment is concerned, here are my 2 Euro cents: > (1): >> If the global policy proposal does not reach consensus or a >> substantial change is made on the proposal in one (or more) of the >> other RIR communities after the proposal was put in "Accepted pending >> consensus in other RIR communities" in RIPE, all the RIPE WG Chairs >> as a group will determine how to proceed. They can decide to withdraw >> the proposal or send it back to one of the previous phases of the >> RIPE PDP with or without a new version of the proposal. > > (2): >> If the global policy proposal fails to receive acceptance at the end >> of the global policy development process that is evaluated by the ASO >> Address Council (can be due to having substantial differences in the >> proposed text in different RIR communities or due to that the >> proposal failed to reach consensus in one of the RIR communities) >> then the proposal will be withdrawn automatically in RIPE too. The >> RIPE NCC will make the necessary announcements. > > Is the second of these paragraphs needed? Well, in my opinion this is a very good question. I think the proposal 2010-03 assumes that the global policy proposal that has been accepted by the RIPE community and has been put in this new state, has been accepted only on condition it will eventually become a global policy and has no value if it remains a regional policy. In such a case, the automatic withdrawal in case of failure to become a global policy is the right thing to do. However, if the conditionally accepted policy has value as a regional policy too, then it may not be a good idea to automatically withdraw it. This is an argument in favour of deleting (2), as the RIPE WG Chairs could decide in accordance with (1) what to do in such a situation. This also raises the question whether it would be useful for the RIPE WG Chairs to be able to decide to keep a policy that is in this new state as a(n accepted) regional policy as it is (i.e without any further changes). In other words, the question is whether we want the RIPE WG Chairs to be able to move the policy from this new state to the Accepted state without having to consult the community, even if the policy would not become global. At present this possibility is not there, so either it becomes a _global_ policy as it is, or it goes back to the PDP (or it is withdrawn, of course). This could be solved by adding this possibility to (1). I personally think we should add this possibility. > (Alternatively, is the first > one needed?) Well, I definitely think it is important to have it there, as (2) deals only with the case when there is no chance to get a global policy in the end, while (1) deals with the case when some fine tuning could "save" the proposal. This fine tuning suggestion can come from the RIPE WG Chairs or from the community (when it is sent back in the same version). > They appear to cover similar events, so for clarity > shouldn't it either be up to the WG chairs 'collective' or the output of > the ASO AC? I personally would be inclined to delete (2) and extend (1) as suggested above. > (As an aside, I'd remove 'all' from the first paragraph...) I would also remove it, but I see no harm in having it there. I am sure the RIPE WG Chairs as a group will be able to reach consensus on what they recommend to do. Best regards, Janos From e.bubeck at EnBW.com Thu Apr 22 20:57:00 2010 From: e.bubeck at EnBW.com (Bubeck Eberhard) Date: Thu, 22 Apr 2010 20:57:00 +0200 Subject: [address-policy-wg] AW: address-policy-wg digest, Vol 1 #1137 - 1 msg Message-ID: Pop ----- Originalnachricht ----- Von: address-policy-wg-admin at ripe.net An: address-policy-wg at ripe.net Gesendet: Tue Apr 20 12:00:03 2010 Betreff: address-policy-wg digest, Vol 1 #1137 - 1 msg Send address-policy-wg mailing list submissions to address-policy-wg at ripe.net To subscribe or unsubscribe via the World Wide Web, visit http://www.ripe.net/mailman/listinfo/address-policy-wg or, via email, send a message with subject or body 'help' to address-policy-wg-request at ripe.net You can reach the person managing the list at address-policy-wg-admin at ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of address-policy-wg digest..." Today's Topics: 1. 2010-03 New Policy Proposal (Global Policy State in RIPE PDP) (Filiz Yilmaz) --__--__-- Message: 1 From: "Filiz Yilmaz" To: policy-announce at ripe.net Cc: address-policy-wg at ripe.net Reply-To: address-policy-wg at ripe.net Date: Tue, 20 Apr 2010 11:14:43 +0200 Subject: [address-policy-wg] 2010-03 New Policy Proposal (Global Policy State in RIPE PDP) PDP Number: 2010-03 Global Policy State in RIPE PDP Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2010-03.html We encourage you to review this proposal and send your comments to before 18 May 2010. Regards Filiz Yilmaz Policy Development Manager RIPE NCC End of address-policy-wg Digest From jcurran at arin.net Thu Apr 29 17:57:29 2010 From: jcurran at arin.net (John Curran) Date: Thu, 29 Apr 2010 11:57:29 -0400 Subject: [address-policy-wg] Policy proposal 2009-01 In-Reply-To: <1271353255.3392.644.camel@ntitley-laptop> References: <1271165480.3392.82.camel@ntitley-laptop> <121DDC55-2C3B-4EE8-8E48-CEFACA2173C1@arin.net> <1271351075.3392.630.camel@ntitley-laptop> <1271353255.3392.644.camel@ntitley-laptop> Message-ID: <2B8EC6F1-B721-42A2-A9B0-ADB68B4CC67C@arin.net> On Apr 15, 2010, at 1:40 PM, Nigel Titley wrote: > > And this policy is going to be completely ineffective once IANA has less > than a /8 in store... which is next year, remember. One of the goals of > 2009-01 was to provide a means for IANA to accept and allocate smaller > than /8s. The policy remains effective even after IANA has less than a /8 in store, as any subsequent returned address space will still be subject to it. Since address space can be returned for numerous reasons, the policy will almost certainly see some use if adopted. > But I re-iterate. I'm only trying to sort out the washup of 2009-01. It > isn't ever likely to be a global policy now. In the absence of such a policy, there is no incentive at all to return resources to the IANA, as they lack a policy to reissue them (in the case of smaller blocks) or will issue them entirely to one RIR (in the case of a /8) which is to the detriment of all other regions. While having the address return be designated by the RIR may not be ideal, at least in the ARIN region that is considered a far better outcome than the non-functional IANA that we're presently heading towards. /John John Curran President and CEO ARIN