From sander at steffann.nl Mon Jul 1 09:43:22 2013 From: sander at steffann.nl (Sander Steffann) Date: Mon, 1 Jul 2013 09:43:22 +0200 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: References: <51C994DD.1040005@ripe.net> <51C9BBA2.8030806@inex.ie> Message-ID: <453AEEAA-CDA2-4431-A8D7-087762541AA2@steffann.nl> Hi, Op 28 jun. 2013, om 11:38 heeft Lindqvist Kurt Erik het volgende geschreven: > On 25 jun 2013, at 17:51, Randy Bush wrote: > >> inform owner of dangling reference. wait a week. inform again. >> wait a month. inform again. wait a week. remove dangling reference. >> wait a month to see if anything has broken enough to get the attention >> of folk who do not respond to email. reassign AS number. > > Seems like a reasonable approach to me. +1 Sander From sander at steffann.nl Mon Jul 1 09:44:02 2013 From: sander at steffann.nl (Sander Steffann) Date: Mon, 1 Jul 2013 09:44:02 +0200 Subject: [address-policy-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <8386C119-F5D9-4A38-A9C1-CFAFE9A8ECBD@kurtis.pp.se> References: <51C994DD.1040005@ripe.net> <004801ce72a6$1d32d010$57987030$@a2b-internet.com> <8386C119-F5D9-4A38-A9C1-CFAFE9A8ECBD@kurtis.pp.se> Message-ID: <1EA485C1-5E97-4D39-BB97-F1B7DE0A455F@steffann.nl> Hi, Op 28 jun. 2013, om 11:40 heeft Lindqvist Kurt Erik het volgende geschreven: > On 26 jun 2013, at 21:48, Erik Bais wrote: > >> Are we going to provide them with the list of current returned AS numbers to >> make sure they can also do their housekeeping ? > > I think that publishing lists on ASNs in each stage in Randy's proposal for example would be prudent... +1 on this as well Sander From richih.mailinglist at gmail.com Mon Jul 1 12:33:39 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Mon, 1 Jul 2013 12:33:39 +0200 Subject: [address-policy-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: References: <7C49C19C69319E4FB1279CA15A84D18B61DBA921@SAX20244.bia.abraxas.ch> <51CAB392.3030809@CC.UniVie.ac.at> Message-ID: On Wed, Jun 26, 2013 at 12:06 PM, Richard Hartmann wrote: > There is no shortage of ASn so we have the luxury of being able to be _very_ > careful. I now realized that this is mainly about 16 bit ASn. > Even after an ASn had been reclaimed we can easily wait a significant period > of time before recycling them. And thus, this opinion changes. I don't think anything should be changed by RIPE NCC, objects need to be updated by their respective maintainers. In the best case, objects are recreated from scratch locally whenever an update occurs, rendering this moot. In the worst case, automated systems that do Weird Things (tm) will malfunction in interesting ways. Thus, I would think something along the lines of: * When ASn is being deregistered, automatically email anyone who's responsible for an object that references this ASn * Once ASn is actually deregistered, send out automated email * Once grace period is over, send out automated email * Once ASn is reassigned, send final automated email This means no effort on RIPE NCC's side, constant reminders to operators who may either need time to find out what those emails mean or under day-to-day stress (those exist, let's account for them), and overall reasonable effort to clean something up that may never be fully clean. As to what time is appropriate, I am still unsure, but "short-ish". Richard From elvis at velea.eu Mon Jul 1 13:41:40 2013 From: elvis at velea.eu (Elvis Velea) Date: Mon, 01 Jul 2013 13:41:40 +0200 Subject: [address-policy-wg] PA/PI unification IPv6 Address Space In-Reply-To: <7C49C19C69319E4FB1279CA15A84D18B61DBAF92@SAX20244.bia.abraxas.ch> References: <20130626124403.GI2706@Space.Net> <20130627124217.GE2706@Space.Net> <7C49C19C69319E4FB1279CA15A84D18B61DBAF92@SAX20244.bia.abraxas.ch> Message-ID: <51D16AF4.5060102@velea.eu> Hi Gert, everyone, I'd like to volunteer and join this editorial team. I used to be an IPRA so I've got first-hand experience with address requests and the whole process. Count on me, I hope we can get this policy proposal written by the next RIPE Meeting. cheers, Elvis On 6/27/13 4:32 PM, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote: > Hi Daniel, Hi Gert, Hi Sander > > I have same experience level as Daniel, but I will support you as much as I can. > > Do you have any collaboration platform to write together this policy? Or how do you normally start? > > Olaf > > > -----Original Message----- > From: Daniel Stolpe [mailto:stolpe at resilans.se] > Sent: Donnerstag, 27. Juni 2013 14:56 > To: Gert Doering > Cc: Sonderegger Olaf ABRAXAS INFORMATIK AG; address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] PA/PI unification IPv6 Address Space > > > Hi Gert, > > I have very limited experience of writing RIPE policy documents (but you have to start somewhere, right?) but I think I can check the other boxes. > > Hand up. > > On Thu, 27 Jun 2013, Gert Doering wrote: > >> Hi, >> >> On Wed, Jun 26, 2013 at 02:57:45PM +0200, Daniel Stolpe wrote: >>>> [PA/PI unification proposal] >>> >>>> For IPv6, it's still sitting on my lap, and I need to restart the >>>> process - thanks for the reminder. >>> >>> Just let us know if you need volonteers or cheering. >> >> Since Sander already mentioned it, I now need to write down what I had >> in mind :-) >> >> The original proposal (text appended below) received quite positive >> feedback, so I think we want to go ahead with that. >> >> What is necessary next is to actually write this up in the form of a >> RIPE policy document - and since the secondary effects of this change >> are quite radical, I think it leads to "write a new policy document >> for the new IPv6 address policy in RIPE, after that change, taking >> into account most of the questions that have come up" (like: what are >> the rules for a LIR to receive multiple "blocks of addresses"?). >> >> I can't seem to find enough "undisturbed time" to actually get going >> with this, so my idea was to form a *small* editorial team, maybe 3-5 >> people, who would work together with Sander, me and Emilio to write >> this new policy document (you write, we review :) ), and if we all >> agree that "yes, this is good!" it will be presented as a formal >> policy proposal to the WG, possibly leading to further tweaks of the text. >> >> The group writing this should be people that have had first-hand >> experience with address requests, customer confusion about PA and PI, >> with the RIPE policy process - and who have nerves of steel, to >> actually fight for it in the ensueing arguments on the list... >> >> >> So... volunteers? :-) >> >> Gert Doering >> -- APWG chair >> >> ---------------------------------------------------------------------- >> Motivation: why? >> ---------------- >> - PA and PI are just different labels for "IPv6 addresses" >> ... but with different strings attached: >> - PI must not be used for 3rd party assignments (problem for hosting >> providers) >> - only single PA allocation for LIRs possible, even if multiple >> independent networks exist >> - network structure and operation is very different these days than >> at the time where the PA/PI distinction was made. The boundaries >> between networks, different operators and different services are not >> as clear as they used to be... >> - the classic distinction >> "PA is for ISPs and their access customers" >> "PI is for enterprises that do not do ISP-like business" >> has been overcome by reality, and there are no longer clear borders >> between "ISP", "enterprise" and "end-customer" networks >> >> - Network addresses are for *numbering network devices*. Limiting what >> someone is allowed to do with certain addresses creates confusion. >> Constantly having to tweak policy to work around this is the wrong >> solution. >> >> >> Goals and Caveats >> ----------------- >> - encourage IPv6 deployment >> - be flexible enough to accommodate both typical and non-typical >> network- and business models >> - do not encourage assignment of /64 or single addresses to end users >> - do not encourage excessive routing table growth >> - encourage proper documentation and discourage lying to the RIPE NCC >> to wiggle around policy restrictions >> >> >> The Proposal >> ------------ >> - abandon distinction between PA (allocation) and PI (assignment) >> - everything is just "numbers" >> - RIPE NCC hands out "block(s) of numbers" to "users of numbers" >> - see below for answers on the fine print... >> >> >> Who get's address space? >> ------------------------ >> - existing model is kept: LIRs as distribution point for address space >> - either to "the LIR organization" - classic model: "LIR is part of the Internet Provider business" >> - or via the LIR to "the entity that wants to use the space and take >> responsibility for it" (sponsoring LIR), keeping the contractual >> requirements of 2007-01 >> - "Direct Assignment Users" members could still be possible, but >> "every NCC member is an LIR" would simplify things further (see >> "Costs" section) >> >> >> Amount of space per "block of numbers"? >> --------------------------------------- >> - /48 (or larger with justification) by default >> - /32.../29 (or larger with justification) allowed when planning to >> assign to 3rd parties >> - multiple "blocks of numbers" to or via a single LIR allowed and >> expected to be a frequently seen usage case >> >> >> Allocation from well-known ranges for anything that people might want >> to treat specially in their routing policy (former "special case" and >> PI >> policies): >> - IXP >> - Root DNS >> - Anycast DNS >> - /33.../48 blocks >> >> >> Cost? >> ----- >> - determined by AGM, but we can discuss models here and provide >> recommendations to AGM and NCC board, e.g.: >> - base cost per year per LIR >> - yearly recurring cost "per block of numbers", independent of >> size(!), reflecting the cost of handling the address space request, >> documentation, RIPE database, etc., which increase if you need "many blocks" >> >> >> Multiple blocks per LIR? >> ------------------------ >> - since there would no longer be any difference between PA and PI, >> "more than one block going to a single LIR" would be a typical case - >> so it needs to be permitted >> - "get any number of blocks that people are asking for" is not likely >> to get consensus due to pressure on the routing system >> - proposal for compromise: >> ``one "block of numbers" per "network"'' >> - needs workable definition for "network": >> - interconnected network >> - operated by the same entity >> - operated as a layer 3 network >> - be flexible in allowing multiple blocks, but don't *require* anyone >> to actually ask for multiple number blocks if they are happy with >> using the same address block for multiple networks/sites/... >> >> - problem cases to keep in mind, leading to this definition >> - ISPs providing L3 services on top of other ISPs' Layer 2 infrastructure >> - single LIRs providing addresses to two independent Layer 3 networks >> that are not directly connected - e.g. due to political >> (commercial/NREN), legal or geographical reasons >> - "classical PI" type connections - end users with independent numbers >> - Multiple L3 providers providing address space to a single user must >> be allowed (multi-homing, special-purpose networks, etc.) >> >> -- >> have you enabled 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 >> > > Best Regards, > > Daniel Stolpe > > _________________________________________________________________________________ > Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se > Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ > Box 13 054 556741-1193 > 103 02 Stockholm > > From lists-ripe at c4inet.net Mon Jul 1 14:14:34 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 1 Jul 2013 13:14:34 +0100 Subject: [address-policy-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: References: <7C49C19C69319E4FB1279CA15A84D18B61DBA921@SAX20244.bia.abraxas.ch> <51CAB392.3030809@CC.UniVie.ac.at> Message-ID: <20130701121434.GA11168@cilantro.c4inet.net> Hi Andrea, group, On Mon, Jul 01, 2013 at 12:33:39PM +0200, Richard Hartmann wrote: >I don't think anything should be changed by RIPE NCC, objects need to >be updated by their respective maintainers. In the best case, objects >are recreated from scratch locally whenever an update occurs, >rendering this moot. In the worst case, automated systems that do >Weird Things (tm) will malfunction in interesting ways. Things need to be balanced here. A 'route:' object referencing a re-assigned ASN can cause problems for the new holder if their upstreams generate ACLs based on ripedb information. It's not feasible to leave these ASNs "blocked" forever. OTOH, gratuitiously deleting these objects can cause breakage for the holder of the referencing object (for the same reasons), possibly hops away and thus very hard to troubleshoot. >* When ASn is being deregistered, automatically email anyone who's >responsible for an object that references this ASn >* Once ASn is actually deregistered, send out automated email >* Once grace period is over, send out automated email >* Once ASn is reassigned, send final automated email +1 but: if no reaction to the final email, delete any 'route:' object referencing a returned ASN. There is a possible race condition here between "old/invalid" and "new/valid" 'route:' objects so the deletion should happen some time before the re-assignment. As for the issue of provisioning systems re-creating a removed 'route:' object, does the creation need to be authenticated by the ASN mntner? If not, could this be required to forestall such automatic re-creations? Finally, I'm not sure about treating policy statements in 'aut-num:' objects the same way. Is the presence of those actually an operational issue? I would certainly be opposed to simply deleting an aut-num object just because it contains an obsolete neighbour ASN. rgds, Sascha Luck From elvis at velea.eu Mon Jul 1 14:55:44 2013 From: elvis at velea.eu (Elvis Velea) Date: Mon, 01 Jul 2013 14:55:44 +0200 Subject: [address-policy-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <20130701121434.GA11168@cilantro.c4inet.net> References: <7C49C19C69319E4FB1279CA15A84D18B61DBA921@SAX20244.bia.abraxas.ch> <51CAB392.3030809@CC.UniVie.ac.at> <20130701121434.GA11168@cilantro.c4inet.net> Message-ID: <51D17C50.9000303@velea.eu> Hi Sascha, everyone, On 7/1/13 2:14 PM, Sascha Luck wrote: > Hi Andrea, group, > > On Mon, Jul 01, 2013 at 12:33:39PM +0200, Richard Hartmann wrote: >> I don't think anything should be changed by RIPE NCC, objects need to >> be updated by their respective maintainers. In the best case, objects >> are recreated from scratch locally whenever an update occurs, >> rendering this moot. In the worst case, automated systems that do >> Weird Things (tm) will malfunction in interesting ways. > > Things need to be balanced here. A 'route:' object referencing a > re-assigned ASN can cause problems for the new holder if their upstreams > generate ACLs based on ripedb information. It's not feasible to leave > these ASNs "blocked" forever. > OTOH, gratuitiously deleting these objects can cause breakage for the > holder of the referencing object (for the same reasons), possibly hops > away and thus very hard to troubleshoot. As far as I know, an AS Number can not be returned to the free pool/deleted from the RIPE Database unless all referencing route objects have been deleted. Any route object referencing a deleted AS Number is a broken object and should be deleted. Therefore, the discussion here is not about references of returned AS Numbers in route objects but more about references in other types of objects (see below). > >> * When ASn is being deregistered, automatically email anyone who's >> responsible for an object that references this ASn >> * Once ASn is actually deregistered, send out automated email >> * Once grace period is over, send out automated email >> * Once ASn is reassigned, send final automated email > > +1 but: > > if no reaction to the final email, delete any 'route:' object > referencing a returned ASN. > There is a possible race condition here between "old/invalid" and > "new/valid" 'route:' objects so the deletion should happen some time > before the re-assignment. > > As for the issue of provisioning systems re-creating a removed 'route:' > object, does the creation need to be authenticated by the ASN mntner? If > not, could this be required to forestall such automatic re-creations? Currently, creation of a route object requires the authentication of both the inet(6)num maintainer and the aut-num object's maintainer. https://www.ripe.net/data-tools/db/faq/faq-route-object So, a route object could not be re-created to reference an AS Number that does not exist. > > Finally, I'm not sure about treating policy statements in 'aut-num:' > objects the same way. Is the presence of those actually an operational > issue? I would certainly be opposed to simply deleting an aut-num object > just because it contains an obsolete neighbour ASN. > Returned AS Numbers can still be referenced in other type of objects like aut-num, as-set, peering-set, route-set. To reference an ASN (returned or not) in these objects you are not required to authenticate with the maintainer of that ASN. Anyone can reference your AS Number in their objects. I think that publishing a list of referenced AS Numbers would be a good first step in the clean-up. This way, any "concerned netcitizen could parse the list and fix their records". Additionally, I think that contacting the maintainers that currently maintain the objects which reference the returned AS Numbers is a must. Give them some time to clean-up their objects and if they do not react, see the next paragraph. After, let's say a month and a few reminders, if some returned AS Numbers are still referenced, additional to the list of referenced ASNs the RIPE NCC could publish an aggregated list of maintainers which are still maintaining objects that reference returned AS Numbers. This list could be updated automatically (daily/weekly) to show which maintainer still needs to update it's objects. for example: EXAMPLE-MNT is maintaining 'x' objects that reference 'y' returned AS Numbers. Quite a few objects are being updated in the RIPE Database by scripts. If the RIPE NCC updates those objects, the changes made by the RIPE NCC will be reverted once the script is run again. On the other hand, if the maintainer is made aware that they need to update their script and remove those references, the process may be smoother. my 2 cents, elvis From charlie at evilforbeginners.com Mon Jul 1 15:47:22 2013 From: charlie at evilforbeginners.com (Charlie Allom) Date: Mon, 1 Jul 2013 14:47:22 +0100 Subject: [address-policy-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <51D17C50.9000303@velea.eu> References: <7C49C19C69319E4FB1279CA15A84D18B61DBA921@SAX20244.bia.abraxas.ch> <51CAB392.3030809@CC.UniVie.ac.at> <20130701121434.GA11168@cilantro.c4inet.net> <51D17C50.9000303@velea.eu> Message-ID: <20130701134722.GC12930@spodder.com> On Mon, Jul 01, 2013 at 02:55:44PM +0200, Elvis Velea wrote: > > As far as I know, an AS Number can not be returned to the free > pool/deleted from the RIPE Database unless all referencing route > objects have been deleted. Any route object referencing a deleted AS > Number is a broken object and should be deleted. > > Therefore, the discussion here is not about references of returned > AS Numbers in route objects but more about references in other types > of objects (see below). Thanks for helping bring some clarity to this thread. > I think that publishing a list of referenced AS Numbers would be a > good first step in the clean-up. This way, any "concerned netcitizen > could parse the list and fix their records". Great idea. +1 C. -- 0x8486EDA8 http://spodder.com/ From emadaio at ripe.net Tue Jul 2 15:28:05 2013 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 02 Jul 2013 15:28:05 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) Message-ID: Dear colleagues, The second version of the draft document for the policy proposal 2013-03 has been published, along with an impact analysis carried out by the RIPE NCC. Noteworthy changes in this version include: - Text that suggested contractual requirements are only "recommended" for PI space (section 7.0) has been removed. This text was dependent on previously established context discussing PI vs PA space. As version 1.0 of the proposal removed the PI discussion in the preceding paragraphs, the resulting lack of context made the sentence confusing. The statement was also incorrect, as contractual requirements have been mandatory for PI space since 2007-01 was accepted. - Additional wording has been added to explicitly state that PI space cannot be reassigned or further assigned to other parties (see section 7.0 for ASSIGNED PI). - The third point from the last /8 policy (section 5.1) has been removed, as this is considered a meaningless circular reference by the author. - General re-wording in some sections for improved readability. - The policy proposal 2012-03 has been withdrawn, so the related argument against the proposal has been removed from the rationale. You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2013-03 The draft document can be found at: https://www.ripe.net/ripe/policies/proposals/2013-03/draft We encourage you to read the draft document text and send any comments to before 30 July 2013. Regards Emilio Madaio Policy Development Officer RIPE NCC From emadaio at ripe.net Wed Jul 3 10:56:07 2013 From: emadaio at ripe.net (Emilio Madaio) Date: Wed, 03 Jul 2013 10:56:07 +0200 Subject: [address-policy-wg] RIPE 66 Address Policy WG Meeting Draft Minutes Message-ID: <51D3E727.7090303@ripe.net> Dear Colleagues, The draft minutes of Address Policy Working Group sessions from RIPE 61 are now available at: https://www.ripe.net/ripe/groups/wg/ap/minutes/ripe-66 Best Regards Emilio Madaio Policy Development Officer RIPE NCC From tore at fud.no Wed Jul 3 13:02:40 2013 From: tore at fud.no (Tore Anderson) Date: Wed, 03 Jul 2013 13:02:40 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: Message-ID: <0b85a6c595959d1b2e14502dedb7e2e2@greed.fud.no> Hello APWG, I would like to stress that version 2.0 of the proposal brings no substantial changes. The effective proposed policy remains the exact same. The changes since version 1.0 are all either editorial (language improvements, etc.), further removal of "dead"/obsolete policy text that was overlooked in version 1.0, and ensuring that the proposal does not accidentally create ambiguities. I elaborate on some of those individual changes below. I'd like to thank (in alphabetical order) the following people for providing the feedback that lead to these changes: Alex Le Heux, Marco Schmidt, and Richard Hartmann. I'd also like to remind the working group that the start of the Review Phase means that any feedback given during the Discussion Phase is voided. In other words: If you voiced an opinion on the proposal during the Discussion Phase, you will need to repeat your opinion again during the Review Phase in order for your voice to be counted. > - Additional wording has been added to explicitly state that PI space > cannot be reassigned or further assigned to other parties (see > section 7.0 for ASSIGNED PI). The wording that prohibits PI space from being reassigned of or further assigned is already present in the current policy. However it is "buried" within a larger block text that discusses whether an operator should choose PA or PI space. Following the implementation of the last /8 policy, this choice does no longer exist, and 2013-03 therefore removed the entire block of text. It was pointed out to me that this caused the "reassignability" of PI space to be undefined, which was never an intended consequence of the proposal. Therefore version 2.0 adds back this particular wording. > - The third point from the last /8 policy (section 5.1) has been > removed, as this is considered a meaningless circular reference by > the author. Actually it was Marco Schmidt from the RIPE NCC's Policy Development Office that made this observation. I concur, though. The last /8 policy is currently a weird "odd man out" policy, located all by itself in section 5.6 and partially superseding the "normal" allocation policy (sections 5.0 through 5.5). The third bullet point of the last /8 policy essentially made sure that the (non-superseded) provisions from the "normal" allocation policy were imported into the last /8 policy. 2013-03 merges the last /8 policy into the "normal" allocation policy, ensuring there is only one unified allocation policy. Therefore there is no need for such an "import provisions from the normal policy" statement, as this would essentially be a circular, and thus meaningless, reference. Best regards, -- Tore Anderson From richih.mailinglist at gmail.com Wed Jul 3 14:24:21 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Wed, 3 Jul 2013 14:24:21 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: Message-ID: On Tue, Jul 2, 2013 at 3:28 PM, Emilio Madaio wrote: > The second version of the draft document for the policy proposal > 2013-03 has been published, along with an impact analysis carried out > by the RIPE NCC. Support. Thanks to all involved, Richard From tore at fud.no Thu Jul 4 01:48:08 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 04 Jul 2013 01:48:08 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <0b85a6c595959d1b2e14502dedb7e2e2@greed.fud.no> References: <0b85a6c595959d1b2e14502dedb7e2e2@greed.fud.no> Message-ID: Hi again, I was asked off-list if I could provide a unified diff showing the changes between version 1.0 and 2.0 of the proposed policy text. Attached! Tore * Tore Anderson > I would like to stress that version 2.0 of the proposal brings no > substantial changes. The effective proposed policy remains the exact > same. The changes since version 1.0 are all either editorial (language > improvements, etc.), further removal of "dead"/obsolete policy text that > was overlooked in version 1.0, and ensuring that the proposal does not -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 2013-03-v2-changes.diff.txt URL: From richih.mailinglist at gmail.com Thu Jul 4 02:01:49 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Thu, 4 Jul 2013 02:01:49 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <0b85a6c595959d1b2e14502dedb7e2e2@greed.fud.no> Message-ID: Sent by mobile; excuse my brevity. On Jul 4, 2013 1:48 AM, "Tore Anderson" wrote: > I was asked off-list if I could provide a unified diff showing the > changes between version 1.0 and 2.0 of the proposed policy text. > Attached! Thanks! Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Fri Jul 12 02:19:50 2013 From: randy at psg.com (Randy Bush) Date: Thu, 11 Jul 2013 14:19:50 -1000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <0b85a6c595959d1b2e14502dedb7e2e2@greed.fud.no> References: <0b85a6c595959d1b2e14502dedb7e2e2@greed.fud.no> Message-ID: tore, you did not succeed in making the proposal unappealing. so i still support it. randy From elvis at velea.eu Fri Jul 12 03:01:55 2013 From: elvis at velea.eu (Elvis Daniel Velea) Date: Fri, 12 Jul 2013 03:01:55 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <0b85a6c595959d1b2e14502dedb7e2e2@greed.fud.no> Message-ID: <-1730481542746753856@unknownmsgid> Hi, I also support it. Regards, Elvis Excuse the briefness of this mail, it was sent from a mobile device. On 12 jul. 2013, at 02:20, Randy Bush wrote: > tore, > > you did not succeed in making the proposal unappealing. so i still > support it. > > randy > From frettled at gmail.com Fri Jul 12 09:55:13 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Fri, 12 Jul 2013 09:55:13 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <0b85a6c595959d1b2e14502dedb7e2e2@greed.fud.no> Message-ID: On Thu, Jul 4, 2013 at 1:48 AM, Tore Anderson wrote: > Hi again, > > I was asked off-list if I could provide a unified diff showing the > changes between version 1.0 and 2.0 of the proposed policy text. > Attached! Excellent, that made it much easier to see the changes. I support this version. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sid at free.net Fri Jul 12 13:25:18 2013 From: sid at free.net (Dimitri I Sidelnikov) Date: Fri, 12 Jul 2013 15:25:18 +0400 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <-1730481542746753856@unknownmsgid> References: <0b85a6c595959d1b2e14502dedb7e2e2@greed.fud.no> <-1730481542746753856@unknownmsgid> Message-ID: <51DFE79E.5040607@free.net> Me either. 12.07.2013 05:01, Elvis Daniel Velea ?????: > Hi, > > I also support it. > > Regards, > Elvis +1 -- Regards, D.Sidelnikov From ripe-wgs.cs at schiefner.de Fri Jul 12 14:44:32 2013 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Fri, 12 Jul 2013 14:44:32 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <51C30D04.8090809@titley.com> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C2BB31.5060701@fud.no> <51C2E753.50307@schiefner.de> <51C303C6.5040408@opteamax.de> <51C30D04.8090809@titley.com> Message-ID: <51DFFA30.7070707@schiefner.de> Hi Nigel, On 20.06.2013 16:09, Nigel Titley wrote: > FWIW, and wearing my own personal hat (the grey-green waterproof one > that I had to buy in Amsterdam one year to stop from drowning in the > rain), I think this is a good idea. We're going to discuss it at the > board meeting next week. would you dare to shed some light on the potential outcome of your deliberations in this regard? Or is it yet to early and the board intends to wrap it as a christmas gift? ;-) All the best, -C. From koalafil at gmail.com Fri Jul 12 15:48:19 2013 From: koalafil at gmail.com (Filiz Yilmaz) Date: Fri, 12 Jul 2013 15:48:19 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <20130626124850.GJ2706@Space.Net> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C82A3E.9030508@CC.UniVie.ac.at> <20130626124850.GJ2706@Space.Net> Message-ID: <3B5014F2-0364-4BD6-A7E7-6B366C87E7D2@gmail.com> Hello, On 26 Jun 2013, at 14:48, Gert Doering wrote: > Hi Carlos, > > On Wed, Jun 26, 2013 at 08:42:50AM +0100, Carlos Friacas wrote: >> But shouldn't this go through the regular PDP...? >> (i.e. who really needs this should write a new policy proposal...) > > We're not actually changing policy - we have something here where > the policy text isn't specifying anything, so if we can agree how > we want the RIPE NCC to handle this, we can do this in a quicker and > more light-weight way of "just asking the community for guidance". > > One of the important aspects here is that this will not change the way > the RIPE NCC hands out resources. I mentioned my similar worry on this at the last RIPE meeting in Dublin, but there was not enough time at that session for a proper discussion. I will try here again: I have a sense this is further than just stamping a best practice for the RIPE NCC and giving them guidance on a corner case. First of all that we are already talking about transfer policies and practices here in this thread is a sign that this is not just a simple guidance issue. PI assignments were given for a specific reason at the time. The recipient is an LIR or not is irrelevant here. The purpose was specific at the time of the assignment and obviously different than what a PA allocation is or was at the time. PI assignments are assignments to start with, while allocations are blocks to keep assignments within. We may like it or not, but the policy text still has various mentions of this criteria issue: --- All assignments are valid as long as the original criteria on which the assignment was based are still valid and the assignment is properly registered in the RIPE Database. If an assignment is made for a specific purpose and that purpose no longer exists, the assignment is no longer valid. End Users requesting PI space should be given this or a similar warning: Assignment of this IP space is valid as long as the criteria for the original assignment are still met and is also subject to the policies described in the RIPE NCC document entitled ... --- Accordingly I do not think changing the status of an address block from PI Assignment to PA Allocation abides completely with the current RIPE Policy as it is written today. And I think the policy text should be changed first to allow the RIPE NCC properly to perform such a practice. This will be good for the RIPE NCC, as they are supposed to be following the policy text to the letter. This will also be good for the community, I think, for transparency reasons: A lot of people who are not following the current debate in the list may never have the chance to be aware of this "specific" practice to be adopted by the RIPE NCC, unless it is properly documented through a proposal and then in the policy document, which is the main purpose of the PDP in my opinion. Finally I want to note that I do agree with the argument that the important thing here is to get the registration in the database right. I am not disagreeing with this and in fact I do agree with this overall goal. But I also am an advocate of doing things the right way. The policy documents and the PDP are there for a reason. We should be careful in by-passing them by adopting a practice after just holding a thread in a mailing list without a proper final-documentation for everyone. Cheers Filiz Yilmaz > > Gert Doering > -- APWG chair > -- > have you enabled 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nigel at titley.com Fri Jul 12 18:52:40 2013 From: nigel at titley.com (Nigel Titley) Date: Fri, 12 Jul 2013 17:52:40 +0100 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <51DFFA30.7070707@schiefner.de> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C2BB31.5060701@fud.no> <51C2E753.50307@schiefner.de> <51C303C6.5040408@opteamax.de> <51C30D04.8090809@titley.com> <51DFFA30.7070707@schiefner.de> Message-ID: <51E03458.2090701@titley.com> On 12/07/2013 13:44, Carsten Schiefner wrote: > Hi Nigel, > > On 20.06.2013 16:09, Nigel Titley wrote: >> FWIW, and wearing my own personal hat (the grey-green waterproof one >> that I had to buy in Amsterdam one year to stop from drowning in the >> rain), I think this is a good idea. We're going to discuss it at the >> board meeting next week. > > would you dare to shed some light on the potential outcome of your > deliberations in this regard? Or is it yet to early and the board > intends to wrap it as a christmas gift? ;-) Well, I'm happy to hold off until Christmas if you really want, but the draft board minutes are currently scheduled to go out on Monday (with an announcement to the members list). All the best Nigel From ripe-wgs.cs at schiefner.de Fri Jul 12 19:26:46 2013 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Fri, 12 Jul 2013 19:26:46 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <51E03458.2090701@titley.com> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C2BB31.5060701@fud.no> <51C2E753.50307@schiefner.de> <51C303C6.5040408@opteamax.de> <51C30D04.8090809@titley.com> <51DFFA30.7070707@schiefner.de> <51E03458.2090701@titley.com> Message-ID: <51E03C56.4060107@schiefner.de> Hi Nigel, On 12.07.2013 18:52, Nigel Titley wrote: > Well, I'm happy to hold off until Christmas if you really want, no need at all for such modesty. REALLY! ;-) > but the > draft board minutes are currently scheduled to go out on Monday (with an > announcement to the members list). As this might not just interest members (aka. LIRs), could the concerning part of the minutes be published here - or on the RIPE list - as well, please? Thanks and best, -C. From Ragnar.Anfinsen at altibox.no Sat Jul 13 07:11:24 2013 From: Ragnar.Anfinsen at altibox.no (Anfinsen, Ragnar) Date: Sat, 13 Jul 2013 05:11:24 +0000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: Message-ID: Den 2. juli 2013 kl. 16:28 skrev "Emilio Madaio" : > The second version of the draft document for the policy proposal > 2013-03 has been published, along with an impact analysis carried out > by the RIPE NCC. Support. BR Ragnar Anfinsen Altibox AS From rogerj at gmail.com Sat Jul 13 07:58:54 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Sat, 13 Jul 2013 07:58:54 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: Message-ID: On Tue, Jul 2, 2013 at 3:28 PM, Emilio Madaio wrote: > Dear colleagues, > > The second version of the draft document for the policy proposal > 2013-03 has been published, along with an impact analysis carried out > by the RIPE NCC. still supported -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From mps31.ripe at gmail.com Sat Jul 13 12:23:17 2013 From: mps31.ripe at gmail.com (Mike Simkins) Date: Sat, 13 Jul 2013 11:23:17 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: Message-ID: <5A99DDDB-AD78-40CF-8FF7-EB41529E629A@gmail.com> Support On 2 Jul 2013, at 14:28, Emilio Madaio wrote: > Dear colleagues, > > The second version of the draft document for the policy proposal > 2013-03 has been published, along with an impact analysis carried out > by the RIPE NCC. > > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > > From jan at go6.si Sat Jul 13 17:51:06 2013 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sat, 13 Jul 2013 17:51:06 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: Message-ID: <51E1776A.1010006@go6.si> On 7/13/13 7:11 AM, Anfinsen, Ragnar wrote: > > Den 2. juli 2013 kl. 16:28 skrev "Emilio Madaio" : > >> The second version of the draft document for the policy proposal >> 2013-03 has been published, along with an impact analysis carried out >> by the RIPE NCC. > > Support. +1 Jan From M.Sabour at respina.net Mon Jul 15 09:18:57 2013 From: M.Sabour at respina.net (Mehdi Sabour) Date: Mon, 15 Jul 2013 11:48:57 +0430 Subject: [address-policy-wg] regid: rspn.ir Message-ID: <24F25F71E5583446AE77C21A7EFD72464DAB7289BA@exchange.respina.net> Dear Colleague, I've faced a problem and I want to address it to you; I hope you can help me. One of my customers called "Sapco" has 193.105.2.0/24 range of IP address, It has already established BGP protocol with us and ITC (You can find its diagram in attachment). Everything with this Range IP is ok but when Sapco's clients want to browse Google's website, google.br (Belgium) opens instead of google.com. I registered its IPs in Google' support (https://support.google.com/websearch/contact/ip), unfortunately the problem hasn't solved yet. I've checked these IPs in all websites, in all of them 193.105.2.0/24 registered Iran country but I and ITC don't know what the problem is. I hope you can help me, if you face this kind of problem. Best Regards. --- Mehdi Sabour NOC Manager Technical Division Respina Networks & Beyond T: +98 21 84 23 00 00 F: +98 21 88 19 10 83 www.respina.net ________________________________ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system administrator. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of RESPINA. Finally, the recipient should check this email and any attachments for the presence of viruses. RESPINA accepts no liability for any damage caused by any virus transmitted by this email. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Sapco.png Type: image/png Size: 25388 bytes Desc: Sapco.png URL: From dcunningham at airspeed.ie Mon Jul 15 11:07:16 2013 From: dcunningham at airspeed.ie (Donal Cunningham) Date: Mon, 15 Jul 2013 09:07:16 +0000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <5A99DDDB-AD78-40CF-8FF7-EB41529E629A@gmail.com> References: <5A99DDDB-AD78-40CF-8FF7-EB41529E629A@gmail.com> Message-ID: > Dear colleagues, > > The second version of the draft document for the policy proposal > 2013-03 has been published, along with an impact analysis > carried out by the RIPE NCC. Support. D. Airspeed Telecom From Jamie.Stallwood at imerja.com Mon Jul 15 11:06:03 2013 From: Jamie.Stallwood at imerja.com (Jamie Stallwood) Date: Mon, 15 Jul 2013 10:06:03 +0100 Subject: [address-policy-wg] regid: rspn.ir References: <24F25F71E5583446AE77C21A7EFD72464DAB7289BA@exchange.respina.net> Message-ID: <7B640CC73C18D94F83479A1D0B9A1404074283EF@bhw-srv-dc1.imerja.com> Hi Mehdi, One of the biggest providers of Geolocation for IP's is Maxmind - makers of GeoIP. And as you say, testing on their website (http://www.maxmind.com/en/lookup ) shows this range as being Iran. I'd start by submitting a correction request here: http://www.maxmind.com/en/correction Kind regards Jamie Stallwood Jamie Stallwood Security Specialist Imerja Limited Tel: 0844 225 2888 Mob: 07795 840385 Jamie.Stallwood at imerja.com NIC Handle: uk.imerja.JS7259-RIPE From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Mehdi Sabour Sent: 15 July 2013 08:19 To: address-policy-wg at ripe.net Subject: [address-policy-wg] regid: rspn.ir Dear Colleague, I've faced a problem and I want to address it to you; I hope you can help me. One of my customers called "Sapco" has 193.105.2.0/24 range of IP address, It has already established BGP protocol with us and ITC (You can find its diagram in attachment). Everything with this Range IP is ok but when Sapco's clients want to browse Google's website, google.br (Belgium) opens instead of google.com. I registered its IPs in Google' support (https://support.google.com/websearch/contact/ip), unfortunately the problem hasn't solved yet. I've checked these IPs in all websites, in all of them 193.105.2.0/24 registered Iran country but I and ITC don't know what the problem is. I hope you can help me, if you face this kind of problem. Best Regards. --- Mehdi Sabour NOC Manager Technical Division Respina Networks & Beyond T: +98 21 84 23 00 00 F: +98 21 88 19 10 83 www.respina.net ________________________________ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system administrator. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of RESPINA. Finally, the recipient should check this email and any attachments for the presence of viruses. RESPINA accepts no liability for any damage caused by any virus transmitted by this email. ________________________________ -- Imerja Limited Tel: 0844 225 2888 | Fax: 0870 8611489 | 24x7 ISOC: 0870 8611490 | Web: www.imerja.com Registered Office: Hallmark House, Paragon Business Park, Chorley New Road, Horwich, Bolton BL6 6HG Registered in England and Wales No. 5180119 VAT Registered No. 845 0647 22 ISO9001 / ISO27001 This email is confidential and intended solely for the person or organisation to which it is addressed. It may contain privileged and confidential information. If you are not the intended recipient(s) you should not use, copy, distribute or take any action or reliance on it, since to do so is strictly prohibited and may be unlawful. If you have received this transmission in error please notify the sender immediately by email reply and delete it from your system. E-mail messages are not secure and attachments could contain software viruses which may damage your system. Whilst every reasonable precaution has been taken to minimise this risk, Imerja Limited cannot accept any liability for any damage sustained as a result of these factors. You are advised to carry out your own virus checks before opening any attachment. Any views or opinions expressed in this e-mail are solely those of the author and do not represent those of Imerja Limited unless otherwise stated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stolpe at resilans.se Tue Jul 16 14:36:15 2013 From: stolpe at resilans.se (Daniel Stolpe) Date: Tue, 16 Jul 2013 14:36:15 +0200 (CEST) Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <5A99DDDB-AD78-40CF-8FF7-EB41529E629A@gmail.com> Message-ID: On Mon, 15 Jul 2013, Donal Cunningham wrote: >> Dear colleagues, >> >> The second version of the draft document for the policy proposal >> 2013-03 has been published, along with an impact analysis >> carried out by the RIPE NCC. > > Support. > > D. +1. Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From emadaio at ripe.net Tue Jul 16 15:47:28 2013 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 16 Jul 2013 15:47:28 +0200 Subject: [address-policy-wg] RIPE 66 Address Policy WG Meeting Draft Minutes In-Reply-To: <51D3E727.7090303@ripe.net> References: <51D3E727.7090303@ripe.net> Message-ID: <51E54EF0.3020902@ripe.net> Dear colleagues, Feedback received on the draft minutes from the Address Policy Working Group session at RIPE 66 has resulted in a minor change. A comment referenced by another speaker had been misattributed. This has been corrected. You can find the updated minutes here: https://www.ripe.net/ripe/groups/wg/ap/minutes/ripe-66 Best regards, Emilio Madaio Policy Development Officer RIPE NCC On 7/3/13 10:56 AM, Emilio Madaio wrote: > Dear Colleagues, > > > The draft minutes of Address Policy Working Group sessions from RIPE 61 > are now available at: > > https://www.ripe.net/ripe/groups/wg/ap/minutes/ripe-66 > > > Best Regards > Emilio Madaio > Policy Development Officer > RIPE NCC > From ripe-wgs.cs at schiefner.de Tue Jul 16 23:45:21 2013 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Tue, 16 Jul 2013 23:45:21 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <51E03458.2090701@titley.com> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C2BB31.5060701@fud.no> <51C2E753.50307@schiefner.de> <51C303C6.5040408@opteamax.de> <51C30D04.8090809@titley.com> <51DFFA30.7070707@schiefner.de> <51E03458.2090701@titley.com> Message-ID: <51E5BEF1.3000507@schiefner.de> Hi Nigel, On 12.07.2013 18:52, Nigel Titley wrote: > but the > draft board minutes are currently scheduled to go out on Monday (with an > announcement to the members list). I can't find anything in the minutes concerning a status change of PI space. Or did I miss something somewhere? Thanks and best, -C. From nigel at titley.com Wed Jul 17 12:30:28 2013 From: nigel at titley.com (Nigel Titley) Date: Wed, 17 Jul 2013 11:30:28 +0100 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <51E5BEF1.3000507@schiefner.de> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C2BB31.5060701@fud.no> <51C2E753.50307@schiefner.de> <51C303C6.5040408@opteamax.de> <51C30D04.8090809@titley.com> <51DFFA30.7070707@schiefner.de> <51E03458.2090701@titley.com> <51E5BEF1.3000507@schiefner.de> Message-ID: <51E67244.3090908@titley.com> On 16/07/2013 22:45, Carsten Schiefner wrote: > Hi Nigel, > > On 12.07.2013 18:52, Nigel Titley wrote: >> but the >> draft board minutes are currently scheduled to go out on Monday (with an >> announcement to the members list). > > I can't find anything in the minutes concerning a status change of PI > space. Or did I miss something somewhere? > > Thanks and best, > Hmm, yes the discussion we had didn't get formally minuted. Looking back on the correspondence on the board mailing list after the meeting, where this lack of minuting was brought up, it was decided that as the discussion was still taking place on the AP-WG list that we shouldn't bias the discussion by minuting the board discussion. Which I've managed to completely put my foot in... The upshot was that the Board agreed in principle that they thought that a move from PI to PA under the defined circumstances was fine in principle, as far as they could see, but that the discussion should run to a close in the community before coming to a final conclusion. Nigel From hph at oslo.net Wed Jul 17 12:34:39 2013 From: hph at oslo.net (Hans Petter Holen) Date: Wed, 17 Jul 2013 12:34:39 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <51E67244.3090908@titley.com> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C2BB31.5060701@fud.no> <51C2E753.50307@schiefner.de> <51C303C6.5040408@opteamax.de> <51C30D04.8090809@titley.com> <51DFFA30.7070707@schiefner.de> <51E03458.2090701@titley.com> <51E5BEF1.3000507@schiefner.de> <51E67244.3090908@titley.com> Message-ID: I think we should consider to remove the distinction between PI and PA. As the free pool is depleted I do no loger see this need for registry purposes. -hph On Wednesday, July 17, 2013, Nigel Titley wrote: > On 16/07/2013 22:45, Carsten Schiefner wrote: > >> Hi Nigel, >> >> On 12.07.2013 18:52, Nigel Titley wrote: >> >>> but the >>> draft board minutes are currently scheduled to go out on Monday (with an >>> announcement to the members list). >>> >> >> I can't find anything in the minutes concerning a status change of PI >> space. Or did I miss something somewhere? >> >> Thanks and best, >> >> Hmm, yes the discussion we had didn't get formally minuted. Looking back > on the correspondence on the board mailing list after the meeting, where > this lack of minuting was brought up, it was decided that as the discussion > was still taking place on the AP-WG list that we shouldn't bias the > discussion by minuting the board discussion. Which I've managed to > completely put my foot in... > > The upshot was that the Board agreed in principle that they thought that a > move from PI to PA under the defined circumstances was fine in principle, > as far as they could see, but that the discussion should run to a close in > the community before coming to a final conclusion. > > Nigel > > -- Hans Petter Holen Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From h.lu at anytimechinese.com Wed Jul 17 12:42:32 2013 From: h.lu at anytimechinese.com (Lu) Date: Wed, 17 Jul 2013 12:42:32 +0200 Subject: [address-policy-wg] address-policy-wg Digest, Vol 23, Issue 5 In-Reply-To: References: Message-ID: I support it as it would greatly reduce our work load. This transmission is intended solely for the addressee(s) shown above. It may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, dissemination or use of this transmission or its contents by persons other than the intended addressee(s) is strictly prohibited. If you have received this transmission in error, please notify this office immediately and e-mail the original at the sender's address above by replying to this message and including the text of the transmission received. ? 2013-7-12?12:00?address-policy-wg-request at ripe.net ??? > Send address-policy-wg mailing list submissions to > address-policy-wg at ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ripe.net/mailman/listinfo/address-policy-wg > or, via email, send a message with subject or body 'help' to > address-policy-wg-request at ripe.net > > You can reach the person managing the list at > address-policy-wg-owner at ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." > > > Today's Topics: > > 1. Re: 2013-03 New Draft Document and Impact Analysis Published > (No Need - Post-Depletion Reality Adjustment and Clean up) > (Randy Bush) > 2. Re: 2013-03 New Draft Document and Impact Analysis Published > (No Need - Post-Depletion Reality Adjustment and Clean up) > (Elvis Daniel Velea) > 3. Re: 2013-03 New Draft Document and Impact Analysis Published > (No Need - Post-Depletion Reality Adjustment and Clean up) > (Jan Ingvoldstad) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 11 Jul 2013 14:19:50 -1000 > From: Randy Bush > Subject: Re: [address-policy-wg] 2013-03 New Draft Document and Impact > Analysis Published (No Need - Post-Depletion Reality Adjustment and > Clean up) > To: Tore Anderson > Cc: RIPE address policy WG > Message-ID: > Content-Type: text/plain; charset=US-ASCII > > tore, > > you did not succeed in making the proposal unappealing. so i still > support it. > > randy > > > > ------------------------------ > > Message: 2 > Date: Fri, 12 Jul 2013 03:01:55 +0200 > From: Elvis Daniel Velea > Subject: Re: [address-policy-wg] 2013-03 New Draft Document and Impact > Analysis Published (No Need - Post-Depletion Reality Adjustment and > Clean up) > To: Randy Bush > Cc: Tore Anderson , RIPE address policy WG > > Message-ID: <-1730481542746753856 at unknownmsgid> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > I also support it. > > Regards, > Elvis > > Excuse the briefness of this mail, it was sent from a mobile device. > > On 12 jul. 2013, at 02:20, Randy Bush wrote: > >> tore, >> >> you did not succeed in making the proposal unappealing. so i still >> support it. >> >> randy > > > > ------------------------------ > > Message: 3 > Date: Fri, 12 Jul 2013 09:55:13 +0200 > From: Jan Ingvoldstad > Subject: Re: [address-policy-wg] 2013-03 New Draft Document and Impact > Analysis Published (No Need - Post-Depletion Reality Adjustment and > Clean up) > To: RIPE Address Policy WG > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > On Thu, Jul 4, 2013 at 1:48 AM, Tore Anderson wrote: > >> Hi again, >> >> I was asked off-list if I could provide a unified diff showing the >> changes between version 1.0 and 2.0 of the proposed policy text. >> Attached! > > > Excellent, that made it much easier to see the changes. > > I support this version. > -- > Jan > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: https://www.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20130712/6c26407d/attachment-0001.html > > End of address-policy-wg Digest, Vol 23, Issue 5 > ************************************************ From hph at oslo.net Wed Jul 17 12:57:04 2013 From: hph at oslo.net (Hans Petter Holen) Date: Wed, 17 Jul 2013 12:57:04 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <5A99DDDB-AD78-40CF-8FF7-EB41529E629A@gmail.com> Message-ID: While I expressed support for this proposal at the last RIPE meeting, and still have some sympathy for the proposal, I think valid objectionsn were raised at the last meeting. . As the free pool is gone - and there are no more 'unused addresses' to preserve - there is still a need for responsibe use of the IPv4 pool. Conserving the public resource of v4 is important to make the Internet work while migrating to v6. It was unfortunate that this discussion was cut short at the last meeting - as the original meeting plan allowed ample time for discussing this. So I do belive further duiscussion and carefull reflection of the consequences of this proposal at the next meeting is needed. Moving forward and concluding over summer holidays on such an important matter is not appealing to me. Hans Petter On Tuesday, July 16, 2013, Daniel Stolpe wrote: > > On Mon, 15 Jul 2013, Donal Cunningham wrote: > > Dear colleagues, >>> >>> The second version of the draft document for the policy proposal >>> 2013-03 has been published, along with an impact analysis >>> carried out by the RIPE NCC. >>> >> >> Support. >> >> D. >> > > +1. > > > > > Daniel Stolpe > > ______________________________**______________________________** > _____________________ > Daniel Stolpe Tel: 08 - 688 11 81 > stolpe at resilans.se > Resilans AB Fax: 08 - 55 00 21 63 > http://www.resilans.se/ > Box 13 054 > 556741-1193 > 103 02 Stockholm > > > -- Hans Petter Holen Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-wgs.cs at schiefner.de Wed Jul 17 13:28:24 2013 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Wed, 17 Jul 2013 13:28:24 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C2BB31.5060701@fud.no> <51C2E753.50307@schiefner.de> <51C303C6.5040408@opteamax.de> <51C30D04.8090809@titley.com> <51DFFA30.7070707@schiefner.de> <51E03458.2090701@titley.com> <51E5BEF1.3000507@schiefner.de> <51E67244.3090908@titley.com> Message-ID: <51E67FD8.20808@schiefner.de> Hi Hans Petter, On 17.07.2013 12:34, Hans Petter Holen wrote: > I think we should consider to remove the distinction between PI and PA. > As the free pool is depleted I do no loger see this need for registry > purposes. interesting view point. :-) Maybe you want to elaborate on this a bit more and/or send some text wrt. a policy CR? Thanks and best, -C. From gert at space.net Wed Jul 17 13:34:22 2013 From: gert at space.net (Gert Doering) Date: Wed, 17 Jul 2013 13:34:22 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <5A99DDDB-AD78-40CF-8FF7-EB41529E629A@gmail.com> Message-ID: <20130717113422.GX57623@Space.Net> Hi, On Wed, Jul 17, 2013 at 12:57:04PM +0200, Hans Petter Holen wrote: > While I expressed support for this proposal at the last RIPE meeting, and > still have some sympathy for the proposal, I think valid objectionsn were > raised at the last meeting. . > > As the free pool is gone - and there are no more 'unused addresses' to > preserve - there is still a need for responsibe use of the IPv4 pool. > Conserving the public resource of v4 is important to make the Internet > work while migrating to v6. I agree with you, but how does this proposal change this in your view? The "allocations from the last /8" policy is only slightly changed, as "need" does not need to be documented anymore - but then, the policy always assumed that every single RIPE member would eventually call up on their last /22 allocation, and that every new RIPE member would also ask for that, so the effective difference is small (some members would be able to ask for the /22 before reaching 80% on their previous allocation, but they would still only get a single /22, so the estimation "how long is the last /8 going to last" still mainly depends on the number of new LIRs created). On the LIR-to-customer level, LIRs should be well aware now that the IPv4 space they have might be all they will reasonably get in the foreseeable time, so they have a strong incentive already to give only those addresses to their customers that are really needed - but forcing them to stick to some arbitrary time scale and specific forms for that is really "needless bureaucracy" today. > It was unfortunate that this discussion was cut short at the last meeting - > as the original meeting plan allowed ample time for discussing this. > > So I do belive further duiscussion and carefull reflection of the > consequences of this proposal at the next meeting is needed. As we do not do decisions at meetings, I'm not convinced that this is a useful excercise. Meetings are good to quickly get feedback, and some discussion going, but if objections are not raised here on the list, they do not exist (of course we listen to reasonable objections raised at the meeting, but the main feedback we got *from the RIPE region* was "go ahead!"). If there's a worry that this proposal is not getting enough scrutiny due to holiday time, I'm willing to extend the review period somewhat - but given the amount of explicit "support" and "+1" statements it already got, compared to the typical amount of participation in the review period, I can't say that it looks like everybody is on vacation... Gert Doering -- APWG chair -- have you enabled 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From andreas.larsen at ip-only.se Mon Jul 22 09:29:38 2013 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Mon, 22 Jul 2013 09:29:38 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: Message-ID: Support this wholeheartedly. // Andreas Med v?nlig h?lsning Andreas Larsen IP-Only Telecommunication AB| Postadress: 753 81 UPPSALA | Bes?ksadress: S:t Persgatan 6, Uppsala | Telefon: +46 (0)18 843 10 00 | Direkt: +46 (0)18 843 10 56 www.ip-only.se Den 2013-07-12 02:19 skrev Randy Bush : >tore, > >you did not succeed in making the proposal unappealing. so i still >support it. > >randy > From michele at blacknight.com Mon Jul 22 12:29:29 2013 From: michele at blacknight.com (Michele Neylon - Blacknight) Date: Mon, 22 Jul 2013 10:29:29 +0000 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: Message-ID: Emilio As previously stated, I do NOT support the "no need" policy and cannot support this document. IP addresses are a finite resource, as we all know, and obliging people to provide some level of justification makes sense. The argument for "conservation" may no longer be valid, but there will always be a compelling argument in favour of good resource management, which I believe the policy covers. RIPE should not remove the requirement to provide justification. Regards Michele On 2 Jul 2013, at 14:28, Emilio Madaio wrote: > Dear colleagues, > > The second version of the draft document for the policy proposal > 2013-03 has been published, along with an impact analysis carried out > by the RIPE NCC. > > Noteworthy changes in this version include: > > - Text that suggested contractual requirements are only "recommended" > for PI space (section 7.0) has been removed. This text was dependent > on previously established context discussing PI vs PA space. As > version 1.0 of the proposal removed the PI discussion in the > preceding paragraphs, the resulting lack of context made the > sentence confusing. The statement was also incorrect, as contractual > requirements have been mandatory for PI space since 2007-01 was > accepted. > > - Additional wording has been added to explicitly state that PI space > cannot be reassigned or further assigned to other parties (see > section 7.0 for ASSIGNED PI). > > - The third point from the last /8 policy (section 5.1) has been > removed, as this is considered a meaningless circular reference by > the author. > > - General re-wording in some sections for improved readability. > > - The policy proposal 2012-03 has been withdrawn, so the related > argument against the proposal has been removed from the rationale. > > You can find the full proposal and the impact analysis at: > https://www.ripe.net/ripe/policies/proposals/2013-03 > > The draft document can be found at: > https://www.ripe.net/ripe/policies/proposals/2013-03/draft > > We encourage you to read the draft document text and send any comments > to before 30 July 2013. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > > Mr Michele Neylon Blacknight Solutions ? Hosting & Domains ICANN Accredited Registrar http://www.blacknight.co http://blog.blacknight.com/ Intl. +353 (0) 59 9183072 US: 213-233-1612 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Facebook: http://fb.me/blacknight Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From emadaio at ripe.net Mon Jul 22 15:08:26 2013 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 22 Jul 2013 15:08:26 +0200 Subject: [address-policy-wg] 2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers) Message-ID: Dear Colleagues, A proposed change to RIPE Policy Document ripe-592, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2013-05/ We encourage you to review this proposal and send your comments to before 19 August 2013. Regards Emilio Madaio Policy Development Officer RIPE NCC From tore at fud.no Wed Jul 24 10:52:03 2013 From: tore at fud.no (Tore Anderson) Date: Wed, 24 Jul 2013 10:52:03 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: Message-ID: <51EF95B3.4030705@fud.no> * Michele Neylon - Blacknight > As previously stated, I do NOT support the "no need" policy and > cannot support this document. > > IP addresses are a finite resource, as we all know, and obliging > people to provide some level of justification makes sense. > > The argument for "conservation" may no longer be valid, but there > will always be a compelling argument in favour of good resource > management, which I believe the policy covers. > > RIPE should not remove the requirement to provide justification. Hi Michele, I doubt you'll find anyone in the working group who is against good resource management. I am convinced that the proposed policy is not in conflict with good resource management, otherwise I would never have proposed it. While I can obviously only speak with certainty for myself, I assume that the people who support the proposal feel the same way. While it appears you believe that the proposal will bring about poor resource management, your message neglected to explain why or how. This makes it rather difficult for me to try to alleviate your concerns. As Gert also pointed out recently, the main reason I believe that IPv4 would continue to be consumed responsibly under the proposed policy, is that the LIRs in the region are painfully aware that there is no more IPv4 to be had from the RIPE NCC. Should an LIR anyway decide to go on a "spending spree" with its remaining inventory, it would only end up hurting itself by expediting its own depletion date. The community will not be impacted - without a Common, there can be no Tragedy. Best regards, Tore Anderson From koalafil at gmail.com Wed Jul 24 12:53:18 2013 From: koalafil at gmail.com (Filiz Yilmaz) Date: Wed, 24 Jul 2013 12:53:18 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51EF95B3.4030705@fud.no> References: <51EF95B3.4030705@fud.no> Message-ID: Hello Tore, While I am curious for Michele's response to your mail too, here is my bit, as I feel I agree with him in terms of principles. First of all, I am not totally against your proposal; it cleans up the policy text reflecting today's circumstances to some extent and it makes a long document way more readable. This is also why I am writing back because I've read the draft policy document from the beginning to the end. My observation is that the new document proposed is not exactly a "registration" policy document. It more looked to me like a description of how address space management is done within RIPE NCC region "by the RIPE NCC". If I am not missing anything crucial, the main points described are: - The language is English, - How big an allocation can be, - That there is no PI anymore to be assigned directly from the NCC pools to End users (except for the IXPs) so all resources will only goto LIRs - And these blocks can be transferred between LIRs. The only bit about registration I see in the new text is section 4.0 Registration Requirements and it does not go more than saying details should be recorded in the database. So it does not contain any substantial information for registration or address management on the LIR's side. This is interesting as now with this proposed policy any End user's chance to get any IPv4 address space will be through an LIR and hope that these LIRs are responsible and know what they are doing. I would like to see some guidelines or at least principles mentioned in this document so the LIRs know their responsibility in terms of fair address management as well as the End Users so they know what to expect from these LIRs. This is what I would be expecting from a transparent documentation of a set of policies and principles that are still in place. We may not have too many specific policies to set for the few left-over resources but I would like to believe we still have "principles" towards the responsible management of these resources. In that sense Michele has a point and I argue that LIRs need to be guided for "good address management" even without the "conservation" principle as the top priority in the new IP world. This is missing in the proposed policy text for it to be considered as a helpful "registration" policy in my opinion. In practice, I can set up a new LIR now and ask for a new allocation and I may be someone who does not have any previous RIPE or RIPE NCC experience. If all I have is this document, I am not sure if it tells me enough about my responsibilities, while I will be a critical token in the EU address management and registration system by just becoming an LIR. My other concern is in regards to the transfers. As neatly put by the NCC Board in the Impact Analysis: --- As mentioned in previous sections, the policy proposal would negatively affect the ability of LIRs to engage in inter-RIR transfers, as the RIPE NCC?s service region would be the only one without a needs-based requirement for transfers. Implementation of the policy could expose LIRs to legal challenges under EU competition law. --- I think singling out the RIPE NCC region in the world of transfers may not be the best idea at this stage. Kind regards Filiz Yilmaz On 24 Jul 2013, at 10:52, Tore Anderson wrote: > * Michele Neylon - Blacknight > >> As previously stated, I do NOT support the "no need" policy and >> cannot support this document. >> >> IP addresses are a finite resource, as we all know, and obliging >> people to provide some level of justification makes sense. >> >> The argument for "conservation" may no longer be valid, but there >> will always be a compelling argument in favour of good resource >> management, which I believe the policy covers. >> >> RIPE should not remove the requirement to provide justification. > > Hi Michele, > > I doubt you'll find anyone in the working group who is against good > resource management. I am convinced that the proposed policy is not in > conflict with good resource management, otherwise I would never have > proposed it. While I can obviously only speak with certainty for myself, > I assume that the people who support the proposal feel the same way. > > While it appears you believe that the proposal will bring about poor > resource management, your message neglected to explain why or how. This > makes it rather difficult for me to try to alleviate your concerns. > > As Gert also pointed out recently, the main reason I believe that IPv4 > would continue to be consumed responsibly under the proposed policy, is > that the LIRs in the region are painfully aware that there is no more > IPv4 to be had from the RIPE NCC. Should an LIR anyway decide to go on a > "spending spree" with its remaining inventory, it would only end up > hurting itself by expediting its own depletion date. The community will > not be impacted - without a Common, there can be no Tragedy. > > Best regards, > Tore Anderson > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Wed Jul 24 15:21:16 2013 From: tore at fud.no (Tore Anderson) Date: Wed, 24 Jul 2013 15:21:16 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> Message-ID: <51EFD4CC.9000006@fud.no> * Filiz Yilmaz > My observation is that the new document proposed is not exactly a > "registration" policy document. > It more looked to me like a description of how address space management > is done within RIPE NCC region "by the RIPE NCC". > > If I am not missing anything crucial, the main points described are: > > - The language is English, > - How big an allocation can be, > - That there is no PI anymore to be assigned directly from the NCC pools > to End users (except for the IXPs) so all resources will only goto LIRs > - And these blocks can be transferred between LIRs. > > The only bit about registration I see in the new text is section 4.0 > Registration Requirements and it does not go more than saying details > should be recorded in the database. > > So it does not contain any substantial information for registration or > address management on the LIR's side. Hello Filiz, The proposal is a modification of the existing policy document (ripe-592), it is not a brand new document written from scratch. The language regarding registration requirements is not changed, so the proposal does not change anything - it merely upholds the status quo. We can certainly discuss amending the current registration requirements, but to me this topic does not seem germane to the discussion of 2013-03. > This is interesting as now with this proposed policy any End user's > chance to get any IPv4 address space will be through an LIR and hope > that these LIRs are responsible and know what they are doing. I would > like to see some guidelines or at least principles mentioned in this > document so the LIRs know their responsibility in terms of fair address > management as well as the End Users so they know what to expect from > these LIRs. This is what I would be expecting from a transparent > documentation of a set of policies and principles that are still in place. > > We may not have too many specific policies to set for the few left-over > resources but I would like to believe we still have "principles" towards > the responsible management of these resources. > > In that sense Michele has a point and I argue that LIRs need to be > guided for "good address management" even without the "conservation" > principle as the top priority in the new IP world. This is missing in > the proposed policy text for it to be considered as a helpful > "registration" policy in my opinion. I have no problems being sympathetic towards a "good address management" principle, but the simple fact is that this is not written down in our current policy. What constitutes "good address management" is something left to the LIRs to decide for themselves. Example: As a LIR, you are today free to assign your last free IPv4 block to a group of spammers at the expense of having to turn down the Red Cross, perhaps because the spammers were willing to pay you more. Is that "good"? I'd say quite the opposite, but yet it is perfectly allowed by today's policy. So while I'm all for discussing the codification of a set of principles in our policies telling our community to be "good", I'd rather not weigh down this proposal with the addition of a brand-new "principles" section, which I suspect would require a lot of back-and-forth word-smithing to make everyone happy. So if we do want such a section, let's add it in a separate proposal. > In practice, I can set up a new LIR now and ask for a new allocation and > I may be someone who does not have any previous RIPE or RIPE NCC > experience. > If all I have is this document, I am not sure if it tells me enough > about my responsibilities, while I will be a critical token in the EU > address management and registration system by just becoming an LIR. As a new LIR, all the IPv4 address space you are going to get from the RIPE NCC is a /22, or 1024 addresses - hardly a ?critical token in the EU address management and registration system? by any stretch of the imagination. This is the status quo today, and this proposal merely upholds it. I also find it rather hard to believe that an organisation willingly joins the NCC to become a new LIR, acquires an IPv6 allocation, and finally requests its first and only IPv4 /22 - only to find itself confused about how to go about using it in a sensible manner and end up assigning it away to an end user without any actual operational need. > * As mentioned in previous sections, the policy proposal would > negatively affect the ability of LIRs to engage in inter-RIR > transfers, as the RIPE NCC?s service region would be the only one > without a needs-based requirement for transfers. I feel this statement is somewhat disingenuous. The "odd RIR out" here is really ARIN, who is the only one to have a inter-RIR transfer policy that has a needs-based requirement that is also applied to the other region involved in the transfer. The RIPE region does not have a inter-RIR transfer policy *at all*. The same goes for LACNIC and AfriNIC, AFAIK. So as things stand today, 2013-03 cannot possibly "negatively affect the ability of LIRs to engage in inter-RIR transfers" because such transfers are completely verboten in the first place. That said, there has been an inter-RIR proposal (2012-02) on the table for a while now, but the community does not seem to want or care much about it. I think that this is important to keep that in mind when deciding on how much weight to give this argument against 2013-03. APNIC does have a inter-RIR transfer policy, but it does not require the other region to have a needs-based requirement. It explicitly states in section 4.3 that for transfers where the recipient is in another region, any conditions on the recipient is up to the recipient's region to define. So (assuming for a second that 2012-02 has passed) 2013-03 will not have any negative impact on transfers between the APNIC and RIPE regions. Another quite interesting thing to consider here is that APNIC initially had a transfer policy that did not require any need evaluation. It was only after the ARIN community changed their inter-RIR policy to explicitly require the other region to have "needs-based" policies APNIC added the need evaluation requirement to their general transfer policy. I think it is interesting to consider if yielding to the ARIN demand would actually be worth it, and APNIC actually provided some relevant data in this regard - on May 15th 2013, one of their reps explained to the APWG session at RIPE66 that there had been 11 inter-RIR transfers between ARIN and APNIC. APNIC depleted their IPv4 pool on the 19th of April 2011. Contrast this to the number of assignments that are being made in our region: The NCC reported that between depletion on the 14th of September 2012 and May 10th 2013, 251,254 assignments had been registered in the RIPE database. If we do linear extrapolation of the above to get "per year" numbers, what this boils down to is that we ask the entire RIPE community to fill out, validate, and archive 386,327 ripe-583 forms per year to allow 5 LIRs to engage in inter-RIR transfers with the ARIN region. You be the judge if this passes your idea of a basic cost-benefit analysis. It certainly doesn't pass mine. I'm not at all principally opposed to inter-RIR transfers, so if the author of 2012-02 would add a "need compatibility clause" to the proposed inter-RIR policy, I would have nothing against that. In other words, if it would be possible to make the need evaluation a voluntary thing that you only had to do if transferring addresses from the ARIN region - fine. Then those 5 LIRs, and those 5 only, could subject themselves to whatever demands the ARIN community might have, while the rest of us would be free of the IPv4 bureaucracy. Win-win. > * Implementation of the policy could expose LIRs to legal challenges > under EU competition law. If an LIR is willing to engage in unlawful anti-competitive practises, it will of course be exposed to legal challenges. This is certainly nothing new brought on by 2013-03 - the law trumps *any* address policy we can produce here, and that's how it's always been and always will be. Furthermore, it makes absolutely no sense to me for the community to demand that every single LIR and End User in the community uphold the "need" bureaucracy in an attempt to somehow shield or indemnify "bad" members of the community engaged in anti-competitive practises from legal repercussions. > I think singling out the RIPE NCC region in the world of transfers may > not be the best idea at this stage. This "world of transfers" has failed to materialise. The actual statistics show that the second-hand IPv4 transfer market is at most supplying 3-4% of last year's (pre-depletion) demand in our region. If we had completely removed the entire transfer policy today, I think that as far as the internet is concerned, tomorrow would have been business as usual. It seems that for most folks dealing with IPv4 depletion, CGN is the solution, not transfers. I think Rob Blokzijl hit the nail straight on the head when he in the RIPE66 APWG session warned against getting bogged down with discussing the ins and outs of ?little add-on policies like transfer?. After all, this proposal is a large and rough clean-up - it will be much easier to fine-tune and polish the remaining policy afterwards (transfers, PI/PA merging, etc.). Like I've said before, this proposal is essentially the amputation of the policy limbs that died following IPv4 depletion, and any following cosmetic surgery is best left for later. Best regards, Tore Anderson From koalafil at gmail.com Wed Jul 24 17:27:06 2013 From: koalafil at gmail.com (Filiz Yilmaz) Date: Wed, 24 Jul 2013 17:27:06 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51EFD4CC.9000006@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> Message-ID: <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> Hello Tore, Thank you for your detailed e-mail. In order not to have people get lost between our inline comments, I will only attempt to respond to you taking quotes from your mail. Apologies if this distorts the logical thought process you had put in. > The > language regarding registration requirements is not changed, so the > proposal does not change anything - it merely upholds the status quo. Those principle based registration and address management requirements were in the old policy between the lines, pointing to people notions like anti-hoarding practices through "need based" requirements. They may not ensure certain things 100% (policy is a policy, some abide some work around?) but surely they serve as gate-keepers for good behaviour and reflect the principles that this community engaged itself so far. So once you take those bits out, you also take those notions and principles out of the policy. That was my point and so I disagree that your proposal does not change anything. In fact it is bringing a big change, changing address delegation from "I want it because I need it on a network" to just "I want it and I am a member of the RIPE NCC so I can get it and maybe i won't even use it on a network". > What constitutes "good address management" is something > left to the LIRs to decide for themselves. I tend to disagree with this too. LIRs are members of the RIPE NCC but policies are developed by the entire RIPE Community, which is a bigger stakeholder. Those views should be reflected in the policy to be remembered and documented by the LIRs. > Example: As a LIR, you are > today free to assign your last free IPv4 block to a group of spammers at > the expense of having to turn down the Red Cross, perhaps because the > spammers were willing to pay you more. Is that "good"? I'd say quite the opposite, but yet it is perfectly allowed by today's policy. I see your point but policy does not mean "policing". To my knowledge, RIPE NCC never sent agents to LIR premises to check if the justification they documented fit with the reality or not. Besides that the address space is assigned to Red Cross or to a spammer (so who the recipient is) is irrelevant and has always been in the eyes of the RIPE policy. But whether or not either of these networks really needed these resources was the main idea. And this still does not mean that policy is not going to be there to remind people that this is a common pool of resources we are dealing with and its management requires some degree of responsibility. We might as well then not have a policy document at all and just have a click, pay and get your resource button on the RIPE NCC website. > So while I'm all for discussing the codification of a set of principles > in our policies telling our community to be "good", I'd rather not weigh > down this proposal with the addition of a brand-new "principles" > section These are not brand new principles, need base was there and your proposal is taking this away. I agreed with you when you presented your proposal in Dublin and noted it is not efficient to request someone to breakdown their need in such detail as 3 months to 1 yr or so. Yes, agreed, this is bureaucratic, admin resource hogging etc and this needs a change. But the same policy should still make some sense in a region why an LIR would go request some resource from their RIR and would be given that in the first place. If I am an LIR and I go to the RIPE NCC and ask for a resource I should be needing it on *some* network, not to put in my IP collection drawer. Policy should be the guard, gate-keeper for this at the least, in my opinion. >> * Implementation of the policy could expose LIRs to legal challenges >> under EU competition law. > > If an LIR is willing to engage in unlawful anti-competitive practises, > it will of course be exposed to legal challenges. This is certainly > nothing new brought on by 2013-03 - the law trumps *any* address policy > we can produce here, and that's how it's always been and always will be. I am not a lawyer, but hypothetically speaking, if your proposal gets accepted there is some (again totally hypothetical?) potential that some LIRs may chose to rush and get whatever is left in the NCC pool (which is the rest of the last /8?) without really needing them, simply because they do not need to show any justification after all. They want it, they will get it and probably RIPE NCC will have to deal with some very serious First in First Out (granted) service scheme... And then these LIRs who were lucky to get all the space they wanted and the RIPE NCC could provide to them at the time, may chose to put these resources back in the market for others, end users or other LIRs. I would find this quiet an unfortunate environment for new entrants who are not LIRs yet at the time of your proposal gets accepted, but who really need the space and is left to get the resources from an LIR instead of an RIR whose job was the allocation of the resources in the first place. I believe thinking about the impact here in the light of competition laws like this may in fact have some ground. Kind regards Filiz Yilmaz On 24 Jul 2013, at 15:21, Tore Anderson wrote: > * Filiz Yilmaz >> My observation is that the new document proposed is not exactly a >> "registration" policy document. >> It more looked to me like a description of how address space management >> is done within RIPE NCC region "by the RIPE NCC". >> >> If I am not missing anything crucial, the main points described are: >> >> - The language is English, >> - How big an allocation can be, >> - That there is no PI anymore to be assigned directly from the NCC pools >> to End users (except for the IXPs) so all resources will only goto LIRs >> - And these blocks can be transferred between LIRs. >> >> The only bit about registration I see in the new text is section 4.0 >> Registration Requirements and it does not go more than saying details >> should be recorded in the database. >> >> So it does not contain any substantial information for registration or >> address management on the LIR's side. > > Hello Filiz, > > The proposal is a modification of the existing policy document > (ripe-592), it is not a brand new document written from scratch. The > language regarding registration requirements is not changed, so the > proposal does not change anything - it merely upholds the status quo. > > We can certainly discuss amending the current registration requirements, > but to me this topic does not seem germane to the discussion of 2013-03. > >> This is interesting as now with this proposed policy any End user's >> chance to get any IPv4 address space will be through an LIR and hope >> that these LIRs are responsible and know what they are doing. I would >> like to see some guidelines or at least principles mentioned in this >> document so the LIRs know their responsibility in terms of fair address >> management as well as the End Users so they know what to expect from >> these LIRs. This is what I would be expecting from a transparent >> documentation of a set of policies and principles that are still in place. >> >> We may not have too many specific policies to set for the few left-over >> resources but I would like to believe we still have "principles" towards >> the responsible management of these resources. >> >> In that sense Michele has a point and I argue that LIRs need to be >> guided for "good address management" even without the "conservation" >> principle as the top priority in the new IP world. This is missing in >> the proposed policy text for it to be considered as a helpful >> "registration" policy in my opinion. > > I have no problems being sympathetic towards a "good address management" > principle, but the simple fact is that this is not written down in our > current policy. What constitutes "good address management" is something > left to the LIRs to decide for themselves. Example: As a LIR, you are > today free to assign your last free IPv4 block to a group of spammers at > the expense of having to turn down the Red Cross, perhaps because the > spammers were willing to pay you more. Is that "good"? I'd say quite the > opposite, but yet it is perfectly allowed by today's policy. > > So while I'm all for discussing the codification of a set of principles > in our policies telling our community to be "good", I'd rather not weigh > down this proposal with the addition of a brand-new "principles" > section, which I suspect would require a lot of back-and-forth > word-smithing to make everyone happy. So if we do want such a section, > let's add it in a separate proposal. > >> In practice, I can set up a new LIR now and ask for a new allocation and >> I may be someone who does not have any previous RIPE or RIPE NCC >> experience. >> If all I have is this document, I am not sure if it tells me enough >> about my responsibilities, while I will be a critical token in the EU >> address management and registration system by just becoming an LIR. > > As a new LIR, all the IPv4 address space you are going to get from the > RIPE NCC is a /22, or 1024 addresses - hardly a ?critical token in the > EU address management and registration system? by any stretch of the > imagination. This is the status quo today, and this proposal merely > upholds it. > > I also find it rather hard to believe that an organisation willingly > joins the NCC to become a new LIR, acquires an IPv6 allocation, and > finally requests its first and only IPv4 /22 - only to find itself > confused about how to go about using it in a sensible manner and end up > assigning it away to an end user without any actual operational need. > >> * As mentioned in previous sections, the policy proposal would >> negatively affect the ability of LIRs to engage in inter-RIR >> transfers, as the RIPE NCC?s service region would be the only one >> without a needs-based requirement for transfers. > > I feel this statement is somewhat disingenuous. The "odd RIR out" here > is really ARIN, who is the only one to have a inter-RIR transfer policy > that has a needs-based requirement that is also applied to the other > region involved in the transfer. > > The RIPE region does not have a inter-RIR transfer policy *at all*. The > same goes for LACNIC and AfriNIC, AFAIK. So as things stand today, > 2013-03 cannot possibly "negatively affect the ability of LIRs to engage > in inter-RIR transfers" because such transfers are completely verboten > in the first place. > > That said, there has been an inter-RIR proposal (2012-02) on the table > for a while now, but the community does not seem to want or care much > about it. I think that this is important to keep that in mind when > deciding on how much weight to give this argument against 2013-03. > > APNIC does have a inter-RIR transfer policy, but it does not require the > other region to have a needs-based requirement. It explicitly states in > section 4.3 that for transfers where the recipient is in another region, > any conditions on the recipient is up to the recipient's region to > define. So (assuming for a second that 2012-02 has passed) 2013-03 will > not have any negative impact on transfers between the APNIC and RIPE > regions. > > Another quite interesting thing to consider here is that APNIC initially > had a transfer policy that did not require any need evaluation. It was > only after the ARIN community changed their inter-RIR policy to > explicitly require the other region to have "needs-based" policies APNIC > added the need evaluation requirement to their general transfer policy. > I think it is interesting to consider if yielding to the ARIN demand > would actually be worth it, and APNIC actually provided some relevant > data in this regard - on May 15th 2013, one of their reps explained to > the APWG session at RIPE66 that there had been 11 inter-RIR transfers > between ARIN and APNIC. APNIC depleted their IPv4 pool on the 19th of > April 2011. Contrast this to the number of assignments that are being > made in our region: The NCC reported that between depletion on the 14th > of September 2012 and May 10th 2013, 251,254 assignments had been > registered in the RIPE database. > > If we do linear extrapolation of the above to get "per year" numbers, > what this boils down to is that we ask the entire RIPE community to fill > out, validate, and archive 386,327 ripe-583 forms per year to allow 5 > LIRs to engage in inter-RIR transfers with the ARIN region. You be the > judge if this passes your idea of a basic cost-benefit analysis. It > certainly doesn't pass mine. > > I'm not at all principally opposed to inter-RIR transfers, so if the > author of 2012-02 would add a "need compatibility clause" to the > proposed inter-RIR policy, I would have nothing against that. In other > words, if it would be possible to make the need evaluation a voluntary > thing that you only had to do if transferring addresses from the ARIN > region - fine. Then those 5 LIRs, and those 5 only, could subject > themselves to whatever demands the ARIN community might have, while the > rest of us would be free of the IPv4 bureaucracy. Win-win. > >> * Implementation of the policy could expose LIRs to legal challenges >> under EU competition law. > > If an LIR is willing to engage in unlawful anti-competitive practises, > it will of course be exposed to legal challenges. This is certainly > nothing new brought on by 2013-03 - the law trumps *any* address policy > we can produce here, and that's how it's always been and always will be. > > Furthermore, it makes absolutely no sense to me for the community to > demand that every single LIR and End User in the community uphold the > "need" bureaucracy in an attempt to somehow shield or indemnify "bad" > members of the community engaged in anti-competitive practises from > legal repercussions. > >> I think singling out the RIPE NCC region in the world of transfers may >> not be the best idea at this stage. > > This "world of transfers" has failed to materialise. The actual > statistics show that the second-hand IPv4 transfer market is at most > supplying 3-4% of last year's (pre-depletion) demand in our region. If > we had completely removed the entire transfer policy today, I think that > as far as the internet is concerned, tomorrow would have been business > as usual. It seems that for most folks dealing with IPv4 depletion, CGN > is the solution, not transfers. > > I think Rob Blokzijl hit the nail straight on the head when he in the > RIPE66 APWG session warned against getting bogged down with discussing > the ins and outs of ?little add-on policies like transfer?. After all, > this proposal is a large and rough clean-up - it will be much easier to > fine-tune and polish the remaining policy afterwards (transfers, PI/PA > merging, etc.). Like I've said before, this proposal is essentially the > amputation of the policy limbs that died following IPv4 depletion, and > any following cosmetic surgery is best left for later. > > Best regards, > Tore Anderson > From tore at fud.no Wed Jul 24 18:50:01 2013 From: tore at fud.no (Tore Anderson) Date: Wed, 24 Jul 2013 18:50:01 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> Message-ID: <51F005B9.3050408@fud.no> Hi again Filiz, > In order not to have people get lost between our inline comments, I > will only attempt to respond to you taking quotes from your mail. > Apologies if this distorts the logical thought process you had put > in. No problem, I'll do the same. :-) > Those principle based registration and address management > requirements were in the old policy between the lines, pointing to > people notions like anti-hoarding practices through "need based" > requirements. Actually, you don't have to read between the lines to find the reason for "need based"/"anti-hoarding". It is explicitly stated in the policy, specifically section 3.0.3: ?To maximise the lifetime of the public IPv4 address space?. And this of course made perfect sense. If the LIRs had been free to grab as much as they pleased with no checks and bounds, that would in all likelihood have caused the NCC's public pool of IPv4 space, and by extension the IANA's, to deplete many many years ago. It was all about delaying the Tragedy of the Commons as much as possible. Had we as a community done a much better job with IPv6, we could have avoided it from happening altogether, but that ship has sailed - the Tragedy occurred last September. > So once you take those bits out, you also take those notions and > principles out of the policy. That was my point and so I disagree > that your proposal does not change anything. In fact it is bringing a > big change, changing address delegation from "I want it because I > need it on a network" There is a difference between a Service Provider and an Internet Registry. The former operates networks, the latter delegates numbers. Often a single organisation fills both roles, but this is not a requirement, just a convenience. You could easily run an LIR from your laptop or tablet in the local coffee shop - all you need is an e-mail account, really (and money to pay the membership fee). So when it comes to allocations, "need" isn't borne from "I need it on a network", but rather "I need it so I can assign it to an End User". > "I want it and I am a member of the RIPE NCC so I can get it Get it from *where* and *who*, exactly? >> What constitutes "good address management" is something left to the >> LIRs to decide for themselves. > > I tend to disagree with this too. LIRs are members of the RIPE NCC > but policies are developed by the entire RIPE Community, which is a > bigger stakeholder. Those views should be reflected in the policy to > be remembered and documented by the LIRs. Clearly, if the RIPE Community makes a policy that says X, then the LIRs must do X. But *as of right now*, the policy does not define any principles of "good address management", hence, LIRs are free to do what they wish. > I see your point but policy does not mean "policing". To my > knowledge, RIPE NCC never sent agents to LIR premises to check if the > justification they documented fit with the reality or not. Indeed, the whole "needs-based" system is entirely built on trust. The NCC is not the IPv4 Police (and I wouldn't want them to be either for simple cost/benefit reasons). > And this still does not mean that policy is not going to be there to > remind people that this is a common pool of resources we are dealing > with and its management requires some degree of responsibility. We > might as well then not have a policy document at all and just have a > click, pay and get your resource button on the RIPE NCC website. Again, get that resource from *where* and *who*? > If I am an LIR and I go to the RIPE NCC and ask for a resource [...] ...the RIPE NCC necessarily say "sorry, we're fresh out". (Except if you didn't pick up your last /22 yet, see below.) > I am not a lawyer, but hypothetically speaking, if your proposal gets > accepted there is some (again totally hypothetical?) potential that > some LIRs may chose to rush and get whatever is left in the NCC pool [...] > And then these LIRs who were lucky to get all the space they wanted No, this is completely impossible, and to be honest I am starting to wonder if you are familiar with the "last /8 policy" at all, or if you are under the impression that 2013-03 proposes to remove it (it does not). In a nutshell, it is the following: An LIR can get one (1) /22, no more, no less. Sizing according to "need" has *already been abandoned*; it doesn't matter one bit if the LIR's actual need is for 1 address or 1.000.000.000.000 addresses - the only thing you'll get, ever, is 1.024. The only way an LIR could possibly get "all the space they wanted", is if they wanted 1.024 addresses or less. But in that case, they would be able to get it under today's policy, too. Best regards, Tore Anderson From h.lu at anytimechinese.com Wed Jul 24 19:50:05 2013 From: h.lu at anytimechinese.com (Lu Heng) Date: Wed, 24 Jul 2013 19:50:05 +0200 Subject: [address-policy-wg] address-policy-wg Digest, Vol 23, Issue 15 In-Reply-To: References: Message-ID: Hi Should the technical side of resouce training being done by ripe ncc training rather than policy? I am not against put basic principal there though. On Jul 24, 2013 5:27 PM, wrote: > Send address-policy-wg mailing list submissions to > address-policy-wg at ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ripe.net/mailman/listinfo/address-policy-wg > or, via email, send a message with subject or body 'help' to > address-policy-wg-request at ripe.net > > You can reach the person managing the list at > address-policy-wg-owner at ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." > > > Today's Topics: > > 1. Re: 2013-03 New Draft Document and Impact Analysis Published > (No Need - Post-Depletion Reality Adjustment and Clean up) > (Filiz Yilmaz) > 2. Re: 2013-03 New Draft Document and Impact Analysis Published > (No Need - Post-Depletion Reality Adjustment and Clean up) > (Tore Anderson) > 3. Re: 2013-03 New Draft Document and Impact Analysis Published > (No Need - Post-Depletion Reality Adjustment and Clean up) > (Filiz Yilmaz) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 24 Jul 2013 12:53:18 +0200 > From: Filiz Yilmaz > Subject: Re: [address-policy-wg] 2013-03 New Draft Document and Impact > Analysis Published (No Need - Post-Depletion Reality Adjustment > and > Clean up) > To: Tore Anderson > Cc: "address-policy-wg at ripe.net" > Message-ID: > Content-Type: text/plain; charset="windows-1252" > > Hello Tore, > > While I am curious for Michele's response to your mail too, here is my > bit, as I feel I agree with him in terms of principles. > > First of all, I am not totally against your proposal; it cleans up the > policy text reflecting today's circumstances to some extent and it makes a > long document way more readable. > This is also why I am writing back because I've read the draft policy > document from the beginning to the end. > > My observation is that the new document proposed is not exactly a > "registration" policy document. > It more looked to me like a description of how address space management is > done within RIPE NCC region "by the RIPE NCC". > > If I am not missing anything crucial, the main points described are: > > - The language is English, > - How big an allocation can be, > - That there is no PI anymore to be assigned directly from the NCC pools > to End users (except for the IXPs) so all resources will only goto LIRs > - And these blocks can be transferred between LIRs. > > The only bit about registration I see in the new text is section 4.0 > Registration Requirements and it does not go more than saying details > should be recorded in the database. > > So it does not contain any substantial information for registration or > address management on the LIR's side. > > This is interesting as now with this proposed policy any End user's chance > to get any IPv4 address space will be through an LIR and hope that these > LIRs are responsible and know what they are doing. I would like to see some > guidelines or at least principles mentioned in this document so the LIRs > know their responsibility in terms of fair address management as well as > the End Users so they know what to expect from these LIRs. This is what I > would be expecting from a transparent documentation of a set of policies > and principles that are still in place. > > We may not have too many specific policies to set for the few left-over > resources but I would like to believe we still have "principles" towards > the responsible management of these resources. > > In that sense Michele has a point and I argue that LIRs need to be guided > for "good address management" even without the "conservation" principle as > the top priority in the new IP world. This is missing in the proposed > policy text for it to be considered as a helpful "registration" policy in > my opinion. > > In practice, I can set up a new LIR now and ask for a new allocation and I > may be someone who does not have any previous RIPE or RIPE NCC experience. > If all I have is this document, I am not sure if it tells me enough about > my responsibilities, while I will be a critical token in the EU address > management and registration system by just becoming an LIR. > > > My other concern is in regards to the transfers. As neatly put by the NCC > Board in the Impact Analysis: > > --- > As mentioned in previous sections, the policy proposal would negatively > affect the ability of LIRs to engage in inter-RIR transfers, as the RIPE > NCC?s service region would be the only one without a needs-based > requirement for transfers. > Implementation of the policy could expose LIRs to legal challenges under > EU competition law. > --- > > > I think singling out the RIPE NCC region in the world of transfers may not > be the best idea at this stage. > > Kind regards > Filiz Yilmaz > > > > > On 24 Jul 2013, at 10:52, Tore Anderson wrote: > > > * Michele Neylon - Blacknight > > > >> As previously stated, I do NOT support the "no need" policy and > >> cannot support this document. > >> > >> IP addresses are a finite resource, as we all know, and obliging > >> people to provide some level of justification makes sense. > >> > >> The argument for "conservation" may no longer be valid, but there > >> will always be a compelling argument in favour of good resource > >> management, which I believe the policy covers. > >> > >> RIPE should not remove the requirement to provide justification. > > > > Hi Michele, > > > > I doubt you'll find anyone in the working group who is against good > > resource management. I am convinced that the proposed policy is not in > > conflict with good resource management, otherwise I would never have > > proposed it. While I can obviously only speak with certainty for myself, > > I assume that the people who support the proposal feel the same way. > > > > While it appears you believe that the proposal will bring about poor > > resource management, your message neglected to explain why or how. This > > makes it rather difficult for me to try to alleviate your concerns. > > > > As Gert also pointed out recently, the main reason I believe that IPv4 > > would continue to be consumed responsibly under the proposed policy, is > > that the LIRs in the region are painfully aware that there is no more > > IPv4 to be had from the RIPE NCC. Should an LIR anyway decide to go on a > > "spending spree" with its remaining inventory, it would only end up > > hurting itself by expediting its own depletion date. The community will > > not be impacted - without a Common, there can be no Tragedy. > > > > Best regards, > > Tore Anderson > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > https://www.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20130724/ba913f41/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Wed, 24 Jul 2013 15:21:16 +0200 > From: Tore Anderson > Subject: Re: [address-policy-wg] 2013-03 New Draft Document and Impact > Analysis Published (No Need - Post-Depletion Reality Adjustment and > Clean up) > To: "address-policy-wg at ripe.net" > Message-ID: <51EFD4CC.9000006 at fud.no> > Content-Type: text/plain; charset=windows-1252 > > * Filiz Yilmaz > > My observation is that the new document proposed is not exactly a > > "registration" policy document. > > It more looked to me like a description of how address space management > > is done within RIPE NCC region "by the RIPE NCC". > > > > If I am not missing anything crucial, the main points described are: > > > > - The language is English, > > - How big an allocation can be, > > - That there is no PI anymore to be assigned directly from the NCC pools > > to End users (except for the IXPs) so all resources will only goto LIRs > > - And these blocks can be transferred between LIRs. > > > > The only bit about registration I see in the new text is section 4.0 > > Registration Requirements and it does not go more than saying details > > should be recorded in the database. > > > > So it does not contain any substantial information for registration or > > address management on the LIR's side. > > Hello Filiz, > > The proposal is a modification of the existing policy document > (ripe-592), it is not a brand new document written from scratch. The > language regarding registration requirements is not changed, so the > proposal does not change anything - it merely upholds the status quo. > > We can certainly discuss amending the current registration requirements, > but to me this topic does not seem germane to the discussion of 2013-03. > > > This is interesting as now with this proposed policy any End user's > > chance to get any IPv4 address space will be through an LIR and hope > > that these LIRs are responsible and know what they are doing. I would > > like to see some guidelines or at least principles mentioned in this > > document so the LIRs know their responsibility in terms of fair address > > management as well as the End Users so they know what to expect from > > these LIRs. This is what I would be expecting from a transparent > > documentation of a set of policies and principles that are still in > place. > > > > We may not have too many specific policies to set for the few left-over > > resources but I would like to believe we still have "principles" towards > > the responsible management of these resources. > > > > In that sense Michele has a point and I argue that LIRs need to be > > guided for "good address management" even without the "conservation" > > principle as the top priority in the new IP world. This is missing in > > the proposed policy text for it to be considered as a helpful > > "registration" policy in my opinion. > > I have no problems being sympathetic towards a "good address management" > principle, but the simple fact is that this is not written down in our > current policy. What constitutes "good address management" is something > left to the LIRs to decide for themselves. Example: As a LIR, you are > today free to assign your last free IPv4 block to a group of spammers at > the expense of having to turn down the Red Cross, perhaps because the > spammers were willing to pay you more. Is that "good"? I'd say quite the > opposite, but yet it is perfectly allowed by today's policy. > > So while I'm all for discussing the codification of a set of principles > in our policies telling our community to be "good", I'd rather not weigh > down this proposal with the addition of a brand-new "principles" > section, which I suspect would require a lot of back-and-forth > word-smithing to make everyone happy. So if we do want such a section, > let's add it in a separate proposal. > > > In practice, I can set up a new LIR now and ask for a new allocation and > > I may be someone who does not have any previous RIPE or RIPE NCC > > experience. > > If all I have is this document, I am not sure if it tells me enough > > about my responsibilities, while I will be a critical token in the EU > > address management and registration system by just becoming an LIR. > > As a new LIR, all the IPv4 address space you are going to get from the > RIPE NCC is a /22, or 1024 addresses - hardly a ?critical token in the > EU address management and registration system? by any stretch of the > imagination. This is the status quo today, and this proposal merely > upholds it. > > I also find it rather hard to believe that an organisation willingly > joins the NCC to become a new LIR, acquires an IPv6 allocation, and > finally requests its first and only IPv4 /22 - only to find itself > confused about how to go about using it in a sensible manner and end up > assigning it away to an end user without any actual operational need. > > > * As mentioned in previous sections, the policy proposal would > > negatively affect the ability of LIRs to engage in inter-RIR > > transfers, as the RIPE NCC?s service region would be the only one > > without a needs-based requirement for transfers. > > I feel this statement is somewhat disingenuous. The "odd RIR out" here > is really ARIN, who is the only one to have a inter-RIR transfer policy > that has a needs-based requirement that is also applied to the other > region involved in the transfer. > > The RIPE region does not have a inter-RIR transfer policy *at all*. The > same goes for LACNIC and AfriNIC, AFAIK. So as things stand today, > 2013-03 cannot possibly "negatively affect the ability of LIRs to engage > in inter-RIR transfers" because such transfers are completely verboten > in the first place. > > That said, there has been an inter-RIR proposal (2012-02) on the table > for a while now, but the community does not seem to want or care much > about it. I think that this is important to keep that in mind when > deciding on how much weight to give this argument against 2013-03. > > APNIC does have a inter-RIR transfer policy, but it does not require the > other region to have a needs-based requirement. It explicitly states in > section 4.3 that for transfers where the recipient is in another region, > any conditions on the recipient is up to the recipient's region to > define. So (assuming for a second that 2012-02 has passed) 2013-03 will > not have any negative impact on transfers between the APNIC and RIPE > regions. > > Another quite interesting thing to consider here is that APNIC initially > had a transfer policy that did not require any need evaluation. It was > only after the ARIN community changed their inter-RIR policy to > explicitly require the other region to have "needs-based" policies APNIC > added the need evaluation requirement to their general transfer policy. > I think it is interesting to consider if yielding to the ARIN demand > would actually be worth it, and APNIC actually provided some relevant > data in this regard - on May 15th 2013, one of their reps explained to > the APWG session at RIPE66 that there had been 11 inter-RIR transfers > between ARIN and APNIC. APNIC depleted their IPv4 pool on the 19th of > April 2011. Contrast this to the number of assignments that are being > made in our region: The NCC reported that between depletion on the 14th > of September 2012 and May 10th 2013, 251,254 assignments had been > registered in the RIPE database. > > If we do linear extrapolation of the above to get "per year" numbers, > what this boils down to is that we ask the entire RIPE community to fill > out, validate, and archive 386,327 ripe-583 forms per year to allow 5 > LIRs to engage in inter-RIR transfers with the ARIN region. You be the > judge if this passes your idea of a basic cost-benefit analysis. It > certainly doesn't pass mine. > > I'm not at all principally opposed to inter-RIR transfers, so if the > author of 2012-02 would add a "need compatibility clause" to the > proposed inter-RIR policy, I would have nothing against that. In other > words, if it would be possible to make the need evaluation a voluntary > thing that you only had to do if transferring addresses from the ARIN > region - fine. Then those 5 LIRs, and those 5 only, could subject > themselves to whatever demands the ARIN community might have, while the > rest of us would be free of the IPv4 bureaucracy. Win-win. > > > * Implementation of the policy could expose LIRs to legal challenges > > under EU competition law. > > If an LIR is willing to engage in unlawful anti-competitive practises, > it will of course be exposed to legal challenges. This is certainly > nothing new brought on by 2013-03 - the law trumps *any* address policy > we can produce here, and that's how it's always been and always will be. > > Furthermore, it makes absolutely no sense to me for the community to > demand that every single LIR and End User in the community uphold the > "need" bureaucracy in an attempt to somehow shield or indemnify "bad" > members of the community engaged in anti-competitive practises from > legal repercussions. > > > I think singling out the RIPE NCC region in the world of transfers may > > not be the best idea at this stage. > > This "world of transfers" has failed to materialise. The actual > statistics show that the second-hand IPv4 transfer market is at most > supplying 3-4% of last year's (pre-depletion) demand in our region. If > we had completely removed the entire transfer policy today, I think that > as far as the internet is concerned, tomorrow would have been business > as usual. It seems that for most folks dealing with IPv4 depletion, CGN > is the solution, not transfers. > > I think Rob Blokzijl hit the nail straight on the head when he in the > RIPE66 APWG session warned against getting bogged down with discussing > the ins and outs of ?little add-on policies like transfer?. After all, > this proposal is a large and rough clean-up - it will be much easier to > fine-tune and polish the remaining policy afterwards (transfers, PI/PA > merging, etc.). Like I've said before, this proposal is essentially the > amputation of the policy limbs that died following IPv4 depletion, and > any following cosmetic surgery is best left for later. > > Best regards, > Tore Anderson > > > > ------------------------------ > > Message: 3 > Date: Wed, 24 Jul 2013 17:27:06 +0200 > From: Filiz Yilmaz > Subject: Re: [address-policy-wg] 2013-03 New Draft Document and Impact > Analysis Published (No Need - Post-Depletion Reality Adjustment > and > Clean up) > To: Tore Anderson > Cc: "address-policy-wg at ripe.net" > Message-ID: <965997CB-07D2-49B9-BD9A-74E230F13724 at gmail.com> > Content-Type: text/plain; charset=windows-1252 > > Hello Tore, > > Thank you for your detailed e-mail. > > In order not to have people get lost between our inline comments, I will > only attempt to respond to you taking quotes from your mail. > Apologies if this distorts the logical thought process you had put in. > > > The > > language regarding registration requirements is not changed, so the > > proposal does not change anything - it merely upholds the status quo. > > Those principle based registration and address management requirements > were in the old policy between the lines, pointing to people notions like > anti-hoarding practices through "need based" requirements. They may not > ensure certain things 100% (policy is a policy, some abide some work > around?) but surely they serve as gate-keepers for good behaviour and > reflect the principles that this community engaged itself so far. > > So once you take those bits out, you also take those notions and > principles out of the policy. That was my point and so I disagree that your > proposal does not change anything. In fact it is bringing a big change, > changing address delegation from "I want it because I need it on a network" > to just "I want it and I am a member of the RIPE NCC so I can get it and > maybe i won't even use it on a network". > > > What constitutes "good address management" is something > > left to the LIRs to decide for themselves. > > I tend to disagree with this too. LIRs are members of the RIPE NCC but > policies are developed by the entire RIPE Community, which is a bigger > stakeholder. > Those views should be reflected in the policy to be remembered and > documented by the LIRs. > > > Example: As a LIR, you are > > today free to assign your last free IPv4 block to a group of spammers at > > the expense of having to turn down the Red Cross, perhaps because the > > spammers were willing to pay you more. Is that "good"? I'd say quite the > opposite, but yet it is perfectly allowed by today's policy. > > I see your point but policy does not mean "policing". To my knowledge, > RIPE NCC never sent agents to LIR premises to check if the justification > they documented fit with the reality or not. Besides that the address space > is assigned to Red Cross or to a spammer (so who the recipient is) is > irrelevant and has always been in the eyes of the RIPE policy. But whether > or not either of these networks really needed these resources was the main > idea. > > And this still does not mean that policy is not going to be there to > remind people that this is a common pool of resources we are dealing with > and its management requires some degree of responsibility. We might as well > then not have a policy document at all and just have a click, pay and get > your resource button on the RIPE NCC website. > > > > So while I'm all for discussing the codification of a set of principles > > in our policies telling our community to be "good", I'd rather not weigh > > down this proposal with the addition of a brand-new "principles" > > section > > > These are not brand new principles, need base was there and your proposal > is taking this away. > I agreed with you when you presented your proposal in Dublin and noted it > is not efficient to request someone to breakdown their need in such detail > as 3 months to 1 yr or so. Yes, agreed, this is bureaucratic, admin > resource hogging etc and this needs a change. > > But the same policy should still make some sense in a region why an LIR > would go request some resource from their RIR and would be given that in > the first place. > If I am an LIR and I go to the RIPE NCC and ask for a resource I should be > needing it on *some* network, not to put in my IP collection drawer. > Policy should be the guard, gate-keeper for this at the least, in my > opinion. > > > >> * Implementation of the policy could expose LIRs to legal challenges > >> under EU competition law. > > > > If an LIR is willing to engage in unlawful anti-competitive practises, > > it will of course be exposed to legal challenges. This is certainly > > nothing new brought on by 2013-03 - the law trumps *any* address policy > > we can produce here, and that's how it's always been and always will be. > > > I am not a lawyer, but hypothetically speaking, if your proposal gets > accepted there is some (again totally hypothetical?) potential that some > LIRs may chose to rush and get whatever is left in the NCC pool (which is > the rest of the last /8?) without really needing them, simply because they > do not need to show any justification after all. They want it, they will > get it and probably RIPE NCC will have to deal with some very serious First > in First Out (granted) service scheme... > > And then these LIRs who were lucky to get all the space they wanted and > the RIPE NCC could provide to them at the time, may chose to put these > resources back in the market for others, end users or other LIRs. I would > find this quiet an unfortunate environment for new entrants who are not > LIRs yet at the time of your proposal gets accepted, but who really need > the space and is left to get the resources from an LIR instead of an RIR > whose job was the allocation of the resources in the first place. > > I believe thinking about the impact here in the light of competition laws > like this may in fact have some ground. > > Kind regards > Filiz Yilmaz > > On 24 Jul 2013, at 15:21, Tore Anderson wrote: > > > * Filiz Yilmaz > >> My observation is that the new document proposed is not exactly a > >> "registration" policy document. > >> It more looked to me like a description of how address space management > >> is done within RIPE NCC region "by the RIPE NCC". > >> > >> If I am not missing anything crucial, the main points described are: > >> > >> - The language is English, > >> - How big an allocation can be, > >> - That there is no PI anymore to be assigned directly from the NCC pools > >> to End users (except for the IXPs) so all resources will only goto LIRs > >> - And these blocks can be transferred between LIRs. > >> > >> The only bit about registration I see in the new text is section 4.0 > >> Registration Requirements and it does not go more than saying details > >> should be recorded in the database. > >> > >> So it does not contain any substantial information for registration or > >> address management on the LIR's side. > > > > Hello Filiz, > > > > The proposal is a modification of the existing policy document > > (ripe-592), it is not a brand new document written from scratch. The > > language regarding registration requirements is not changed, so the > > proposal does not change anything - it merely upholds the status quo. > > > > We can certainly discuss amending the current registration requirements, > > but to me this topic does not seem germane to the discussion of 2013-03. > > > >> This is interesting as now with this proposed policy any End user's > >> chance to get any IPv4 address space will be through an LIR and hope > >> that these LIRs are responsible and know what they are doing. I would > >> like to see some guidelines or at least principles mentioned in this > >> document so the LIRs know their responsibility in terms of fair address > >> management as well as the End Users so they know what to expect from > >> these LIRs. This is what I would be expecting from a transparent > >> documentation of a set of policies and principles that are still in > place. > >> > >> We may not have too many specific policies to set for the few left-over > >> resources but I would like to believe we still have "principles" towards > >> the responsible management of these resources. > >> > >> In that sense Michele has a point and I argue that LIRs need to be > >> guided for "good address management" even without the "conservation" > >> principle as the top priority in the new IP world. This is missing in > >> the proposed policy text for it to be considered as a helpful > >> "registration" policy in my opinion. > > > > I have no problems being sympathetic towards a "good address management" > > principle, but the simple fact is that this is not written down in our > > current policy. What constitutes "good address management" is something > > left to the LIRs to decide for themselves. Example: As a LIR, you are > > today free to assign your last free IPv4 block to a group of spammers at > > the expense of having to turn down the Red Cross, perhaps because the > > spammers were willing to pay you more. Is that "good"? I'd say quite the > > opposite, but yet it is perfectly allowed by today's policy. > > > > So while I'm all for discussing the codification of a set of principles > > in our policies telling our community to be "good", I'd rather not weigh > > down this proposal with the addition of a brand-new "principles" > > section, which I suspect would require a lot of back-and-forth > > word-smithing to make everyone happy. So if we do want such a section, > > let's add it in a separate proposal. > > > >> In practice, I can set up a new LIR now and ask for a new allocation and > >> I may be someone who does not have any previous RIPE or RIPE NCC > >> experience. > >> If all I have is this document, I am not sure if it tells me enough > >> about my responsibilities, while I will be a critical token in the EU > >> address management and registration system by just becoming an LIR. > > > > As a new LIR, all the IPv4 address space you are going to get from the > > RIPE NCC is a /22, or 1024 addresses - hardly a ?critical token in the > > EU address management and registration system? by any stretch of the > > imagination. This is the status quo today, and this proposal merely > > upholds it. > > > > I also find it rather hard to believe that an organisation willingly > > joins the NCC to become a new LIR, acquires an IPv6 allocation, and > > finally requests its first and only IPv4 /22 - only to find itself > > confused about how to go about using it in a sensible manner and end up > > assigning it away to an end user without any actual operational need. > > > >> * As mentioned in previous sections, the policy proposal would > >> negatively affect the ability of LIRs to engage in inter-RIR > >> transfers, as the RIPE NCC?s service region would be the only one > >> without a needs-based requirement for transfers. > > > > I feel this statement is somewhat disingenuous. The "odd RIR out" here > > is really ARIN, who is the only one to have a inter-RIR transfer policy > > that has a needs-based requirement that is also applied to the other > > region involved in the transfer. > > > > The RIPE region does not have a inter-RIR transfer policy *at all*. The > > same goes for LACNIC and AfriNIC, AFAIK. So as things stand today, > > 2013-03 cannot possibly "negatively affect the ability of LIRs to engage > > in inter-RIR transfers" because such transfers are completely verboten > > in the first place. > > > > That said, there has been an inter-RIR proposal (2012-02) on the table > > for a while now, but the community does not seem to want or care much > > about it. I think that this is important to keep that in mind when > > deciding on how much weight to give this argument against 2013-03. > > > > APNIC does have a inter-RIR transfer policy, but it does not require the > > other region to have a needs-based requirement. It explicitly states in > > section 4.3 that for transfers where the recipient is in another region, > > any conditions on the recipient is up to the recipient's region to > > define. So (assuming for a second that 2012-02 has passed) 2013-03 will > > not have any negative impact on transfers between the APNIC and RIPE > > regions. > > > > Another quite interesting thing to consider here is that APNIC initially > > had a transfer policy that did not require any need evaluation. It was > > only after the ARIN community changed their inter-RIR policy to > > explicitly require the other region to have "needs-based" policies APNIC > > added the need evaluation requirement to their general transfer policy. > > I think it is interesting to consider if yielding to the ARIN demand > > would actually be worth it, and APNIC actually provided some relevant > > data in this regard - on May 15th 2013, one of their reps explained to > > the APWG session at RIPE66 that there had been 11 inter-RIR transfers > > between ARIN and APNIC. APNIC depleted their IPv4 pool on the 19th of > > April 2011. Contrast this to the number of assignments that are being > > made in our region: The NCC reported that between depletion on the 14th > > of September 2012 and May 10th 2013, 251,254 assignments had been > > registered in the RIPE database. > > > > If we do linear extrapolation of the above to get "per year" numbers, > > what this boils down to is that we ask the entire RIPE community to fill > > out, validate, and archive 386,327 ripe-583 forms per year to allow 5 > > LIRs to engage in inter-RIR transfers with the ARIN region. You be the > > judge if this passes your idea of a basic cost-benefit analysis. It > > certainly doesn't pass mine. > > > > I'm not at all principally opposed to inter-RIR transfers, so if the > > author of 2012-02 would add a "need compatibility clause" to the > > proposed inter-RIR policy, I would have nothing against that. In other > > words, if it would be possible to make the need evaluation a voluntary > > thing that you only had to do if transferring addresses from the ARIN > > region - fine. Then those 5 LIRs, and those 5 only, could subject > > themselves to whatever demands the ARIN community might have, while the > > rest of us would be free of the IPv4 bureaucracy. Win-win. > > > >> * Implementation of the policy could expose LIRs to legal challenges > >> under EU competition law. > > > > If an LIR is willing to engage in unlawful anti-competitive practises, > > it will of course be exposed to legal challenges. This is certainly > > nothing new brought on by 2013-03 - the law trumps *any* address policy > > we can produce here, and that's how it's always been and always will be. > > > > Furthermore, it makes absolutely no sense to me for the community to > > demand that every single LIR and End User in the community uphold the > > "need" bureaucracy in an attempt to somehow shield or indemnify "bad" > > members of the community engaged in anti-competitive practises from > > legal repercussions. > > > >> I think singling out the RIPE NCC region in the world of transfers may > >> not be the best idea at this stage. > > > > This "world of transfers" has failed to materialise. The actual > > statistics show that the second-hand IPv4 transfer market is at most > > supplying 3-4% of last year's (pre-depletion) demand in our region. If > > we had completely removed the entire transfer policy today, I think that > > as far as the internet is concerned, tomorrow would have been business > > as usual. It seems that for most folks dealing with IPv4 depletion, CGN > > is the solution, not transfers. > > > > I think Rob Blokzijl hit the nail straight on the head when he in the > > RIPE66 APWG session warned against getting bogged down with discussing > > the ins and outs of ?little add-on policies like transfer?. After all, > > this proposal is a large and rough clean-up - it will be much easier to > > fine-tune and polish the remaining policy afterwards (transfers, PI/PA > > merging, etc.). Like I've said before, this proposal is essentially the > > amputation of the policy limbs that died following IPv4 depletion, and > > any following cosmetic surgery is best left for later. > > > > Best regards, > > Tore Anderson > > > > > > > End of address-policy-wg Digest, Vol 23, Issue 15 > ************************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Wed Jul 24 19:58:23 2013 From: gert at space.net (Gert Doering) Date: Wed, 24 Jul 2013 19:58:23 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> Message-ID: <20130724175823.GE65295@Space.Net> Hi, On Wed, Jul 24, 2013 at 05:27:06PM +0200, Filiz Yilmaz wrote: > I am not a lawyer, but hypothetically speaking, if your proposal > gets accepted there is some (again totally hypothetical?) potential > that some LIRs may chose to rush and get whatever is left in the > NCC pool (which is the rest of the last /8?) without really needing > them, simply because they do not need to show any justification > after all. They want it, they will get it and probably RIPE NCC > will have to deal with some very serious First in First Out (granted) > service scheme... Uh, Filiz, there is no real difference between "old policy" and "with 2013-03 in place" in that regard. Both limit the address space that a single LIR can "rush and get whatever is left" to a *single /22*. So if you want to hoard, you need to open 5000 LIRs today, each of them applying for a /22, and documenting the need for a *single* IPv4 address (as the /22 allocation is not sized based on the difference between "I need a single address" vs. "I need a /8" - need is need) and a single IPv4 address is easier documented than a new corporation opened to become LIR. If you want it after 2013-03 is in place, you need to open 5000 LIRs, each of them applying for a /22, and not documenting the need for a single IPv4 address anymore. But you still need to incoprorate 5000 companies. The only place where "document need" makes a difference is if a LIR already has allocated space, which needs to be filled to 80% today, and that would go away with 2013-03 - but there is just no way a single LIR can "grab the rest of the last /8 pool". But maybe I'm misunderstanding your point? (The /22 in the "last /8 policy" was chosen to ensure that every single LIR in existence today can get their /22, and we'll still have some left - the /8 will last for 16.000 /22s, and the number of active LIR is still below 9000 today) Gert Doering -- NetMaster -- have you enabled 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From tore at fud.no Wed Jul 24 20:16:35 2013 From: tore at fud.no (Tore Anderson) Date: Wed, 24 Jul 2013 20:16:35 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <20130724175823.GE65295@Space.Net> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <20130724175823.GE65295@Space.Net> Message-ID: <51F01A03.2040808@fud.no> * Gert Doering > (The /22 in the "last /8 policy" was chosen to ensure that every single > LIR in existence today can get their /22, and we'll still have some left - > the /8 will last for 16.000 /22s, and the number of active LIR is still > below 9000 today) It's last much longer, actually. Since depletion, the NCC has recovered 922,824 IPv4 addresses (outside of 185/8), and the NCC's one-fifth share of the IANA Recovered IPv4 Pool currently numbers 3,820,953 addresses. Put together, this gives us another 4,632 /22s to give to new LIRs. When taking these not-185/8 (yet still covered by the last /8 policy) pools into account, it is actually the case that the "last /8" pool has seen a net *growth* since the NCC hit IPv4 depletion. :-) Tore From gert at space.net Wed Jul 24 22:22:56 2013 From: gert at space.net (Gert Doering) Date: Wed, 24 Jul 2013 22:22:56 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51F01A03.2040808@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <20130724175823.GE65295@Space.Net> <51F01A03.2040808@fud.no> Message-ID: <20130724202256.GG65295@Space.Net> Hi, On Wed, Jul 24, 2013 at 08:16:35PM +0200, Tore Anderson wrote: > When taking these not-185/8 (yet still covered by the last /8 policy) > pools into account, it is actually the case that the "last /8" pool has > seen a net *growth* since the NCC hit IPv4 depletion. :-) Interesting, I was not aware of that. I take this as a success of our policy framework as it is now(*): ensure that there is some IPv4 left for new market entrants, for the years to come. ( (*) and not significally changed by 2013-03 ) Gert -- have you enabled 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From sandrabrown at ipv4marketgroup.com Wed Jul 24 23:19:44 2013 From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com) Date: Wed, 24 Jul 2013 14:19:44 -0700 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published(No Need - Post-Depletion Reality Adjustment and Clean up)(Tore Anderson) Message-ID: <20130724141944.ec289651d84890fcbef5f195936e1217.f53d8382e9.wbe@email17.secureserver.net> Dear Tore, Thank you for inviting me to speak. >>I feel this statement is somewhat disingenuous. The "odd RIR out" here is really ARIN, who is the only one to have a inter-RIR transfer policy that has a needs-based requirement that is also applied to the other region involved in the transfer. I agree 100% that ARIN is the "Odd RIR Out". Only ARIN pushes for needs assessments and other silliness on transfers, and I agree 100% that companies will not be silly about spending good money on IPv4 addresses that may become worthless. >>That said, there has been an inter-RIR proposal (2012-02) on the table for a while now, but the community does not seem to want or care much about it. I think that this is important to keep that in mind when deciding on how much weight to give this argument against 2013-03. Yes, 2012-02 was on the table, but has now been withdrawn, pending the outcome of 2013-03. If, and hopefully when, 2013-03 is implemented, then my intention is to put in place a new inter-RIR proposal for the RIPE community, at a time the community feels is appropriate, which allows for transfer of **legacy** IP's currently in the ARIN registry. As you probably know, legacy IP's were issued to resource holders prior to the creation of ARIN in 1997, and thus legacy holders can request RIPE to register their IP's, if the RIPE community agrees, rather than ARIN, as the registry. Then the inter-RIR transfer of legacy IP's from ARIN to RIPE can proceed regardless of needs justification, as the legacy IP's would be in the RIPE registry rather than the ARIN registry. We would have to discuss the mechanics as it might better be regarded as an inter-RIR transfer from a legacy ARIN registry element to a RIPE LIR. This is much like the ERX transfers of the past, but to a purchasing LIR. >>I'm not at all principally opposed to inter-RIR transfers, so if the author of 2012-02 would add a "need compatibility clause" to the proposed inter-RIR policy, I would have nothing against that. In other words, if it would be possible to make the need evaluation a voluntary thing that you only had to do if transferring addresses from the ARIN region - fine. Then those 5 LIRs, and those 5 only, could subject themselves to whatever demands the ARIN community might have, while the rest of us would be free of the IPv4 bureaucracy. Win-win. No, the author of 2012-02 is strongly opposed to needs justification so I would not be interested in adding needs compatibility to inter-RIR transfers. I would much rather focus on legacy IP's for inter-RIR transfers, intra-RIR transfers within RIPE, and will support any discussion within the community to bring modern economics to ARIN. Best Regards, and Thanks for the Invitation, Sandra Brown From koalafil at gmail.com Thu Jul 25 00:19:45 2013 From: koalafil at gmail.com (Filiz Yilmaz) Date: Thu, 25 Jul 2013 00:19:45 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51F005B9.3050408@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> Message-ID: <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> Hello Tore and Gert, According to the current policy your main reason to request an IP address must be that you need it to use on a network. As soon as you remove this, that the IP address is actually needed on a "network" (network can be LIR's or End Users, does not matter), you make them a commodity. As soon as you do that within your policy, you stamp that they actually are money making assets to be turned into some value now or later and this practice is all fine according to the policy too. This means an LIR can request these resources to do whatever they want to do with them including requesting them not to be used on any network of their own or an End Users' at all but for some other reason. One of these reasons will be deliberately passing them on to a paying 3rd party who may or may not use them on any other network either. I think we all see this happening as one scenario. I do not think this is good practice or responsible address management. This is how I see this proposal will have an impact. I believe with this we are moving far away from a core principle; that we, as the RIPE Community, are dealing with networks and resources for networks. If you take the network notion from the address management policy, you are then dealing with some numbers separated with few dots with monetary value only. Rest assured I am aware of the developments in the industry and yes I know how the last /8 policy works too. In fact I was working at the RIPE NCC when it was at its earliest proposal stage and worked on it at various levels, from proposal, Impact analysis and resulting policy documentation within and across RIR regions. I remember there was also a strong argument in these circles, not too long ago, that as we reach the end of IPv4 pool, the more policy changes we make the more it will be disruptive to the system overall. And so in fact I am curious what is the rush of this proposal now that RIPE NCC is allocating from the last /8 and that soon it will be exhausted anyways and what is wrong with keeping what we have as policy as long as this last bit of /8 lasts. Maybe your proposal will be more suitable once everything has ran out and RIPE NCC does not have anything more to provide other than few recycled/returned (hard to imagine if that will be ever happen?) space. Finally Gert seems to get my point with his example of someone going through the effort of opening 5000 new LIRs. I am not saying this will happen but even someone going to through the effort of opening maybe 2 or three just to get more address space for the wrong reasons should be telling us something that our policy is missing some core notion, that notion being IP addresses are mainly there to be used on networks as soon as they leave an RIR pool. Kind regards Filiz Yilmaz On 24 Jul 2013, at 18:50, Tore Anderson wrote: > Hi again Filiz, > >> In order not to have people get lost between our inline comments, I >> will only attempt to respond to you taking quotes from your mail. >> Apologies if this distorts the logical thought process you had put >> in. > > No problem, I'll do the same. :-) > >> Those principle based registration and address management >> requirements were in the old policy between the lines, pointing to >> people notions like anti-hoarding practices through "need based" >> requirements. > > Actually, you don't have to read between the lines to find the reason > for "need based"/"anti-hoarding". It is explicitly stated in the policy, > specifically section 3.0.3: ?To maximise the lifetime of the public IPv4 > address space?. > > And this of course made perfect sense. If the LIRs had been free to grab > as much as they pleased with no checks and bounds, that would in all > likelihood have caused the NCC's public pool of IPv4 space, and by > extension the IANA's, to deplete many many years ago. It was all about > delaying the Tragedy of the Commons as much as possible. Had we as a > community done a much better job with IPv6, we could have avoided it > from happening altogether, but that ship has sailed - the Tragedy > occurred last September. > >> So once you take those bits out, you also take those notions and >> principles out of the policy. That was my point and so I disagree >> that your proposal does not change anything. In fact it is bringing a >> big change, changing address delegation from "I want it because I >> need it on a network" > > There is a difference between a Service Provider and an Internet > Registry. The former operates networks, the latter delegates numbers. > Often a single organisation fills both roles, but this is not a > requirement, just a convenience. You could easily run an LIR from your > laptop or tablet in the local coffee shop - all you need is an e-mail > account, really (and money to pay the membership fee). So when it comes > to allocations, "need" isn't borne from "I need it on a network", but > rather "I need it so I can assign it to an End User". > >> "I want it and I am a member of the RIPE NCC so I can get it > > Get it from *where* and *who*, exactly? > >>> What constitutes "good address management" is something left to the >>> LIRs to decide for themselves. >> >> I tend to disagree with this too. LIRs are members of the RIPE NCC >> but policies are developed by the entire RIPE Community, which is a >> bigger stakeholder. Those views should be reflected in the policy to >> be remembered and documented by the LIRs. > > Clearly, if the RIPE Community makes a policy that says X, then the LIRs > must do X. But *as of right now*, the policy does not define any > principles of "good address management", hence, LIRs are free to do what > they wish. > >> I see your point but policy does not mean "policing". To my >> knowledge, RIPE NCC never sent agents to LIR premises to check if the >> justification they documented fit with the reality or not. > > Indeed, the whole "needs-based" system is entirely built on trust. The > NCC is not the IPv4 Police (and I wouldn't want them to be either for > simple cost/benefit reasons). > >> And this still does not mean that policy is not going to be there to >> remind people that this is a common pool of resources we are dealing >> with and its management requires some degree of responsibility. We >> might as well then not have a policy document at all and just have a >> click, pay and get your resource button on the RIPE NCC website. > > Again, get that resource from *where* and *who*? > >> If I am an LIR and I go to the RIPE NCC and ask for a resource [...] > > ...the RIPE NCC necessarily say "sorry, we're fresh out". (Except if you > didn't pick up your last /22 yet, see below.) > >> I am not a lawyer, but hypothetically speaking, if your proposal gets >> accepted there is some (again totally hypothetical?) potential that >> some LIRs may chose to rush and get whatever is left in the NCC pool > [...] >> And then these LIRs who were lucky to get all the space they wanted > > No, this is completely impossible, and to be honest I am starting to > wonder if you are familiar with the "last /8 policy" at all, or if you > are under the impression that 2013-03 proposes to remove it (it does > not). In a nutshell, it is the following: > > An LIR can get one (1) /22, no more, no less. Sizing according to "need" > has *already been abandoned*; it doesn't matter one bit if the LIR's > actual need is for 1 address or 1.000.000.000.000 addresses - the only > thing you'll get, ever, is 1.024. > > The only way an LIR could possibly get "all the space they wanted", is > if they wanted 1.024 addresses or less. But in that case, they would be > able to get it under today's policy, too. > > Best regards, > Tore Anderson > From jcurran at arin.net Thu Jul 25 04:31:15 2013 From: jcurran at arin.net (John Curran) Date: Thu, 25 Jul 2013 02:31:15 +0000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published(No Need - Post-Depletion Reality Adjustment and Clean up)(Tore Anderson) In-Reply-To: <20130724141944.ec289651d84890fcbef5f195936e1217.f53d8382e9.wbe@email17.secureserver.net> References: <20130724141944.ec289651d84890fcbef5f195936e1217.f53d8382e9.wbe@email17.secureserver.net> Message-ID: <4254A942-EC23-4BA6-86A5-C4C86DF1F2FB@corp.arin.net> On Jul 24, 2013, at 5:19 PM, sandrabrown at ipv4marketgroup.com wrote: > I agree 100% that ARIN is the "Odd RIR Out". Only ARIN pushes for > needs assessments and other silliness on transfers, and I agree 100% > that companies will not be silly about spending good money on IPv4 > addresses that may become worthless. For the record, both ARIN and APNIC have compatible transfer policies and many successful transfers completed to date. See my recent update from the ARIN 31 meeting: https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/curran-transfers.pdf Incompatibility between RIPE and ARIN on inter-RIR transfer policies potentially impacts the communities in both regions, albeit likely in different ways due to allocation history. > If, and hopefully when, 2013-03 is implemented, then my > intention is to put in place > a new inter-RIR proposal for the RIPE community, at a time the community > feels is > appropriate, which allows for transfer of **legacy** IP's currently in > the ARIN registry. Interesting concept. Note that it may be necessary to update ICANN Global Policy ICP-2 first , as that global policy specifies some requirements for RIRs agreed to per the ICANN MOU, including "regions of coverage", each served by a single RIR. Periodically reviewing such policies is probably a good idea in any case, as the Internet evolves over time and policy needs to do likewise. FYI, /John John Curran President and CEO ARIN From pwilson at apnic.net Thu Jul 25 05:35:18 2013 From: pwilson at apnic.net (Paul Wilson) Date: Thu, 25 Jul 2013 13:35:18 +1000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published(No Need - Post-Depletion Reality Adjustment and Clean up)(Tore Anderson) In-Reply-To: <20130724141944.ec289651d84890fcbef5f195936e1217.f53d8382e9.wbe@email17.secureserver.net> References: <20130724141944.ec289651d84890fcbef5f195936e1217.f53d8382e9.wbe@email17.secureserver.net> Message-ID: Sandra and all, Some comments below. On 25/07/2013, at 7:19 AM, wrote: > > Dear Tore, > > Thank you for inviting me to speak. > >>> I feel this statement is somewhat disingenuous. The "odd RIR out" here > is really ARIN, who is the only one to have a inter-RIR transfer policy > that has a needs-based requirement that is also applied to the other > region involved in the transfer. > > I agree 100% that ARIN is the "Odd RIR Out". Only ARIN pushes for > needs assessments and other silliness on transfers, and I agree 100% > that > companies will not be silly about spending good money on IPv4 addresses > that > may become worthless. To clarify, the entire APNIC transfer system is "needs-based". The requirement applies to the recipient of any transfer, whether it is intra- and inter-regional; and not just in the case of transfers received from ARIN. I will also add that once the policy decision was made, the implementation of needs-based transfers has been almost entirely without complaint or controversy at APNIC. The requirements for receiving a transfer are exactly the same as they were for receiving an allocation, and these are well understood within the APNIC community. The only difference is that the recipient receives a "pre-approval" rather than an actual allocation. By the way, recipients can opt to have their pre-approval listed on the APNIC website, and you can see this listing here: http://www.apnic.net/services/become-a-member/manage-your-membership/pre-approval/listing Currently we are completing on average around 10 transfers per month, 20% being inter-regional. All the best Paul Wilson Director General. > >>> That said, there has been an inter-RIR proposal (2012-02) on the table > for a while now, but the community does not seem to want or care much > about it. I think that this is important to keep that in mind when > deciding on how much weight to give this argument against 2013-03. > > Yes, 2012-02 was on the table, but has now been withdrawn, pending the > outcome > of 2013-03. If, and hopefully when, 2013-03 is implemented, then my > intention is to put in place > a new inter-RIR proposal for the RIPE community, at a time the community > feels is > appropriate, which allows for transfer of **legacy** IP's currently in > the ARIN registry. > As you probably know, legacy IP's were issued to resource holders prior > to the > creation of ARIN in 1997, and thus legacy holders can request RIPE to > register > their IP's, if the RIPE community agrees, rather than ARIN, as the > registry. > Then the inter-RIR transfer of legacy IP's from ARIN to RIPE can proceed > regardless of needs justification, as the legacy IP's would be in the > RIPE > registry rather than the ARIN registry. We would have to discuss the > mechanics as it might better be regarded as an inter-RIR transfer from a > legacy > ARIN registry element to a RIPE LIR. This is much like the ERX > transfers of the > past, but to a purchasing LIR. > > >>> I'm not at all principally opposed to inter-RIR transfers, so if the > author of 2012-02 would add a "need compatibility clause" to the > proposed inter-RIR policy, I would have nothing against that. In other > words, if it would be possible to make the need evaluation a voluntary > thing that you only had to do if transferring addresses from the ARIN > region - fine. Then those 5 LIRs, and those 5 only, could subject > themselves to whatever demands the ARIN community might have, while the > rest of us would be free of the IPv4 bureaucracy. Win-win. > > No, the author of 2012-02 is strongly opposed to needs justification so > I > would not be interested in adding needs compatibility to inter-RIR > transfers. > I would much rather focus on legacy IP's for inter-RIR transfers, > intra-RIR > transfers within RIPE, and will support any discussion within the > community > to bring modern economics to ARIN. > > Best Regards, and Thanks for the Invitation, > Sandra Brown > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2880 bytes Desc: not available URL: From tore at fud.no Thu Jul 25 09:32:06 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 25 Jul 2013 09:32:06 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> Message-ID: <51F0D476.8080409@fud.no> Filiz, > According to the current policy your main reason to request an IP > address must be that you need it to use on a network. This is only the true for *assignments*, not *allocations*. This is a subtle, but important, difference. > As soon as you remove this, that the IP address is actually needed > on a "network" (network can be LIR's or End Users, does not matter), > you make them a commodity. As soon as you do that within your policy, > you stamp that they actually are money making assets to be turned > into some value now or later and this practice is all fine according > to the policy too. We have *today*, under our current policy: - An allocation transfer policy that has no restrictions on monetary compensation being exchanged between the parties to a transaction; - A list of ?Recognised IPv4 Transfer Brokers? published by the NCC; - A NCC-operated "lightweight self-service IPv4 broker" or "bulletin board" aimed at helping LIRs interested in trading find each other. 2013-03 takes no position whether or not all of this is a "good thing", nor do I. But let's face the facts, it's *already there*. > This means an LIR can request these resources to do whatever they > want to do with them including requesting them not to be used on any > network of their own or an End Users' at all but for some other > reason. One of these reasons will be deliberately passing them on to > a paying 3rd party who may or may not use them on any other network > either. This is *already possible* today; in fact, what you're describing above is pretty much the core function of an LIR. Let me try to explain by making an hypothetical example: Background: John Q. Public wants to make money on IPv4. He has a laptop and and e-mail account, but no networking equipment, nor an internet connection of his own; in fact, he's leeching off his local coffee shop gratis WiFi in order to get online. John then does the following: 1) Incorporates "JQP IPv4 Leasing Company" in his local jurisdiction. 2) Joins the NCC and pays the membership fee, thus becoming an LIR. 3) Requests and receives an IPv6 allocation, ignores it. 4) Requests and receives his "last /8" /22. 5) Sets up an auction or something like it, and finds the end user(s) willing to pay the most for [parts of] the /22. 6) Gets a completed ripe-583 form from the auction winner(s), forwards it to the RIPE NCC (if he does not yet have an AW), and saves a copy in an archive folder. 7) Assigns the address space over to the new end user(s) (i.e., registering ASSIGNED PA inetnum objects in the RIPE database). So, again, this would be *already possible* and completely legitimate under our current policy. If John manages to get higher income from his customers then what he's paying the NCC in membership fees, then voila! John is making money off IPv4, without having ever forwarded a single IPv4 packet on behalf of his customers. Again, 2013-03 takes no position whether or not this is a "good thing", but it is the status quo today, so when discussing the proposal, I think we should try to keep on-topic, i.e. discussing what the proposal actually *changes*, which in the above case is the removal of point #6 and nothing else: John's customer won't have to fill out the ripe-583 form anymore. This is a good thing at least in one way, because it removes a bureaucratic overhead that would otherwise impose a work load on John, John's customer, and the RIPE NCC. I think you referred to it as "admin hogging" in an earlier message and I couldn't agree more. Your concern is that by removing point #6, it becomes possible that the winner(s) of John's auction does not "need" the space, yet are able to receive it. I concede that this is theoretically possible. But I remain unconvinced that this is an *realistic* problem - I simply don't see why someone would bid on address space that they don't "need", especially when they have to outbid a bunch of others who *do* have potentially quite desperate "need". And even if such actors do exist and do outbid all the folks that do "need", keep in mind that *today* 1) the entire system is trust-based and that 2) John has absolutely no incentive to undertake a deep investigation into whether or not his customer's ripe-583 form is truthfully filled out or not - if it looks credible enough, his job is done. He could also make a habit of forwarding the forms to the NCC to get "official" stamps of approval. > I do not think this is good practice or responsible address > management. Maybe, maybe not - but it is what we have today. If we want to ban paid IPv4 allocation transfers and assignments because it's these do not constitute "good practice or responsible address management", then we as a community can do that, but please let's keep that discussion in a separate proposal. > And so in fact I am curious what is the rush of this proposal now > that RIPE NCC is allocating from the last /8 and that soon it will > be exhausted anyways and what is wrong with keeping what we have as > policy as long as this last bit of /8 lasts. Your definition of "soon" differs wildly from mine, or you haven't done the math. Allow me: - Number of /22s in 185.0.0.0/8 (sans the /16 for IXPs): 16320 - Number of LIRs that held allocations outside 185/8 at the time of depletion (these are the only ones who can get their last /22 as an additional allocation): 7912 - Number of reclaimed space held by the NCC as of today, in /22s: 903 - Number of reclaimed space held by the IANA as of today, divided by 5 RIRs, in /22s: 3731 In other words, there is a total of 13042 /22s to be given out to new LIRs under the last /8 policy (and this number keeps increasing as the IANA and the NCC continues to recovers space). As of today, there are 959 LIRs who hold *only* a /22 from 185/8. 314 days have passed since IPv4 depletion. So how long will the last /8 last us based on the current usage rates and available space? 13042 / (959 / 314 * 365) = 11.7 years I truly hope that we've gotten IPv6 properly out the door by then... To answer the second question, "what's wrong with keeping what we have": About half of the current policy text is describing out of date concepts, is self-contradictory or otherwise wrong, and that it imposes a bureaucracy on the community that demands that hundreds of thousands forms be filled out every year, all in the name of delaying something which has already happened. I mean, you even said it yourself in an earlier message: ?Yes, agreed, this is bureaucratic, admin resource hogging etc and this needs a change? - and I could not agree more, this is *exactly* why I have proposed 2013-03. > Finally Gert seems to get my point with his example of someone going > through the effort of opening 5000 new LIRs. I am not saying this > will happen but even someone going to through the effort of opening > maybe 2 or three just to get more address space for the wrong > reasons should be telling us something that our policy is missing > some core notion, that notion being IP addresses are mainly there to > be used on networks as soon as they leave an RIR pool. I believe Gert's point was that you can open 5000 LIRs in this manner *today*, under our *current* policy. 2013-03 brings no change. Therefore, this is not a valid argument against 2013-03. If you want to close this loophole, then that's food for another policy proposal. Opposing 2013-03 won't do anything about it, one way or the other (nor would supporting 2013-03). (That said, in the current data there's no evidence of someone attempting to use this loophole in the described manner. Personally I believe that the NCC's membership fee is a sufficient deterrence against it.) Tore From koalafil at gmail.com Thu Jul 25 10:30:11 2013 From: koalafil at gmail.com (Filiz Yilmaz) Date: Thu, 25 Jul 2013 10:30:11 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51F0D476.8080409@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <51F0D476.8080409@fud.no> Message-ID: Dear Tore, I am aware of all the practical examples you have provided. You keep saying that everything but one thing is the status quo already but that one thing bares a whole notion and a principle (beyond maths) that I have been trying to express in my previous posts because I simply do care about it. Few points of clarification about my own thoughts so far instead of someone labelling them for me too: - Yes, I already agreed with certain things you are proposing, true. I've explained why. - I know what an allocation and assignment is. - I am not against transfers but I am against the practice of getting space now from the NCC just to be able to transfer it later. I do not call this a best practice and I would not like RIPE Policies encourage it. - But I find transfers extremely useful if they are to bring out some already allocated space out of some drawer. While the current system is based on trust, there is definitely enough of wording for what that trust is to be in the current text. It is my belief that your proposal is taking them out all together and leaving the resulting document a mere description of a system that is an IP market, removing the core essential that IPs are for networks in the first place. This is where my concern lies, not about removing the bureaucracy. You seem to say that you want to change the annoying step 6 in your John Q example, where everything else is going to stay the same anyways. ripe-583 may be an overkill today, agreed. It is just a form and a practice NCC applies though as a result of their interpretation of the policy. If it is a problem ask the NCC folks to come up with a more efficient form or a new scheme or totally have it removed even. Policy document does not talk about ripe-583 specifically anyway. But your proposal is removing way too many important principles from the policy text in order to fix an operational problem. In other words, the way it is written, the resulting text and so your proposal is taking it to the extreme, doing more than just removing the unhelpful bureaucracy in my opinion. This is not a matter of an other proposal that can be made after yours. This discussion is happening to note these about this proposal. I may be just one person who thinks we should still mention in the resulting document that RIPE Community cares about networks, that we do realise that IPs are for networks and that these are expected to be used with care and responsibility. And so this is my input to the current discussion. I hope it is now clear what I am opposing to and what not. Kind regards Filiz Yilmaz On 25 Jul 2013, at 09:32, Tore Anderson wrote: > Filiz, > >> According to the current policy your main reason to request an IP >> address must be that you need it to use on a network. > > This is only the true for *assignments*, not *allocations*. This is a > subtle, but important, difference. > >> As soon as you remove this, that the IP address is actually needed >> on a "network" (network can be LIR's or End Users, does not matter), >> you make them a commodity. As soon as you do that within your policy, >> you stamp that they actually are money making assets to be turned >> into some value now or later and this practice is all fine according >> to the policy too. > > We have *today*, under our current policy: > > - An allocation transfer policy that has no restrictions on monetary > compensation being exchanged between the parties to a transaction; > - A list of ?Recognised IPv4 Transfer Brokers? published by the NCC; > - A NCC-operated "lightweight self-service IPv4 broker" or "bulletin > board" aimed at helping LIRs interested in trading find each other. > > 2013-03 takes no position whether or not all of this is a "good thing", > nor do I. But let's face the facts, it's *already there*. > >> This means an LIR can request these resources to do whatever they >> want to do with them including requesting them not to be used on any >> network of their own or an End Users' at all but for some other >> reason. One of these reasons will be deliberately passing them on to >> a paying 3rd party who may or may not use them on any other network >> either. > > This is *already possible* today; in fact, what you're describing above > is pretty much the core function of an LIR. > > Let me try to explain by making an hypothetical example: > > Background: John Q. Public wants to make money on IPv4. He has a laptop > and and e-mail account, but no networking equipment, nor an internet > connection of his own; in fact, he's leeching off his local coffee shop > gratis WiFi in order to get online. John then does the following: > > 1) Incorporates "JQP IPv4 Leasing Company" in his local jurisdiction. > 2) Joins the NCC and pays the membership fee, thus becoming an LIR. > 3) Requests and receives an IPv6 allocation, ignores it. > 4) Requests and receives his "last /8" /22. > 5) Sets up an auction or something like it, and finds the end user(s) > willing to pay the most for [parts of] the /22. > 6) Gets a completed ripe-583 form from the auction winner(s), forwards > it to the RIPE NCC (if he does not yet have an AW), and saves a copy in > an archive folder. > 7) Assigns the address space over to the new end user(s) (i.e., > registering ASSIGNED PA inetnum objects in the RIPE database). > > So, again, this would be *already possible* and completely legitimate > under our current policy. If John manages to get higher income from his > customers then what he's paying the NCC in membership fees, then voila! > John is making money off IPv4, without having ever forwarded a single > IPv4 packet on behalf of his customers. > > Again, 2013-03 takes no position whether or not this is a "good thing", > but it is the status quo today, so when discussing the proposal, I think > we should try to keep on-topic, i.e. discussing what the proposal > actually *changes*, which in the above case is the removal of point #6 > and nothing else: > > John's customer won't have to fill out the ripe-583 form anymore. This > is a good thing at least in one way, because it removes a bureaucratic > overhead that would otherwise impose a work load on John, John's > customer, and the RIPE NCC. I think you referred to it as "admin > hogging" in an earlier message and I couldn't agree more. > > Your concern is that by removing point #6, it becomes possible that the > winner(s) of John's auction does not "need" the space, yet are able to > receive it. I concede that this is theoretically possible. But I remain > unconvinced that this is an *realistic* problem - I simply don't see why > someone would bid on address space that they don't "need", especially > when they have to outbid a bunch of others who *do* have potentially > quite desperate "need". > > And even if such actors do exist and do outbid all the folks that do > "need", keep in mind that *today* 1) the entire system is trust-based > and that 2) John has absolutely no incentive to undertake a deep > investigation into whether or not his customer's ripe-583 form is > truthfully filled out or not - if it looks credible enough, his job is > done. He could also make a habit of forwarding the forms to the NCC to > get "official" stamps of approval. > >> I do not think this is good practice or responsible address >> management. > > Maybe, maybe not - but it is what we have today. If we want to ban paid > IPv4 allocation transfers and assignments because it's these do not > constitute "good practice or responsible address management", then we as > a community can do that, but please let's keep that discussion in a > separate proposal. > >> And so in fact I am curious what is the rush of this proposal now >> that RIPE NCC is allocating from the last /8 and that soon it will >> be exhausted anyways and what is wrong with keeping what we have as >> policy as long as this last bit of /8 lasts. > > Your definition of "soon" differs wildly from mine, or you haven't done > the math. Allow me: > > - Number of /22s in 185.0.0.0/8 (sans the /16 for IXPs): 16320 > - Number of LIRs that held allocations outside 185/8 at the time of > depletion (these are the only ones who can get their last /22 as an > additional allocation): 7912 > - Number of reclaimed space held by the NCC as of today, in /22s: 903 > - Number of reclaimed space held by the IANA as of today, divided by 5 > RIRs, in /22s: 3731 > > In other words, there is a total of 13042 /22s to be given out to new > LIRs under the last /8 policy (and this number keeps increasing as the > IANA and the NCC continues to recovers space). As of today, there are > 959 LIRs who hold *only* a /22 from 185/8. 314 days have passed since > IPv4 depletion. > > So how long will the last /8 last us based on the current usage rates > and available space? > > 13042 / (959 / 314 * 365) = 11.7 years > > I truly hope that we've gotten IPv6 properly out the door by then... > > To answer the second question, "what's wrong with keeping what we have": > About half of the current policy text is describing out of date > concepts, is self-contradictory or otherwise wrong, and that it imposes > a bureaucracy on the community that demands that hundreds of thousands > forms be filled out every year, all in the name of delaying something > which has already happened. > > I mean, you even said it yourself in an earlier message: ?Yes, agreed, > this is bureaucratic, admin resource hogging etc and this needs a > change? - and I could not agree more, this is *exactly* why I have > proposed 2013-03. > >> Finally Gert seems to get my point with his example of someone going >> through the effort of opening 5000 new LIRs. I am not saying this >> will happen but even someone going to through the effort of opening >> maybe 2 or three just to get more address space for the wrong >> reasons should be telling us something that our policy is missing >> some core notion, that notion being IP addresses are mainly there to >> be used on networks as soon as they leave an RIR pool. > > I believe Gert's point was that you can open 5000 LIRs in this manner > *today*, under our *current* policy. 2013-03 brings no change. > Therefore, this is not a valid argument against 2013-03. > > If you want to close this loophole, then that's food for another policy > proposal. Opposing 2013-03 won't do anything about it, one way or the > other (nor would supporting 2013-03). > > (That said, in the current data there's no evidence of someone > attempting to use this loophole in the described manner. Personally I > believe that the NCC's membership fee is a sufficient deterrence against > it.) > > Tore > From gert at space.net Thu Jul 25 12:28:41 2013 From: gert at space.net (Gert Doering) Date: Thu, 25 Jul 2013 12:28:41 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> Message-ID: <20130725102841.GM65295@Space.Net> Hi, On Thu, Jul 25, 2013 at 12:19:45AM +0200, Filiz Yilmaz wrote: > Finally Gert seems to get my point with his example of someone > going through the effort of opening 5000 new LIRs. > I am not saying this will happen but even someone going to through > the effort of opening maybe 2 or three just to get more address > space for the wrong reasons should be telling us something that our > policy is missing some core notion, that notion being IP addresses > are mainly there to be used on networks as soon as they leave an > RIR pool. 2013-03 would not be changing that particular game. If someone wants to open extra LIRs to get extra /22s, they can do that today, and they can do that if 2013-03 is implemented. Needs justification for the /22 is already so minimal ("I need a single IPv4 address") that I can't really see how 2013-03 would make a big for these cases. If you're concerned about people gaming the system by opening extra LIRs and getting extra /22s that they should not have, opposing 2013-03 is not the right approach - we'd need a modification of the actual last /8 policy to qualify under which rules "new LIRs" might *not* be eligible to get a /22 - and I think *this* would cause much more grave problems with competition laws. Gert Doering -- APWG chair -- have you enabled 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From randy at psg.com Thu Jul 25 12:51:01 2013 From: randy at psg.com (Randy Bush) Date: Thu, 25 Jul 2013 12:51:01 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <20130725102841.GM65295@Space.Net> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> Message-ID: >> I am not saying this will happen but even someone going to through >> the effort of opening maybe 2 or three just to get more address >> space for the wrong reasons should be telling us something that our >> policy is missing some core notion the issue is not policy. the issue is that ipv4 is essentially gone and folk will do whatever they can to get that last pathetic little bit. we should not be writing kinky and complex policies to try and prevent every bit of stupid greed we can fantacize. ipv4 space is gone but we will get to live with the silly policies and then have to clean them up as we are having to do now. randy From nick at inex.ie Thu Jul 25 15:42:29 2013 From: nick at inex.ie (Nick Hilliard) Date: Thu, 25 Jul 2013 14:42:29 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> Message-ID: <51F12B45.2010603@inex.ie> On 25/07/2013 11:51, Randy Bush wrote: > the issue is that ipv4 is essentially gone therein lies the problem: ipv4 is not essentially gone, nor do I foresee that it will be gone in my lifetime. Nor do I see that the RIR pools will ever stop garbage collection of ipv4 address space, which means that for the foreseeable future, they will continue to play a part in ipv4 address allocation. Also they can still serve a useful purpose as the registries of allocated space. With regard to 2013-03, we know that: 1. the RIRs will no longer be the dominant source for injecting liquidity into the available addressing pool 2. demand for ipv4 address space over time will continue to increase 3. there will be a market for ipv4 address space. The ipv4 address market will work if the market stays liquid, but 2013-03 creates an environment for full deregulation of the addressing market with almost no control mechanisms for handling problems [There is a 24-month reallocation freeze, but I don't think this is going to work because it will not affect the reality of real world allocation transfers. Consequently, people will flout it, and then we will need to remove it from the policy mechanism because it's causing the registry function to break down.] Liquidity will be generated almost entirely by existing address space holders releasing existing address space into the market. So the interesting question is: just how much slack space is there out there? Answering this will give us a good idea how much potential future liquidity there is, and consequently whether full deregulation is likely or not to run into liquidity constraints, given historical addressing demands over the last several years. This will give us a better perspective to decide on whether 2013-03 is actually a good idea. Nick From drc at virtualized.org Thu Jul 25 16:26:08 2013 From: drc at virtualized.org (David Conrad) Date: Thu, 25 Jul 2013 07:26:08 -0700 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51F12B45.2010603@inex.ie> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> Message-ID: On Jul 25, 2013, at 6:42 AM, Nick Hilliard wrote: > Also they can still serve a useful purpose as the registries of allocated space. Well, assuming they don't shoot themselves in the head by attempting to use their registries as a weapon against their customers. > With regard to 2013-03, we know that: > > 1. the RIRs will no longer be the dominant source for injecting liquidity > into the available addressing pool Agreed. > 2. demand for ipv4 address space over time will continue to increase Demand for IPv4 will increase as long as the price is competitive relative to the alternatives. Right now, the price of IPv4 is wildly distorted by the regulatory regime imposed by the RIRs so stuff like CGN and IPv6 is (seen to be) too expensive. At some point, the regulatory regime that is 'injecting liquidity' _IS_ going to be unable to do so, and the price of IPv4 is going to skyrocket with a corresponding decrease in demand as alternatives become more appealing. The only question is when. > 3. there will be a market for ipv4 address space. There already is. > The ipv4 address market will work if the market stays liquid, but 2013-03 > creates an environment for full deregulation of the addressing market with > almost no control mechanisms for handling problems AFAICT, 2013-03 simply says "get out of the way and let the market work." The main concern appears to be that Evil Greedy Speculators will descend upon RIPE like locusts, gobbling up the remaining RIPE IPv4 free pool in a blink of an eye, and not putting that address space into actual use. I tend to agree that is a risk. However, as has been pointed out, there is little stopping that now (well, other than penalizing honesty). Regards, -drc From tore at fud.no Thu Jul 25 16:44:07 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 25 Jul 2013 16:44:07 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51F12B45.2010603@inex.ie> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> Message-ID: <51F139B7.9060703@fud.no> * Nick Hilliard > The ipv4 address market will work if the market stays liquid, but 2013-03 > creates an environment for full deregulation of the addressing market with > almost no control mechanisms for handling problems Hi Nick, I'd like to know: - What kind of problems are you foreseeing? - What kind of control mechanisms exist in today's policy, that are removed by 2013-03, will forestall these problems? > [There is a 24-month reallocation freeze, but I don't think this is going > to work because it will not affect the reality of real world allocation > transfers. Consequently, people will flout it, and then we will need to > remove it from the policy mechanism because it's causing the registry > function to break down.] s/24-month reallocation freeze/requirement to demonstrate need/ Does this argument work equally well? If no, why not? > Liquidity will be generated almost entirely by existing address space > holders releasing existing address space into the market. So the > interesting question is: just how much slack space is there out there? Probably impossible to answer accurately. The best indication I could come up with is to 1) compare pre-depletion allocation rates with post-depletion transfer rates, making the assumption that the actual demand has at least not decreased, and 2) compare supply with demand at the RIPE NCC's listing site. Today's numbers: Pre-depletion IPv4 RIR->LIR allocation stats (20110914-20120725): - allocations: 1980 - addresses: 36052992 Post-depletion IPv4 LIR->LIR allocation transfer stats (20120914-20130725): - transfers: 70 (3.54% of pre-depletion) - addresses: 1189888 (3.30% of pre-depletion) RIPE NCC IPv4 Transfer Listing Service stats: - requested: 15043584 - available: 225280 (1.50% of requested) Tore From ebais at a2b-internet.com Thu Jul 25 17:30:59 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Thu, 25 Jul 2013 17:30:59 +0200 Subject: [address-policy-wg] Is the final /8 the correct term ? - semi off track to the 2013-03 discussion.. Message-ID: <008c01ce894b$f7160110$e5420330$@a2b-internet.com> Hi, I?ve heard the phrase ?the final /8? in several discussions but I want to ask people what their idea is about the pool that is currently still left If you think that the pool which we have left is only the final /8 that we are working into currently (185.x.y.z) I think that the assumption is incorrect. There is still space left at IANA and once the first RIR reaches below their /9 mark of their final /8 from my understanding it is , that also that space is going to be allocated to the RIR?s . Also there will be reclaimed space from 2007-01 and closing LIR?s (forced or by people their own decision) and also that space all goes back into the same pool. So you might need quite a couple of new entities to finish the pool as it is. . . I?ve seen people say, why not open 20 new entities, setup a new LIR in each .. and you have 20 /22?s Yes it is possible.. However I?ve noticed, there is little support to close this gap.. or the gap to be able to merge those 20 LIR?s .. or the option to be able to merge any LIR?s that already have their final /8 /22 provided. Yes there will be people who play the system.. and with the bottom in sight, do we want to close all possible loopholes ? If we decide, no we don?t want to close the loopholes, stop mentioning it in the discussion as a possible threat, because we already decided it is what it is and we are not going to close the gap. There will be some people that will just open a second LIR or perhaps even 8, there will be people who go to the IPv4 market and seek their v4 fix there The more people will request space from the current pool, with their own benefit in mind without any regard for the actual intention of the policy (provide an option for new companies into the market) it is too bad. If we are happy with the policy in place or don?t see/feel the need to change, it is to me a clear consensus on how it is potentially abused. If there is no consensus and people do feel the requirement to adjust it, let?s see what goes faster Getting a new policy in place or the depletion of the pool as it is currently Just my 2 cent. Erik -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Thu Jul 25 17:31:01 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 25 Jul 2013 17:31:01 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> Message-ID: <51F144B5.6080600@fud.no> * David Conrad > 2013-03 simply says "get out of the way and let the market work." For what it's worth, the motivation behind 2013-03 has nothing to do with "the market" whatsoever. What I'm gunning for, is the bureaucratic overhead surrounding IPv4 LIR->End User assignments, and obviously incorrect/obsoleted self-contradictory policy statements. The reason it makes a "no need" change for allocations (and by extension for allocation transfers), is that the "need" for allocations are determined exclusively by an LIRs intention to register assignments. Once we've removed need evaluation for assignments, there is no point in maintaining it for allocations, as LIRs could trivially work around that by proclaiming to the NCC an intention to assign a /1 to their break-room gaming console. That would be a valid assignment, in turn causing a valid "need" for a correspondingly sized allocation. > The main concern appears to be that Evil Greedy Speculators will > descend upon RIPE like locusts, gobbling up the remaining RIPE IPv4 > free pool in a blink of an eye, and not putting that address space > into actual use. > > I tend to agree that is a risk. However, as has been pointed out, > there is little stopping that now (well, other than penalizing > honesty). Actually, you don't even have to be dishonest in order to do this, it is perfectly possible under today's policy. Here's how: What this Evil Greedy Speculator needs to do is to register a few thousand LIRs, since each new LIR is entitled a single /22. Today, each of those LIRs must demonstrate "need", but this is merely a formality - if you have an intention of assigning one (1) IPv4 address to some End User within 12 months, you qualify. I seriously doubt that this formality is what has prevented the Evil Greedy Speculators from having done this already. A few to me more plausible reasons why it hasn't happened so far include: "too much trouble for too few addresses", "too high RIPE NCC membership fee to pay for too few addresses", "too high risk of being shunned and any obtained blocks filtered by the operator community", "too high risk of being countered by hostile policy", a combination of the preceding, or simply that "Evil Greedy Speculator is a bogeyman which doesn't really exist". Tore From mueller at syr.edu Thu Jul 25 16:40:50 2013 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 25 Jul 2013 14:40:50 +0000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> Message-ID: <855077AC3D7A7147A7570370CA01ECD24715CD@SUEX10-mbx-10.ad.syr.edu> Filiz, Michele When number blocks are traded by companies in a market, the price of number blocks reflects their scarcity - i.e., the relationship between supply and demand - and thus companies have very strong incentives to allocate and conserve. These incentives are at once both more effectively enforced and more flexible than a regime in which a central bureaucratic authority looks at some technical indicators submitted to them on pieces of paper (or digital forms) and tries to assess "need." So there are still strong incentives for responsible management without needs assessment. And since v4 is depleting, the idea that the price would rise and people would over time be discouraged from using it, ought to be seen as a good thing. Administrative needs assessment is not the ONLY method that could EVER be used to allocate resources. There are a variety of tools and mechanisms and the authors of 2013-3 are correct that the conditions that led to traditional needs assessments for numbers are gone, and not applicable to the current situation. I've always asked the religious believers in needs assessment whether they think their rental of office space should be subject to a needs assessment. It's not meant to be a challenge, just something to make you think. The economic characteristics of the resources are not that different (space, like number blocks, are occupied but not consumed, and there is a short-term fixity in supply). So let me volunteer to do a needs assessment on Michele's offices, and his home, and perhaps a few other belongings. I just want to see if he is wasting any resources. ;-) Or would Michele prefer to just pay for what he thinks he needs? From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Filiz Yilmaz Sent: Wednesday, July 24, 2013 6:53 AM To: Tore Anderson Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) Hello Tore, While I am curious for Michele's response to your mail too, here is my bit, as I feel I agree with him in terms of principles. First of all, I am not totally against your proposal; it cleans up the policy text reflecting today's circumstances to some extent and it makes a long document way more readable. This is also why I am writing back because I've read the draft policy document from the beginning to the end. My observation is that the new document proposed is not exactly a "registration" policy document. It more looked to me like a description of how address space management is done within RIPE NCC region "by the RIPE NCC". If I am not missing anything crucial, the main points described are: - The language is English, - How big an allocation can be, - That there is no PI anymore to be assigned directly from the NCC pools to End users (except for the IXPs) so all resources will only goto LIRs - And these blocks can be transferred between LIRs. The only bit about registration I see in the new text is section 4.0 Registration Requirements and it does not go more than saying details should be recorded in the database. So it does not contain any substantial information for registration or address management on the LIR's side. This is interesting as now with this proposed policy any End user's chance to get any IPv4 address space will be through an LIR and hope that these LIRs are responsible and know what they are doing. I would like to see some guidelines or at least principles mentioned in this document so the LIRs know their responsibility in terms of fair address management as well as the End Users so they know what to expect from these LIRs. This is what I would be expecting from a transparent documentation of a set of policies and principles that are still in place. We may not have too many specific policies to set for the few left-over resources but I would like to believe we still have "principles" towards the responsible management of these resources. In that sense Michele has a point and I argue that LIRs need to be guided for "good address management" even without the "conservation" principle as the top priority in the new IP world. This is missing in the proposed policy text for it to be considered as a helpful "registration" policy in my opinion. In practice, I can set up a new LIR now and ask for a new allocation and I may be someone who does not have any previous RIPE or RIPE NCC experience. If all I have is this document, I am not sure if it tells me enough about my responsibilities, while I will be a critical token in the EU address management and registration system by just becoming an LIR. My other concern is in regards to the transfers. As neatly put by the NCC Board in the Impact Analysis: --- * As mentioned in previous sections, the policy proposal would negatively affect the ability of LIRs to engage in inter-RIR transfers, as the RIPE NCC's service region would be the only one without a needs-based requirement for transfers. * Implementation of the policy could expose LIRs to legal challenges under EU competition law. --- I think singling out the RIPE NCC region in the world of transfers may not be the best idea at this stage. Kind regards Filiz Yilmaz On 24 Jul 2013, at 10:52, Tore Anderson > wrote: * Michele Neylon - Blacknight As previously stated, I do NOT support the "no need" policy and cannot support this document. IP addresses are a finite resource, as we all know, and obliging people to provide some level of justification makes sense. The argument for "conservation" may no longer be valid, but there will always be a compelling argument in favour of good resource management, which I believe the policy covers. RIPE should not remove the requirement to provide justification. Hi Michele, I doubt you'll find anyone in the working group who is against good resource management. I am convinced that the proposed policy is not in conflict with good resource management, otherwise I would never have proposed it. While I can obviously only speak with certainty for myself, I assume that the people who support the proposal feel the same way. While it appears you believe that the proposal will bring about poor resource management, your message neglected to explain why or how. This makes it rather difficult for me to try to alleviate your concerns. As Gert also pointed out recently, the main reason I believe that IPv4 would continue to be consumed responsibly under the proposed policy, is that the LIRs in the region are painfully aware that there is no more IPv4 to be had from the RIPE NCC. Should an LIR anyway decide to go on a "spending spree" with its remaining inventory, it would only end up hurting itself by expediting its own depletion date. The community will not be impacted - without a Common, there can be no Tragedy. Best regards, Tore Anderson -------------- next part -------------- An HTML attachment was scrubbed... URL: From koalafil at gmail.com Thu Jul 25 17:45:57 2013 From: koalafil at gmail.com (Filiz Yilmaz) Date: Thu, 25 Jul 2013 17:45:57 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD24715CD@SUEX10-mbx-10.ad.syr.edu> References: <51EF95B3.4030705@fud.no> <855077AC3D7A7147A7570370CA01ECD24715CD@SUEX10-mbx-10.ad.syr.edu> Message-ID: <684E2FC2-2828-47B6-9ACB-8E33EBA76BD1@gmail.com> Hello Milton, I hear what you are saying but I think you are comparing apples and pears. In regards to Michele's office space, try think of that analysis when Michele and say whole of RIPE community are to share a finite, i repeat finite, possibility of office spaces. In real economics of today you have more options to create your own alternative if something is not suiting your needs. IP address space is finite though, we wont be able to create all sorts of alternatives other than one kind; IPv6 which still has its issues. I would agree with you in the domain name space but not in IP. Filiz Apologies for the brevity of this mail, it was sent from my iphone On 25 Jul 2013, at 16:40, Milton L Mueller wrote: > Filiz, Michele > When number blocks are traded by companies in a market, the price of number blocks reflects their scarcity - i.e., the relationship between supply and demand - and thus companies have very strong incentives to allocate and conserve. These incentives are at once both more effectively enforced and more flexible than a regime in which a central bureaucratic authority looks at some technical indicators submitted to them on pieces of paper (or digital forms) and tries to assess "need." > > So there are still strong incentives for responsible management without needs assessment. And since v4 is depleting, the idea that the price would rise and people would over time be discouraged from using it, ought to be seen as a good thing. Administrative needs assessment is not the ONLY method that could EVER be used to allocate resources. There are a variety of tools and mechanisms and the authors of 2013-3 are correct that the conditions that led to traditional needs assessments for numbers are gone, and not applicable to the current situation. > > I've always asked the religious believers in needs assessment whether they think their rental of office space should be subject to a needs assessment. It's not meant to be a challenge, just something to make you think. The economic characteristics of the resources are not that different (space, like number blocks, are occupied but not consumed, and there is a short-term fixity in supply). So let me volunteer to do a needs assessment on Michele's offices, and his home, and perhaps a few other belongings. I just want to see if he is wasting any resources. ;-) Or would Michele prefer to just pay for what he thinks he needs? > > From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Filiz Yilmaz > Sent: Wednesday, July 24, 2013 6:53 AM > To: Tore Anderson > Cc: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) > > Hello Tore, > > While I am curious for Michele's response to your mail too, here is my bit, as I feel I agree with him in terms of principles. > > First of all, I am not totally against your proposal; it cleans up the policy text reflecting today's circumstances to some extent and it makes a long document way more readable. > This is also why I am writing back because I've read the draft policy document from the beginning to the end. > > My observation is that the new document proposed is not exactly a "registration" policy document. > It more looked to me like a description of how address space management is done within RIPE NCC region "by the RIPE NCC". > > If I am not missing anything crucial, the main points described are: > > - The language is English, > - How big an allocation can be, > - That there is no PI anymore to be assigned directly from the NCC pools to End users (except for the IXPs) so all resources will only goto LIRs > - And these blocks can be transferred between LIRs. > > The only bit about registration I see in the new text is section 4.0 Registration Requirements and it does not go more than saying details should be recorded in the database. > > So it does not contain any substantial information for registration or address management on the LIR's side. > > This is interesting as now with this proposed policy any End user's chance to get any IPv4 address space will be through an LIR and hope that these LIRs are responsible and know what they are doing. I would like to see some guidelines or at least principles mentioned in this document so the LIRs know their responsibility in terms of fair address management as well as the End Users so they know what to expect from these LIRs. This is what I would be expecting from a transparent documentation of a set of policies and principles that are still in place. > > We may not have too many specific policies to set for the few left-over resources but I would like to believe we still have "principles" towards the responsible management of these resources. > > In that sense Michele has a point and I argue that LIRs need to be guided for "good address management" even without the "conservation" principle as the top priority in the new IP world. This is missing in the proposed policy text for it to be considered as a helpful "registration" policy in my opinion. > > In practice, I can set up a new LIR now and ask for a new allocation and I may be someone who does not have any previous RIPE or RIPE NCC experience. > If all I have is this document, I am not sure if it tells me enough about my responsibilities, while I will be a critical token in the EU address management and registration system by just becoming an LIR. > > > My other concern is in regards to the transfers. As neatly put by the NCC Board in the Impact Analysis: > > --- > As mentioned in previous sections, the policy proposal would negatively affect the ability of LIRs to engage in inter-RIR transfers, as the RIPE NCC?s service region would be the only one without a needs-based requirement for transfers. > Implementation of the policy could expose LIRs to legal challenges under EU competition law. > --- > > > I think singling out the RIPE NCC region in the world of transfers may not be the best idea at this stage. > > Kind regards > Filiz Yilmaz > > > > > On 24 Jul 2013, at 10:52, Tore Anderson wrote: > > > * Michele Neylon - Blacknight > > > As previously stated, I do NOT support the "no need" policy and > cannot support this document. > > IP addresses are a finite resource, as we all know, and obliging > people to provide some level of justification makes sense. > > The argument for "conservation" may no longer be valid, but there > will always be a compelling argument in favour of good resource > management, which I believe the policy covers. > > RIPE should not remove the requirement to provide justification. > > Hi Michele, > > I doubt you'll find anyone in the working group who is against good > resource management. I am convinced that the proposed policy is not in > conflict with good resource management, otherwise I would never have > proposed it. While I can obviously only speak with certainty for myself, > I assume that the people who support the proposal feel the same way. > > While it appears you believe that the proposal will bring about poor > resource management, your message neglected to explain why or how. This > makes it rather difficult for me to try to alleviate your concerns. > > As Gert also pointed out recently, the main reason I believe that IPv4 > would continue to be consumed responsibly under the proposed policy, is > that the LIRs in the region are painfully aware that there is no more > IPv4 to be had from the RIPE NCC. Should an LIR anyway decide to go on a > "spending spree" with its remaining inventory, it would only end up > hurting itself by expediting its own depletion date. The community will > not be impacted - without a Common, there can be no Tragedy. > > Best regards, > Tore Anderson > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Thu Jul 25 19:20:32 2013 From: nick at inex.ie (Nick Hilliard) Date: Thu, 25 Jul 2013 18:20:32 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51F139B7.9060703@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> Message-ID: <51F15E60.5000003@inex.ie> On 25/07/2013 15:44, Tore Anderson wrote: > - What kind of problems are you foreseeing? address hoarding, leading to reduction in market liquidity, leading to profiteering. > - What kind of control mechanisms exist in today's policy, that are > removed by 2013-03, will forestall these problems? historically, two things: the presence of policies which make it difficult to transfer large amount of address space from many different sources, and secondly, the fact that IP addresses had little market value due to the fact they were effectively being dispensed for $notmuch by the rirs. I.e. lots of effort for little return. >> [There is a 24-month reallocation freeze, but I don't think this is going >> to work because it will not affect the reality of real world allocation >> transfers. Consequently, people will flout it, and then we will need to >> remove it from the policy mechanism because it's causing the registry >> function to break down.] > > s/24-month reallocation freeze/requirement to demonstrate need/ > > Does this argument work equally well? If no, why not? it's the same argument, which means that we need to understand that it is a bad idea to put any faith in the 24-month reallocation freeze rule as a means of regulating the market, or to believe that the rule will stay there as a long term fixture. > Probably impossible to answer accurately. that is true, but it might be useful to make some sort of estimate particularly with regard to the class A+B legacy allocations. Eyeballing, I figure there's probably quite a good chunk of unrouted legacy space or legacy space which ended up in commercial organisations who probably don't need all that space, and which could eventually come into the market - maybe 30-40 /8s as a rough estimate. Given that the RIRs ploughed through 94 /8s since the early 1990s, this represents a reasonably large amount of integers from the point of view of potential future liquidity. Nick From nick at inex.ie Thu Jul 25 19:39:23 2013 From: nick at inex.ie (Nick Hilliard) Date: Thu, 25 Jul 2013 18:39:23 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51F144B5.6080600@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F144B5.6080600@fud.no> Message-ID: <51F162CB.6010309@inex.ie> On 25/07/2013 16:31, Tore Anderson wrote: > For what it's worth, the motivation behind 2013-03 has nothing to do > with "the market" whatsoever. perhaps it's not the intention, but the consequence of the proposal is full market deregulation. > What this Evil Greedy Speculator needs to do is to register a few > thousand LIRs, since each new LIR is entitled a single /22. Today, each > of those LIRs must demonstrate "need", but this is merely a formality - > if you have an intention of assigning one (1) IPv4 address to some End > User within 12 months, you qualify. I seriously doubt that this > formality is what has prevented the Evil Greedy Speculators from having > done this already. the current ripe ncc pricing structure means that each IP address has a nominal capex value of ?3.70 + third party costs. So the nominal residual value of the remaining .88 /8 is about ?55m + a real headache when you realise that you also need to convince some company registration office that they should be ok about 15000 new company registrations if they wouldn't mind thankyouverymuch. Microsoft paid $11 per integer in 2011 for ~660k addresses. So right now, opening up bazillions of LIRs doesn't look like a particularly good option. [that said, maybe we should put forward a policy to ask RIPE to create a restful api for opening new LIRs, and to plump up Axel's medical insurance policy for when he needs to sign his name 15000 times. Just thinking out loud here...] Nick From tore at fud.no Thu Jul 25 20:41:32 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 25 Jul 2013 20:41:32 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <51F0D476.8080409@fud.no> Message-ID: <51F1715C.7090808@fud.no> * Filiz Yilmaz > I am aware of all the practical examples you have provided. > > You keep saying that everything but one thing is the status quo > already but that one thing bares a whole notion and a principle > (beyond maths) that I have been trying to express in my previous > posts because I simply do care about it. When I say that 2013-03 merely upholds the status quo with regards to a specific concern you have brought up, I truly believe that this is the case. So when we discuss the individual issues you raise, I would truly appreciate it very much if you would quote the relevant phrases or sections in the current policy, and that are removed or modified by 2013-03, that is responsible for causing an actual change from what we have today. This would make it much easier for me to understand exactly what it is that you are referring to in each case, and we can discuss those points specifically, and hopefully be able to find some common ground or agreement on them, one at a time. With that in mind: > I am not against transfers but I am against the practice of getting > space now from the NCC just to be able to transfer it later. Agreed in principle, but I don't see that the current policy prevents this. As has been pointed out by myself and others several times already, under the current policy each new LIR gets a /22, and the associated need evaluation ("1 address to assign to someone within a year") is merely a formality that is highly unlikely to prevent any new LIR who wants to do this from succeeding in doing so. > I do not call this a best practice and I would not like RIPE Policies > encourage it. Please quote the text in the proposed policy which encourages this kind of behaviour. > - But I find transfers extremely useful if they are to bring out some > already allocated space out of some drawer. Please quote the text in the proposed policy that would discourage LIRs from bringing out already allocated space out of some drawer. > While the current system is based on trust, there is definitely > enough of wording for what that trust is to be in the current text. > It is my belief that your proposal is taking them out all together > and leaving the resulting document a mere description of a system > that is an IP market, removing the core essential that IPs are for > networks in the first place. This is where my concern lies, not about > removing the bureaucracy. To the best of my knowledge, all the text in the proposed policy that "describes a system that is an IP market" is also present in today's policy, and was by and large added by proposal 2007-08. Could you please point out to me the specific passages added by 2013-03 that you are thinking of? > ripe-583 may be an overkill today, agreed. It is just a form > and a practice NCC applies though as a result of their interpretation > of the policy. If it is a problem ask the NCC folks to come up with a > more efficient form or a new scheme or totally have it removed even. As it happens, you'll be delighted to learn I've recently submitted a policy proposal that does exactly this! ;-) > Policy document does not talk about ripe-583 specifically anyway. > But your proposal is removing way too many important principles from > the policy text in order to fix an operational problem. Please cite the specific sentences or sections in the current policy, removed by 2013-03, that defined these important principles. > I may be just one person who thinks we should still mention in the > resulting document that RIPE Community cares about networks, that we > do realise that IPs are for networks and that these are expected to > be used with care and responsibility. I can tell you with absolute certainty that you are not the only one. This statement describes me, too, and for the record I operate both a network and an LIR. Best regards, Tore Anderson From tore at fud.no Thu Jul 25 21:49:21 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 25 Jul 2013 21:49:21 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51F15E60.5000003@inex.ie> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> Message-ID: <51F18141.1080609@fud.no> * Nick Hilliard > On 25/07/2013 15:44, Tore Anderson wrote: >> - What kind of problems are you foreseeing? > > address hoarding, I would actually claim that this is not difficult to pull off under today's policy either. If you want to set up a LIR to hoard address space, you can team up with someone who does have "need". (There are several buyers on the Listing Service who are seeking large blocks, perhaps a good place to start looking.) Make a proposition to them to loan them any address space you are able to find and buy on the market for free. With their ripe-583 forms in hand, your "hoarder LIR" has the required need to get approval from the NCC to receive allocation transfers. When the time comes that you need the addresses yourself, terminate the loaning contracts and reassign/transfer to yourself as appropriate. > leading to reduction in market liquidity, The numbers I posted in my previous message suggest that the market is only supplying 3-4% of actual demand (assuming last year's demand is a good indicator of this year's). I'd say that this is not a particularly liquid market to begin with, making it hard to see how any kind of further marginalisation of whatever little liquidity is there now can be a significant issue to the community when looking at the bigger picture. > leading to profiteering. It's perfectly possible and sanctioned by today's policy for LIRs to make a profit from IPv4. I gave an example to Filiz earlier about how you can, under today's policy, set up an LIR that only exists to lease out IPv4 blocks to whatever End Users are willing to pay the most. We were talking about the /22 allocation from the "last /8" then, but the procedure would work equally well for transfers - simply line up End Users and gather their ripe-582 forms, find space on the market and buy it, assign whatever you bought to whoever is first in line (or willing to pay the most). Lather, rinse, repeat. When a certain allocation has been in your possession for 24 months, you may also choose to transfer it away, or just keep leasing it out of course. Do whatever maximises your profits. You're not in any way breaching current policy, after all, you're essentially just operating an LIR. I'm not saying this is "good" or this is "bad", all I'm saying this can be done today, it's not something new that 2013-03 brings to the table. >> - What kind of control mechanisms exist in today's policy, that are >> removed by 2013-03, will forestall these problems? > > historically, two things: the presence of policies which make it difficult > to transfer large amount of address space from many different sources, Could you point out which part/passage of the policy you're referring to here? I am under the impression that if you have approval from the NCC for, say, a /8, there's no language in the current policy that makes it more difficult to transfer 16384 /22s from 16384 different sources, compared to transferring 1 /8 from 1 source. [I have absolutely no problems seeing that performing lots of small purchases is wildly more difficult than performing one large one, but for reasons that has nothing to do with any current policy language. Locating all the sellers and striking a deal with all of them, for starters.] > secondly, the fact that IP addresses had little market value due to the > fact they were effectively being dispensed for $notmuch by the rirs. I.e. > lots of effort for little return. But - this already changed when the RIPE NCC ran out of space and implemented the last /8 policy last September. I don't see what change is brought by 2013-03 in this regard? Could you point to the changed/removed policy language in question? >> s/24-month reallocation freeze/requirement to demonstrate need/ >> >> Does this argument work equally well? > > it's the same argument, which means that we need to understand that it is a > bad idea to put any faith in the 24-month reallocation freeze rule as a > means of regulating the market, or to believe that the rule will stay there > as a long term fixture. So just to make sure I have not misunderstood you here, you are also accepting the following argument to be equally valid (or invalid) as the one you wrote above? "we need to understand that it is a bad idea to put any faith in the requirement to demonstrate need rule as a means of regulating the market, or to believe that the rule will stay there as a long term fixture." Tore From frettled at gmail.com Thu Jul 25 21:55:41 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Thu, 25 Jul 2013 21:55:41 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51F18141.1080609@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> Message-ID: I'm bewildered, confuzzled, and wide-eyed, yes, nearly astonished, that Tore's points don't seem to penetrate the fog. I've read this proposal a few times, and as far as I can tell, most if not all of the alleged counterpoints to 2013-03 are _not_ counterpoints to 2013-03, but to something else. I may have misread the proposal, and therefore I request that Filiz, Michele and Nick please point out exactly which points _introduced_ or _altered_ with 2013-03 they disagree with, so that I, and other confused people, can have a better chance of understanding your arguments. Please? -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Thu Jul 25 21:59:35 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 25 Jul 2013 21:59:35 +0200 Subject: [address-policy-wg] Is the final /8 the correct term ? - semi off track to the 2013-03 discussion.. In-Reply-To: <008c01ce894b$f7160110$e5420330$@a2b-internet.com> References: <008c01ce894b$f7160110$e5420330$@a2b-internet.com> Message-ID: <51F183A7.9070602@fud.no> * Erik Bais > If you think that the pool which we have left is only the final /8 that > we are working into currently (185.x.y.z) I think that the assumption is > incorrect. It is incorrect indeed. This is one of the rather confusing things about our current policy that 2013-03 aims to improve. Under 2013-03, the phase "the last /8" is completely purged from the policy language. > There is still space left at IANA and once the first RIR reaches below > their /9 mark of their final /8 ? from my understanding it is , that > also that space is going to be allocated to the RIR?s . > > Also there will be reclaimed space from 2007-01 and closing LIR?s > (forced or by people their own decision) and also that space all goes > back into the same pool. Both these statements are correct. > So you might need quite a couple of new entities to finish the pool as > it is. . . Correct. I gave some stats about this here: http://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-July/008040.html (near the bottom of the message). > I?ve seen people say, why not open 20 new entities, setup a new LIR in > each .. and you have 20 /22?s ? Yes it is possible.. > > However I?ve noticed, there is little support to close this gap.. or the > gap to be able to merge those 20 LIR?s .. or the option to be able to > merge any LIR?s that already have their final /8 /22 provided. > > Yes there will be people who play the system.. and with the bottom in > sight, do we want to close all possible loopholes ? > > If we decide, no we don?t want to close the loopholes, stop mentioning > it in the discussion as a possible threat, because we already decided it > is what it is and we are not going to close the gap. Couldn't agree more. If there is a problem in today's policy that continues to be a problem with 2013-03 - don't hold it against 2013-03 (but do feel free to submit a new proposal that fixes the problem). Tore From sander at steffann.nl Thu Jul 25 22:49:39 2013 From: sander at steffann.nl (Sander Steffann) Date: Thu, 25 Jul 2013 22:49:39 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> Message-ID: <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> Hi, Op 25 jul. 2013, om 21:55 heeft Jan Ingvoldstad het volgende geschreven: > I'm bewildered, confuzzled, and wide-eyed, yes, nearly astonished, that Tore's points don't seem to penetrate the fog. > > I've read this proposal a few times, and as far as I can tell, most if not all of the alleged counterpoints to 2013-03 are _not_ counterpoints to 2013-03, but to something else. > > I may have misread the proposal, and therefore I request that Filiz, Michele and Nick please point out exactly which points _introduced_ or _altered_ with 2013-03 they disagree with, so that I, and other confused people, can have a better chance of understanding your arguments. As chair I can only agree to this. There is a lot of discussion going on, which is a good thing: it shows that the community (which includes all of you) actually cares about this and is involved in the decision making process. This makes chairs happy :-) But I have seen lots of cases where Tore asks people to point out which part of his policy proposal causes concern, and I haven't seen any answers to that. This makes an honest discussion about 2013-03 very difficult. I realise that there are many things in the current policies that people might want to change, but trying to put everything into one policy proposal doesn't work. If you have concerns that are not directly caused by the changes that 2013-03 proposes then please discuss them in a separate thread (and change the subject line accordingly please) and we can turn them into separate policy proposals if necessary. So for the sake of an open, transparent and honest discussion about 2013-03 please include references to existing policy that is removed by 2013-03 or to specific sections of 2013-03 itself. When a need for improvement is identified providing suggestions for text would of course also be appreciated. Thank you, Sander Steffann APWG co-chair From mueller at syr.edu Thu Jul 25 22:50:27 2013 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 25 Jul 2013 20:50:27 +0000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51F162CB.6010309@inex.ie> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F144B5.6080600@fud.no> <51F162CB.6010309@inex.ie> Message-ID: <855077AC3D7A7147A7570370CA01ECD24718C0@SUEX10-mbx-10.ad.syr.edu> Nick, I am detecting a contradiction in your argument: you say excessive costs associated with fees and registrations WILL stop people from hoarding under the current system, which underprices address blocks. But at the same time you are arguing that if we remove needs assessment, droves of "hoarders" will pay excessive and rising costs to buy up large quantities of number blocks they don't really need. That argument just doesn't make sense. The most reasonable way to get out of this contradiction is simply to admit that hoarding will have a very limited impact on the remnants of the IPv4 address space due to existing market conditions. The price of v4 blocks will rise as scarcity increases. People who pay that money have strong incentives to move the blocks to people who can use them to generate revenue. Possession of number blocks is widely distributed now, so no one can corner the market. The real hoarders are the legacy holders who are not releasing their addresses as widely as possible now. Why? Because needs assessment prevents them from transaction with many willing buyers. If you were really concerned about hoarding, you wouldn't be talking about some hypothetical future state, you'd be talking about the situation we are in right now. 30% of the v4 address space is hoarded. You can see a pretty good challenge to the hoary hoarding argument from Louis Sterchi here: http://blog.kalorama.com/archives/1239 Hoarding is an economic phenomenon, driven by economic incentives. If you want to argue it will take place, don't just assert it, provide a coherent economic analysis. > -----Original Message----- > From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg- > bounces at ripe.net] On Behalf Of Nick Hilliard > Sent: Thursday, July 25, 2013 1:39 PM > To: Tore Anderson > Cc: David Conrad; address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] 2013-03 New Draft Document and Impact > Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean > up) > > On 25/07/2013 16:31, Tore Anderson wrote: > > For what it's worth, the motivation behind 2013-03 has nothing to do > > with "the market" whatsoever. > > perhaps it's not the intention, but the consequence of the proposal is full > market deregulation. > > > What this Evil Greedy Speculator needs to do is to register a few > > thousand LIRs, since each new LIR is entitled a single /22. Today, each > > of those LIRs must demonstrate "need", but this is merely a formality - > > if you have an intention of assigning one (1) IPv4 address to some End > > User within 12 months, you qualify. I seriously doubt that this > > formality is what has prevented the Evil Greedy Speculators from having > > done this already. > > the current ripe ncc pricing structure means that each IP address has a > nominal capex value of ?3.70 + third party costs. So the nominal residual > value of the remaining .88 /8 is about ?55m + a real headache when you > realise that you also need to convince some company registration office > that they should be ok about 15000 new company registrations if they > wouldn't mind thankyouverymuch. > > Microsoft paid $11 per integer in 2011 for ~660k addresses. So right now, > opening up bazillions of LIRs doesn't look like a particularly good option. > > [that said, maybe we should put forward a policy to ask RIPE to create a > restful api for opening new LIRs, and to plump up Axel's medical insurance > policy for when he needs to sign his name 15000 times. Just thinking out > loud here...] > > Nick > From koalafil at gmail.com Thu Jul 25 22:59:11 2013 From: koalafil at gmail.com (Filiz Yilmaz) Date: Thu, 25 Jul 2013 22:59:11 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> Message-ID: <8345910C-4BD5-4CC7-8287-9D56605D4A08@gmail.com> Hello, On 25 Jul 2013, at 21:55, Jan Ingvoldstad wrote: > I'm bewildered, confuzzled, and wide-eyed, yes, nearly astonished, that Tore's points don't seem to penetrate the fog. > I can say the same thing. I did not really think what I was saying was so confusing? > I've read this proposal a few times, and as far as I can tell, most if not all of the alleged counterpoints to 2013-03 are _not_ counterpoints to 2013-03, but to something else. > > I may have misread the proposal, and therefore I request that Filiz, Michele and Nick please point out exactly which points _introduced_ or _altered_ with 2013-03 they disagree with, so that I, and other confused people, can have a better chance of understanding your arguments. > > Please? Just because you asked nicely :).. I am not going to go through a very detailed word smithing or referencing, sorry, in my case I do not believe this will be helpful. But I will try to put my point of view in a different way again, using some different words and then I will stop because I feel I am repeating myself and some of the members of this list may already feel overwhelmed about the discussion. Here it is my main point: "Justification for need" and "evaluation of justification for need" are two different things. First one, "Justification for need", is perfectly a policy matter and I believe IPv4 policy should still mention this, as long as RIPE NCC continues allocating space to its members and the last /8 is totally exhausted. Say something along the lines, "LIRs requesting address space from the RIPE NCC should have a need for the requested space for a network of their own or their customer". So that we at least put a barrier in front of those who would just ask for an allocation to immediately turn it into an asset. But those who really are in need are primarily highlighted by the policy. Current policy has the following text: "Members can receive an initial IPv4 allocation when they have demonstrated a need for IPv4 address space." Tore's proposal is removing this totally and I do not agree with it. The latter, "evaluation of justification for need" is totally an operational matter that is performed by the RIPE NCC. Neither the current policy nor Tore's proposal has any significant text on this but this is one of his arguments for his proposal. In my opinion, real solution to this procedural problem of evaluation is on procedural level, not on the policy level. RIPE NCC may be asked to change their evaluation tools/systems/mechanisms. This does not require to remove the entire "need" notion from the policy text. Kind regards Filiz Yilmaz > -- > Jan From tore at fud.no Thu Jul 25 23:06:26 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 25 Jul 2013 23:06:26 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51F1715C.7090808@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <51F0D476.8080409@fud.no> <51F1715C.7090808@fud.no> Message-ID: <51F19352.6020903@fud.no> * Tore Anderson >> I may be just one person who thinks we should still mention in the >> resulting document that RIPE Community cares about networks, that we >> do realise that IPs are for networks and that these are expected to >> be used with care and responsibility. > > I can tell you with absolute certainty that you are not the only one. > This statement describes me, too, and for the record I operate both a > network and an LIR. Uhm, apologies, I misread your original statement there Filiz. So to clarify, I do *not* think 2013-03 needs to add a statement saying that the RIPE Community cares about networks and so forth. After all, the current document makes no such statement either. What I thought you said first was that *you* was one person in the RIPE Community that cares about networks and so forth. That was what I wanted to agree with because I care about networks too. :-) In any case, I would be quite willing to discuss a separate proposal, independent from 2013-03, that added a statement along those lines. Tore From frettled at gmail.com Thu Jul 25 23:56:17 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Thu, 25 Jul 2013 23:56:17 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <8345910C-4BD5-4CC7-8287-9D56605D4A08@gmail.com> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <8345910C-4BD5-4CC7-8287-9D56605D4A08@gmail.com> Message-ID: On Thu, Jul 25, 2013 at 10:59 PM, Filiz Yilmaz wrote: > > Just because you asked nicely :).. > Thanks :) > > I am not going to go through a very detailed word smithing or referencing, > sorry, in my case I do not believe this will be helpful. > > But I will try to put my point of view in a different way again, using > some different words and then I will stop because I feel I am repeating > myself and some of the members of this list may already feel overwhelmed > about the discussion. > > Here it is my main point: > > "Justification for need" and "evaluation of justification for need" are > two different things. > > First one, "Justification for need", is perfectly a policy matter and I > believe IPv4 policy should still mention this, as long as RIPE NCC > continues allocating space to its members and the last /8 is totally > exhausted. Say something along the lines, "LIRs requesting address space > from the RIPE NCC should have a need for the requested space for a network > of their own or their customer". > > So that we at least put a barrier in front of those who would just ask for > an allocation to immediately turn it into an asset. > That barrier is a paper tiger, unfortunately. > But those who really are in need are primarily highlighted by the policy. > > Current policy has the following text: > "Members can receive an initial IPv4 allocation when they have > demonstrated a need for IPv4 address space." > > Tore's proposal is removing this totally and I do not agree with it. > > The latter, "evaluation of justification for need" is totally an > operational matter that is performed by the RIPE NCC. > Neither the current policy nor Tore's proposal has any significant text on > this but this is one of his arguments for his proposal. > > In my opinion, real solution to this procedural problem of evaluation is > on procedural level, not on the policy level. > RIPE NCC may be asked to change their evaluation tools/systems/mechanisms. > This does not require to remove the entire "need" notion from the policy > text. So, in essence, what you state is that: a) There is no need to change or remove the "need" statement in the policy. b) The RIPE NCC should decide how "need" is determined as a matter of procedure. Given what appears to be the majority view here, the NCC may just as well decide to interpret the community's view on "need" as something that does not need to be documented in itself, other than placing a request for a network block. Altering this particular part of the policy document as Tore suggests will change very little in practice and procedure. The way I see it, if you want for this to be a barrier, you should propose new wording in the relevant policy documents, which stresses that a need should be present, that there should be a justification for it, and _what justification_ is sufficient. PS I'm aware of organizations becoming LIRs because of a claimed need for IP addresses for end users, just to ensure that they get IPv4 space they may not _actually_ need ? and that this happened just because of the current policies. The "need" is fictional and/or hypothetical, and there is little way for the RIPE NCC and the community to know whether this is the case or not. Speaking as someone working for someone who currently uses both IPv4 and IPv6, the "need" requirement always seemed a bit out of place. If it is to have a place, it needs a clear policy for that. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri Jul 26 04:44:41 2013 From: jcurran at arin.net (John Curran) Date: Fri, 26 Jul 2013 02:44:41 +0000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51F15E60.5000003@inex.ie> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> Message-ID: <5A2DE121-9858-4043-B127-FA62A11A1D9A@corp.arin.net> On Jul 25, 2013, at 10:20 AM, Nick Hilliard wrote: > > that is true, but it might be useful to make some sort of estimate > particularly with regard to the class A+B legacy allocations. Eyeballing, > I figure there's probably quite a good chunk of unrouted legacy space or > legacy space which ended up in commercial organisations who probably don't > need all that space, and which could eventually come into the market - > maybe 30-40 /8s as a rough estimate. Given that the RIRs ploughed through > 94 /8s since the early 1990s, this represents a reasonably large amount of > integers from the point of view of potential future liquidity. Nick - It's probably best to look at the last 2 or 3 years of IANA->RIR allocations as an estimator of demand, rather than averaging across the entire period, e.g. reference Geoff Huston's recent blog entry for some very interesting pre-runout statistics (including APNIC numbers in excess of 12 /8's per year) - http://www.potaroo.net/ispcol/2013-08/when.html In terms of available space that may come to market, I'll note that many of these address blocks are actually in use by organizations, but in terms of routing hidden behind various firewall/nat combinations. Taking both the recent burn rate and in-use-but-not-routed factors into consideration, it's likely that (at a high enough price) that there are several years of additional IPv4 liquidity that could be obtained, but rather uncertain as to whether it could provide, say, 10 more years of continued IPv4 Internet growth... FYI, /John From tore at fud.no Fri Jul 26 08:32:57 2013 From: tore at fud.no (Tore Anderson) Date: Fri, 26 Jul 2013 08:32:57 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <8345910C-4BD5-4CC7-8287-9D56605D4A08@gmail.com> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <8345910C-4BD5-4CC7-8287-9D56605D4A08@gmail.com> Message-ID: <51F21819.1040408@fud.no> * Filiz Yilmaz > So that we at least put a barrier in front of those who would just > ask for an allocation to immediately turn it into an asset. But those > who really are in need are primarily highlighted by the policy. > > Current policy has the following text: "Members can receive an > initial IPv4 allocation when they have demonstrated a need for IPv4 > address space." > > Tore's proposal is removing this totally and I do not agree with it. Hi Filiz, and thanks for pointing out the specific text! I'll just reply with my reasons for removing this text and why I think it is the right thing to do, given 2013-03's ambition. I understand that ultimately, we might just have to agree to disagree on this. :-/ First, on a higher philosophical level, the only reason for the above sentence's existence, is the "Conservation" goal in section 3.0 ("..To maximise the lifetime of the public IPv4 address space, addresses must be distributed according to need..."). 2013-03 removes the "Conservation" goal, which means it also removes the only rationale for requiring the demonstration of need for initial IPv4 allocations. Hence, it makes sense to remove this part of the policy text as well. Second, on a more pragmatic level, when we hit IPv4 depletion last year, the requirement to demonstrate need in order to receive initial allocations changed. It is no longer "specify how many addresses do you need?", but a boolean "do you need more than 0 addresses? yes/no". Demonstrating the need for 1 IPv4 address is, in my opinion, merely a formality - anyone could do that with almost no effort. So I do not believe that the current requirement to demonstrate need in order to receive an initial allocation could be considered a "barrier", as you put it. If an organisation is determined enough to join the NCC and pay its membership fees, it will be able to receive its initial (and last) IPv4 /22 as well, regardless of what its ulterior intentions for its use are, including "assetification". Also, we do need to make a cost/benefit analysis here and look at the proposal as a whole - i.e., does it make sense to maintain the entire IPv4 assignment bureaucracy, in order to keep this completely inefficient barrier around? Third, referring more to ensuring the policy text forms a complete whole: Let's say I agreed to add this particular sentence back into the proposed policy, in order to alleviate your concerns and make you support the proposal. (Pragmatically, I wouldn't mind - I don't particularly care if the NCC asks the new LIRs "do you need at least 1 IPv4 address?" before handing out the initial /22 allocation as I see this as a mere formality.) This would cause a headache for the NCC, as we're telling them to demand a "need demonstration" from new LIRs, without telling them what that actually means. So the exchange could very well be "NCC: do you need it? LIR: yes, I plan on selling it." - which is pretty much exactly what you'd wanted a barrier against, right? So in order to prevent that, we'd need to add back more and more "need" text, and sooner or later we'd be end up back where we started. So I don't really want to go down that road, especially when the potential upside from doing so is a totally inefficient deterrence in the first place. > The latter, "evaluation of justification for need" is totally an > operational matter that is performed by the RIPE NCC. Neither the > current policy nor Tore's proposal has any significant text on this > but this is one of his arguments for his proposal. > > In my opinion, real solution to this procedural problem of evaluation > is on procedural level, not on the policy level. RIPE NCC may be > asked to change their evaluation tools/systems/mechanisms. This does > not require to remove the entire "need" notion from the policy text. I actually tried something like this during the discussion of 2012-05. At this point, the service requested from the NCC was something that was not mentioned in the policy at all, and for which there had been no previous established practice. My point of view was pretty much the same as yours above: "Do we need to put this in policy? Can't we just ask the NCC first?" However, the answer given by the NCC was that they preferred this to be a clear request coming out of the PDP. Evaluation of need, on the other hand, is deeply entrenched in our current policy document, and we have years of previously established practice. In light of this, and also my experiences in this approach failing for 2012-05, I highly doubt that me withdrawing 2013-03 and instead simply asking the NCC to stop evaluating need and expecting the LIRs to do so is likely to get anywhere. (I'm sure Andrea will correct me if I'm wrong!) Best regards, Tore Anderson From ebais at a2b-internet.com Fri Jul 26 10:46:31 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Fri, 26 Jul 2013 10:46:31 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51F162CB.6010309@inex.ie> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F144B5.6080600@fud.no> <51F162CB.6010309@inex.ie> Message-ID: <001701ce89dc$a02bd280$e0837780$@a2b-internet.com> Hi Nick, > [that said, maybe we should put forward a policy to ask RIPE to create a > restful api for opening new LIRs, and to plump up Axel's medical insurance > policy for when he needs to sign his name 15000 times. Just thinking out > loud here...] I think the NCC already took steps to prevent RSI with Axel and has been using a signature stamp for quite a while on the services agreements. From nick at inex.ie Fri Jul 26 12:33:03 2013 From: nick at inex.ie (Nick Hilliard) Date: Fri, 26 Jul 2013 11:33:03 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51F18141.1080609@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> Message-ID: <51F2505F.60400@inex.ie> On 25/07/2013 20:49, Tore Anderson wrote: > I would actually claim that this is not difficult to pull off under > today's policy either. no, indeed. btw, I'm not trying to imply that 2013-03 will cause hoarding and market skew - I'm just thinking out loud here and trying to understand how the proposal might affect the address market in the future. >> leading to reduction in market liquidity, > > The numbers I posted in my previous message suggest that the market is > only supplying 3-4% of actual demand on face value, this is not good but it's also interesting to note that ipv4 address demand is not so furious that people are desperate enough to go out and register large quantities of LIRs. This suggests that the cost of ?4/address + hassle is too high for people to want to bother doing it in bulk. > to pay the most). Lather, rinse, repeat. yep, agreed. >> historically, two things: the presence of policies which make it difficult >> to transfer large amount of address space from many different sources, > > Could you point out which part/passage of the policy you're referring to > here? the two things I pointed out are artefacts of current policy, not features of 2013-03. > So just to make sure I have not misunderstood you here, you are also > accepting the following argument to be equally valid (or invalid) as the > one you wrote above? > > "we need to understand that it is a bad idea to put any faith in the > requirement to demonstrate need rule as a means of regulating the > market, or to believe that the rule will stay there as a long term fixture." yes, correct. As I said, I'm not arguing in favour or against 2013-03 here, but just trying to understand its potential consequences. Broadly speaking, I think it's probably a rather good policy, but as it's such a fundamental shift away from all previous policy and practices, it's important to have discussions like this so that we understand the changes we're making. Nick From james.blessing at despres.co.uk Fri Jul 26 12:40:43 2013 From: james.blessing at despres.co.uk (James Blessing) Date: Fri, 26 Jul 2013 11:40:43 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51F21819.1040408@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <8345910C-4BD5-4CC7-8287-9D56605D4A08@gmail.com> <51F21819.1040408@fud.no> Message-ID: On 26 July 2013 07:32, Tore Anderson wrote: > Second, on a more pragmatic level, when we hit IPv4 depletion last year, > the requirement to demonstrate need in order to receive initial > allocations changed. It is no longer "specify how many addresses do you > need?", but a boolean "do you need more than 0 addresses? yes/no". > Demonstrating the need for 1 IPv4 address is, in my opinion, merely a > formality - anyone could do that with almost no effort. However, I know of several organisations who refer to the requirement to require IP address when asking for them from customers using the line: "We have to be able to justify the needs basis to get address space from RIPE and they require us to make sure that you have a need for the address space too" By removing a need at the LIR/RIR boundary you will create a problem at the Customer/LIR boundary. So keeping the text about need but removing the conservation goal bit is actually a desirable outcome. I think the goal of making life easier is nice but I fear we are rearranging deck chairs again :) J -- James Blessing 07989 039 476 From nick at inex.ie Fri Jul 26 13:00:34 2013 From: nick at inex.ie (Nick Hilliard) Date: Fri, 26 Jul 2013 12:00:34 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD24718C0@SUEX10-mbx-10.ad.syr.edu> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F144B5.6080600@fud.no> <51F162CB.6010309@inex.ie> <855077AC3D7A7147A7570370CA01ECD24718C0@SUEX10-mbx-10.ad.syr.edu> Message-ID: <51F256D2.4070202@inex.ie> On 25/07/2013 21:50, Milton L Mueller wrote: > I am detecting a contradiction in your argument: you say excessive costs > associated with fees and registrations WILL stop people from hoarding > under the current system, which underprices address blocks. But at the > same time you are arguing that if we remove needs assessment, droves of > "hoarders" will pay excessive and rising costs to buy up large > quantities of number blocks they don't really need. I'm not arguing for/against the policy and any concern I have relates to market speculators sucking up transfers from existing holders rather than new LIR allocations - which by any reasonable analysis is currently too painful for anyone to bother abusing on a large scale. > The most reasonable way to get out of this contradiction is simply to > admit that hoarding will have a very limited impact on the remnants of > the IPv4 address space due to existing market conditions. I don't believe any of us is in a position to make an assumption of this form. > The price of > v4 blocks will rise as scarcity increases. People who pay that money > have strong incentives to move the blocks to people who can use them to > generate revenue. Possession of number blocks is widely distributed now, > so no one can corner the market. no-one can corner the market in terms of overall possession of assigned address, but my concern is about speculators reducing liquidity in the market by hoovering up transferred addresses rather than getting lots of tiny new allocations from the lirs. Because there is relatively little liquidity in the market at the moment, this probably isn't very difficult or very expensive to do, yet it could have a significant effect on pricing and availability. > The real hoarders are the legacy holders who are not releasing their > addresses as widely as possible now. Why? Because needs assessment > prevents them from transaction with many willing buyers. If you were > really concerned about hoarding, you wouldn't be talking about some > hypothetical future state, you'd be talking about the situation we are > in right now. 30% of the v4 address space is hoarded. I mentioned this as a relevant factor in one of my emails yesterday. > Hoarding is an economic phenomenon, driven by economic incentives. If > you want to argue it will take place, don't just assert it, provide a > coherent economic analysis. "Please provide more convincing hand-waving". Right :-) Nick From sander at steffann.nl Fri Jul 26 14:01:39 2013 From: sander at steffann.nl (Sander Steffann) Date: Fri, 26 Jul 2013 14:01:39 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <8345910C-4BD5-4CC7-8287-9D56605D4A08@gmail.com> <51F21819.1040408@fud.no> Message-ID: <02EDF1CA-58B8-4DAC-8705-578CCEBE2BA2@steffann.nl> Hi James, > "We have to be able to justify the needs basis to get address space > from RIPE and they require us to make sure that you have a need for > the address space too" Euhm, you do realise that the "to get address space from RIPE" part has ended last year, right? ;-) > By removing a need at the LIR/RIR boundary you will create a problem > at the Customer/LIR boundary. I have heard that argument multiple times, but I don't understand it. What is wrong with: "There is a very limited amount of IPv4 address space left, so I have to be able to justify the needs basis to get address space for this project from my boss/manager/etc and he/she requires us to make sure that you have a need for the address space too" Cheers, Sander From gert at space.net Fri Jul 26 15:23:05 2013 From: gert at space.net (Gert Doering) Date: Fri, 26 Jul 2013 15:23:05 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <8345910C-4BD5-4CC7-8287-9D56605D4A08@gmail.com> <51F21819.1040408@fud.no> Message-ID: <20130726132305.GG65295@Space.Net> Hi, On Fri, Jul 26, 2013 at 11:40:43AM +0100, James Blessing wrote: > I think the goal of making life easier is nice but I fear we are > rearranging deck chairs again :) IPv4 is going to be with us for a long time, and the specific bits that Tore is attacking with 2013-03 are going to cause work for LIR network admins for the next 10 years, or so. So there is more benefit to this than mere deck chairs... Gert Doering -- APWG chair -- have you enabled 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From nigel at titley.com Fri Jul 26 15:52:15 2013 From: nigel at titley.com (Nigel Titley) Date: Fri, 26 Jul 2013 14:52:15 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <20130726132305.GG65295@Space.Net> References: <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <8345910C-4BD5-4CC7-8287-9D56605D4A08@gmail.com> <51F21819.1040408@fud.no> <20130726132305.GG65295@Space.Net> Message-ID: <51F27F0F.4030709@titley.com> On 26/07/2013 14:23, Gert Doering wrote: > Hi, > > On Fri, Jul 26, 2013 at 11:40:43AM +0100, James Blessing wrote: >> I think the goal of making life easier is nice but I fear we are >> rearranging deck chairs again :) > IPv4 is going to be with us for a long time, and the specific bits that > Tore is attacking with 2013-03 are going to cause work for LIR network > admins for the next 10 years, or so. So there is more benefit to this > than mere deck chairs... > And if we are going to go down with the ship, then at least the deckchairs will be pleasingly arranged and the band will be playing a heartwarming selection from the shows. Nigel From hph at oslo.net Fri Jul 26 17:49:51 2013 From: hph at oslo.net (Hans Petter Holen) Date: Fri, 26 Jul 2013 17:49:51 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> Message-ID: On Thursday, July 25, 2013, Jan Ingvoldstad wrote: > I'm bewildered, confuzzled, and wide-eyed, yes, nearly astonished, that > Tore's points don't seem to penetrate the fog. > > I've read this proposal a few times, and as far as I can tell, most if not > all of the alleged counterpoints to 2013-03 are _not_ counterpoints to > 2013-03, but to something else. > Well, it could be the title: "No need - Post-Depletion" -hph > -- Hans Petter Holen Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From hph at oslo.net Fri Jul 26 18:31:47 2013 From: hph at oslo.net (Hans Petter Holen) Date: Fri, 26 Jul 2013 18:31:47 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <8345910C-4BD5-4CC7-8287-9D56605D4A08@gmail.com> Message-ID: On Thursday, July 25, 2013, Jan Ingvoldstad wrote: > Here it is my main point: >> >> "Justification for need" and "evaluation of justification for need" are >> two different things. >> >> First one, "Justification for need", is perfectly a policy matter and I >> believe IPv4 policy should still mention this, as long as RIPE NCC >> continues allocating space to its members and the last /8 is totally >> exhausted. Say something along the lines, "LIRs requesting address space >> from the RIPE NCC should have a need for the requested space for a network >> of their own or their customer". >> >> So that we at least put a barrier in front of those who would just ask >> for an allocation to immediately turn it into an asset. >> > > That barrier is a paper tiger, unfortunately. > and has been so since the beginning.The amount of paper have changed over times. If the policy states "need" then NCC feels obliged to figure out how to determine "need" > > >> But those who really are in need are primarily highlighted by the policy. >> >> Current policy has the following text: >> "Members can receive an initial IPv4 allocation when they have >> demonstrated a need for IPv4 address space." >> >> Tore's proposal is removing this totally and I do not agree with it. >> (...) > > > So, in essence, what you state is that: > > a) There is no need to change or remove the "need" statement in the policy. > b) The RIPE NCC should decide how "need" is determined as a matter of > procedure. > > Given what appears to be the majority view here, the NCC may just as well > decide to interpret the community's view on "need" as something that does > not need to be documented in itself, other than placing a request for a > network block. > Be careful here - we are not operating by majority but by consensus - so we need to get everybody - or at least most - to understand and not object. > > Altering this particular part of the policy document as Tore suggests will > change very little in practice and procedure. > That is still not clear to me. Hans Petter -- Hans Petter Holen Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From hph at oslo.net Fri Jul 26 18:47:13 2013 From: hph at oslo.net (Hans Petter Holen) Date: Fri, 26 Jul 2013 18:47:13 +0200 Subject: [address-policy-wg] Is the final /8 the correct term ? - semi off track to the 2013-03 discussion.. In-Reply-To: <51F183A7.9070602@fud.no> References: <008c01ce894b$f7160110$e5420330$@a2b-internet.com> <51F183A7.9070602@fud.no> Message-ID: On Thursday, July 25, 2013, Tore Anderson wrote: > * Erik Bais > > > If you think that the pool which we have left is only the final /8 that > > we are working into currently (185.x.y.z) I think that the assumption is > > incorrect. > > It is incorrect indeed. This is one of the rather confusing things about > our current policy that 2013-03 aims to improve. Under 2013-03, the > phase "the last /8" is completely purged from the policy language. Which I belive is a good thing. > > There is still space left at IANA Yes roughly a /8 in bits an pieces according to IANA management at the last ICANN meeting. > > and once the first RIR reaches below > > their /9 mark of their final /8 ? from my understanding it is , that > > also that space is going to be allocated to the RIR?s . > > > > Also there will be reclaimed space from 2007-01 and closing LIR?s > > (forced or by people their own decision) and also that space all goes > > back into the same pool. > > Both these statements are correct. Is it really? If we remove the needs based criteria will it then be returned to the NCC or put up for sale? Hans Petter -- Hans Petter Holen Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.vegoda at icann.org Fri Jul 26 20:28:16 2013 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 26 Jul 2013 11:28:16 -0700 Subject: [address-policy-wg] Is the final /8 the correct term ? - semi off track to the 2013-03 discussion.. In-Reply-To: References: <008c01ce894b$f7160110$e5420330$@a2b-internet.com> <51F183A7.9070602@fud.no> Message-ID: <5648A8908CCB564EBF46E2BC904A75B184E131A804@EXVPMBX100-1.exc.icann.org> Hi, Hans Petter Holen wrote: [ ] ? > > There is still space left at IANA? > > Yes roughly a /8 in bits an pieces according to IANA management at the last ICANN meeting.? You can see the full details of the recovered pool in the IANA IPv4 Recovered Address Space registry: http://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recove red-address-space.xml which is also available as a CSV file, for the convenience of anyone who wants to import it into some spreadsheet software. Kind regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5475 bytes Desc: not available URL: From frettled at gmail.com Sat Jul 27 11:28:33 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Sat, 27 Jul 2013 11:28:33 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <8345910C-4BD5-4CC7-8287-9D56605D4A08@gmail.com> Message-ID: On Fri, Jul 26, 2013 at 6:31 PM, Hans Petter Holen wrote: > Given what appears to be the majority view here, the NCC may just as well >> decide to interpret the community's view on "need" as something that does >> not need to be documented in itself, other than placing a request for a >> network block. >> > > Be careful here - we are not operating by majority but by consensus - so > we need to get everybody - or at least most - to understand and not object. > Yes, we do operate by consensus, but let's say that we can't get everybody to not object to the change, and therefore the sentence in question remains (as an oddity, IMHO, but nevertheless). The majority has then given pretty clear signals about how important that "need" is, which is to say "not at all", while a vocal few have said it _is_ important, and apparently more important than current and former practice has been handled by the RIPE NCC. Now, what is the RIPE NCC to make of that? There are three options: 1) Carry on as before. 2) Loosen up on the "need" interpretation. 3) Become more strict with how "need" must be documented. Additionally, this will lead to new proposals for changes to other policy texts to ensure harmony with the remaining requirement for some sort of "need". This is what I'm getting at. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Sat Jul 27 11:32:29 2013 From: randy at psg.com (Randy Bush) Date: Sat, 27 Jul 2013 11:32:29 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <8345910C-4BD5-4CC7-8287-9D56605D4A08@gmail.com> Message-ID: http://www.ietf.org/id/draft-resnick-on-consensus-02.txt may be of help From frettled at gmail.com Sat Jul 27 11:56:58 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Sat, 27 Jul 2013 11:56:58 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <8345910C-4BD5-4CC7-8287-9D56605D4A08@gmail.com> Message-ID: On Sat, Jul 27, 2013 at 11:32 AM, Randy Bush wrote: > http://www.ietf.org/id/draft-resnick-on-consensus-02.txt > > may be of help > Actually, it was. And it is sane. Thanks. -- Jan, perhaps less silly now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Sun Jul 28 12:29:54 2013 From: tore at fud.no (Tore Anderson) Date: Sun, 28 Jul 2013 12:29:54 +0200 Subject: [address-policy-wg] Is the final /8 the correct term ? - semi off track to the 2013-03 discussion.. In-Reply-To: References: <008c01ce894b$f7160110$e5420330$@a2b-internet.com> <51F183A7.9070602@fud.no> Message-ID: <51F4F2A2.8090408@fud.no> * Hans Petter Holen > and once the first RIR reaches below > > their /9 mark of their final /8 ? from my understanding it is , that > > also that space is going to be allocated to the RIR?s . > > > > Also there will be reclaimed space from 2007-01 and closing LIR?s > > (forced or by people their own decision) and also that space all goes > > back into the same pool. > > Both these statements are correct. > > Is it really? Demonstrably so. You confirmed yourself that there is currently reclaimed address space in the IANA pool (19,104,768 addresses to be exact), and according to the delegated file there are currently 933,832 returned/reclaimed addresses in the NCC's possession. > If we remove the needs based criteria will it then be returned to the > NCC or put up for sale? Needs based criteria is irrelevant here, as selling LIRs are not subjected to any form of need evaluation. If an LIR is closing down in a controlled manner (i.e., not forcibly by the NCC), it may choose to put its allocations up for sale or to return them to the NCC. (PI assignments, OTOH, have nowhere to go except back to the NCC.) Tore From gert at space.net Sun Jul 28 13:20:30 2013 From: gert at space.net (Gert Doering) Date: Sun, 28 Jul 2013 13:20:30 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <8345910C-4BD5-4CC7-8287-9D56605D4A08@gmail.com> Message-ID: <20130728112030.GU65295@Space.Net> Hi, On Sat, Jul 27, 2013 at 11:32:29AM +0200, Randy Bush wrote: > http://www.ietf.org/id/draft-resnick-on-consensus-02.txt Thanks for the pointer. While this is an IETF draft, the principles by which Sander and I try to assert consensus are similar - so while we certainly prefer to reach unanimous agreement (or at least, abstention instead of opposition from those that do not support a proposal), we've had proposals in the past where single individuals very strongly opposed the proposal, but nobody else agreed to their reasoning, and it wasn't possible to convince them that their argument does not hold - so we went ahead nevertheless. For this particular proposal here, Sander and I are reading and listening carefully, and will write a very detailed summary at the end of the review phase... Of course it helps us enormously if those that post their concerns about things, for example, "abuse of the last /8 policy" or "unrestricted trading of addresses", clearly state whether they see this as a consequence of 2013-03 and actually object to 2013-03 because of that (and if yes, which parts of 2013-03, so Tore can answer to that). If we can't see specific opposition to changes brought by 2013-03, we tend to evaluate such statements as "neutral as far as the proposal at hand goes". Gert Doering -- APWG chair -- have you enabled 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From randy at psg.com Sun Jul 28 13:34:46 2013 From: randy at psg.com (Randy Bush) Date: Sun, 28 Jul 2013 13:34:46 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <20130728112030.GU65295@Space.Net> References: <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <8345910C-4BD5-4CC7-8287-9D56605D4A08@gmail.com> <20130728112030.GU65295@Space.Net> Message-ID: > we certainly prefer to reach unanimous agreement and i prefer cash to fall from the sky. can we now return to the real world? for any issue of substance, there will usually be honest disagreement. what we are not good at is saying is o you three people are the ones not moving from disagreement. o can you live with what everyone else seems to be able to live with? o if not, well, sometimes life is tough. it would be *really* nice is the few in disagreement could live with the general consensus. and we certainly need to pay good attention to their points. but sometimes we need to move ahead with there still being a (very few) folk in disagreement. randy From frettled at gmail.com Sun Jul 28 15:39:18 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Sun, 28 Jul 2013 15:39:18 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <8345910C-4BD5-4CC7-8287-9D56605D4A08@gmail.com> <20130728112030.GU65295@Space.Net> Message-ID: On Sun, Jul 28, 2013 at 1:34 PM, Randy Bush wrote: > > it would be *really* nice is the few in disagreement could live with the > general consensus. and we certainly need to pay good attention to their > points. but sometimes we need to move ahead with there still being a > (very few) folk in disagreement. > > I think this is where the point about having a mutual understanding is important: - what the proposition changes and does not change - what the opposing arguments are, to which points of the proposition ? because, as someone aptly noted earlier, the number of ayes and nays do not necessarily reflect the opinions of a majority or minority of the members. It seems to me that we are just about there, now, and that any unclear statements, suggestions and criticisms can probably be considered "neutral". Then again, this is merely my personal opinion. :) -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogerj at gmail.com Mon Jul 29 12:08:21 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Mon, 29 Jul 2013 12:08:21 +0200 Subject: [address-policy-wg] Assignment window vs allocated space vs "bought" IP space? Message-ID: Earlier today a friend with a new LIR got confused by assignment window (21) vs allocated address space (/22). That trigged another question for me. If that LIR somehow got their hand on another /20 from somewhere that is not RIPE, does the same assignment window apply to that /20 ? Or how does AW apply to bought/transferred address space? -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From gert at space.net Mon Jul 29 12:15:28 2013 From: gert at space.net (Gert Doering) Date: Mon, 29 Jul 2013 12:15:28 +0200 Subject: [address-policy-wg] Assignment window vs allocated space vs "bought" IP space? In-Reply-To: References: Message-ID: <20130729101528.GA65295@Space.Net> Hi, On Mon, Jul 29, 2013 at 12:08:21PM +0200, Roger J?rgensen wrote: > Earlier today a friend with a new LIR got confused by assignment > window (21) vs allocated address space (/22). That trigged another > question for me. > > If that LIR somehow got their hand on another /20 from somewhere that > is not RIPE, does the same assignment window apply to that /20 ? > Or how does AW apply to bought/transferred address space? AW applies to all space allocated by the RIPE NCC, so that would also apply to space allocated from the NCC to another LIR and then transferred by our procedures to this LIR. OTOH, if that LIR got a /20 from "somewhere else", this would have to be done outside the RIPE policy (as we do not have a policy to formally register such a transfer), so RIPE AW would not apply to that /20 - but "whatever rules come with it". Gert Doering -- APWG chair -- have you enabled 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From ripe-wgs.cs at schiefner.de Wed Jul 31 11:08:20 2013 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Wed, 31 Jul 2013 11:08:20 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <51E67244.3090908@titley.com> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C2BB31.5060701@fud.no> <51C2E753.50307@schiefner.de> <51C303C6.5040408@opteamax.de> <51C30D04.8090809@titley.com> <51DFFA30.7070707@schiefner.de> <51E03458.2090701@titley.com> <51E5BEF1.3000507@schiefner.de> <51E67244.3090908@titley.com> Message-ID: <51F8D404.8070703@schiefner.de> All - On 17.07.2013 12:30, Nigel Titley wrote: >On 16/07/2013 22:45, Carsten Schiefner wrote: >> I can't find anything in the minutes concerning a status change of PI >> space. Or did I miss something somewhere? >> > Hmm, yes the discussion we had didn't get formally minuted. Looking back > on the correspondence on the board mailing list after the meeting, where > this lack of minuting was brought up, it was decided that as the > discussion was still taking place on the AP-WG list that we shouldn't > bias the discussion by minuting the board discussion. Which I've managed > to completely put my foot in... > > The upshot was that the Board agreed in principle that they thought that > a move from PI to PA under the defined circumstances was fine in > principle, as far as they could see, but that the discussion should run > to a close in the community before coming to a final conclusion. I feel that this got stalled a bit in the meantime: any feelings on where we are and what to do next? AFAIR most, if not all contributions were in favour of the idea. Filiz Yilmaz on Fri, 12 Jul 2013, at 15:48:19 +0200 pledged to have a slightly more careful discussion, maybe even a PDP, about it: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-July/008005.html And the somewhat connected idea to completely abandon PI vs. PA distinction was floated by Olaf Sonderegger and Hans Petter Holen: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-June/007951.html https://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-July/008019.html I am still in favour of the original approach and would like to see it implemented and/or executed, respectively. All the best, -C. From ebais at a2b-internet.com Wed Jul 31 13:50:36 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Wed, 31 Jul 2013 13:50:36 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <51F8D404.8070703@schiefner.de> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C2BB31.5060701@fud.no> <51C2E753.50307@schiefner.de> <51C303C6.5040408@opteamax.de> <51C30D04.8090809@titley.com> <51DFFA30.7070707@schiefner.de> <51E03458.2090701@titley.com> <51E5BEF1.3000507@schiefner.de> <51E67244.3090908@titley.com> <51F8D404.8070703@schiefner.de> Message-ID: <007301ce8de4$2bf9e3a0$83edaae0$@a2b-internet.com> Hi Carsten, I'm in favor of LIR's being able to change the PI status to PA for their own assigned PI space. (Infrastructure) I think that the whole PI and PA discussion itself will take some time to complete, but this particular change should be fairly easy to implement imho. Regards, Erik Bais -----Original Message----- From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Carsten Schiefner Sent: woensdag 31 juli 2013 11:08 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space All - On 17.07.2013 12:30, Nigel Titley wrote: >On 16/07/2013 22:45, Carsten Schiefner wrote: >> I can't find anything in the minutes concerning a status change of PI >> space. Or did I miss something somewhere? >> > Hmm, yes the discussion we had didn't get formally minuted. Looking back > on the correspondence on the board mailing list after the meeting, where > this lack of minuting was brought up, it was decided that as the > discussion was still taking place on the AP-WG list that we shouldn't > bias the discussion by minuting the board discussion. Which I've managed > to completely put my foot in... > > The upshot was that the Board agreed in principle that they thought that > a move from PI to PA under the defined circumstances was fine in > principle, as far as they could see, but that the discussion should run > to a close in the community before coming to a final conclusion. I feel that this got stalled a bit in the meantime: any feelings on where we are and what to do next? AFAIR most, if not all contributions were in favour of the idea. Filiz Yilmaz on Fri, 12 Jul 2013, at 15:48:19 +0200 pledged to have a slightly more careful discussion, maybe even a PDP, about it: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-July/008005.html And the somewhat connected idea to completely abandon PI vs. PA distinction was floated by Olaf Sonderegger and Hans Petter Holen: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-June/007951.html https://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-July/008019.html I am still in favour of the original approach and would like to see it implemented and/or executed, respectively. All the best, -C. From malcolm at linx.net Wed Jul 31 15:26:31 2013 From: malcolm at linx.net (Malcolm Hutty) Date: Wed, 31 Jul 2013 14:26:31 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> Message-ID: <51F91087.5040104@linx.net> I don't support the approval of 2013-03 "No need" at this time. Needs-based allocation is more than an operational procedure for the RIPE NCC to follow. It encapsulates a core policy objective for the management of the IPv4 address space, not only by RIPE NCC but also by LIRs. I am not convinced by the the principle argument being made in favour of abolishing the concept of "need", and concerned that we do not fully appreciate the potential consequences. The proposal adopts one particular type of "reality adjustment" in response to IPv4 address pool depletion, abandoning the core objective. There might be other types of responses, but if we abandon the core objective, as 2013-03 would do, we're basically closing the door on any discussion of what those alternatives might be. Finally, as noted by the RIPE NCC, this takes away a key message the RIRs have used to justify their independence from government. That may not be sufficient reason to oppose the policy if it is otherwise necessary, but it does seem to me to indicate caution and counsel against acting precipitously. In short, the potential downsides seem to me to be more compelling than the claimed upside, and certainly sufficient to justify an extended delay (by which I mean, broadly indefinite, or until the community feels the implications of depletion are clearly understood and well established). Let me elaborate. 1. The main argument in favour of 2013-03, as I understand it, is in the title "Post-Depletion Reality Adjustment and Clean up". It has been expressed in the summary /'The goal that precipitated the requirement to demonstrate need for delegations is explicitly stated in section 3.0.3 of the policy, which reads: Conservation: Public IPv4 address space must be fairly distributed to the End Users operating networks. To maximise the lifetime of the public IPv4 address space, addresses must be distributed according to need, and stockpiling must be prevented. Following the depletion of the IANA free pool on the 3rd of February 2011, and the subsequent depletion of the RIPE NCC free pool on the 14th of September 2012, the "lifetime of the public IPv4 address space" in the RIPE NCC region has reached zero, making the stated goal unattainable and therefore obsolete. This proposal attempts to recognise this fact by removing all policy requirements that was working exclusively towards attaining this "Conservation" goal.'/ However this argument is fallacious. The Conservation policy, even as stated, expresses *two separate* policy objectives: 'fair distribution', and maximising the lifetime of the public address pool. Depletion means that reality has superseded the second objective, but not necessarily the first. So my first question to Tore is: "Why should 'fair distribution' of addresses between users no longer be considered an overarching objective of IPv4 address management?" 2. "Fair distribution" establishes a basic goal for IPv4 address management policy. Other policies exist to pursue that goal. If we abolish the goal, we not only abolish those other, secondary policies (which may indeed be out of date) but we also deny ourselves the right to introduce new, updated policies to pursue that goal. 2A. Incidentally, I've seen comments in this thread that I read as claiming that we effectively abolished the goal of fair distribution back when we set a precise allocation size for the final /8. I can see this argument, but disagree: limiting the maximum allocation size directly relies upon the notion of fairness (we're only giving you X, even though you want Y, so that the next guy can have some at all). By limiting the minimum allocation size we made a pragmatic choice to trade off some precision for efficiency in the allocation process, rather than fundamentally abolishing the policy goal. 3. The proponents of 2013-03 have argued on this list that the existing policy is unsupportable because, in a post-depletion world, RIPE NCC has lost the means of enforcing it. It is certainly true that post-depletion it will have lost the means by which it has traditionally enforced it. But that doesn't necessarily mean that the policy should be abolished: it might alternatively suggest that the required "reality adjustment" is that the community develop new policies that would give the RIPE NCC alternative means of enforcing it in the post-depletion world, where IPv4 addresses continue to be an important resource. a) I anticipate being asked "What might such policies be?". My answer is, without shame, that I don't know. But perhaps the community should retain the ability to set such policies in the future, if they seem necessary. 2013-03 removes the basis on which such policies would be introduced. b) I anticipate being asked "Are such policies needed? Can you prove this?". My answer is again that I don't know. More than that, it may very well be that such policies are *not* needed, yet. But proof that may change in the future. I would prefer that at that time new policies could be introduced if they were proven to be needed. I would prefer that such proof were not met with the response "When we abolished needs based allocation back in 2013, we accepted that RIPE has neither the responsibility nor the legitimacy to address these issues.". I fear that the effect of passing 2013-03 will be to invite that response. c) Actually, contrary to what I seem to say in the paragraph above, I'm open to be persuaded that we should say "RIPE is not responsible for the efficient and fair management of the address space, that's a purely market process". But that's so far away from what we've had in the past, I strongly believe we should set an unusually high bar for community support for this, in determining a rough consensus, even at the cost of taking a very long time to achieve it. Extraordinary measures require extraordinary support. d) Suppose that we do end up saying "It's nothing to do with us, let the market rule". Who do we think should be responsible for clearing up the mess if this does result in a clear, unequivocal disaster? Will we take that as a failure of the new address policy, and change the policy again? Would that even be legally possible, once we've commoditised addresses? Or would we consider that a failure of the market, and leave it to government regulators, competition authorities etc? 4. For the reasons above, I don't think it's accurate to claim that 2013-03 is a mere "reality adjustment"; I think it's a fundamental change in policy. I believe the following represents a reasonable alternative "reality adjustment", that more accurately states the current reality: "It has always been the policy of RIPE to seek to ensure that IPv4 addresses are allocated fairly and efficiently. While the RIPE NCC had free IPv4 addresses to assign, this policy was implemented by requiring End Users to provide documentation to the LIR (and/or the RIPE NCC) that proved their need for address space, and the LIR need to provide similar documentation to the RIPE NCC. In all cases, the documentation had to be thoroughly vetted and archived for later auditing. After depletion of the IPv4 address pool this process is no longer an effective control. With the introduction of a transfer mechanism, it is possible that market pressures may prove adequate to ensure efficient and fair allocation of IPv4 addresses; in this transition period, the consequences of run-out are uncertain. RIPE has chosen not to act pre-emptively, to give market mechanisms a chance to succeed. However if market mechanisms prove inadequate to safeguard the fair and efficient use of IPv4 address space, RIPE stands ready to introduce new measures as necessary." 5. We have lived with "needs based allocation" for a long time, and it has served us well. "Delaying run-out" may previously have been a sufficient justification for the policy, but that doesn't mean it's the only justification for the policy. I do accept that the onus should be on those that wish to retain the policy on this basis to produce and convince the community of an alternative justification. However, given that we're talking about abolishing the core rule at the heart of allocation policy for the past many (nearly twenty?) years, I believe it would be prudent to allow quite an extended time to conduct that discussion. 6. My sixth reason for speaking out against the adoption 2013-03 at this time is the potential political fall-out. Certain governments are keen to end the independence of the RIRs and move them from being run by and on behalf the community to being made directly answerable to governments. In practice, this would mean the abolition of RIPE (or at least, its policy making function) and perhaps having the RIPE NCC board appointed by an intergovernmental body, likely the ITU. Some nation's governments remain very keen on this. Others, notably developing countries, used to be very keen on this but have subsequently been persuaded that the RIRs do a good job and that "bottom-up" / community-based policy-making just works. This change of heart has been hard won, and a key part of the message of RIRs and their defenders (myself included) has been that these governments should support the management of address space on a purely technical basis, with allocation according to need, rather than risk politicising the issue by placing it under inter-governmental control. As someone who has worked in that space for the past eight years (some of you may remember I proposed and chaired the RIPE Enhanced Cooperation Taskforce, which recommended measures to address that debate) I can say from experience that 2013-03 will be politically uncomfortable for the RIPE NCC, and will give ammunition to those governments that still want to gain intergovernmental control. The RIPE NCC impact assessment also alludes to this risk. Now, if there were a strong technical necessity for a policy to go through, I would agree that the politics would have to take second place. The NCC, and its supporters, like me, would have to justify the change as best we can. However 2013-03 doesn't seem as important as that, and certainly not urgent: it is just a "clean up" after all. So this political downside should also be taken into account. Moreover I would ask that the WG Chairs take this sixth issue into account as evidence that the community hasn't fully examined the potential consequences, and should be wary of proceeding too precipitously. I would suggest that the NCC (or perhaps another NRO member) be invited to give a presentation on this topic at the next Working Group meeting. Sorry for the long message on a long thread, and thank you for considering it. Regards, Malcolm. P.S. Direct response to specific questions for objectors from the WG Chair follow. On 25/07/2013 21:49, Sander Steffann wrote: > > But I have seen lots of cases where Tore asks people to point out > which part of his policy proposal causes concern, and I haven't seen > any answers to that. For me, it's not a question of a particular element of the proposal that needs improvement, it's a concern that its essence is misguided as a whole. > So for the sake of an open, transparent and honest discussion about > 2013-03 please include references to existing policy that is removed > by 2013-03 or to specific sections of 2013-03 itself. My comments relate mostly to, and at the minimum to "Removes "Conservation" as a stated goal of the policy". Since this seems to be the core of the proposal, I would think that most of the rest of the proposal would fall away if this were deleted. However it's possible that I'm wrong: perhaps there may be some compromise whereby we continue to assert that that the objective of policy is fair allocation, but when considering the small assignments from the final /8 "assume" that there is need (without documentation) unless there is reason to believe otherwise. This would allow for future policies that established reasons deemed to suggest otherwise. For example, in the unlikely case where someone registers 5,000 companies just to get 5,000 allocations (as has been suggested on this thread), it would also allow the RIPE NCC to step in and say "No, that's just gaming the system and we're not fooled". It would also allow other policies to continue to require the demonstration of need for the transfer of large blocks and of intraregional transfers, if such policies were thought necessary and someone could come up with a proposal to make them enforceable. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd 21-27 St Thomas Street, London SE1 9RY Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA From tore at fud.no Wed Jul 31 17:00:02 2013 From: tore at fud.no (Tore Anderson) Date: Wed, 31 Jul 2013 17:00:02 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51F91087.5040104@linx.net> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> Message-ID: <51F92672.50400@fud.no> Hi Malcom, and thank you for your detailed feedback! I'll be trimming your message heavily in order to try to respond to your main points in order to avoid doubling the size of the message - if you feel I have neglected to respond to something I ought to have, please let me know. > if we abandon the core objective, as 2013-03 would do, > we're basically closing the door on any discussion of what those > alternatives might be. I do not agree with this at all. The IPv4 policy document is a living thing, and anyone may suggest changes to it at any time. For example, the possible addition of a section describing "Principles" has been discussed earlier, and 2013-03 would not prevent this in any way. Indeed, such a proposal could be proposed and adopted independently of 2013-03. > Finally, as noted by the RIPE NCC, this takes away a key message the > RIRs have used to justify their independence from government. That may > not be sufficient reason to oppose the policy if it is otherwise > necessary, but it does seem to me to indicate caution and counsel > against acting precipitously. This is one of those things where I feel the message needs to be updated to match the new realities on the ground. Regardless of any change brought by 2013-03, the RIPE NCC's role in IPv4 address distribution is pretty much over, the "last /8" policy being its final death cramp, so to speak. It was claimed earlier that the proposal would change the NCC into a "pay here to buy your IPv4 block today" type of outlet, and I don't doubt that some government could potentially make similar claims in an attempt to undermine the NCC's role in IPv4 address distribution. However I have full faith in the NCC's ability to adjust its argumentation to explain that this is simply not the case, as its role in IPv4 address distribution is pretty much unchanged by 2013-03. That said, I would be more concerned about keeping or making certain policies for the purpose of "staying in power" instead of due to a belief it is "the right thing to do". If anything would undermine the community's validity, IMHO, it would be this. > However this argument is fallacious. The Conservation policy, even as > stated, expresses *two separate* policy objectives: 'fair distribution', > and maximising the lifetime of the public address pool. Depletion means > that reality has superseded the second objective, but not necessarily > the first. > > So my first question to Tore is: "Why should 'fair distribution' of > addresses between users no longer be considered an overarching objective > of IPv4 address management?" For NCC->LIR and NCC->End User delegations, it has already been abandoned. For example: - LIR A requires an allocation to serve 10000000 nodes - LIR B requires an allocation to serve 1000 nodes - End User C requires an assignment to serve 1000 nodes These would (both with current and 2013-03 policy) get 1024, 1024, and 0 addresses, respectively - even though the NCC currently has enough addresses to give all three every single address they requested. In my view, this is clearly unfair to A and C, but it's what we have today. For LIR->End User delegations, I question that 'fair distribution' has ever existed, or if it ever did - if it does now. I'll demonstrate with another example: Your LIR has a /23 left of unassigned address space. Three End Users are knocking on your door, requesting a /24, a /23, and a /22. All fully justified. How does our current policy guide your LIR to be "fair", let alone *enforce* this fairness? > 2. "Fair distribution" establishes a basic goal for IPv4 address > management policy. Other policies exist to pursue that goal. > If we abolish the goal, we not only abolish those other, secondary > policies (which may indeed be out of date) How does the secondary mechanisms (I'm guessing you're referring to things like the AW, 80% rule, and "documented need") actually ensure "fairness", these days? Going back to the previous argument with the three End Users - the only way "fairness" could work in the first place, is that your LIR could just give out everything that was asked by covering their "expenses" with fresh allocations from the NCC's free pool. But that doesn't work anymore. > but we also deny ourselves the right to introduce new, updated policies > to pursue that goal. > > 3. The proponents of 2013-03 have argued on this list that the existing > policy is unsupportable because, in a post-depletion world, RIPE NCC has > lost the means of enforcing it. It is certainly true that post-depletion > it will have lost the means by which it has traditionally enforced it. > But that doesn't necessarily mean that the policy should be abolished: > it might alternatively suggest that the required "reality adjustment" is > that the community develop new policies that would give the RIPE NCC > alternative means of enforcing it in the post-depletion world, where > IPv4 addresses continue to be an important resource. I just don't buy the argument that 2013-03 makes the IPv4 policy immutable. This isn't APNIC prop-103. If 2013-03 turns out to be a terrible mistake, it could even be reverted word by word. Last year, I reverted 2009-03 *precisely* in this manner (proposal 2012-06). If you believe that the current policy provisions that are responsible for enforcing "fairness" are no longer effective (if they ever were), then we might as well take them out completely. If we come up with a clever replacement, then we can discuss that in a separate proposal, but if we fail to come up with an effective replacement, what good will it do us to keep the inefficient stuff around? (Surely not the bureaucratic overhead?) > Certain governments are keen to end the independence of the RIRs and > move them from being run by and on behalf the community to being made > directly answerable to governments. In practice, this would mean the > abolition of RIPE (or at least, its policy making function) and perhaps > having the RIPE NCC board appointed by an intergovernmental body, likely > the ITU. 2013-03 is specific to IPv4, and does not make any difference to other number resources such as IPv6 and ASNs. While I have no difficulty understanding that governments would have liked to have the RIR role, I guess I fail to see how they could possibly get that role in IPv4 address distribution now. I mean - what addresses would they be distributing? :-) Tore From alain.bidron at orange.com Wed Jul 31 23:07:47 2013 From: alain.bidron at orange.com (alain.bidron at orange.com) Date: Wed, 31 Jul 2013 23:07:47 +0200 Subject: [address-policy-wg] Policy proposal 2013-03 Message-ID: <20646_1375304869_51F97CA5_20646_13068_1_CA218F279863D84AA5DA653CFB425FCF7B1E51CCF6@PMEXCB1A.intranet-paris.francetelecom.fr> I object to the policy proposal 2013-03 2013- No Need - Post-Depletion Reality Adjustment and Clean up. I will not reiterate the arguments developed by Michele during the meeting in Dublin and on this list, and those clearly explained by Malcom. I agree with both of them. This proposal is in no way a post depletion adjustment, and clean up, it would dramatically change the basic principle in IPv4 management and would have a very strong impact on local management. Rather than simplifying the local management, it would make it even more difficult as the core principle is that existing and future assignments are based on needs. If this core principle is not part of the consistent set of policies to be applied by the LIRs, any management decision at local level would be questionable. We introduce here some instability, with potential impact on LIRs responsibilities. On the political side the consequences would also be quite problematic. Regards. Alain _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: