From emadaio at ripe.net Wed Aug 4 16:03:06 2010 From: emadaio at ripe.net (Emilio Madaio) Date: Wed, 04 Aug 2010 16:03:06 +0200 Subject: [address-policy-wg] 2010-02 Review Period has ended (Allocations from the last /8) Message-ID: <20100804140306.74FD76A005@postboy.ripe.net> Dear Gert and Sander, The review period for the new RIPE Document described in proposal 2010-02 has ended. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2010-02.html Please reply to this email to let us know how you would like to proceed. * Do you want to move the proposal to "Last Call"? The Last Call period is four weeks. * Do you want us to edit the draft document text? Please tell us the details that you want us to edit. * Do you want to extend the review period? Please let us know what date you wish to extend it to, and we will tell the RIPE community. * Do you want to withdraw this proposal? Please let us know your decision in the next seven days. Below a brief summary of the discussion in the Review Phase. Some observations were made on some points of the new proposal draft and on the possible consequences to the proposal implementation: -there should be a need to mention how the PI space will be handled (Tulyev, Davidson, Kuenzler); -it may be prudent to implement the policy on the last /8 contiguous block from IANA, rather than the potential fragmented last available /8 in the NCC address pool(Anderson); -possible situations when an LIR cannot justify an immediate need for a /22 (Anderson) and therefore a suggestion to allow extra /22 assignment overtime (Schliesser); -impossibility to assign Anycast address(Tulyev). The archived discussion is available at http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2010/index-thread.html We look forward to your response. Kind Regards Emilio Madaio Policy Development Officer RIPE NCC From emadaio at ripe.net Wed Aug 4 16:30:09 2010 From: emadaio at ripe.net (Emilio Madaio) Date: Wed, 04 Aug 2010 16:30:09 +0200 Subject: [address-policy-wg] 2010-02 Review Period has ended (Allocations from the last /8) In-Reply-To: <20100804140306.74FD76A005@postboy.ripe.net> References: <20100804140306.74FD76A005@postboy.ripe.net> Message-ID: <4C597971.7010505@ripe.net> Dear Colleagues, The mail you received earlier today on the address-policy-wg mailing list entitled "2010-02 Review Period has ended (Allocations from the last /8)" was sent in error. Please disregard that email. Apologies for any inconvenience. Regards, Emilio Madaio On 8/4/10 4:03 PM, Emilio Madaio wrote: > Dear Gert and Sander, > > The review period for the new RIPE Document described in proposal > 2010-02 has ended. > > > You can find the full proposal at: > > http://ripe.net/ripe/policies/proposals/2010-02.html > > > > Please reply to this email to let us know how you would like to proceed. > > * Do you want to move the proposal to "Last Call"? The Last Call > period is four weeks. > > * Do you want us to edit the draft document text? Please tell us the > details that you want us to edit. > > * Do you want to extend the review period? Please let us know what > date you wish to extend it to, and we will tell the RIPE community. > > * Do you want to withdraw this proposal? > > Please let us know your decision in the next seven days. > > Below a brief summary of the discussion in the Review Phase. Some > observations were made on some points of the new proposal draft and on > the possible consequences to the proposal implementation: > > -there should be a need to mention how the PI space will be handled > (Tulyev, Davidson, Kuenzler); > > -it may be prudent to implement the policy on the last /8 contiguous > block from IANA, rather than the potential fragmented last available > /8 in the NCC address pool(Anderson); > > -possible situations when an LIR cannot justify an immediate need for > a /22 (Anderson) and therefore a suggestion to allow extra /22 > assignment overtime (Schliesser); > > -impossibility to assign Anycast address(Tulyev). > > > The archived discussion is available at > > http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2010/index-thread.html > > We look forward to your response. > > Kind Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > > From nick at inex.ie Thu Aug 5 11:33:30 2010 From: nick at inex.ie (Nick Hilliard) Date: Thu, 05 Aug 2010 10:33:30 +0100 Subject: [address-policy-wg] New Draft Document: Autonomous System (AS) Number Assignment Policies In-Reply-To: References: Message-ID: <4C5A856A.2000806@inex.ie> On 15/07/2010 15:38, Filiz Yilmaz wrote: > Please review the text and send any feedback you might have to the Address > Policy Working Group mailing list. > > The period for review is two weeks and lasts until 29 July 2010. These changes look fine to me: there is no substantial change to the policy, and the document looks much better. Nick From nick at inex.ie Thu Aug 5 11:36:09 2010 From: nick at inex.ie (Nick Hilliard) Date: Thu, 05 Aug 2010 10:36:09 +0100 Subject: [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8) In-Reply-To: <270F6D72-1CCF-4B13-B5EC-7EB688607E60@nosignal.org> References: <20100707073247.76DB06A013@postboy.ripe.net> <4C345899.6020609@ukraine.su> <4C34FCD6.3060901@cisco.com> <270F6D72-1CCF-4B13-B5EC-7EB688607E60@nosignal.org> Message-ID: <4C5A8609.7000507@inex.ie> On 08/07/2010 16:58, Andy Davidson wrote: > What is the rationale to stop assigning PI ? I, too, am very concerned that PI has been dropped as a consideration from the last /8. This will disenfranchise a disproportionately large number of end users. Nick From gert at space.net Mon Aug 9 16:08:02 2010 From: gert at space.net (Gert Doering) Date: Mon, 9 Aug 2010 16:08:02 +0200 Subject: [address-policy-wg] 2010-01 New Draft Document Published (Temporary Internet Number Assignment Policies) In-Reply-To: <20100708143739.6D4F36A021@postboy.ripe.net> References: <20100708143739.6D4F36A021@postboy.ripe.net> Message-ID: <20100809140802.GA61900@Space.Net> Hi APWG folks, since *no* comments were received on the revised 2010-01 document announced by Emilio some 6 weeks ago, we can't move forward with this ("silence is consent" is valid in Last Call, but not in the discussion and review phases). Please read the document and tell us whether you want to see this become policy or not. We'll prolong the review period by 4 more weeks, to give you time to read & comment this. Thanks, Gert Doering, APWG chair On Thu, Jul 08, 2010 at 04:37:38PM +0200, Emilio Madaio wrote: > PDP Number: 2010-01 > Temporary Internet Number Assignment Policies > > Dear Colleagues, > > The text of the policy proposal 2010-01 has been revised based on the > community feedback received. > > The draft policy document and the impact analysis for the proposal > have also been published. > > > > You can find the full proposal at: > > http://ripe.net/ripe/policies/proposals/2010-01.html > > and the draft document at: > > http://ripe.net/ripe/draft-documents/ripe-new-draft-2010-01.html > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 5 August 2010. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > Gert Doering -- NetMaster -- 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 marcoh at marcoh.net Mon Aug 9 16:29:48 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Mon, 9 Aug 2010 16:29:48 +0200 Subject: [address-policy-wg] 2010-01 New Draft Document Published (Temporary Internet Number Assignment Policies) In-Reply-To: <20100809140802.GA61900@Space.Net> References: <20100708143739.6D4F36A021@postboy.ripe.net> <20100809140802.GA61900@Space.Net> Message-ID: On 9 aug 2010, at 16:08, Gert Doering wrote: > Hi APWG folks, > > since *no* comments were received on the revised 2010-01 document > announced by Emilio some 6 weeks ago, we can't move forward with this > ("silence is consent" is valid in Last Call, but not in the discussion > and review phases). > > Please read the document and tell us whether you want to see this > become policy or not. > > We'll prolong the review period by 4 more weeks, to give you time > to read & comment this. With no hats other than that of a concerned citizen who happened to be involved in conference assignments in the past. I in general agree with this proposal. However I have some concerns regarding the actual content and limitations set in this proposal. I think 7 days beyond the length of a conference is too short, it usually takes a while to get things properly routed and being able to announce the prefix while you go that process I think is mandatory to be able to debug. I would set this to a month minimum, maybe with a note that after the conference a maximum of 7 days is allowed for cleanup. Second concern is cool off or quarantine of previously used space, you probably want some time in between assignments of these resources just in case. For some situations there might even be privacy concerns with this as a block which was recently used for some experiment all of a sudden starts to carry real data from real people visiting a conference. Question for the proposer(s) what about polution, using the same space for experiments as well as conferences in any shape and size might have impact on the reputation of such blocks. I also think that maybe (RIS ?) we should announce a proper last resort when these blocks are not in use, otherwise they are likely to become an easy target for hijacking and this will further damage the usuability of these blocks in the long run. Oh and how should the NCC handle when there are more requests as resources ? This is after all a fiinite pool, if we make it first come first serrve, the draft text should mention somehting. If we can decide on a preference it shouls also be included in the text. Groet, MarcoH From emadaio at ripe.net Mon Aug 9 16:34:13 2010 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 09 Aug 2010 16:34:13 +0200 Subject: [address-policy-wg] 2010-04 New Draft Document Published (80% Rule Ambiguity Cleanup) Message-ID: <20100809143413.C08876A01C@postboy.ripe.net> Dear Colleagues, 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 and the draft document at: http://www.ripe.net/ripe/draft-documents/ripe-492-draft2010-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. Regards Emilio Madaio Policy Development Officer RIPE NCC From slz at baycix.de Mon Aug 9 17:04:11 2010 From: slz at baycix.de (Sascha Lenz) Date: Mon, 09 Aug 2010 17:04:11 +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: <4C6018EB.90806@baycix.de> Hi, Am 09.08.2010 16:34, schrieb Emilio Madaio: > Dear Colleagues, > > 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 > > and the draft document at: > > http://www.ripe.net/ripe/draft-documents/ripe-492-draft2010-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. clarifications are always good. Since it's just more or less a wording change and was discussed before, i'd say move on with it! -- ===================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Design & Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ===================================================================== From emadaio at ripe.net Tue Aug 10 16:24:46 2010 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 10 Aug 2010 16:24:46 +0200 Subject: [address-policy-wg] 2010-01 Review Period extended until 7 September (Temporary Internet Number Assignment Policies) Message-ID: <20100810142446.3B1546A020@postboy.ripe.net> Dear Colleagues, The Review Period for the proposal 2010-01 has been extended until 7 September. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2010-01.html We encourage you to review this policy proposal and send your comments to . Regards, Emilio Madaio Policy Development Officer RIPE NCC From niels=apwg at bakker.net Tue Aug 10 18:07:52 2010 From: niels=apwg at bakker.net (Niels Bakker) Date: Tue, 10 Aug 2010 18:07:52 +0200 Subject: [address-policy-wg] 2010-01 New Draft Document Published (Temporary Internet Number Assignment Policies) In-Reply-To: References: <20100708143739.6D4F36A021@postboy.ripe.net> <20100809140802.GA61900@Space.Net> Message-ID: <20100810160752.GS50223@burnout.tpb.net> * marcoh at marcoh.net (Marco Hogewoning) [Mon 09 Aug 2010, 16:30 CEST]: >I think 7 days beyond the length of a conference is too short, it >usually takes a while to get things properly routed and being able >to announce the prefix while you go that process I think is >mandatory to be able to debug. I would set this to a month minimum, >maybe with a note that after the conference a maximum of 7 days is >allowed for cleanup. Plus, especially for conferences, a relatively significant amount of time (compared to the length of most conferences) is needed beforehand to have align connectivity, update IRRdbs, have filters updated etc. In my experience this can take a few weeks at least. Likewise, 7 days is short given that in the case of temporary ASN assignments the conference depends on its upstreams to update their IRRdb objects before they can be returned to the NCC. >Second concern is cool off or quarantine of previously used space, >you probably want some time in between assignments of these >resources just in case. For some situations there might even be >privacy concerns with this as a block which was recently used for >some experiment all of a sudden starts to carry real data from real >people visiting a conference. Given experience with "debogonising" new IANA assignments, this is a valid concern. The RIPE NCC can alleviate this by assigning in an LRU fashion from the block(s) reserved for this purpose. -- Niels. -- "It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account." -- roy edroso, alicublog.blogspot.com From emadaio at ripe.net Wed Aug 11 16:26:59 2010 From: emadaio at ripe.net (Emilio Madaio) Date: Wed, 11 Aug 2010 16:26:59 +0200 Subject: [address-policy-wg] 2010-02 Draft Document will be edited (Allocations from the last /8) Message-ID: <20100811142700.29CE96A011@postboy.ripe.net> Dear Colleagues, The review period for the proposal 2010-02 has ended. Following the feedback received, the draft document(s) will be edited. We will publish the updated text soon and we will tell you when it is available. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2010-02.html Regards Emilio Madaio Policy Development Officer RIPE NCC From noreply at ripe.net Thu Aug 12 12:22:20 2010 From: noreply at ripe.net (Axel Pawlik) Date: Thu, 12 Aug 2010 12:22:20 +0200 Subject: [address-policy-wg] NRO NC Call for Nominations Message-ID: <4C63CB5C.7090609@ripe.net> [Apologies for duplicate emails] Dear Colleagues, This is a call for nominations from the RIPE NCC service region to fill one vacant seat on the Number Resource Organization (NRO) Number Council (NC). The term of Hans Petter Holen, who was elected to the NRO NC in January 2008, ends on 31 December 2010. The election to the NRO NC seat will take place during a Plenary session at the RIPE 61 Meeting to be held in Rome, Italy from 15-19 November 2010. All members of the Internet community who are present at the Plenary session may vote in the election. The deadline for nominations is 15 October 2010. Any individual residing within the RIPE NCC service region is eligible for nomination, except Regional Internet Registry (RIR) staff members. Self-nominations are permitted. Please send your nominations to by 23:00 UTC on 15 October 2010. All confirmed nominations will be listed on the RIPE NCC website by 17 October 2010. All nominees may submit a written statement in support of their nomination for publication on the RIPE NCC website. Other individuals may express support for nominated individuals by sending an email to . Expressions of support will also be published on the RIPE NCC website. To find out more about the NRO NC and the election process, please see: http://www.ripe.net/info/resource-admin/nro2010/ Regards, Axel Pawlik Managing Director RIPE NCC From slz at baycix.de Mon Aug 16 10:45:10 2010 From: slz at baycix.de (Sascha Lenz) Date: Mon, 16 Aug 2010 10:45:10 +0200 Subject: [address-policy-wg] 2010-01 New Draft Document Published (Temporary Internet Number Assignment Policies) In-Reply-To: <20100809140802.GA61900@Space.Net> References: <20100708143739.6D4F36A021@postboy.ripe.net> <20100809140802.GA61900@Space.Net> Message-ID: <4C68FA96.3010403@baycix.de> Hi, Am 09.08.2010 16:08, schrieb Gert Doering: > Hi APWG folks, > > since *no* comments were received on the revised 2010-01 document > announced by Emilio some 6 weeks ago, we can't move forward with this > ("silence is consent" is valid in Last Call, but not in the discussion > and review phases). i know that only commenting on "interesting" policies which concern oneself is a bad habbit, but really, how many people does this one concern at all? The proposer should have sneaked something in the text like "..and regular IPv4 assignments will stop on 31.12.2010." or so :-) > > Please read the document and tell us whether you want to see this > become policy or not. > > We'll prolong the review period by 4 more weeks, to give you time > to read& comment this. Since i haven't needed any temp. assignments yet, i can't say much about the text itself - i think the comments from Marco etc. were reasonable though. I just like to comment on the general idea now. Basically i didn't really react to this proposal because my first thought was "on no, not another legacy IP regulation policy. I don't want any new ones about IPv4.". OTOH since it only concerns TEMPORARY assignments, it's nothing permanent and can be changed again any time in the future. AND it even does help a bit with the depletion of IPv4 since there would be some medium large block being reserved and taken out of the free pool for this ;-) So, in the greater sense of why i think is right, i have no problems with this policy, and it might help some people organizing bigger conferences and similar events in the near future. Since it seems like bigger continuous PI blocks already get scarce, it's about time to think about such things requiring a larger block. No objections. -- ===================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Design & Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ===================================================================== From emadaio at ripe.net Thu Aug 19 17:02:20 2010 From: emadaio at ripe.net (Emilio Madaio) Date: Thu, 19 Aug 2010 17:02:20 +0200 Subject: [address-policy-wg] IETF Internet-Draft "IANA Reserved IPv4 Prefix for IPv6 Transition" Message-ID: <4C6D477C.5050801@ripe.net> Dear Colleagues, At the IETF 78 Meeting in Maastricht in July 2010, the Operations and Management Area Working Group (OPSAWG) presented "IANA Reserved IPv4 Prefix for IPv6 Transition". This presentation introduced the Internet draft document that specifies the use of a reserved IANA /8 address block from its remaining pool of unallocated IPv4 addresses. The reserved address space would be used as "Shared Transition Space", intended as: "[...] IPv4 address space reserved for Service Provider or large enterprise use with the purpose of facilitating IPv6 transition and IPv4 coexistence deployment. This space SHOULD only be used for the purpose of providing NAT'ed IPv4 access to subscriber networks or IPv6-in-IPv4 tunnels during the transition to full IPv6 deployment. These addresses MAY be used without any coordination with IANA or any other Internet registry. " The Internet draft document is available at: http://datatracker.ietf.org/doc/draft-weil-opsawg-provider-address-space/ Discussion on this draft document is ongoing at: http://www.ietf.org/mail-archive/web/opsawg/current/maillist.html Kind Regards, Emilio Madaio Policy Development Officer RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From emadaio at ripe.net Mon Aug 23 16:23:33 2010 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 23 Aug 2010 16:23:33 +0200 Subject: [address-policy-wg] 2010-05 New Policy Proposal (Global Policy for IPv4 Allocation by the IANA post exhaustion) Message-ID: <20100823145412.B28326A002@postboy.ripe.net> Dear Colleagues, A new Global Policy Proposal has been made and is now available to the RIPE Community for discussion. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2010-05.html We encourage you to review this proposal and send your comments to before 20 September 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC From grousseau at afone.com Mon Aug 23 16:55:27 2010 From: grousseau at afone.com (grousseau at afone.com) Date: Mon, 23 Aug 2010 16:55:27 +0200 Subject: [address-policy-wg] Absence [Message automatique] In-Reply-To: <20100823145412.B28326A002@postboy.ripe.net> References: <20100823145412.B28326A002@postboy.ripe.net> Message-ID: <201008231455.o7NEtRjJ015575@lame21.ldc.afone.priv> An HTML attachment was scrubbed... URL: From tore.anderson at redpill-linpro.com Sat Aug 28 19:12:24 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Sat, 28 Aug 2010 19:12:24 +0200 Subject: [address-policy-wg] 2010-05 New Policy Proposal (Global Policy for IPv4 Allocation by the IANA post exhaustion) In-Reply-To: <20100823145412.B28326A002@postboy.ripe.net> References: <20100823145412.B28326A002@postboy.ripe.net> Message-ID: <4C794378.5060600@redpill-linpro.com> * http://ripe.net/ripe/policies/proposals/2010-05.html > The reclamation pool will initially contain any fragments that may > be left over in IANA inventory. I assume these fragments are the so-called ?VARIOUS? blocks? These, that is: ? > The Reclamation Pool will be divided on CIDR boundaries and > distributed evenly to all eligible RIRs. [...] > [...] an RIR will become eligible to request address space from the IANA > Reclamation Pool [...] These two statements appear to me to contradict each other. The first seems to imply a push-based model, where the Reclamation Pool (RP) is divided in five equally large chunks and dealt out to the RIRs at the same time, in a manner very similar to the procedure in 2008-03. The second seems to imply a pull model, much like how the IANA today allocates /8s to the RIRs upon request. (If so, how much can a RIR allocate at a time? 18 months worth of consumption, like today?) Which is it? And if it is the latter, I fail to see how it will be distributed ?evenly?. It's unrealistic to assume that all RIRs will deplete at the same time. Isn't it then more likely that the first RIR(s) to deplete their inventory (and thus activate the RP) will burn through all of the RP long before the last RIR depletes its inventory and gets eligible for making use of it? Finally there's proposal 2010-02 ... If that one is accepted as currently prosposed, RIPE won't be eligible to receive anything from the RP until there's 16384 LIRs in the region who have all received an IPv6 allocation and a /22 from the last IPv4 /8. At that point, I'm not sure if anybody really cares about what happens to the remaining IPv4 space, especially as none of the 16384 LIRs that have already received their /22 from the last /8 can come back for more anyway. Should the space set aside for the implementation of 2010-02 (and similar policies in the other regions) be disregarded when determining when a RIR has exhausted its inventory? That is, a timeline like the following: 1) Receive last /8 from the IANA - set aside for 2010-02 2) Allocate/assign remaining inventory to LIRs according to ripe-492 3) Receive 1/5 (or: continuously allocate until no longer possible) from the IANA RP. Allocate/assign to LIRs according to ripe-492 4) Implement 2010-02 (using the /8 set aside in step #1) Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From emadaio at ripe.net Mon Aug 30 15:30:31 2010 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 30 Aug 2010 15:30:31 +0200 Subject: [address-policy-wg] Cosmetic Surgery Project: new revised document for Autonomous System (AS) Number Assignment Policies Message-ID: <4C7BB277.7020100@ripe.net> Dear Colleagues, At the RIPE 59 Meeting in Lisbon in October 2009, the RIPE NCC announced that it would undertake a project to improve the language of various RIPE Policy Documents, without changing their substance or meaning. This project is aimed at improving the clarity and readability of RIPE Documents. For more information, see: http://www.ripe.net/ripe/updated-documents/ The first RIPE Document to be revised was "Autonomous System (AS) Number Assignment Policies and Procedures". The revised document is now available at: http://www.ripe.net/ripe/docs/ripe-496.html The second document for review will be ripe-481, "IPv6 Address Allocation and Assignment Policy". More information about this will follow shortly Kind Regards Emilio Madaio Policy Development Officer RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgrundemann at gmail.com Mon Aug 30 20:05:51 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 30 Aug 2010 12:05:51 -0600 Subject: [address-policy-wg] 2010-05 New Policy Proposal (Global Policy for IPv4 Allocation by the IANA post exhaustion) In-Reply-To: <4C794378.5060600@redpill-linpro.com> References: <20100823145412.B28326A002@postboy.ripe.net> <4C794378.5060600@redpill-linpro.com> Message-ID: On Sat, Aug 28, 2010 at 11:12, Tore Anderson wrote: > * http://ripe.net/ripe/policies/proposals/2010-05.html > >> The reclamation pool will initially contain any fragments that may >> be left over in IANA inventory. > > I assume these fragments are the so-called ?VARIOUS? blocks? ?These, > that is: ?? > >> The Reclamation Pool will be divided on CIDR boundaries and >> distributed evenly to all eligible RIRs. > [...] >> [...] an RIR will become eligible to request address space from the IANA >> Reclamation Pool [...] > > These two statements appear to me to contradict each other. ?The first > seems to imply a push-based model, where the Reclamation Pool (RP) is > divided in five equally large chunks and dealt out to the RIRs at the > same time, in a manner very similar to the procedure in 2008-03. > > The second seems to imply a pull model, much like how the IANA today > allocates /8s to the RIRs upon request. ?(If so, how much can a RIR > allocate at a time? ?18 months worth of consumption, like today?) > > Which is it? It is a pull model with equal distribution. The key term in the first statement is "*eligible* RIRs." If three RIRs have exhausted their IPv4 address space, they all make that announcement and the subsequent request to the IANA. They then all receive one third of the Reclamation Pool (divided on CIDR boundaries). > And if it is the latter, I fail to see how it will be distributed > ?evenly?. ?It's unrealistic to assume that all RIRs will deplete at the > same time. ?Isn't it then more likely that the first RIR(s) to deplete > their inventory (and thus activate the RP) will burn through all of the > RP long before the last RIR depletes its inventory and gets eligible for > making use of it? The intent is to distribute the space evenly amongst all RIRs with need, hence the eligibility requirement. Consider a scenario where three RIRs have exhausted their IPv4 address space and the IANA has nothing to replenish them with. They all declare exhaustion and make their request to IANA. Then someone returns IPv4 space to the IANA. That space would be carved into three blocks and distributed evenly to all three exhausted RIRs. Without this policy, the IANA would have no way to distribute that space at all. > Finally there's proposal 2010-02 ... ?If that one is accepted as > currently prosposed, RIPE won't be eligible to receive anything from the > RP until there's 16384 LIRs in the region who have all received an IPv6 > allocation and a /22 from the last IPv4 /8. ?At that point, I'm not sure > if anybody really cares about what happens to the remaining IPv4 space, > especially as none of the 16384 LIRs that have already received their > /22 from the last /8 can come back for more anyway. > > Should the space set aside for the implementation of 2010-02 (and > similar policies in the other regions) be disregarded when determining > when a RIR has exhausted its inventory? ?That is, a timeline like the > following: > > 1) Receive last /8 from the IANA - set aside for 2010-02 > 2) Allocate/assign remaining inventory to LIRs according to ripe-492 > 3) Receive 1/5 (or: continuously allocate until no longer possible) from > the IANA RP. ?Allocate/assign to LIRs according to ripe-492 > 4) Implement 2010-02 (using the /8 set aside in step #1) The authors of this proposal (I included) will take this suggestion into consideration. Our largest concern is that this may create a loophole by which an RIR could stockpile IPv4 addresses to the disadvantage of the other regions. Cheers, ~Chris > > Best regards, > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com/ > Tel: +47 21 54 41 27 > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From tore.anderson at redpill-linpro.com Mon Aug 30 20:49:20 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Mon, 30 Aug 2010 20:49:20 +0200 Subject: [address-policy-wg] 2010-05 New Policy Proposal (Global Policy for IPv4 Allocation by the IANA post exhaustion) In-Reply-To: References: <20100823145412.B28326A002@postboy.ripe.net> <4C794378.5060600@redpill-linpro.com> Message-ID: <4C7BFD30.9090409@redpill-linpro.com> Hi Chris, * Chris Grundemann > It is a pull model with equal distribution. The key term in the > first statement is "*eligible* RIRs." If three RIRs have exhausted > their IPv4 address space, they all make that announcement and the > subsequent request to the IANA. They then all receive one third of the > Reclamation Pool (divided on CIDR boundaries). I see. So, what exactly prevents something like this from happening: Day 1: 0 RIRs eligible, 125.4M addresses in RP Day 2: RIR ?Red? depletes its inventory, now only RIR eligible for RP Day 3: RIR ?Red? requests and receives its 125.4M/1 share of the RP Day 4: RIR ?Blue? depletes its inventory, but can't receive anything from the now-empty RP. Repeat for remaining three RIRs. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From cgrundemann at gmail.com Mon Aug 30 21:20:17 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 30 Aug 2010 13:20:17 -0600 Subject: [address-policy-wg] 2010-05 New Policy Proposal (Global Policy for IPv4 Allocation by the IANA post exhaustion) In-Reply-To: <4C7BFD30.9090409@redpill-linpro.com> References: <20100823145412.B28326A002@postboy.ripe.net> <4C794378.5060600@redpill-linpro.com> <4C7BFD30.9090409@redpill-linpro.com> Message-ID: On Mon, Aug 30, 2010 at 12:49, Tore Anderson wrote: > Hi Chris, > > * Chris Grundemann > >> It is a pull model with equal distribution. The key term in the >> first statement is "*eligible* RIRs." If three RIRs have exhausted >> their IPv4 address space, they all make that announcement and the >> subsequent request to the IANA. They then all receive one third of the >> Reclamation Pool (divided on CIDR boundaries). > > I see. ?So, what exactly prevents something like this from happening: > > Day 1: ?0 RIRs eligible, 125.4M addresses in RP > Day 2: ?RIR ?Red? depletes its inventory, now only RIR eligible for RP > Day 3: ?RIR ?Red? requests and receives its 125.4M/1 share of the RP > Day 4: ?RIR ?Blue? depletes its inventory, but can't receive anything > ? ? ? ?from the now-empty RP. ?Repeat for remaining three RIRs. Thanks Tore, A similar concern was raised by folks in the APNIC region and we (the group of authors) are currently discussing some possible changes or additional text to prevent this scenario. We were originally operating under the impression that eligible RIRs would already be in line waiting for space before it was returned. Please let me know if you would like to join the authors group, we would appreciate your ideas on how to make the proposed policy better. ~Chris > > Best regards, > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com/ > Tel: +47 21 54 41 27 > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From tore.anderson at redpill-linpro.com Mon Aug 30 22:51:46 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Mon, 30 Aug 2010 22:51:46 +0200 Subject: [address-policy-wg] 2010-05 New Policy Proposal (Global Policy for IPv4 Allocation by the IANA post exhaustion) In-Reply-To: References: <20100823145412.B28326A002@postboy.ripe.net> <4C794378.5060600@redpill-linpro.com> <4C7BFD30.9090409@redpill-linpro.com> Message-ID: <4C7C19E2.3000208@redpill-linpro.com> Hi again, * Chris Grundemann > A similar concern was raised by folks in the APNIC region and we > (the group of authors) are currently discussing some possible changes > or additional text to prevent this scenario. We were originally > operating under the impression that eligible RIRs would already be in > line waiting for space before it was returned. The proposal says the following: ?The reclamation pool will initially contain any fragments that may be left over in IANA inventory?. You didn't comment on it in your first reply, but if these fragments indeed are the unused space in the legacy /8s (I don't know what else they could be), the initial contents of the RP would be some 125.4M addresses, according to Geoff Huston's IPv4 Address Report (http://ipv4.potaroo.net/). That's a sizable chunk... > Please let me know if you would like to join the authors group, we > would appreciate your ideas on how to make the proposed policy > better. I don't really have any suggestions for alternative text for you, but I'd be happy to give you my feedback on any draft updates you might have. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From cgrundemann at gmail.com Mon Aug 30 23:22:15 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 30 Aug 2010 15:22:15 -0600 Subject: [address-policy-wg] 2010-05 New Policy Proposal (Global Policy for IPv4 Allocation by the IANA post exhaustion) In-Reply-To: <4C7C19E2.3000208@redpill-linpro.com> References: <20100823145412.B28326A002@postboy.ripe.net> <4C794378.5060600@redpill-linpro.com> <4C7BFD30.9090409@redpill-linpro.com> <4C7C19E2.3000208@redpill-linpro.com> Message-ID: On Mon, Aug 30, 2010 at 14:51, Tore Anderson wrote: > The proposal says the following: ??The reclamation pool will initially > contain any fragments that may be left over in IANA inventory?. > > You didn't comment on it in your first reply, but if these fragments > indeed are the unused space in the legacy /8s (I don't know what else > they could be), the initial contents of the RP would be some 125.4M > addresses, according to Geoff Huston's IPv4 Address Report > (http://ipv4.potaroo.net/). ?That's a sizable chunk... It certainly is. When this topic came up in our initial conversations, we asked an IANA representative about fragments and were told that IANA did not currently have any. My understanding is that this may be due to a deal that was struck between the IANA and the NRO - but I do not have any authoritative information on that at this time. Geoff Huston's report states that: "At the time IANA reaches the last 5 /8s (the "IANA Exhaustion time" as defined by current address allocation policies), these unassigned addresses in the legacy /8s are then distributed evenly to the RIRs." I am not sure where this information came from though, since this is not spelled out in the "Allocation of the Remaining IPv4 Address Space" policy (http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm) as far as I can discern. And of course the IANA report (http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml) shows all of the "various/legacy" /8s as being administered by individual RIRs, since it only has a /8 granularity. So there is some confusion (on my part at least) as to where these fragments currently reside and who has responsibility for them. Perhaps if someone from IANA monitors this list they can chime in? If not, I and the other authors will certainly be following up to iron these fairly significant details out. I apologize for not having a more complete answer. > I don't really have any suggestions for alternative text for you, but > I'd be happy to give you my feedback on any draft updates you might have. Thanks! ~Chris > > Best regards, > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com/ > Tel: +47 21 54 41 27 > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From scottleibrand at gmail.com Mon Aug 30 23:33:07 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 30 Aug 2010 14:33:07 -0700 Subject: [address-policy-wg] 2010-05 New Policy Proposal (Global Policy for IPv4 Allocation by the IANA post exhaustion) In-Reply-To: References: <20100823145412.B28326A002@postboy.ripe.net> <4C794378.5060600@redpill-linpro.com> <4C7BFD30.9090409@redpill-linpro.com> <4C7C19E2.3000208@redpill-linpro.com> Message-ID: <4C7C2393.5020306@gmail.com> Leo Vegoda had a good post on this same topic over on the APNIC list that may answer your question: On Mon 8/16/2010 10:54 AM, Leo Vegoda wrote: > Hi Philip, > > On 16 Aug 2010, at 4:37, Philip Smith wrote: > > [...] > >>> 5.1 Reclamation Pool >>> >>> Upon adoption of this IPv4 address policy by the ICANN Board of >>> Directors, the IANA shall establish a Reclamation Pool to be >>> utilized post RIR IPv4 exhaustion as defined in Section 4. The >>> reclamation pool will initially contain any fragments that may be >>> left over in IANA inventory. >> I understood that IANA was exhausting its entire pool. Or is exhaustion >> really just complete /8s? It would be helpful if someone from IANA could >> clarify as I was under the impression that remaining fragments would be >> distributed as well, certainly before IANA declared that the cupboard >> was bare. The remaining fragments are not insignificant. > I can't speak for the authors but I can describe what we "have in stock" and what the ratified policies allows us to do. The only IPv4 address blocks we have with an UNALLOCATED status are whole /8s. Further, the current policy we implement only allows us to allocate /8s: > > " * The IANA will allocate IPv4 address space to the RIRs in /8 units." > -- http://www.icann.org/en/general/allocation-IPv4-rirs.html > > Similarly, the policy for allocating the last blocks required that they be allocated in /8s, too: > > "IANA will automatically allocate the reserved IPv4 allocation units to each RIR (one /8 to each one)" > -- http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm > > My personal interpretation of the text above was the the "Reclamation Pool" would only be a potential pool unless and until one of the RIRs found that they no longer needed the IPv4 address space they were recovering and could return it to IANA for re-distribution. If I've misunderstood the authors' intentions I am sure that they will correct me. > > Kind regards, > > Leo Vegoda > * sig-policy: APNIC SIG on resource management policy * > _______________________________________________ > sig-policy mailing list > sig-policy at lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/sig-policy On Mon 8/30/2010 2:22 PM, Chris Grundemann wrote: > On Mon, Aug 30, 2010 at 14:51, Tore Anderson > wrote: > >> The proposal says the following: ?The reclamation pool will initially >> contain any fragments that may be left over in IANA inventory?. >> >> You didn't comment on it in your first reply, but if these fragments >> indeed are the unused space in the legacy /8s (I don't know what else >> they could be), the initial contents of the RP would be some 125.4M >> addresses, according to Geoff Huston's IPv4 Address Report >> (http://ipv4.potaroo.net/). That's a sizable chunk... > It certainly is. > > When this topic came up in our initial conversations, we asked an IANA > representative about fragments and were told that IANA did not > currently have any. My understanding is that this may be due to a deal > that was struck between the IANA and the NRO - but I do not have any > authoritative information on that at this time. > > Geoff Huston's report states that: "At the time IANA reaches the last > 5 /8s (the "IANA Exhaustion time" as defined by current address > allocation policies), these unassigned addresses in the legacy /8s are > then distributed evenly to the RIRs." I am not sure where this > information came from though, since this is not spelled out in the > "Allocation of the Remaining IPv4 Address Space" policy > (http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm) > as far as I can discern. > > And of course the IANA report > (http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml) > shows all of the "various/legacy" /8s as being administered by > individual RIRs, since it only has a /8 granularity. > > So there is some confusion (on my part at least) as to where these > fragments currently reside and who has responsibility for them. > Perhaps if someone from IANA monitors this list they can chime in? If > not, I and the other authors will certainly be following up to iron > these fairly significant details out. I apologize for not having a > more complete answer. Someone else can likely provide more detail, but my understanding is that the various /16s in legacy swamp space (the "various/legacy" listings there) are all allocated to (or administered by) individual RIRs, and they're just listed that way because the IANA list doesn't show anything more granular than a /8. So, as far as I can tell, the reclamation pool would initially be empty, unless/until someone returned something smaller than a /8 to IANA. -Scott From leo.vegoda at icann.org Mon Aug 30 23:32:09 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 30 Aug 2010 14:32:09 -0700 Subject: [address-policy-wg] 2010-05 New Policy Proposal (Global Policy for IPv4 Allocation by the IANA post exhaustion) In-Reply-To: References: <20100823145412.B28326A002@postboy.ripe.net> <4C794378.5060600@redpill-linpro.com> <4C7BFD30.9090409@redpill-linpro.com> <4C7C19E2.3000208@redpill-linpro.com> Message-ID: <8C1A6E47-C8A6-4BE1-B2BE-2F22DA6869F4@icann.org> Hi, On 30 Aug 2010, at 2:22, Chris Grundemann wrote: [...] > When this topic came up in our initial conversations, we asked an IANA > representative about fragments and were told that IANA did not > currently have any. My understanding is that this may be due to a deal > that was struck between the IANA and the NRO - but I do not have any > authoritative information on that at this time. Yes, the RIRs agreed a split for the old "Various Registries" space between themselves. They wrote to us about it in 2008 and a copy of the message and the breakdown is published on the ICANN web site: http://www.icann.org/correspondence/wilson-to-conrad-28jan08-en.pdf > > Geoff Huston's report states that: "At the time IANA reaches the last > 5 /8s (the "IANA Exhaustion time" as defined by current address > allocation policies), these unassigned addresses in the legacy /8s are > then distributed evenly to the RIRs." I am not sure where this > information came from though, since this is not spelled out in the > "Allocation of the Remaining IPv4 Address Space" policy > (http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm) > as far as I can discern. This is presumably an address management practice agreed by the NRO rather than a matter of policy. Regards, Leo Vegoda From cgrundemann at gmail.com Mon Aug 30 23:42:30 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 30 Aug 2010 15:42:30 -0600 Subject: [address-policy-wg] 2010-05 New Policy Proposal (Global Policy for IPv4 Allocation by the IANA post exhaustion) In-Reply-To: <8C1A6E47-C8A6-4BE1-B2BE-2F22DA6869F4@icann.org> References: <20100823145412.B28326A002@postboy.ripe.net> <4C794378.5060600@redpill-linpro.com> <4C7BFD30.9090409@redpill-linpro.com> <4C7C19E2.3000208@redpill-linpro.com> <8C1A6E47-C8A6-4BE1-B2BE-2F22DA6869F4@icann.org> Message-ID: On Mon, Aug 30, 2010 at 15:32, Leo Vegoda wrote: > Hi, > > On 30 Aug 2010, at 2:22, Chris Grundemann wrote: > > [...] > >> When this topic came up in our initial conversations, we asked an IANA >> representative about fragments and were told that IANA did not >> currently have any. My understanding is that this may be due to a deal >> that was struck between the IANA and the NRO - but I do not have any >> authoritative information on that at this time. > > Yes, the RIRs agreed a split for the old "Various Registries" space between themselves. They wrote to us about it in 2008 and a copy of the message and the breakdown is published on the ICANN web site: > > http://www.icann.org/correspondence/wilson-to-conrad-28jan08-en.pdf Thank you Leo! That was the missing link. I take this to mean that the authors original assumption is correct and that as things sit today, IANA will have no IPv4 addresses remaining immediately following IPv4 exhaustion. The Reclamation Pool will therefor only contain addresses returned to the IANA. >> >> Geoff Huston's report states that: "At the time IANA reaches the last >> 5 /8s (the "IANA Exhaustion time" as defined by current address >> allocation policies), these unassigned addresses in the legacy /8s are >> then distributed evenly to the RIRs." I am not sure where this >> information came from though, since this is not spelled out in the >> "Allocation of the Remaining IPv4 Address Space" policy >> (http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm) >> as far as I can discern. > > This is presumably an address management practice agreed by the NRO rather than a matter of policy. Understood - and thanks again. ~Chris > > Regards, > > Leo Vegoda From leo.vegoda at icann.org Mon Aug 30 23:57:51 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 30 Aug 2010 14:57:51 -0700 Subject: [address-policy-wg] 2010-05 New Policy Proposal (Global Policy for IPv4 Allocation by the IANA post exhaustion) In-Reply-To: References: <20100823145412.B28326A002@postboy.ripe.net> <4C794378.5060600@redpill-linpro.com> <4C7BFD30.9090409@redpill-linpro.com> <4C7C19E2.3000208@redpill-linpro.com> <8C1A6E47-C8A6-4BE1-B2BE-2F22DA6869F4@icann.org> Message-ID: On 30 Aug 2010, at 2:42, Chris Grundemann wrote: [...] >> Yes, the RIRs agreed a split for the old "Various Registries" space between themselves. They wrote to us about it in 2008 and a copy of the message and the breakdown is published on the ICANN web site: >> >> http://www.icann.org/correspondence/wilson-to-conrad-28jan08-en.pdf > > Thank you Leo! That was the missing link. > > I take this to mean that the authors original assumption is correct > and that as things sit today, IANA will have no IPv4 addresses > remaining immediately following IPv4 exhaustion. The Reclamation Pool > will therefor only contain addresses returned to the IANA. Yes, as things stand now, that's right. Regards, Leo From pk at DENIC.DE Tue Aug 31 12:04:55 2010 From: pk at DENIC.DE (Peter Koch) Date: Tue, 31 Aug 2010 12:04:55 +0200 Subject: [address-policy-wg] Cosmetic Surgery Project: new revised document for Autonomous System (AS) Number Assignment Policies In-Reply-To: <4C7BB277.7020100@ripe.net> References: <4C7BB277.7020100@ripe.net> Message-ID: <20100831100455.GA1925@unknown.office.denic.de> On Mon, Aug 30, 2010 at 03:30:31PM +0200, Emilio Madaio wrote: > RIPE Policy Documents, without changing their substance or meaning. This > project is aimed at improving the clarity and readability of RIPE > Documents. For more information, see: > http://www.ripe.net/ripe/updated-documents/ thanks, this is a helpful effort. > The first RIPE Document to be revised was "Autonomous System (AS) Number > Assignment Policies and Procedures". The revised document is now > available at: > http://www.ripe.net/ripe/docs/ripe-496.html The predecessor at has this copyright note in the footer: "? RIPE Community. All rights reserved". The updated version now points to the standard disclaimer , which reads "Copyright (c) 1992-2009 the R?seaux IP Europ?en Network Coordination Centre RIPE NCC. All rights restricted." The second paragraph then clarifies that policy documents are not covered by this NCC copyright and the second last paragraph says "Please be advised that no copyrights originate with the RIPE community but instead with the creator of the material, whether that be the RIPE NCC or any other individual or organisation whose material appears on the RIPE NCC website or RIPE website." So, for the curious, who holds the copyrights for the RIPE policy documents? -Peter From mueller at syr.edu Tue Aug 31 16:50:10 2010 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 31 Aug 2010 10:50:10 -0400 Subject: [address-policy-wg] RE: address-policy-wg digest, Vol 1 #1183 - 6 msgs In-Reply-To: <20100831100003.21089.95947.Mailman@postboy.ripe.net> References: <20100831100003.21089.95947.Mailman@postboy.ripe.net> Message-ID: <75822E125BCB994F8446858C4B19F0D7073968F3D6@SUEX07-MBX-04.ad.syr.edu> I would advise everyone to be very careful about allowing an organization to arbitrarily define something as "implementation" or "management practice" rather than "policy," especially when such a unilateral redefinition allows important processes and public input to be bypassed. --MM > -----Original Message----- > > Geoff Huston's report states that: "At the time IANA reaches the last > > 5 /8s (the "IANA Exhaustion time" as defined by current address > > allocation policies), these unassigned addresses in the legacy /8s are > > then distributed evenly to the RIRs." I am not sure where this > > information came from though, since this is not spelled out in the > > "Allocation of the Remaining IPv4 Address Space" policy > > (http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm) > > as far as I can discern. > > This is presumably an address management practice agreed by the NRO > rather than a matter of policy. > > Regards, > > Leo Vegoda= > > From emadaio at ripe.net Tue Aug 31 17:56:43 2010 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 31 Aug 2010 17:56:43 +0200 Subject: [address-policy-wg] Cosmetic Surgery Project: new revised document for Autonomous System (AS) Number Assignment Policies In-Reply-To: <20100831100455.GA1925@unknown.office.denic.de> References: <4C7BB277.7020100@ripe.net> <20100831100455.GA1925@unknown.office.denic.de> Message-ID: <4C7D263B.8090509@ripe.net> Dear Peter, Thank you for your question. In principle, the copyright holder of material (document, website, etc.) is the creator of this material or the person whom the copyright license for this material has been given to. A copyright holder can be a natural person or a legal person. The RIPE NCC is the copyright holder for, among others, the RIPE NCC documents and the RIPE NCC website. The copyright statement "Copyright ? 1992-2009 the R?seaux Europ?en Network Coordination Centre RIPE NCC All rights restricted" refers to this kind of material. For RIPE Policy documents, the RIPE community does not have the form of a legal person. Therefore, in this case, the copyright holder is the individual creator of each policy. This is reason for the Attribution section at the end of the revised document. These topics were discussed during the presentation "Authorship of RIPE Policy Documents" at RIPE 60. For documentation, please see: - Presentation: http://www.ripe.net/ripe/meetings/ripe-60/presentations/Yilmaz-Authorship_of_RIPE_Policy_Documents.pdf - Webcast: http://ripe.net/ripe/meetings/ripe-60/flash-video.php?day=Wednesday&pres=Filiz%20Yilmaz%20-%20Authorship%20of%20RIPE%20Policy%20Documents%20-%202.flv - Transcripts: http://www.ripe.net/ripe/meetings/ripe-60/steno-transcripts.php?steno=Main-100505-AM2 Kind regards, Emilio Madaio Policy Development Officer RIPE NCC On 8/31/10 12:04 PM, Peter Koch wrote: > On Mon, Aug 30, 2010 at 03:30:31PM +0200, Emilio Madaio wrote: > >> RIPE Policy Documents, without changing their substance or meaning. This >> project is aimed at improving the clarity and readability of RIPE >> Documents. For more information, see: >> http://www.ripe.net/ripe/updated-documents/ > thanks, this is a helpful effort. > >> The first RIPE Document to be revised was "Autonomous System (AS) Number >> Assignment Policies and Procedures". The revised document is now >> available at: >> http://www.ripe.net/ripe/docs/ripe-496.html > The predecessor at has this > copyright note in the footer: "? RIPE Community. All rights reserved". > The updated version now points > to the standard disclaimer, > which reads "Copyright (c) 1992-2009 the R?seaux IP Europ?en Network > Coordination Centre RIPE NCC. All rights restricted." > > The second paragraph then clarifies that policy documents are not > covered by this NCC copyright and the second last paragraph says > "Please be advised that no copyrights originate with the RIPE community but > instead with the creator of the material, whether that be the RIPE NCC or any > other individual or organisation whose material appears on the RIPE NCC > website or RIPE website." > > So, for the curious, who holds the copyrights for the RIPE policy > documents? > > -Peter > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.vegoda at icann.org Tue Aug 31 18:41:44 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 31 Aug 2010 09:41:44 -0700 Subject: [address-policy-wg] 2010-05 New Policy Proposal (Global Policy for IPv4 Allocation by the IANA post exhaustion) In-Reply-To: References: <20100823145412.B28326A002@postboy.ripe.net> <4C794378.5060600@redpill-linpro.com> <4C7BFD30.9090409@redpill-linpro.com> <4C7C19E2.3000208@redpill-linpro.com> <8C1A6E47-C8A6-4BE1-B2BE-2F22DA6869F4@icann.org> Message-ID: On 30 Aug 2010, at 2:57, Leo Vegoda wrote: [...] >> I take this to mean that the authors original assumption is correct >> and that as things sit today, IANA will have no IPv4 addresses >> remaining immediately following IPv4 exhaustion. The Reclamation Pool >> will therefor only contain addresses returned to the IANA. > > Yes, as things stand now, that's right. I should probably add a clarification to my previous note. Once those five /8s have been allocated to RIRs we won't have any unallocated unicast /8s. But we will still be managing the multicast space, and various IETF assigned blocks for registries like the IANA IPv4 Special Purpose Address Registry: http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml Regards, Leo Vegoda