From emadaio at ripe.net Wed Sep 1 16:21:22 2010 From: emadaio at ripe.net (Emilio Madaio) Date: Wed, 01 Sep 2010 16:21:22 +0200 Subject: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments): discussion in the IPv6-WG mailing list Message-ID: <4C7E6162.2040809@ripe.net> [Apologies for duplicate emails] Dear Colleagues, A new policy proposal, 2010-06, "Registration Requirements for IPv6 End User Assignments", was published to the IPv6 Working Group mailing list today. The proposal can be found here: http://www.ripe.net/ripe/policies/proposals/2010-06.html The proposers would like to draw your attention to the proposal and invite you to join the discussion about it on the IPv6 Working Group mailing list: http://ripe.net/ripe/maillists/archives/ipv6-wg/2010/index.html You can email the working group at: Kind regards Emilio Madaio Policy Development Officer RIPE NCC From nick at inex.ie Fri Sep 3 17:09:08 2010 From: nick at inex.ie (Nick Hilliard) Date: Fri, 03 Sep 2010 16:09:08 +0100 Subject: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments): discussion in the IPv6-WG mailing list In-Reply-To: <4C7E6162.2040809@ripe.net> References: <4C7E6162.2040809@ripe.net> Message-ID: <4C810F94.4070602@inex.ie> On 01/09/2010 15:21, Emilio Madaio wrote: > A new policy proposal, 2010-06, "Registration Requirements for IPv6 End > User Assignments", was published to the IPv6 Working Group mailing list today. I think I like this policy, mostly. The only issue I have is that it appears to mandate that all assignments makes from a SUB-ASSIGNED PA block are exactly the length specified. This means that if the ISP has policies of, say, /56 for most customers but /48 for some, while at the same time wanting to implement some form of per-PoP prefix aggregation, it means assigning multiple blocks per aggregation point, one per assignment size. Is this intentional? Nick From nick at inex.ie Fri Sep 3 17:34:35 2010 From: nick at inex.ie (Nick Hilliard) Date: Fri, 03 Sep 2010 16:34:35 +0100 Subject: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments): discussion in the IPv6-WG mailing list In-Reply-To: <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> References: <4C7E6162.2040809@ripe.net> <4C810F94.4070602@inex.ie> <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> Message-ID: <4C81158B.8040408@inex.ie> On 03/09/2010 16:30, Sander Steffann wrote: > Allowing multiple "assignment-size:" fields might solve that. perhaps. But the beauty of only allowing a single size is that the RIPE NCC can multiply the number of assignments by the value of the assignment-size: field to find out the H/D ratio. I'm not trying to argue out both sides of my mouth here, btw. I'm just trying to understand what the intention of the proposal is, and whether the proposal needs to be clearer in this regard. Nick From nick at inex.ie Fri Sep 3 17:56:18 2010 From: nick at inex.ie (Nick Hilliard) Date: Fri, 03 Sep 2010 16:56:18 +0100 Subject: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments): discussion in the IPv6-WG mailing list In-Reply-To: References: <4C7E6162.2040809@ripe.net> <4C810F94.4070602@inex.ie> <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> <4C81158B.8040408@inex.ie> Message-ID: <4C811AA2.9040309@inex.ie> On 03/09/2010 16:43, Remco van Mook wrote: > I guess it really depends on what you'd want to consider as more > important; ease of administration or aggregation. The policy makes the > assumption of large amounts of end user assignments being made - if you > want out both /48 and /56 from a single PoP and you're going to do both > in any significant quantity, I'd personally choose to use separate > blocks for the /56 and the /48 assignments to allow for easier > recycling. Then those blocks can have their own separate entry in the > database, each with a single assignment size. If you need to re-hash > block sizes at a later point, you can always change to a larger number > of smaller blocks in the database. Database entries are (relatively) > cheap. So the "assignment-size:" really means maximum assignment size rather than exact assignment size? Yes, certainly if you're large enough, you would go for separate blocks for /48 and /56 anyway. However, smaller operations may carve them from the same block for whatever reasons. Nick From Remco.vanMook at eu.equinix.com Fri Sep 3 18:15:22 2010 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Fri, 3 Sep 2010 17:15:22 +0100 Subject: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments): discussion in the IPv6-WG mailing list In-Reply-To: <4C811AA2.9040309@inex.ie> References: <4C7E6162.2040809@ripe.net> <4C810F94.4070602@inex.ie> <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> <4C81158B.8040408@inex.ie> <4C811AA2.9040309@inex.ie> Message-ID: Nick Hilliard wrote: > So the "assignment-size:" really means maximum assignment size rather > than exact assignment size? There's certainly nothing stopping you from doing that - however it'll leave you with some explaining to do by the time you want your next block, because the smaller sub-assignments might not be reflected in HD ratios. > > Yes, certainly if you're large enough, you would go for separate blocks for > /48 and /56 anyway. However, smaller operations may carve them from the > same block for whatever reasons. > As I said, database entries are relatively cheap - you can still use a single routable block and use multiple database entries to describe that single block, using separate entries for separate prefix sizes. If an operation is of such a size that they don't have enough customer volume in a single block size to be able to aggregate, they're probably down to using individual database entries for individual customers anyway. You could even use overlapping database entries, where the 'most specific' entry wins. This way you can define blocks of /56s in a block that would otherwise have /48s, for example. Remco 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 Remco.vanMook at eu.equinix.com Fri Sep 3 17:43:40 2010 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Fri, 3 Sep 2010 16:43:40 +0100 Subject: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments): discussion in the IPv6-WG mailing list In-Reply-To: <4C81158B.8040408@inex.ie> References: <4C7E6162.2040809@ripe.net> <4C810F94.4070602@inex.ie> <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> <4C81158B.8040408@inex.ie> Message-ID: I guess it really depends on what you'd want to consider as more important; ease of administration or aggregation. The policy makes the assumption of large amounts of end user assignments being made - if you want out both /48 and /56 from a single PoP and you're going to do both in any significant quantity, I'd personally choose to use separate blocks for the /56 and the /48 assignments to allow for easier recycling. Then those blocks can have their own separate entry in the database, each with a single assignment size. If you need to re-hash block sizes at a later point, you can always change to a larger number of smaller blocks in the database. Database entries are (relatively) cheap. Best Remco > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > admin at ripe.net] On Behalf Of Nick Hilliard > Sent: vrijdag 3 september 2010 17:35 > To: Sander Steffann > Cc: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration > Requirements for IPv6 End User Assignments): discussion in the IPv6-WG > mailing list > > On 03/09/2010 16:30, Sander Steffann wrote: > > Allowing multiple "assignment-size:" fields might solve that. > > perhaps. But the beauty of only allowing a single size is that the RIPE NCC can > multiply the number of assignments by the value of the > assignment-size: field to find out the H/D ratio. > > I'm not trying to argue out both sides of my mouth here, btw. I'm just trying > to understand what the intention of the proposal is, and whether the > proposal needs to be clearer in this regard. > > Nick 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 nick at inex.ie Fri Sep 3 18:41:04 2010 From: nick at inex.ie (Nick Hilliard) Date: Fri, 03 Sep 2010 17:41:04 +0100 Subject: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments): discussion in the IPv6-WG mailing list In-Reply-To: References: <4C7E6162.2040809@ripe.net> <4C810F94.4070602@inex.ie> <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> <4C81158B.8040408@inex.ie> <4C811AA2.9040309@inex.ie> Message-ID: <4C812520.2060904@inex.ie> On 03/09/2010 17:15, Remco van Mook wrote: > Nick Hilliard wrote: >> So the "assignment-size:" really means maximum assignment size rather >> than exact assignment size? > > There's certainly nothing stopping you from doing that - however it'll > leave you with some explaining to do by the time you want your next > block, because the smaller sub-assignments might not be reflected in HD > ratios. I'm concerned that unless this is spelled out, it creates a hole for unsuspecting LIRs to fall into. Think of how much future LIR and IPRA frustration could be prevented by making a one-line note in the "Usage" section about what will happen if you mix-n-match your assignment sizes! Nick From sander at steffann.nl Fri Sep 3 17:30:38 2010 From: sander at steffann.nl (Sander Steffann) Date: Fri, 3 Sep 2010 17:30:38 +0200 Subject: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments): discussion in the IPv6-WG mailing list In-Reply-To: <4C810F94.4070602@inex.ie> References: <4C7E6162.2040809@ripe.net> <4C810F94.4070602@inex.ie> Message-ID: <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> Hi, >> A new policy proposal, 2010-06, "Registration Requirements for IPv6 End >> User Assignments", was published to the IPv6 Working Group mailing list today. > > I think I like this policy, mostly. > > The only issue I have is that it appears to mandate that all assignments makes from a SUB-ASSIGNED PA block are exactly the length specified. This means that if the ISP has policies of, say, /56 for most customers but /48 for some, while at the same time wanting to implement some form of per-PoP prefix aggregation, it means assigning multiple blocks per aggregation point, one per assignment size. Allowing multiple "assignment-size:" fields might solve that. Sander From marcoh at marcoh.net Fri Sep 3 21:13:22 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 3 Sep 2010 21:13:22 +0200 Subject: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments): discussion in the IPv6-WG mailing list In-Reply-To: <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> References: <4C7E6162.2040809@ripe.net> <4C810F94.4070602@inex.ie> <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> Message-ID: <87ED25D5-FD6D-4329-98C9-881A788AB56F@marcoh.net> On 3 sep 2010, at 17:30, Sander Steffann wrote: > Hi, > >>> A new policy proposal, 2010-06, "Registration Requirements for IPv6 End >>> User Assignments", was published to the IPv6 Working Group mailing list today. >> >> I think I like this policy, mostly. >> >> The only issue I have is that it appears to mandate that all assignments makes from a SUB-ASSIGNED PA block are exactly the length specified. This means that if the ISP has policies of, say, /56 for most customers but /48 for some, while at the same time wanting to implement some form of per-PoP prefix aggregation, it means assigning multiple blocks per aggregation point, one per assignment size. > > Allowing multiple "assignment-size:" fields might solve that. No it won't, you have a /40 with assignment size /56 and /64 and then how to specify which customer has what. Can't we solve this by allowing more specifics ? The original thought was to just create multiple entries, one for each assignment size. But we could allow for something like: bla:://40 -> assignment size /48 bla::1/48 -> assignment size /56 MarcoH From marcoh at marcoh.net Fri Sep 3 21:20:59 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 3 Sep 2010 21:20:59 +0200 Subject: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments): discussion in the IPv6-WG mailing list In-Reply-To: <87ED25D5-FD6D-4329-98C9-881A788AB56F@marcoh.net> References: <4C7E6162.2040809@ripe.net> <4C810F94.4070602@inex.ie> <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> <87ED25D5-FD6D-4329-98C9-881A788AB56F@marcoh.net> Message-ID: Oh and could people at least cross-post ? On 3 sep 2010, at 21:13, Marco Hogewoning wrote: > > On 3 sep 2010, at 17:30, Sander Steffann wrote: > >> Hi, >> >>>> A new policy proposal, 2010-06, "Registration Requirements for IPv6 End >>>> User Assignments", was published to the IPv6 Working Group mailing list today. >>> >>> I think I like this policy, mostly. >>> >>> The only issue I have is that it appears to mandate that all assignments makes from a SUB-ASSIGNED PA block are exactly the length specified. This means that if the ISP has policies of, say, /56 for most customers but /48 for some, while at the same time wanting to implement some form of per-PoP prefix aggregation, it means assigning multiple blocks per aggregation point, one per assignment size. >> >> Allowing multiple "assignment-size:" fields might solve that. > > No it won't, you have a /40 with assignment size /56 and /64 and then how to specify which customer has what. Can't we solve this by allowing more specifics ? > > The original thought was to just create multiple entries, one for each assignment size. But we could allow for something like: > > bla:://40 -> assignment size /48 > bla::1/48 -> assignment size /56 > > MarcoH > MarcoH From sander at steffann.nl Fri Sep 3 21:38:15 2010 From: sander at steffann.nl (Sander Steffann) Date: Fri, 3 Sep 2010 21:38:15 +0200 Subject: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments): discussion in the IPv6-WG mailing list In-Reply-To: References: <4C7E6162.2040809@ripe.net> <4C810F94.4070602@inex.ie> <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> <87ED25D5-FD6D-4329-98C9-881A788AB56F@marcoh.net> Message-ID: Hi Marco, > Oh and could people at least cross-post ? Sorry. Probably my fault. >>>> The only issue I have is that it appears to mandate that all assignments makes from a SUB-ASSIGNED PA block are exactly the length specified. This means that if the ISP has policies of, say, /56 for most customers but /48 for some, while at the same time wanting to implement some form of per-PoP prefix aggregation, it means assigning multiple blocks per aggregation point, one per assignment size. >>> >>> Allowing multiple "assignment-size:" fields might solve that. >> >> No it won't, you have a /40 with assignment size /56 and /64 and then how to specify which customer has what. Can't we solve this by allowing more specifics ? >> >> The original thought was to just create multiple entries, one for each assignment size. But we could allow for something like: >> >> bla:://40 -> assignment size /48 >> bla::1/48 -> assignment size /56 After thinking about it, this seems to be the best solution. Sander From kpn-ip-office at kpn.com Mon Sep 6 16:06:38 2010 From: kpn-ip-office at kpn.com (kpn-ip-office at kpn.com) Date: Mon, 6 Sep 2010 16:06:38 +0200 Subject: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments) In-Reply-To: References: <4C7E6162.2040809@ripe.net> <4C810F94.4070602@inex.ie> <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> <87ED25D5-FD6D-4329-98C9-881A788AB56F@marcoh.net> Message-ID: <81D36F4CA788E041922BF0E4F3C7C93FFC84DE9C66@W2055.kpnnl.local> I have some questions about the proposal Question 1: Why was chosen for "SUB-ASSIGNED PA" and not for "SUB-ALLOCATED PA" or even "LIR-PARTITIONED PA", which according to my understanding would be more in line with the IPv4 world and the proposal states it "...is largely designed based on the current IPv4 practice..."? Besides that, ASSIGNED PA is the 'lowest status' in the IPv4. Using the term SUB-ASSIGNED PA higher in the hierarchy than ASSIGNED PA in IPv6 world might only create confusion. Question 2: Also, when putting such an inetnum object on the RIPE database, would it require approval from the RIPE NCC if the (initial) sub-'assignment' exceeds a /48 (in relation with RIPE-481 chapter 5.4.2)? Question 3: In IPv4 world (and policy document) the purpose of registration is "... to ensure uniqueness and to support network operations." (RIPE-492 4.0) I realise that this sentence is not in the RIPE-481 document, so maybe this is out of order/scope, but in creating a 'pool' possibility we explicitely choose to not register inetnum information on the End User level. Does this not make "support network operations" a lot harder? Question 4: In IPv4 world, there are also LIRs that use this idea (registering a pool of addresses from which assignments are made to a number of different End Users) . But an extra status has not been required: on approval from RIPE NCC the LIR registers an inetnum with status "ASSIGNED PA". Why would an extra status be required in IPv6 world? 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 Sander Steffann Verzonden: vrijdag 3 september 2010 21:38 Aan: ipv6-wg at ripe.net CC: Marco Hogewoning; Nick Hilliard; address-policy-wg at ripe.net Working Group Onderwerp: Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments): discussion in the IPv6-WG mailing list Hi Marco, > Oh and could people at least cross-post ? Sorry. Probably my fault. >>>> The only issue I have is that it appears to mandate that all assignments makes from a SUB-ASSIGNED PA block are exactly the length specified. This means that if the ISP has policies of, say, /56 for most customers but /48 for some, while at the same time wanting to implement some form of per-PoP prefix aggregation, it means assigning multiple blocks per aggregation point, one per assignment size. >>> >>> Allowing multiple "assignment-size:" fields might solve that. >> >> No it won't, you have a /40 with assignment size /56 and /64 and then how to specify which customer has what. Can't we solve this by allowing more specifics ? >> >> The original thought was to just create multiple entries, one for each assignment size. But we could allow for something like: >> >> bla:://40 -> assignment size /48 >> bla::1/48 -> assignment size /56 After thinking about it, this seems to be the best solution. Sander From gert at space.net Mon Sep 6 18:28:34 2010 From: gert at space.net (Gert Doering) Date: Mon, 6 Sep 2010 18:28:34 +0200 Subject: [address-policy-wg] 2010-04 New Draft Document Published (80% Rule Ambiguity Cleanup) In-Reply-To: <20100809143413.C08876A01C@postboy.ripe.net> References: <20100809143413.C08876A01C@postboy.ripe.net> Message-ID: <20100906162834.GW61734@Space.Net> Hi APWG, On Mon, Aug 09, 2010 at 04:34:13PM +0200, Emilio Madaio wrote: > The draft document for the proposal described in 2010-04 has been > published. The impact analysis that was conducted for this proposal > has also been published. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2010-04.html .. > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 6 September 2010. This period is now over. Normally, I would now post a summary of the discussion of the proposal and (potentially) start the next phase in the PDP, "Last Call". Since I'm the respective WG chair *and* the proposer, there is a formal conflict of interest. So I will not do any WG chair work on this proposal --> expect to see summary + decisions from APWG's co-chair, Sander Steffann, soon :-) Gert Doering -- proposer of 2010-04 -- Total number of prefixes smaller than registry allocations: 155817 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 sander at steffann.nl Tue Sep 7 15:36:19 2010 From: sander at steffann.nl (Sander Steffann) Date: Tue, 7 Sep 2010 15:36:19 +0200 Subject: [address-policy-wg] The review phase for 2010-04 (80% Rule Ambiguity Cleanup) has ended Message-ID: <7EEE1C6A-FA46-4256-B239-4F6F388694F9@steffann.nl> Hello working group, As Gert has already told you he won't be acting as working group chair when discussing proposal 2010-04, as he is the author of that proposal. It falls to me now to decide if we have consensus on this proposal. During the lifetime of this proposal there have been 16 messages on the list declaring support for this proposal, and no questions or objections. I feel confident that this is a very clear case of consensus and therefore I ask the PDO staff to move this proposal forward to the concluding phase (?Last Call for Comments?). Sander Steffann APWG co-chair From emadaio at ripe.net Thu Sep 9 17:17:11 2010 From: emadaio at ripe.net (Emilio Madaio) Date: Thu, 09 Sep 2010 17:17:11 +0200 Subject: [address-policy-wg] 2010-04 Last Call for Comments (80% Rule Ambiguity Cleanup) Message-ID: <20100909162302.EC51C6A005@postboy.ripe.net> Dear Colleagues, The proposal described in 2010-04 is now at its Concluding Phase. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2010-04.html Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 7 October 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC From gert at space.net Mon Sep 13 15:04:01 2010 From: gert at space.net (Gert Doering) Date: Mon, 13 Sep 2010 15:04:01 +0200 Subject: [address-policy-wg] Address Policy WG Minutes from RIPE 60 / Prague Message-ID: <20100913130401.GY74702@Space.Net> Hi AP WG list, thanks to Susannah from the RIPE NCC, the minutes from the APWG meeting in Prague are now online: http://www.ripe.net/ripe/wg/address-policy/minutes.html (The long delay since Prague is actually my fault in not reviewing the first draft quickly enough) please review the draft and send in anything that is not as you remember the session, or any typos, or whatsoever. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 155817 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 cgrundemann at gmail.com Sun Sep 19 20:12:56 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Sun, 19 Sep 2010 12:12:56 -0600 Subject: [address-policy-wg] Suggested updates to 2010-05 (Global Policy for IPv4 Allocation by the IANA post exhaustion) Message-ID: Hello APWG, After receiving great feedback in several regions, the original authors of the proposal have discussed all of the feedback received and our suggested revisions are below: Problem #1: The allocation method was unfair. The intent was never for a single RIR to be able to be allocated all available address space in mass quantities. We do however want any available address space to be utilized if there is need. We've addressed what we would characterize as a mechanical issue. --new text: Section 3. Address Allocations from the Reclamation Pool by the IANA Allocations from the Reclamation Pool may begin once the pool is declared active. Addresses in the Reclamation Pool must be allocated on a CIDR boundary. Allocations from the Reclamation Pool are subject to a minimum allocation unit equal to the minimum allocation unit of all RIRs and a maximum allocation unit of one /8. The Reclamation Pool will be divided on CIDR boundaries and distributed evenly to all eligible RIRs once each quarter. Any remainder not evenly divisible by the number of eligible RIRs based on a CIDR boundary equal to or larger than the minimum allocation unit will remain in the Reclamation Pool. Addresses that are left over will be held in the Reclamation Pool until additional IP addresses can be returned to rejoin addresses on CIDR boundaries to the Reclamation Pool or a minimum allocation unit is set to allow allocation from existing inventory. Problem #2: Without excluding transition space, some RIR's would never be eligible. To address this, we've defined a /10 exemption for any/all pools of address space set-aside by any RIR. --new text Section 4. RIR Eligibility for Receiving Allocations from the Reclamation Pool Upon the exhaustion of an RIR's free space pool and after receiving their final /8 from the IANA[3], an RIR will become eligible to request address space from the IANA Reclamation Pool when it publicly announces via its respective global announcements email list and by posting a notice on its website that it has exhausted its supply of IPv4 address space. Exhaustion is defined as an inventory of less than the equivalent of a single /8 and the inability to further assign address space to its customers in units equal to or shorter than the longest of any RIR's policy defined minimum allocation unit. Up to one /10 or equivalent of IPv4 address space specifically reserved for any special purpose by an RIR will not be counted against that RIR when determining eligibility unless that space was received from the IANA reclamation pool. Any RIR that is formed after the ICANN Board of Directors has ratified this policy is not eligible to utilize this policy to obtain IPv4 address space from the IANA. These revisions are being proposed in all regions in order to maintain consistency in the policy text on the global level. Thank you for your consideration. ~Chris -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From randy at psg.com Sun Sep 19 20:41:16 2010 From: randy at psg.com (Randy Bush) Date: Sun, 19 Sep 2010 14:41:16 -0400 Subject: [address-policy-wg] Suggested updates to 2010-05 (Global Policy for IPv4 Allocation by the IANA post exhaustion) In-Reply-To: References: Message-ID: there was a policy passed in all regions except arin. get a bleeping clue. randy From marty at akamai.com Mon Sep 20 01:56:40 2010 From: marty at akamai.com (Hannigan, Martin) Date: Sun, 19 Sep 2010 19:56:40 -0400 Subject: [address-policy-wg] Suggested updates to 2010-05 (Global Policy for IPv4 Allocation by the IANA post exhaustion) In-Reply-To: Message-ID: Randy, The clue is that without a compromise nothing with pass anywhere. That would be a more sad state of affairs. Best, -M< On 9/19/10 2:41 PM, "Randy Bush" wrote: > there was a policy passed in all regions except arin. get a bleeping > clue. > > randy > From filiz at ripe.net Mon Sep 20 13:16:49 2010 From: filiz at ripe.net (Filiz Yilmaz) Date: Mon, 20 Sep 2010 13:16:49 +0200 Subject: [address-policy-wg] Fwd: New Document: Policy Development Process in RIPE (ripe-500) References: <4CCAB1A3-FE09-4CF5-86C0-F91213FABD89@ripe.net> Message-ID: <245299DB-D1F6-4951-B0B3-AAD646935BC8@ripe.net> Further apologies for the missing link to the document in my previous mail. You can find the new document at: http://www.ripe.net/ripe/docs/ripe-500.html Kind regards, Filiz Yilmaz Policy Development Manager RIPE NCC Begin forwarded message: > From: Filiz Yilmaz > Date: 20 September 2010 13:02:42 GMT+02:00 > To: policy-announce at ripe.net, ripe-list at ripe.net > Cc: RIPE Address Policy Working Group > Subject: New Document: Policy Development Process in RIPE (ripe-500) > > > [Apologies for duplicate emails] > > Dear Colleagues, > > A new RIPE Document, ripe-500, "Policy Development Process in RIPE", > is published. > > This document obsoletes the previous version of the document, > ripe-470. > The main feature of the updated document is that it better explains > the Impact Analysis that the RIPE NCC performs within the RIPE > Policy Development Process. > > Kind regards, > > Filiz Yilmaz > Policy Development Manager > RIPE NCC > From filiz at ripe.net Mon Sep 20 13:02:42 2010 From: filiz at ripe.net (Filiz Yilmaz) Date: Mon, 20 Sep 2010 13:02:42 +0200 Subject: [address-policy-wg] New Document: Policy Development Process in RIPE (ripe-500) Message-ID: <4CCAB1A3-FE09-4CF5-86C0-F91213FABD89@ripe.net> [Apologies for duplicate emails] Dear Colleagues, A new RIPE Document, ripe-500, "Policy Development Process in RIPE", is published. This document obsoletes the previous version of the document, ripe-470. The main feature of the updated document is that it better explains the Impact Analysis that the RIPE NCC performs within the RIPE Policy Development Process. Kind regards, Filiz Yilmaz Policy Development Manager RIPE NCC From cgrundemann at gmail.com Mon Sep 20 23:55:29 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 20 Sep 2010 15:55:29 -0600 Subject: [address-policy-wg] Suggested updates to 2010-05 (Global Policy for IPv4 Allocation by the IANA post exhaustion) In-Reply-To: References: Message-ID: On Sun, Sep 19, 2010 at 12:41, Randy Bush wrote: > there was a policy passed in all regions except arin. ?get a bleeping > clue. I will try to explain my reasoning for supporting this proposal once more: 1) The previous global policy referred to above had two very distinct provisions; to allow IANA to accept and re-allocate space and to mandate that all space returned to all RIRs was returned to IANA. 2) The policy that I helped write, under discussion here, addresses the former provision. 3) This new policy proposal in no way precludes another proposal to address the latter provision if folks feel that is the correct course of action. In fact it likely facilitates it. We (the co-authors/contributers) see the absolute need for IANA to be able to accept and distribute IPv4 space post free-pool depletion and we see that the previous proposal appears to be at an impasse. Hence this proposal. Thus, the fact that the previous proposal has not been adopted globally is actually the very reason that we need this policy. It is not, as the OP seems to suggest, a reason not to adopt this proposal. Cheers, ~Chris > > randy > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From nick at inex.ie Tue Sep 21 00:20:17 2010 From: nick at inex.ie (Nick Hilliard) Date: Mon, 20 Sep 2010 23:20:17 +0100 Subject: [address-policy-wg] Suggested updates to 2010-05 (Global Policy for IPv4 Allocation by the IANA post exhaustion) In-Reply-To: References: Message-ID: <4C97DE21.6090505@inex.ie> On 20/09/2010 22:55, Chris Grundemann wrote: > Thus, the fact that the previous proposal has not been adopted > globally is actually the very reason that we need this policy. It is > not, as the OP seems to suggest, a reason not to adopt this proposal. Regardless of the history of the previous proposal, history will not look back kindly if we collectively flail our arms in the air and claim "it would never work, so there's no point in even trying". Call this naivety, idealism, or stupidity - I don't really care. The policy has merit and refusing to deal with it now (while we're still vaguely sanguine about IPv4 address allocation) will merely create a much more troublesome environment for attempting to get any sort of global agreement of any sort in the future (when no-one will be even remotely happy about allocation policy). Nick From nick at inex.ie Tue Sep 21 00:26:36 2010 From: nick at inex.ie (Nick Hilliard) Date: Mon, 20 Sep 2010 23:26:36 +0100 Subject: [address-policy-wg] Suggested updates to 2010-05 (Global Policy for IPv4 Allocation by the IANA post exhaustion) In-Reply-To: References: Message-ID: <4C97DF9C.9000406@inex.ie> On 19/09/2010 19:12, Chris Grundemann wrote: > Problem #1: The allocation method was unfair. "Fairness" is a remarkably mercurial concept which has little or no meaning in an environment of plenty. It's much easier to talk about "unfairness": which is the state of mind of candidate A, when candidate B receives preferential treatment. Just look at squabbling children and their exquisitely honed sense of personal injustice. I would suggest that - regardless of the rules set up now - there will be a lot of "unfairness" and "injustice" of this sort once address space exhaustion hits. Nick From cgrundemann at gmail.com Tue Sep 21 01:12:25 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 20 Sep 2010 17:12:25 -0600 Subject: [address-policy-wg] Suggested updates to 2010-05 (Global Policy for IPv4 Allocation by the IANA post exhaustion) In-Reply-To: <4C97DF9C.9000406@inex.ie> References: <4C97DF9C.9000406@inex.ie> Message-ID: On Mon, Sep 20, 2010 at 16:26, Nick Hilliard wrote: > On 19/09/2010 19:12, Chris Grundemann wrote: > > Problem #1: The allocation method was unfair. > > "Fairness" is a remarkably mercurial concept which has little or no meaning > in an environment of plenty. It's much easier to talk about "unfairness": > which is the state of mind of candidate A, when candidate B receives > preferential treatment. Just look at squabbling children and their > exquisitely honed sense of personal injustice. > Understood. As a parent I definitely see that the term can be used subjectively as well as objectively. Letting one child eat all of the food in the house while the other starves falls clearly into the latter case, imo. This is very similar to the problem we believe that we have corrected in the new text; as described in the OP: The intent was never for a single RIR to be able to be allocated all available address space in mass quantities. We do however want any available address space to be utilized if there is need. We've addressed what we would characterize as a mechanical issue. > > I would suggest that - regardless of the rules set up now - there will be a > lot of "unfairness" and "injustice" of this sort once address space > exhaustion hits. > I agree in that there will be "pain" felt by everyone and thus very likely calls of "unfairness" and "injustice." I believe that our goal as stewards of the Internet (or at the very least policy makers) should be to try to spread the pain as proportionally as possible - so that such inevitable cries are much more of the subjective type than the objective. > > Nick > > Best, ~Chris (speaking for myself - I did not clear this response with other authors, etc) -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgrundemann at gmail.com Tue Sep 21 01:26:21 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 20 Sep 2010 17:26:21 -0600 Subject: [address-policy-wg] Suggested updates to 2010-05 (Global Policy for IPv4 Allocation by the IANA post exhaustion) In-Reply-To: <4C97DE21.6090505@inex.ie> References: <4C97DE21.6090505@inex.ie> Message-ID: On Mon, Sep 20, 2010 at 16:20, Nick Hilliard wrote: > > Regardless of the history of the previous proposal, history will not look > back kindly if we collectively flail our arms in the air and claim "it > would never work, so there's no point in even trying". Call this naivety, > idealism, or stupidity - I don't really care. The policy has merit and > refusing to deal with it now (while we're still vaguely sanguine about IPv4 > address allocation) will merely create a much more troublesome environment > for attempting to get any sort of global agreement of any sort in the > future (when no-one will be even remotely happy about allocation policy). > I completely agree. You have, in fact, written a fairly accurate description of why I am putting my time and effort into this policy. Now is the time to act - we can neither live in the past nor expect the future to take care of itself. ~Chris (again speaking entirely on my own) > > Nick > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emadaio at ripe.net Tue Sep 21 17:05:10 2010 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 21 Sep 2010 17:05:10 +0200 Subject: [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8) Message-ID: <20100921150510.EB5DD6A002@postboy.ripe.net> Dear Colleagues, Following the feedback received,a new version of the policy proposal 2010-02 'Allocations from the last /8' is edited and published. The draft document and the impact analysis for the proposal have also been published. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2010-02.html and the draft document at: http://ripe.net/ripe/draft-documents/ripe-492-draft2010-02.html We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 19 October 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC From filiz at ripe.net Wed Sep 22 10:50:57 2010 From: filiz at ripe.net (Filiz Yilmaz) Date: Wed, 22 Sep 2010 10:50:57 +0200 Subject: [address-policy-wg] Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks to Regional Internet Registries Message-ID: Dear Colleagues, Proposal 2009-07, "Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries", was accepted by the RIPE community in September 2009. This proposal has since reached consensus in all other RIR communities and it is now also ratified by ICANN in September 2010. You can find the policy documented at: http://www.ripe.net/ripe/docs/ripe-480.html Kind regards, Filiz Yilmaz Policy Development Manager RIPE NCC From nigel at titley.com Sat Sep 25 14:25:10 2010 From: nigel at titley.com (Nigel Titley) Date: Sat, 25 Sep 2010 13:25:10 +0100 Subject: [address-policy-wg] Suggested updates to 2010-05 (Global Policy for IPv4 Allocation by the IANA post exhaustion) In-Reply-To: References: Message-ID: <4C9DEA26.1020309@titley.com> On 19/09/2010 19:12, Chris Grundemann wrote: > Hello APWG, > > After receiving great feedback in several regions, the original > authors of the proposal have discussed all of the feedback received > and our suggested revisions are below: > ..... > These revisions are being proposed in all regions in order to maintain > consistency in the policy text on the global level. Thank you for your > consideration. > Just a note that this policy is now exactly equivalent to policy proposal 2009-01 as passed in the ARIN region but which failed globally. Nigel From emadaio at ripe.net Mon Sep 27 13:30:27 2010 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 27 Sep 2010 13:30:27 +0200 Subject: [address-policy-wg] 2008-07 Policy Proposal (Ensuring efficient use of historical IPv4 resources): possible withdrawal Message-ID: <20100927113027.EFAE36A00B@postboy.ripe.net> Dear Colleagues, RIPE policy proposal 2008-07, "Ensuring efficient use of historical IPv4 resources", has completed the Discussion Phase. The proposer has decided to withdraw this proposal. If there are any volunteers who would like to take over this proposal and re-submit it to the Policy Development Process (PDP), please email address-policy-wg at ripe.net. The proposal is available online at: http://ripe.net/ripe/policies/proposals/2008-07.html Regards Emilio Madaio Policy Development Officer RIPE NCC From gert at space.net Mon Sep 27 17:38:04 2010 From: gert at space.net (Gert Doering) Date: Mon, 27 Sep 2010 17:38:04 +0200 Subject: [address-policy-wg] Call for agenda items for RIPE 61 in Rome Message-ID: <20100927153804.GH32268@Space.Net> Hi AP WG members, RIPE 61 in Rome is coming up quickly, and Sander and I have started building the agenda. It will, of course, contain all the usual stuff ("what has happened in policy development in the last 6 months", "discussion of new policy proposals") but if there is anything else you want to see discussed, please let us know. Either here, or via apwg-chairs at ripe.net A first draft of the agenda will be published soon. Gert Doering -- Address Policy WG Chair -- did you enable IPv6 on something today...? 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 emadaio at ripe.net Thu Sep 30 16:37:20 2010 From: emadaio at ripe.net (Emilio Madaio) Date: Thu, 30 Sep 2010 16:37:20 +0200 Subject: [address-policy-wg] 2010-05 Draft Document will be produced (Global Policy for IPv4 Allocation by the IANA post exhaustion) Message-ID: <20100930143720.7677E6A00A@postboy.ripe.net> Dear Colleagues, The discussion period for the global policy proposal described in 2010-05 has ended. A draft document and an Impact Analysis will now be prepared for review. We will publish the document shortly and we will make an announcement. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2010-05.html Regards Emilio Madaio Policy Development Officer RIPE NCC