From Woeber at CC.UniVie.ac.at Sun Sep 8 15:34:59 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Sun, 08 Sep 2013 15:34:59 +0200 Subject: [address-policy-wg] Info from the Address Council, regarding AS# allocation by IANA Message-ID: <522C7D03.4030001@CC.UniVie.ac.at> Dear colleagues, for your information! A while ago the IANA submitted a question regarding the appropriate interpretation of the Global Policy on AS Number Allocation[1]; in particular, whether an allocation needs to be a contiguous block or may be a set of separate ranges, including a portion of the lower value range (legacy 16-bit range). After some discussion, the Address Council agreed (unanimously, in its meeting on June 5th, 2013[2]) on the following resolution: ?The AC answers IANA?s question regarding the allocation of 1024 AS Numbers as follows: There is no requirement in the policy to form the block of 1024 AS Numbers from a contiguous set of numbers, thus allocating from 2 or more different value-ranges is acceptable.? Best regards, Wilfried [1] https://www.icann.org/en/resources/policy/global-addressing/global-policy-asn-blocks-21sep10-en.htm http://aso.icann.org/global-policies/ [2] for clerical reasons, the (draft) minutes for the June 5th meeting have only become available in late August, thus the delay in reporting back to the Working Group and community. From ingrid at ripe.net Tue Sep 10 16:36:44 2013 From: ingrid at ripe.net (Ingrid Wijte) Date: Tue, 10 Sep 2013 16:36:44 +0200 Subject: [address-policy-wg] New AS Number Block allocated to the RIPE NCC Message-ID: <522F2E7C.5020009@ripe.net> Dear Colleagues, The RIPE NCC has received the following AS Number Block from the IANA in September 2013. 61952-62463 199680-200191 You may want to update your records accordingly. Best regards, Ingrid Wijte Registration Services Assistant Manager RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at Space.Net Thu Sep 19 13:22:14 2013 From: gert at Space.Net (Gert Doering) Date: Thu, 19 Sep 2013 13:22:14 +0200 Subject: [address-policy-wg] APWG agenda for RIPE 67 (Draft 1) Message-ID: <20130919112214.GA81889@Space.Net> Hi APWG folks, RIPE meeting orga, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Athens in the following time slots: Wednesday, Oct 16, 09:00 - 10:30 Wednesday, Oct 16, 11:00 - 12:30 If you have anything else you want to see on the agenda, or if we need to change anything, please let us know. The distribution of items to the two timeslot is somewhat subject to the time spent on discussion - but we'll try to stick to what's published. regards, Gert Doering, APWG chair ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters 5 min (welcome, thanking the scribe, approving the minutes, etc.) B. Current Policy Topics - Ingrid Wijte, NCC RS [15-20 min] - global policy overview "what's going on?" - common policy topics in all regions (end of IPv4, transfers, ...) - overview over concluded proposals in the RIPE region since RIPE66 * 2013-02 Removal of requirement for certification of reallocated IPv4 addresses -> consensus, and implemented - brief overview over new proposals (if any) D. Feedback From NCC Registration Service - Andrea Cima (NCC RS) [15-20 min] F. Discussion of open policy proposals [30-45 min] 2012-02 Policy for Inter-RIR transfers of IPv4 Address Space (update from the chair: where are we, what are the next steps) 2013-03 No Need - Post-Depletion Reality Adjustment and Cleanup 2013-05 No Restrictions on End User Assignments in Intra-RIR Transfers ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- F. Discussion of open policy proposals [30-45 min] 2013-06 PA/PI Unification IPv6 Address Space X. WG Chair Selection Procedure Define a process how the APWG (s)selects it's working group chair(s). (Tentative, if there is no time, this goes to the mailing list) Y. Open Policy Hour "The Open Policy Hour (OPH) is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity." Z. AOB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From mschmidt at ripe.net Thu Sep 19 16:44:38 2013 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 19 Sep 2013 16:44:38 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) Message-ID: Dear Colleagues, Following the feedback received, the draft documents for the proposal described in 2013-03 (No Need - Post-Depletion Reality Adjustment and Cleanup) are edited and published. The amendments are: - Retain "Fairness" goal - Retain "Need" for final /22 allocations - Clarify criteria for IXP assignment expansions The impact analysis that was conducted for this proposal has also been published. You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2013-03 and the draft document 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 address-policy-wg at ripe.net before 18 October 2013. Regards, Marco Schmidt Policy Development Office RIPE NCC From richih.mailinglist at gmail.com Thu Sep 19 18:07:38 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Thu, 19 Sep 2013 18:07:38 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: Dear all, I still support this proposal and have the slight hope that this will be the last time I will have to state this. Richard PS: For a unified diff between v2 and v3, see http://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-August/008155.html From andreas.larsen at ip-only.se Thu Sep 19 19:02:25 2013 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Thu, 19 Sep 2013 19:02:25 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: Message-ID: I support this with my whole heart and soul +1 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-09-19 18:07 skrev Richard Hartmann : >Dear all, > > >I still support this proposal and have the slight hope that this will >be the last time I will have to state this. > > > >Richard > >PS: For a unified diff between v2 and v3, see >http://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-August/00815 >5.html > From randy at psg.com Thu Sep 19 21:52:52 2013 From: randy at psg.com (Randy Bush) Date: Thu, 19 Sep 2013 09:52:52 -1000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) Message-ID: > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 18 October 2013. and once more unto the breach, dear friends, once more +1 From lists-ripe at c4inet.net Thu Sep 19 21:57:44 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Thu, 19 Sep 2013 20:57:44 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: Message-ID: <20130919195744.GA23831@cilantro.c4inet.net> On Thu, Sep 19, 2013 at 09:52:52AM -1000, Randy Bush wrote: >and once more unto the breach, dear friends, once more Damn, I wanted to write that ;p +1 also rgds, Sascha Luck From frettled at gmail.com Thu Sep 19 22:16:41 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Thu, 19 Sep 2013 22:16:41 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Thu, Sep 19, 2013 at 6:07 PM, Richard Hartmann < richih.mailinglist at gmail.com> wrote: > Dear all, > > > I still support this proposal and have the slight hope that this will > be the last time I will have to state this. > > I also support this proposal, for the first time for the last time. I hope. :) -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis at v4escrow.net Thu Sep 19 23:45:09 2013 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Thu, 19 Sep 2013 23:45:09 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: > On 19 Sep 2013, at 18:08, Richard Hartmann wrote: > > Dear all, > > > I still support this proposal and have the slight hope that this will > be the last time I will have to state this. +1 Elvis From swmike at swm.pp.se Fri Sep 20 10:27:51 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 20 Sep 2013 10:27:51 +0200 (CEST) Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <20130919144608.48E1E9C@uplift.swm.pp.se> References: <20130919144608.48E1E9C@uplift.swm.pp.se> Message-ID: On Thu, 19 Sep 2013, Marco Schmidt wrote: > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 18 October 2013. I fully support this proposal (as stated before in the discussion some months back). -- Mikael Abrahamsson email: swmike at swm.pp.se From stolpe at resilans.se Fri Sep 20 10:43:20 2013 From: stolpe at resilans.se (Daniel Stolpe) Date: Fri, 20 Sep 2013 10:43:20 +0200 (CEST) Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: Message-ID: On Thu, 19 Sep 2013, Randy Bush wrote: >> We encourage you to read the draft document text and send any comments >> to address-policy-wg at ripe.net before 18 October 2013. > > and once more unto the breach, dear friends, once more > > +1 +1 Cheers, 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 bengan at resilans.se Fri Sep 20 11:03:09 2013 From: bengan at resilans.se (=?ISO-8859-1?Q?Bengt_G=F6rd=E9n?=) Date: Fri, 20 Sep 2013 11:03:09 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <20130919195744.GA23831@cilantro.c4inet.net> References: <20130919195744.GA23831@cilantro.c4inet.net> Message-ID: <523C0F4D.7060305@resilans.se> 2013-09-19 21:57, Sascha Luck skrev: > On Thu, Sep 19, 2013 at 09:52:52AM -1000, Randy Bush wrote: >> and once more unto the breach, dear friends, once more > > Damn, I wanted to write that ;p > > +1 also > I'm favour of this proposal. +1 /bengan From raluca at adnettelecom.ro Fri Sep 20 11:36:59 2013 From: raluca at adnettelecom.ro (Raluca Andreea Gogioiu) Date: Fri, 20 Sep 2013 12:36:59 +0300 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523C0F4D.7060305@resilans.se> References: <20130919195744.GA23831@cilantro.c4inet.net> <523C0F4D.7060305@resilans.se> Message-ID: > 2013-09-19 21:57, Sascha Luck skrev: >> On Thu, Sep 19, 2013 at 09:52:52AM -1000, Randy Bush wrote: >>> and once more unto the breach, dear friends, once more >> >> Damn, I wanted to write that ;p >> >> +1 also >> > > I'm favour of this proposal. > +1 > > /bengan > > > +1 Kind regards, Raluca. From h.lu at anytimechinese.com Fri Sep 20 12:08:44 2013 From: h.lu at anytimechinese.com (Lu Heng) Date: Fri, 20 Sep 2013 12:08:44 +0200 Subject: [address-policy-wg] address-policy-wg Digest, Vol 25, Issue 4 In-Reply-To: References: Message-ID: +1 On Fri, Sep 20, 2013 at 12:00 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 Cleanup) > (Daniel Stolpe) > 2. Re: 2013-03 New Draft Document and Impact Analysis Published > (No Need - Post-Depletion Reality Adjustment and Cleanup) > (Bengt G?rd?n) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 20 Sep 2013 10:43:20 +0200 (CEST) > From: Daniel Stolpe > Subject: Re: [address-policy-wg] 2013-03 New Draft Document and Impact > Analysis Published (No Need - Post-Depletion Reality Adjustment and > Cleanup) > To: Randy Bush > Cc: address-policy-wg at ripe.net, policy-announce at ripe.net > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > On Thu, 19 Sep 2013, Randy Bush wrote: > > >> We encourage you to read the draft document text and send any comments > >> to address-policy-wg at ripe.net before 18 October 2013. > > > > and once more unto the breach, dear friends, once more > > > > +1 > > +1 > > Cheers, > > 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 > > > > > ------------------------------ > > Message: 2 > Date: Fri, 20 Sep 2013 11:03:09 +0200 > From: Bengt G?rd?n > Subject: Re: [address-policy-wg] 2013-03 New Draft Document and Impact > Analysis Published (No Need - Post-Depletion Reality Adjustment and > Cleanup) > To: address-policy-wg at ripe.net > Message-ID: <523C0F4D.7060305 at resilans.se> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > 2013-09-19 21:57, Sascha Luck skrev: > > On Thu, Sep 19, 2013 at 09:52:52AM -1000, Randy Bush wrote: > >> and once more unto the breach, dear friends, once more > > > > Damn, I wanted to write that ;p > > > > +1 also > > > > I'm favour of this proposal. > +1 > > /bengan > > > > > End of address-policy-wg Digest, Vol 25, Issue 4 > ************************************************ > -- -- Kind regards. Lu 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogerj at gmail.com Fri Sep 20 12:24:49 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Fri, 20 Sep 2013 12:24:49 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523b0e27.85680e0a.4dc4.ffffceefSMTPIN_ADDED_MISSING@mx.google.com> References: <523b0e27.85680e0a.4dc4.ffffceefSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Thu, Sep 19, 2013 at 4:44 PM, Marco Schmidt wrote: > > Dear Colleagues, > > Following the feedback received, the draft documents for the proposal > described in 2013-03 (No Need - Post-Depletion Reality Adjustment and Cleanup) > are edited and published. > supported -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From ml+ripe-list at x-net.be Fri Sep 20 12:40:38 2013 From: ml+ripe-list at x-net.be (Gerry Demaret) Date: Fri, 20 Sep 2013 12:40:38 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <523C2626.8000201@x-net.be> On 09/19/2013 06:07 PM, Richard Hartmann wrote: > I still support this proposal and have the slight hope that this will > be the last time I will have to state this. Support. Gerry From sylvain.vallerot at opdop.net Fri Sep 20 13:19:56 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Fri, 20 Sep 2013 13:19:56 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <20130919144556.ED13D11782@tools.opdop.net> References: <20130919144556.ED13D11782@tools.opdop.net> Message-ID: <523C2F5C.9000302@opdop.net> Hi all, Unfortunately we do not support this new proposal, because conservation still is a goal to us, as IPv4 public ressource keeps being vital for many structures. Deregulation + commercial transfer make the ressources governed by sole market, which we do not agree with. We consider Ripe NCC should stay in its regulation role and not give public ressources away to the private sector and market. Moreover, the rationale "supporting arguments" list doesn't convince us at all, let me be more explicit : 1. reduced bureaucracy : I do not consider proper use of ressources and justification as just "bureaucracy" but as a necessity to take good care 2. for long-term business planning: from 2 year to infinity ? is this serious, we are talking about IPv4 here ? 3. Makes the policy easier to read and understand are we stupid or something ? 4. Removes conflict between "conservation" and "aggregation" this cannot be a supporting argument, one does not just suppress a criteria to ease the problem 5. LIR Audits becomes less time-consuming properly made documentation should not take time to show for LIRs, and Ripe does not expect time spared for itself on the other side 6. Reduction of RIPE NCC workload or not : see impact analysis part C, that says no workload nor financial benefit is to be expected in the Ripe NCC. 7. Elimination of incentive to "game the system". supress rules so no ones will cheat them ? this is nonsense. 8. Makes IPv4 and IPv6 policies more similar in practise IPv4 and IPv6 are not similar, why should policies be ? Unfortunately counter-arguments have been provided for each "con" arguments. I deeply regret it was not done for "pro" arguments because many (above) do not resist a tiny bit of attention. Eventually, it was not mentionned (despite this was discussed previously) that the disappearance of the conservation goal could stop the unused space collection, thus artificially accelerating the depletion and its disastrous effects for some little structures. Best regards, Sylvain Vallerot From dogwallah at gmail.com Fri Sep 20 13:32:10 2013 From: dogwallah at gmail.com (McTim) Date: Fri, 20 Sep 2013 07:32:10 -0400 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523C2626.8000201@x-net.be> References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> Message-ID: I am opposed. I don't think shifting to a market based allocation/assignment system is good stewardship. In addition there are multiple issues listed in the Impact Analysis that cause me great concern. The primary issue there is incompatibility with other regional transfer policies. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel On Fri, Sep 20, 2013 at 6:40 AM, Gerry Demaret wrote: > On 09/19/2013 06:07 PM, Richard Hartmann wrote: >> >> I still support this proposal and have the slight hope that this will >> be the last time I will have to state this. > > > Support. > > Gerry > From tore at fud.no Fri Sep 20 14:27:46 2013 From: tore at fud.no (Tore Anderson) Date: Fri, 20 Sep 2013 14:27:46 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523C2F5C.9000302@opdop.net> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> Message-ID: <523C3F42.3080404@fud.no> Hi Sylvain, I in order to keep the discussion on topic, I will only respond to the arguments you make against the proposal itself. I think it is to be expected that the various arguments in favour of the proposal will resonate differently with different people. Even if you may feel that some of them are not at all applicable, that does not mean that they become arguments against. > Unfortunately we do not support this new proposal, because conservation > still is a goal to us, as IPv4 public ressource keeps being vital for > many structures. Conservation is the natural behaviour in an environment of scarcity. This proposal does not compel the LIRs to stop conserving their remaining stock of IPv4 addresses (if any), it merely gives them the freedom to choose exactly how their conservation model looks like. No sensible LIR will respond to 2013-03 by immediately assigning away its remaining stock to the first End User to pass by. And, even if that happens, the non-sensible LIR in question has only done damage to itself. The rest of us are not impacted by its nonsensical behaviour. > Deregulation + commercial transfer make the ressources governed by sole > market, which we do not agree with. We consider Ripe NCC should stay in > its regulation role and not give public ressources away to the private > sector and market. The transfer policy is in place already. If you oppose a commercial transfer market, 2013-03 is the wrong policy proposal to attack, it is really 2007-08 you should be going after. On your second point, I would like to stress that 2013-03 version 3 does ensure that the NCC's distribution of IPv4 address space stays the same as right now: If you want your last /22, you'll have to use it for making assignments; and if you're an IXP and want something larger than a /24, you'll have to demonstrate the operational need for it. Also, I think it is worth noting that "giving public resources away" is and has always been one of the (perhaps "the") primary functions of the NCC. This is true even when the recipient is a private sector LIR who might at a later time choose to sell the resource on the IPv4 market. This is how things are today. 2013-03 does not change it one way or the other. If you want to prohibit private sector entities from being eligible from receiving resources from the NCC, you are free to submit a proposal that does just that. If you want to undo 2007-08 and thus retire the IPv4 market, you are free to submit a proposal that does just that too. But please leave those topics out of the 2013-03 thread. > 1. reduced bureaucracy : > > I do not consider proper use of ressources and justification as > just "bureaucracy" but as a necessity to take good care As above, if you feel that the current forms and paperwork is matching your LIR's requirements perfectly, you are completely at liberty to continue using those exact same forms post 2013-03. Nobody is attempting to take your current forms and operational procedures away from you. Indeed, you are free to ignore this proposal completely and continue running your LIR exactly as you have done before. > Eventually, it was not mentionned (despite this was discussed > previously) that the disappearance of the conservation goal could > stop the unused space collection, thus artificially accelerating > the depletion and its disastrous effects for some little structures. The RIPE NCC does not actively "collect unused space", beyond accepting anything that is being voluntarily returned to them or is left orphaned by closing LIRs (and it will continue to do exactly that post 2013-03). Furthermore, depletion is a past event in the RIPE region. It cannot be "accelerated" (or "stopped"). The only thing that remains is the so-called "last /8" austerity pool, and as I've pointed out above, 2013-03 upholds the conservation policies covering this pool intact (1 /22 per LIR; 1 /24-/22 per IXP). Best regards, Tore Anderson From tore at fud.no Fri Sep 20 14:47:11 2013 From: tore at fud.no (Tore Anderson) Date: Fri, 20 Sep 2013 14:47:11 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> Message-ID: <523C43CF.9070708@fud.no> Hello McTim, > I don't think shifting to a market based allocation/assignment system > is good stewardship. As I've mentioned in my reply to Sylvain Vallerot already, 2013-03 does not cause the founding of an IPv4 market. The IPv4 market is already in place and its existence is sanctioned by the RIPE NCC: http://www.ripe.net/lir-services/resource-management/listing http://www.ripe.net/lir-services/resource-management/ipv4-transfers/brokers http://www.ripe.net/lir-services/resource-management/ipv4-transfers/table-of-transfers > In addition there are multiple issues listed in the Impact Analysis > that cause me great concern. The primary issue there is > incompatibility with other regional transfer policies. 2013-03's proposed policy is no more or less compatible with other regional transfer policies than our current policy is. They are both one hundred percent incompatible, because there is no inter-regional transfer policy in place in the RIPE region to begin with, and this situation does not seem likely to change anytime soon. If we in the RIPE community decide one day that we do want an inter-regional transfer policy after all, we could very well create it so that it ensures perfect compatibility with all other regions' policies. Even if that in the extreme case would mean reverting 2013-03 word by word. Best regards, Tore Anderson From gert at space.net Fri Sep 20 15:36:17 2013 From: gert at space.net (Gert Doering) Date: Fri, 20 Sep 2013 15:36:17 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> Message-ID: <20130920133617.GA65295@Space.Net> Hi, On Fri, Sep 20, 2013 at 07:32:10AM -0400, McTim wrote: > In addition there are multiple issues listed in the Impact Analysis > that cause me great concern. The primary issue there is > incompatibility with other regional transfer policies. Yeah, that statement filled my heart with lots of joy as well. As Tore pointed out, as we do not have a cross-region transfer policy yet, we are 100 per cent incompatible with all other regions *right now*, and 2013-03 is not changing this. If this working group shold ever start having an interest in a cross-region transfer policy (there is an open policy proposal for that, 2012-02, which is hanging in limbo because of massive disinterest(!) from this community) it would not be hard to add provisions to *that* proposal to ensure the necessary compatibility. For example, if one wants to permit transfers from the ARIN region and ARIN at that time still insists on having a needs-based policy on the receiving end, it would be possible to have a policy on our side that gives receiving parties the option to undergo a needs assessment by the RIPE NCC to have documented need where needed. For the record, I'm going to consider the objection "2013-03 is incompatible with cross-region transfers" as fully addressed when judging consensus. 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 (0)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 dogwallah at gmail.com Fri Sep 20 16:22:07 2013 From: dogwallah at gmail.com (McTim) Date: Fri, 20 Sep 2013 10:22:07 -0400 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523C43CF.9070708@fud.no> References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> <523C43CF.9070708@fud.no> Message-ID: Hi Tore, On Fri, Sep 20, 2013 at 8:47 AM, Tore Anderson wrote: > Hello McTim, > >> I don't think shifting to a market based allocation/assignment system >> is good stewardship. > > As I've mentioned in my reply to Sylvain Vallerot already, 2013-03 does > not cause the founding of an IPv4 market. I understand this, however that was not my point. Apologies if I was unclear. What I was trying to get across is that this proposal would go from a system of "pay your membership fees and show you actually need the resources" to just "pay". Needs based distribution has been a cornerstone of the RIR system for the last 2 decades or more. It has worked remarkably well, and I see no need to jettison it now just because there are fewer resources to distribute. In fact, I see a greater need for it now! I expect we will have to agree to disagree on this. > >> In addition there are multiple issues listed in the Impact Analysis >> that cause me great concern. The primary issue there is >> incompatibility with other regional transfer policies. > > 2013-03's proposed policy is no more or less compatible with other > regional transfer policies than our current policy is. While from a certain POV, this may be true, this proposal precludes the RIPE region from compatibility in future (unless one does something like Gert proposes downthread. I think this is not wise public policy making. You surely know that APNIC has already reversed their rejection of needs based allocation. I don't think it smart for us to do something that we will perhaps need to undo shortly. Now I am NOT anti-market in general, nor do I seek to rollback the current state of the v4 market. however, I think a true free-marketeer would be opposed to this policy because it precludes future inter-regional transfers. I don't understand why the brokers aren't opposing this, I guess they hate needs based allocation more than they want to make money on transfers down the road? -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From gert at space.net Fri Sep 20 16:36:56 2013 From: gert at space.net (Gert Doering) Date: Fri, 20 Sep 2013 16:36:56 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> <523C43CF.9070708@fud.no> Message-ID: <20130920143656.GI65295@Space.Net> Hi, On Fri, Sep 20, 2013 at 10:22:07AM -0400, McTim wrote: > I think this is not wise public policy making. You surely know that > APNIC has already reversed their rejection of needs based allocation. > I don't think it smart for us to do something that we will perhaps > need to undo shortly. We're neither APNIC nor ARIN here, so not everything that these RIRs do or like to do applies to us. The RIPE community needs to find their own way, without shying away from something other regions didn't dare go go to. If *we* do not want to go there, fine, but not for "the other ones don't do that either" reasons - and from what I see so far regarding feedback from people from the RIPE region, we seem to want to go there. 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 (0)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 Fri Sep 20 16:53:34 2013 From: tore at fud.no (Tore Anderson) Date: Fri, 20 Sep 2013 16:53:34 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> <523C43CF.9070708@fud.no> Message-ID: <523C616E.5050507@fud.no> * McTim > Apologies if I was unclear. What I was trying to get across is that > this proposal would go from a system of "pay your membership fees > and show you actually need the resources" to just "pay". > > Needs based distribution has been a cornerstone of the RIR system > for the last 2 decades or more. It has worked remarkably well, and I > see no need to jettison it now just because there are fewer resources > to distribute. In fact, I see a greater need for it now! I expect > we will have to agree to disagree on this. This exact point was brought up by a few other people as well as the NCC itself in the first review period, and in order to meet those concerns the proposal was amended so that it does not longer make it possible to simply pay the membership fee and receive an allocation from the RIR without "need". I'd like to make it crystal clear that the proposal has no ambition whatsoever to change how the RIR distributes its last remaining scraps of address space, and the 2nd and 3rd amendments was developed in collaboration with the NCC precisely in order to prevent that from happening as an accidental side-effect, see: http://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-August/008155.html I note that you neglected to respond to this message even though I clearly asked for any remaining material objections to be raised *before* the amended proposal was returned to the NCC. Waiting until now with voicing your objections is quite frankly wasting everyone's time, most of all the good folks at the NCC's time, who have been working on the new IA for more than a month now. Best regards, Tore Anderson (BTW: Since the Chair closed the inter-region transfer topic, I'll not continue that discussion on the list. If you wish I'll be happy to continue off-list, though, just shoot me a direct message and I'll respond as best as I can.) From sid at free.net Fri Sep 20 16:02:29 2013 From: sid at free.net (Dimitri I Sidelnikov) Date: Fri, 20 Sep 2013 18:02:29 +0400 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: Message-ID: <523C5575.4030108@free.net> 19.09.2013 23:52, Randy Bush ?????: > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 18 October 2013. I support the draft. -- Kind regards, --- D.Sidelnikov From dogwallah at gmail.com Fri Sep 20 18:10:15 2013 From: dogwallah at gmail.com (McTim) Date: Fri, 20 Sep 2013 12:10:15 -0400 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523C616E.5050507@fud.no> References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> <523C43CF.9070708@fud.no> <523C616E.5050507@fud.no> Message-ID: Tore, On Fri, Sep 20, 2013 at 10:53 AM, Tore Anderson wrote: > * McTim > >> Apologies if I was unclear. What I was trying to get across is that >> this proposal would go from a system of "pay your membership fees >> and show you actually need the resources" to just "pay". >> >> Needs based distribution has been a cornerstone of the RIR system >> for the last 2 decades or more. It has worked remarkably well, and I >> see no need to jettison it now just because there are fewer resources >> to distribute. In fact, I see a greater need for it now! I expect >> we will have to agree to disagree on this. > > This exact point was brought up by a few other people as well as the NCC > itself in the first review period, and in order to meet those concerns > the proposal was amended so that it does not longer make it possible to > simply pay the membership fee and receive an allocation from the RIR > without "need". I consider the check box yes/no "I will be making assignments.." a fig leaf at best. You can see my reasoning on the topic of need here: http://www.circleid.com/posts/the_invisible_hand_vs_the_public_interest_in_ipv4_address_distribution/ So the proposal retains "need", but is title "No need"? > > I'd like to make it crystal clear that the proposal has no ambition > whatsoever to change how the RIR distributes its last remaining scraps > of address space, and the 2nd and 3rd amendments was developed in > collaboration with the NCC precisely in order to prevent that from > happening as an accidental side-effect, see: > > http://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-August/008155.html > > I note that you neglected to respond to this message even I had thought I had, maybe not. though I > clearly asked for any remaining material objections to be raised > *before* the amended proposal was returned to the NCC. Waiting until now > with voicing your objections is quite frankly wasting everyone's time, That is not my intent. My intent was to respond to Marco's message asking for comments. > most of all the good folks at the NCC's time, who have been working on > the new IA for more than a month now. > > Best regards, > Tore Anderson > > (BTW: Since the Chair closed the inter-region transfer topic, I'll not > continue that discussion on the list. If you wish I'll be happy to > continue off-list, though, just shoot me a direct message and I'll > respond as best as I can.) I don't think the chair has the prerogative to close a topic. If the intent of your proposal is to retain need, then the inter-RIR transfer issue is moot. However, I am not sure the IPRAs from another region may see the check box as "compatible". In other words, I still think it is a flaw, even thought the chair might think it "fully addressed" (pun intended?). -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From tore at fud.no Fri Sep 20 18:46:39 2013 From: tore at fud.no (Tore Anderson) Date: Fri, 20 Sep 2013 18:46:39 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> <523C43CF.9070708@fud.no> <523C616E.5050507@fud.no> Message-ID: <523C7BEF.8010201@fud.no> * McTim > On Fri, Sep 20, 2013 at 10:53 AM, Tore Anderson wrote: >> This exact point was brought up by a few other people as well as the NCC >> itself in the first review period, and in order to meet those concerns >> the proposal was amended so that it does not longer make it possible to >> simply pay the membership fee and receive an allocation from the RIR >> without "need". > > I consider the check box yes/no "I will be making assignments.." a fig > leaf at best. Perhaps it is, but for all practical purposes, it's the status quo: To get hold of a /22 with our current policy, you'll have to sign up as an LIR and pay the membership fee, and then be able to say with a straight face that you need it for making an assignment of one (1) IPv4 address (singular). Most of us carry around the hardware needed to truthfully justify such an assignment at all times. > So the proposal retains "need", but is title "No need"? The proposal is not about corner cases such as the "last /8" austerity pool and the NCC's distribution of it; it is about the LIRs and their day to day operations. This is where pretty much all the remaining IPv4 activity is at today, and it is where all the "need bureaucracy" this proposal is aiming to remove at is still mandated to take place. Best regards, Tore Anderson From frettled at gmail.com Fri Sep 20 18:49:22 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Fri, 20 Sep 2013 18:49:22 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> <523C43CF.9070708@fud.no> <523C616E.5050507@fud.no> Message-ID: On Fri, Sep 20, 2013 at 6:10 PM, McTim wrote: > > > I consider the check box yes/no "I will be making assignments.." a fig > leaf at best. You can see my reasoning on the topic of need here: > > http://www.circleid.com/posts/the_invisible_hand_vs_the_public_interest_in_ipv4_address_distribution/ > > I don't quite see how this reasoning is relevant to the proposal and discussion about it that we've had here in this WG. There are a few strawmen there on which you seem to base your reasoning (profiteering, free-market philosophies, Ayn Rand, invisible hand ?), but I don't recognize them in what we've discussed. Your blog post from 2011 therefore seems at best somewhat off the mark. As a fairly fresh member of the list, I would therefore find it far more useful to understand your objections if they came in context of the discussion we've had, rather than other people's hypothetical arguments. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From richih.mailinglist at gmail.com Fri Sep 20 19:05:10 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 20 Sep 2013 19:05:10 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> <523C43CF.9070708@fud.no> <523C616E.5050507@fud.no> Message-ID: On Fri, Sep 20, 2013 at 6:10 PM, McTim wrote: >> http://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-August/008155.html >> >> I note that you neglected to respond to this message even > > I had thought I had, maybe not. No offense, but I see a certain recurring pattern in the discussion about 2013-03. > I don't think the chair has the prerogative to close a topic. http://ripe61.ripe.net/presentations/183-apwg-r61-steering-slides.pdf http://en.wikipedia.org/wiki/Rough_consensus http://tools.ietf.org/html/draft-resnick-on-consensus-00 - section 3 Quite frankly, from my POV, the chairs have been extremely accommodating up to now. If anything, this shows how much they value these principles above and beyond what would be required of them. As per Tore's suggestion, please take this off-list. Richard From gert at space.net Fri Sep 20 20:17:55 2013 From: gert at space.net (Gert Doering) Date: Fri, 20 Sep 2013 20:17:55 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> <523C43CF.9070708@fud.no> <523C616E.5050507@fud.no> Message-ID: <20130920181755.GL65295@Space.Net> Hi, On Fri, Sep 20, 2013 at 12:10:15PM -0400, McTim wrote: > > (BTW: Since the Chair closed the inter-region transfer topic, I'll not > > continue that discussion on the list. If you wish I'll be happy to > > continue off-list, though, just shoot me a direct message and I'll > > respond as best as I can.) > > I don't think the chair has the prerogative to close a topic. I do have the prerogative to ignore certain topics voiced as reason for opposition to a proposal if I consider them suitably addressed, and there is sufficient support for a proposal otherwise. This is what I did: I consider this point to be suitably addressed, given the very specific fact that we do not have a cross-RIR transfer policy today, and this community has not shown interest in working on one. If we start working on a cross-RIR transfer policy, I am very sure our friends from ARIN will help us in determining what they consider a suitable documentation of need to permit a transfer. 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 (0)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 jcurran at arin.net Fri Sep 20 20:57:12 2013 From: jcurran at arin.net (John Curran) Date: Fri, 20 Sep 2013 18:57:12 +0000 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <20130920181755.GL65295@Space.Net> References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> <523C43CF.9070708@fud.no> <523C616E.5050507@fud.no> <20130920181755.GL65295@Space.Net> Message-ID: <207F6C43-A40B-48D7-9C97-4C836F11D327@corp.arin.net> On Sep 20, 2013, at 2:17 PM, Gert Doering wrote: > > If we start working on a cross-RIR transfer policy, I am very sure our > friends from ARIN will help us in determining what they consider a suitable > documentation of need to permit a transfer. Correct - ARIN follows the RIPE address policy working group mailing list and will respond to any question directed to us regarding transfers to/from ARIN and the applicable policy. Best wishes on your policy discussions! /John John Curran President and CEO ARIN From randy at psg.com Fri Sep 20 21:09:18 2013 From: randy at psg.com (Randy Bush) Date: Fri, 20 Sep 2013 09:09:18 -1000 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> Message-ID: > In addition there are multiple issues listed in the Impact Analysis > that cause me great concern. The primary issue there is > incompatibility with other regional transfer policies. if homogenous policy was a goal, why do we need separate RIRs? randy From randy at psg.com Fri Sep 20 21:11:13 2013 From: randy at psg.com (Randy Bush) Date: Fri, 20 Sep 2013 09:11:13 -1000 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <20130920181755.GL65295@Space.Net> References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> <523C43CF.9070708@fud.no> <523C616E.5050507@fud.no> <20130920181755.GL65295@Space.Net> Message-ID: > If we start working on a cross-RIR transfer policy, I am very sure > our friends from ARIN will help us in determining what they consider > a suitable documentation of need to permit a transfer. congratulations. you have just won the dripping sarcasm award of the month. absolutely brilliant! randy From koalafil at gmail.com Fri Sep 20 21:37:51 2013 From: koalafil at gmail.com (Filiz Yilmaz) Date: Fri, 20 Sep 2013 21:37:51 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523C7BEF.8010201@fud.no> References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> <523C43CF.9070708@fud.no> <523C616E.5050507@fud.no> <523C7BEF.8010201@fud.no> Message-ID: <35E712B6-050B-4904-A37C-FDDA1B6EEB4C@gmail.com> Hello, On 20 Sep 2013, at 18:46, Tore Anderson wrote: > * McTim > >> On Fri, Sep 20, 2013 at 10:53 AM, Tore Anderson wrote: >>> This exact point was brought up by a few other people as well as the NCC >>> itself in the first review period, and in order to meet those concerns >>> the proposal was amended so that it does not longer make it possible to >>> simply pay the membership fee and receive an allocation from the RIR >>> without "need". >> >> I consider the check box yes/no "I will be making assignments.." a fig >> leaf at best. > > Perhaps it is, but for all practical purposes, it's the status quo: To > get hold of a /22 with our current policy, you'll have to sign up as an > LIR and pay the membership fee, and then be able to say with a straight > face that you need it for making an assignment of one (1) IPv4 address > (singular). Most of us carry around the hardware needed to truthfully > justify such an assignment at all times. > >> So the proposal retains "need", but is title "No need"? > > The proposal is not about corner cases such as the "last /8" austerity > pool and the NCC's distribution of it; it is about the LIRs and their > day to day operations. This is where pretty much all the remaining IPv4 > activity is at today, and it is where all the "need bureaucracy" this > proposal is aiming to remove at is still mandated to take place. > I had read the two paragraphs above again and again, and I cannot see how they work hand in hand in support of the proposal: So the proposal is to remove some heavy "bureaucracy" (because if it was not heavy, we would not need a change, right?) which at the same time is (according to the 2nd paragraph) as easy as basically "keeping a straight face while justifying the assignment of 1 single IP"? I cannot parse these two in one support argument for the proposal. So what is the goal of this proposal really? I went through the new Rationale of this version and here is what I have to say: ------ proposal says: 1. Reduced bureaucracy: Under the proposed policy, End Users, sub-allocation holders, and LIRs will no longer be required to document their need for IPv4 addresses in order to receive PA assignments, sub-allocations, or (transferred) PA allocations. ------- I agree it can be seen as bureaucracy to ask people to justify PA assignments and sub-allocations now. However, I am not convinced that asking justifying 1 IP from a /22 as a new LIR at this very interesting times is a big deal. And removing a long-standing principle like "need based" should require a better argument than reducing bureaucracy. This is what I think, I do not expect everyone to agree. But this was my main (almost the sole) objection in the 2nd version of this proposal too and so it remains in the 3rd version too. Accordingly, I cannot support removing need justification from "allocation" requesters. I am fine, I repeat I am fine, removing it from assignments and sub-allocations (consensus hint???) ---- proposal says: 2. Allows for long-term business planning. Under the proposed policy, the need-based time period will be raised from the current one/two years (allocation/assignments) to essentially infinity. ----- I do not see this as a supporting argument to the proposal itself. I think it is just irrelevant. No one has any idea what their network will be like in 100 years. Anything that can be rational will be based in the next one/two years which the current text is reflecting already. ------ proposal says: 3. Makes the policy easier to read and understand. ------ This is nothing to do with the content of the proposal. Obviously any adequate policy document (resulting out of this proposal or not) should be easy to read, I agree, still sticking to my main objection stated above. ------ proposal says: 4. Removes conflict between "conservation" and "aggregation". ------ This is just wording. The proposal can obviously not remove the conflict between conservation and aggregation, if any network admin is there to feel it. But the proposal removes the text about these from the policy, yes, but it is not a Rationale to me. ------ proposal says: 5/6. LIR Audits becomes less time-consuming and Reduction of RIPE NCC workload. ------ These are procedural NCC issues, I've already commented regarding reducing bureaucracy with the NCC, without doing a main curriery in the policy before. These two are not real address policy management related, they are "consequences" of the proposal, rather than positive or negative Rationales ------ proposal says: 7. Elimination of incentive to "game the system". ... By removing the need-based requirements, the playing field becomes level and fair for everyone involved, and will become impossible to get ahead by cheating. ------ I do not agree with the content of this statement. By removing the need-based requirements, the playing field becomes level for everyone, but this does not bring "fairness" at all. It only makes it less painful for those who dare or wishes to play unfair, in my opinion. I cannot support any proposal suggesting this in principle. ----- proposal says: 8. Makes IPv4 and IPv6 policies more similar in practise ?. By removing the need principle from the IPv4 policy, it will become more similar to the IPv6 policy in practise, in the sense that need justification will not be mandated for the vast majority of delegations. ----- I am having trouble parsing this sentence, but the question stands; Why is this a good thing to stand as a Rationale, especially that currently IPv4 and IPv6 are separate pool of resources with separate set of problems? I do hope I have my points clearly stated (this time around too). Finally I would like to say ideal policy should, in my opinion, reflect what is the good practice while it is a safe net for all the good practice, it is not so safe for the bad practice, so that such bad practice can be highlighted instead of getting lost and unnoticed among the good ones. In that sense, I believe "need-based" policies did a good job so far for such filtering and I support keeping them in our system as long as there is some pool that the RIPE NCC can allocate from to the new entrants of the system. Kind regards Filiz > Best regards, > Tore Anderson > From farmer at umn.edu Fri Sep 20 22:21:39 2013 From: farmer at umn.edu (David Farmer) Date: Fri, 20 Sep 2013 15:21:39 -0500 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523C2F5C.9000302@opdop.net> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> Message-ID: <523CAE53.9090508@umn.edu> +1 to every thing Sylvain said, and -1 to proposal. On 9/20/13 06:19 , Sylvain Vallerot wrote: > > Hi all, > > Unfortunately we do not support this new proposal, because conservation > still is a goal to us, as IPv4 public ressource keeps being vital for > many structures. > > Deregulation + commercial transfer make the ressources governed by sole > market, which we do not agree with. We consider Ripe NCC should stay in > its regulation role and not give public ressources away to the private > sector and market. > > > Moreover, the rationale "supporting arguments" list doesn't convince us > at all, let me be more explicit : > > 1. reduced bureaucracy : > > I do not consider proper use of ressources and justification as > just "bureaucracy" but as a necessity to take good care > > 2. for long-term business planning: from 2 year to infinity ? > > is this serious, we are talking about IPv4 here ? > > 3. Makes the policy easier to read and understand > > are we stupid or something ? > > 4. Removes conflict between "conservation" and "aggregation" > > this cannot be a supporting argument, one does not just suppress > a criteria to ease the problem > > 5. LIR Audits becomes less time-consuming > > properly made documentation should not take time to show for LIRs, > and Ripe does not expect time spared for itself on the other side > > 6. Reduction of RIPE NCC workload > > or not : see impact analysis part C, that says no workload nor > financial benefit is to be expected in the Ripe NCC. > > 7. Elimination of incentive to "game the system". > > supress rules so no ones will cheat them ? this is nonsense. > > 8. Makes IPv4 and IPv6 policies more similar in practise > > IPv4 and IPv6 are not similar, why should policies be ? > > Unfortunately counter-arguments have been provided for each "con" > arguments. I deeply regret it was not done for "pro" arguments > because many (above) do not resist a tiny bit of attention. > > Eventually, it was not mentionned (despite this was discussed > previously) that the disappearance of the conservation goal could > stop the unused space collection, thus artificially accelerating > the depletion and its disastrous effects for some little structures. > > Best regards, > Sylvain Vallerot > > -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From farmer at umn.edu Fri Sep 20 22:25:39 2013 From: farmer at umn.edu (David Farmer) Date: Fri, 20 Sep 2013 15:25:39 -0500 Subject: [address-policy-wg] Fwd: Re: 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523CAE4B.8020100@umn.edu> References: <523CAE4B.8020100@umn.edu> Message-ID: <523CAF43.4050909@umn.edu> Sorry this should have went to the list. -------- Original Message -------- Subject: Re: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) Date: Fri, 20 Sep 2013 15:21:31 -0500 From: David Farmer Reply-To: David Farmer Organization: University of Minnesota To: Tore Anderson CC: David Farmer On 9/20/13 07:27 , Tore Anderson wrote: > Hi Sylvain, ... >> Deregulation + commercial transfer make the ressources governed by sole >> market, which we do not agree with. We consider Ripe NCC should stay in >> its regulation role and not give public ressources away to the private >> sector and market. > > The transfer policy is in place already. If you oppose a commercial > transfer market, 2013-03 is the wrong policy proposal to attack, it is > really 2007-08 you should be going after. You are obfuscating and trivializing Sylvain's objection. He didn't say that he doesn't support the transfer market. He said he doesn't support your "deregulation" of the transfer market, which I interpret as removal of justification of need for transfers. And, yes the transfer market is a reality as of 2007-08, but this proposal does very much change the status quo, that is deregulating the transfer market by removing justification of need for transfers. > On your second point, I would like to stress that 2013-03 version 3 does > ensure that the NCC's distribution of IPv4 address space stays the same > as right now: If you want your last /22, you'll have to use it for > making assignments; and if you're an IXP and want something larger than > a /24, you'll have to demonstrate the operational need for it. > > Also, I think it is worth noting that "giving public resources away" is > and has always been one of the (perhaps "the") primary functions of the > NCC. This is true even when the recipient is a private sector LIR who > might at a later time choose to sell the resource on the IPv4 market. > This is how things are today. 2013-03 does not change it one way or the > other. > > If you want to prohibit private sector entities from being eligible from > receiving resources from the NCC, you are free to submit a proposal that > does just that. If you want to undo 2007-08 and thus retire the IPv4 > market, you are free to submit a proposal that does just that too. But > please leave those topics out of the 2013-03 thread. Again you are obfuscating and trivializing his objection. The RIPE NCC doesn't just "giving public resources away", the primary cost is the justification of those resources. Or, the cost of dealing with the "bureaucracy" that you want to eliminate, that is not free, which is why you want to eliminate it. Please stop obfuscating and trivializing people's objections, you either have sufficient support to ignore their objections or you should address them properly. Thank you. -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From tore at fud.no Fri Sep 20 22:42:17 2013 From: tore at fud.no (Tore Anderson) Date: Fri, 20 Sep 2013 22:42:17 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <35E712B6-050B-4904-A37C-FDDA1B6EEB4C@gmail.com> References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> <523C43CF.9070708@fud.no> <523C616E.5050507@fud.no> <523C7BEF.8010201@fud.no> <35E712B6-050B-4904-A37C-FDDA1B6EEB4C@gmail.com> Message-ID: <523CB329.6060103@fud.no> Hi again Filiz, > So the proposal is to remove some heavy "bureaucracy" (because if it > was not heavy, we would not need a change, right?) which at the same > time is (according to the 2nd paragraph) as easy as basically > "keeping a straight face while justifying the assignment of 1 single > IP"? You are comparing apples to oranges here (allocations to assignments). The "easy" part is to document "need" enough to get an *allocation* from the NCC. "Need" for allocations comes from one thing only: Intent to make assignments. If you can document an intent to make a valid assignment for one (1) IPv4 address, you have a valid need for an allocation. Following the implementation of the last /8 policy, there is only one size allocation the NCC can delegate to its members (/22). Thus, by submitting a ripe-583 form documenting an intended assignment of 1 IPv4 address (or a /32 if you prefer), you have also automatically qualified for your initial and final /22 allocation. Anyone can do that, it is not heavy bureaucracy at all. The "heavy bureaucracy" part comes when an LIR is about to make a real assignment to an End User. The NCC isn't involved at all in this process (unless the assignment is larger than the AW). For example, say you have a meeting with a new customer who spends a few hours explaining how their network looks like, is subnetted, and how it all works and so on and so on, and you both agree that a /21 looks like a good fit for them. The bureaucracy kicks into play when you finish the meeting by telling them "now you have to just repeat everything you've just told me, translate it into English, and type it into this ripe-583 form so that I can archive it in case I am selected by the NCC for an LIR Audit". Who benefits from the time the customer (or the LIR, on the customer's behalf) spends doing this paperwork? As far as I can tell, nobody. > Accordingly, I cannot support removing need justification from > "allocation" requesters. As described above, this is not being removed. Since an assignment must be sized at least 1 address (or larger), a check-box requiring the requesting LIR to confirm assignments will be made from the allocation is functionally identical to today's current practise. > I am fine, I repeat I am fine, removing it from assignments and > sub-allocations (consensus hint???) That's really what this proposal is all about! :-) > proposal says: 2. Allows for long-term business planning. Under the > proposed policy, the need-based time period will be raised from the > current one/two years (allocation/assignments) to essentially > infinity. > ----- > I do not see this as a supporting argument to the proposal itself. I > think it is just irrelevant. No one has any idea what their network > will be like in 100 years. Anything that can be rational will be > based in the next one/two years which the current text is reflecting > already. Try substituting "essentially infinity" with "more than two years", which is really what is meant here. If the customer in the example above signs a three-year contract with my LIR and expects a gradual growth in address consumption over the contract period, I would like to be able to make an assignment that is expected to last them for their entire contract period, instead of re-doing the need bureaucracy once or twice during the contract period, avoid having to ask them to renumber into the larger assignments they got half-way through, etc. > proposal says: 3. Makes the policy easier to read and understand. > ------ > This is nothing to do with the content of the proposal. I'll limit myself to one example here, although I could go on for quite some time. These two quotes are taken straight from ripe-592, our current policy document: 1) The RIPE NCC's minimum allocation size is /21. 2) The size of the allocation made under this policy will be exactly one /22. 2013-03 changes them to: 1) The RIPE NCC's minimum allocation size is /22. 2) The size of the allocation made will be exactly one /22. I hope I do not need to elaborate on why I feel this is one valid example of how 2013-03 makes the policy easier to read and understand. > proposal says: 5/6. LIR Audits becomes less time-consuming and > Reduction of RIPE NCC workload. > ------ > These are procedural NCC issues, I've already commented regarding > reducing bureaucracy with the NCC, without doing a main curriery in > the policy before. These two are not real address policy management > related, they are "consequences" of the proposal, rather than > positive or negative Rationales It's positive consequence, yes. That is what this point in the rationale is trying to convey. (The word "Rationale" comes from the policy proposal template (ripe-500) by the way, not from the proposal itself. While I'm not a native speaker, I do think it's being used appropriately.) > ... By removing the need-based requirements, the playing field > becomes level and fair for everyone involved, and will become > impossible to get ahead by cheating. ------ > > I do not agree with the content of this statement. By removing the > need-based requirements, the playing field becomes level for > everyone, but this does not bring "fairness" at all. It only makes it > less painful for those who dare or wishes to play unfair, in my > opinion. I cannot support any proposal suggesting this in principle. Perhaps the use of the word "fair" was not ideal here, as this is a rather subjective term. I believe that accomplishing "fairness" in our current state of scarcity is near impossible, 2013-03 or no 2013-03. Absent something we can objectively call a fair playing field, however, I think a level playing field is better than what we have today. > proposal says: 8. Makes IPv4 and IPv6 policies more similar in > practise ?. By removing the need principle from the IPv4 policy, it > will become more similar to the IPv6 policy in practise, in the sense > that need justification will not be mandated for the vast majority of > delegations. ----- > > I am having trouble parsing this sentence, but the question stands; > Why is this a good thing to stand as a Rationale, especially that > currently IPv4 and IPv6 are separate pool of resources with separate > set of problems? While IPv4 and IPv6 are not the same, they are still quite similar. "96 more bits, no magic." Having similar polices makes it easier to relate to them both. Best regards, Tore Anderson From tore at fud.no Fri Sep 20 23:13:13 2013 From: tore at fud.no (Tore Anderson) Date: Fri, 20 Sep 2013 23:13:13 +0200 Subject: [address-policy-wg] Fwd: Re: 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523CAF43.4050909@umn.edu> References: <523CAE4B.8020100@umn.edu> <523CAF43.4050909@umn.edu> Message-ID: <523CBA69.50704@fud.no> * David Farmer > You are obfuscating and trivializing Sylvain's objection. He didn't say > that he doesn't support the transfer market. He said he doesn't support > your "deregulation" of the transfer market, which I interpret as removal > of justification of need for transfers. And, yes the transfer market is > a reality as of 2007-08, but this proposal does very much change the > status quo, that is deregulating the transfer market by removing > justification of need for transfers. The market appears to be supplying only about 3% of the demand, assuming the demand for IPv4 in the region is as high as before the NCC ran out. There is no reason to believe that I can see reason to assume that the buyers and the would-be buyers do not have "need". More likely, I think, is that many by now have a quite desperate need. So for a "buyer without need" to even come into the picture, they must be willing to outspend those needy 97% in order to get at the available resource. If these "buyers without need" truly exist and are that determined and resourceful, I have no doubt they are also capable of synthesising whatever "need" required to stay within the constraints of today's need-based policy. It's not at all difficult, they could simply offer to lease (or even loan) back the addresses to the "needy" LIRs they have just outbid. > Again you are obfuscating and trivializing his objection. The RIPE NCC > doesn't just "giving public resources away", the primary cost is the > justification of those resources. Or, the cost of dealing with the > "bureaucracy" that you want to eliminate, that is not free, which is why > you want to eliminate it. The cost of obtaining public IPv4 resources from the RIPE NCC is an one-time fee of ?2000 plus a yearly fee of ?1800 (which may be adjusted annually). Plus the cost of sending an e-mail requesting the /22. This e-mail is *not* the bureaucracy I want to eliminate. Indeed, the changes going into version 3 is there precisely to keep this the way it is today. The bureaucracy 2013-03 do want to eliminate* is that of the interaction between the LIRs and their End Users. In other words, the *assignment* bureaucracy. The RIPE NCC is not involved in this at all, apart from a few exceptions, for example when assignment size > AW and during LIR Audits. * Actually, "make optional" is more describing. If an LIR wants to keep its current operational practises, by all means, it's free to do so. > Please stop obfuscating and trivializing people's objections, you either > have sufficient support to ignore their objections or you should address > them properly. My aim is always to address any objections properly. I hope this message contributed to that. > From: David Farmer > Organization: University of Minnesota Which reminds me, as you stated earlier on this list ?I neither support or oppose [2013-03], as I do not represent any resources used within the RIPE region?: I am truly perplexed with the intensity at which ARIN community members seem to take an interest in RIPE policy making, and perhaps especially in 2013-03. Do you have any clue as to the reason for this? 2013-03 is not intended as a global policy proposal, has someone claimed that it is? Best regards, Tore Anderson From gert at space.net Fri Sep 20 23:17:59 2013 From: gert at space.net (Gert Doering) Date: Fri, 20 Sep 2013 23:17:59 +0200 Subject: [address-policy-wg] Fwd: Re: 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523CAF43.4050909@umn.edu> References: <523CAE4B.8020100@umn.edu> <523CAF43.4050909@umn.edu> Message-ID: <20130920211759.GW65295@Space.Net> Hi, On Fri, Sep 20, 2013 at 03:25:39PM -0500, David Farmer wrote: > Again you are obfuscating and trivializing his objection. The RIPE NCC > doesn't just "giving public resources away", the primary cost is the > justification of those resources. Or, the cost of dealing with the > "bureaucracy" that you want to eliminate, that is not free, which is why > you want to eliminate it. > > Please stop obfuscating and trivializing people's objections, you either > have sufficient support to ignore their objections or you should address > them properly. Tore is actually responding to your and Sylvain's concerns to *address* them (or to explain why he's convinced that 2013-03 does not affect the concern voiced), not to obfuscate/trivialize them, and the WG chairs appreciate that. Whether or not we as WG chairs can "ignore the objection" depends somewhat on the total balance of support (preferably from the people affected by this, which really is "RIPE LIRs day to day business"), repetitive, and new objections. We'll see. 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 (0)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 koalafil at gmail.com Fri Sep 20 23:23:47 2013 From: koalafil at gmail.com (Fil) Date: Fri, 20 Sep 2013 23:23:47 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523CB329.6060103@fud.no> References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> <523C43CF.9070708@fud.no> <523C616E.5050507@fud.no> <523C7BEF.8010201@fud.no> <35E712B6-050B-4904-A37C-FDDA1B6EEB4C@gmail.com> <523CB329.6060103@fud.no> Message-ID: <6FA8080C-2C47-41E7-A25E-2FD937301D20@gmail.com> Hello Tore, On 20 Sep 2013, at 22:42, Tore Anderson wrote: > Hi again Filiz, > >> So the proposal is to remove some heavy "bureaucracy" (because if it >> was not heavy, we would not need a change, right?) which at the same >> time is (according to the 2nd paragraph) as easy as basically >> "keeping a straight face while justifying the assignment of 1 single >> IP"? > > You are comparing apples to oranges here (allocations to assignments). I do not think I am doing that. I just took your own exact words and put them in a form of a question. But lets move on to the topic and to the point, even if you think I am doing that. > The "easy" part is to document "need" enough to get an *allocation* from > the NCC. "Need" for allocations comes from one thing only: Intent to > make assignments. If you can document an intent to make a valid > assignment for one (1) IPv4 address, you have a valid need for an > allocation. Following the implementation of the last /8 policy, there is > only one size allocation the NCC can delegate to its members (/22). > Thus, by submitting a ripe-583 form documenting an intended assignment > of 1 IPv4 address (or a /32 if you prefer), you have also automatically > qualified for your initial and final /22 allocation. Anyone can do that, > it is not heavy bureaucracy at all. Good, then there is no need to change this in the policy for allocations. And to better address the need based concerns objecting your proposal, I think you could consider taking the "intent" you mentioned above one step further and have it explained to the RIPE NCC. Accordingly, I think following will be a more appropriate wording: 3. LIR must demonstrate its need for the IPv4 address space and must confirm it will make assignment(s) from the allocation. replacing what you proposed: 3. The LIR must confirm it will make assignment(s) from the allocation > > As described above, this is not being removed. Since an assignment must > be sized at least 1 address (or larger), a check-box requiring the > requesting LIR to confirm assignments will be made from the allocation > is functionally identical to today's current practise. Confirming to make assignments on its own is not enough in my belief. But I would support a more explicit need-justification requirement as above. Filiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists-ripe at c4inet.net Sat Sep 21 00:02:49 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Fri, 20 Sep 2013 23:02:49 +0100 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <35E712B6-050B-4904-A37C-FDDA1B6EEB4C@gmail.com> References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> <523C43CF.9070708@fud.no> <523C616E.5050507@fud.no> <523C7BEF.8010201@fud.no> <35E712B6-050B-4904-A37C-FDDA1B6EEB4C@gmail.com> Message-ID: <20130920220249.GA26581@cilantro.c4inet.net> On Fri, Sep 20, 2013 at 09:37:51PM +0200, Filiz Yilmaz wrote: >I agree it can be seen as bureaucracy to ask people to justify PA >assignments and sub-allocations now. However, I am not convinced that >asking justifying 1 IP from a /22 as a new LIR at this very interesting >times is a big deal. And removing a long-standing principle like "need >based" should require a better argument than reducing bureaucracy. This There is a better argument: We are in "Last /8", there is one more /22 per LIR, regardless of what "need" they may have or could demonstrate. Very soon now, IPv4 will be gone altogether and all the need in the world will get you exactly 0 IP addresses. Keeping "must demonstrate need" around in the absence of the premises it was based on is traditionalism for traditionalism's sake. > >These are procedural NCC issues, I've already commented regarding >reducing bureaucracy with the NCC, without doing a main curriery in the >policy before. These two are not real address policy management >related, they are "consequences" of the proposal, rather than positive >or negative Rationales We have no formal way of forcing the NCC to change the way a policy is implemented except by changing the policy. rgds, Sascha Luck From sander at steffann.nl Sat Sep 21 00:03:20 2013 From: sander at steffann.nl (Sander Steffann) Date: Sat, 21 Sep 2013 00:03:20 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <6FA8080C-2C47-41E7-A25E-2FD937301D20@gmail.com> References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> <523C43CF.9070708@fud.no> <523C616E.5050507@fud.no> <523C7BEF.8010201@fud.no> <35E712B6-050B-4904-A37C-FDDA1B6EEB4C@gmail.com> <523CB329.6060103@fud.no> <6FA8080C-2C47-41E7-A25E-2FD937301D20@gmail.com> Message-ID: Hi Filiz, One question for clarification: > And to better address the need based concerns objecting your proposal, I > think you could consider taking the "intent" you mentioned above one step > further and have it explained to the RIPE NCC. > > Accordingly, I think following will be a more appropriate wording: > > 3. LIR must demonstrate its need for the IPv4 address space and must > confirm it will make assignment(s) from the allocation. > > replacing what you proposed: > 3. The LIR must confirm it will make assignment(s) from the allocation What is your motivation for adding the 'LIR must demonstrate its need for the IPv4 address space' part? As the RIPE NCC can currently only allocate /22's the demonstrated need will have no impact on the allocation. Those that demonstrate a need of 1 address will get the same /22 as those that demonstrate a need of a million addresses. Your suggested text doesn't seem to have an impact on _what_ the NCC will allocate. It does have an impact on _when_ the NCC will allocate though. LIRs with existing allocations won't need the new /22 allocation until they used most of their existing ones. This only seems to affect the runout speed of the remaining /22's. Looking at that: the RIPE NCC currently (http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-pool-graph) has more then 14000 /22's left (not including quarantine and reserved). There are less than 9000 LIRs that can have allocations from before the runout. Some of them already have their /22. The remaining ones might be able to get their /22 sooner with the current policy text. More than 5000 /22's will remain even if they do. With my chair hat on: I have no opinion on your suggested change, I'm just interested in what effect you want to achieve with it. Thanks, Sander From tore at fud.no Sat Sep 21 00:25:58 2013 From: tore at fud.no (Tore Anderson) Date: Sat, 21 Sep 2013 00:25:58 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <6FA8080C-2C47-41E7-A25E-2FD937301D20@gmail.com> References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> <523C43CF.9070708@fud.no> <523C616E.5050507@fud.no> <523C7BEF.8010201@fud.no> <35E712B6-050B-4904-A37C-FDDA1B6EEB4C@gmail.com> <523CB329.6060103@fud.no> <6FA8080C-2C47-41E7-A25E-2FD937301D20@gmail.com> Message-ID: <523CCB76.2050606@fud.no> Filiz, > Good, then there is no need to change this in the policy for allocations. And that's the very reason for the 2nd amendment going into version 3 of the proposal, precisely to avoid changing how this works. The "last /8 policy" is *not* a target for 2013-03 (beyond merging it into the main policy text for cleanup/editorial purposes). > And to better address the need based concerns objecting your proposal, I > think you could consider taking the "intent" you mentioned above one > step further and have it explained to the RIPE NCC. The 2nd amendment was actually developed in collaboration with the NCC (in particular Andrea Cima from RS and Emilio Madaio from the PDO), in order to incorporate the feedback and objection received from yourself and Malcolm Hutty during the last review phase: http://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-August/008105.html > Accordingly, I think following will be a more appropriate wording: > 3. LIR must demonstrate its need for the IPv4 address space and /must > confirm it will make assignment(s) from the allocation./ > > replacing what you proposed: > 3. /The LIR must confirm it will make assignment(s) from the allocation/ The *only* thing that defines "need" for *allocations*, is an LIR's intent to make assignments to End Users and/or its own infrastructure. Keeping that in mind, the two sentences above are actually saying *exactly the same thing*! > Confirming to make assignments on its own is not enough in my belief. > But I would support a more explicit need-justification requirement as above. As above, the exact purpose of the the 2nd amendment was to ensure current practise was being upheld. Both because of the feedback from yourself and Malcolm; but also because the NCC felt that not having any "pledge of intent to use" on the requestors' part could potentially make the Dutch Tax Office see it as the NCC "selling IPv4", and withdrawing their advantageous non-profit status. As stated earlier, the amendment was developed in collaboration with the NCC to ensure we achieved exactly that, and accordingly, the Dutch Tax point was removed from the updated Impact Analysis. So I believe the amendment successfully does what it aimed to do. If what you are saying above is that you think there needs to be a stronger and more rigid validation of need in order to obtain the last /22 (for example: intent to assign at least a /23 instead of a /32 like today), then that is of course fine, but if so - it belongs in a separate policy proposal. I try really hard *not* to change the "last /8 policy" in 2013-03, and it is therefore not a suitable vessel for a "more-explicitification" of its allocation criteria. Best regards, Troe Anderson From koalafil at gmail.com Sat Sep 21 01:41:10 2013 From: koalafil at gmail.com (Filiz Yilmaz) Date: Sat, 21 Sep 2013 01:41:10 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> <523C43CF.9070708@fud.no> <523C616E.5050507@fud.no> <523C7BEF.8010201@fud.no> <35E712B6-050B-4904-A37C-FDDA1B6EEB4C@gmail.com> <523CB329.6060103@fud.no> <6FA8080C-2C47-41E7-A25E-2FD937301D20@gmail.com> Message-ID: <9CA6E232-4F69-45A5-A9CB-D2A498F7641D@gmail.com> Hello, On 21 Sep 2013, at 00:03, "Sander Steffann" wrote: > Hi Filiz, > > One question for clarification: > >> And to better address the need based concerns objecting your proposal, I >> think you could consider taking the "intent" you mentioned above one step >> further and have it explained to the RIPE NCC. >> >> Accordingly, I think following will be a more appropriate wording: >> >> 3. LIR must demonstrate its need for the IPv4 address space and must >> confirm it will make assignment(s) from the allocation. >> >> replacing what you proposed: >> 3. The LIR must confirm it will make assignment(s) from the allocation > > What is your motivation for adding the 'LIR must demonstrate its need for > the IPv4 address space' part? > - Demonstration brings accountability to any claim and makes the claim (of confirming the intent of making assignments) believable and supported. [This demonstration can be as simple as a couple of sentences describing the network and business of the new LIR and does not need to come in any specific form or shape.] - Those who intend to lie to the RIPE NCC will be forced to be a bit more creative and work on their case harder than just clicking a combo box. Those who really have a need can explain this briefly very easily and pass the criteria without any hassle. So policy will still have some substance for some differentiation between bad and good practice. - RIPE NCC may be able to demonstrate and defend their position why they allocated space rightfully way better if they have to one day to some I* organisation, having received some demonstration from LIRs. The LIR may have chosen to lie and fake their demonstration but the RIR will be still have had asked the right questions to consider "need" as their justification of who gets the space. - Adding this may help getting agreement of those who currently object the proposal because of the complete removal of justification of need from the policy, as it is kept for allocations to new LIRs, while it is removed from assignments, which is the real bureaucracy on the LIR side. So this looks to me like a compromise between two conflicting interests/wishes. Filiz > As the RIPE NCC can currently only allocate /22's the demonstrated need > will have no impact on the allocation. Those that demonstrate a need of 1 > address will get the same /22 as those that demonstrate a need of a > million addresses. > > Your suggested text doesn't seem to have an impact on _what_ the NCC will > allocate. It does have an impact on _when_ the NCC will allocate though. > LIRs with existing allocations won't need the new /22 allocation until > they used most of their existing ones. This only seems to affect the > runout speed of the remaining /22's. > > Looking at that: the RIPE NCC currently > (http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-pool-graph) > has more then 14000 /22's left (not including quarantine and reserved). > There are less than 9000 LIRs that can have allocations from before the > runout. Some of them already have their /22. The remaining ones might be > able to get their /22 sooner with the current policy text. More than 5000 > /22's will remain even if they do. > > With my chair hat on: I have no opinion on your suggested change, I'm just > interested in what effect you want to achieve with it. > > Thanks, > Sander > > From randy at psg.com Sat Sep 21 06:54:18 2013 From: randy at psg.com (Randy Bush) Date: Fri, 20 Sep 2013 18:54:18 -1000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523CAE53.9090508@umn.edu> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523CAE53.9090508@umn.edu> Message-ID: David Farmer wrote: > +1 to every thing Sylvain said, and -1 to proposal. does the university of minnesota operate in the ripe region, or just have global opinions on how everybody else should operate? randy From hph at oslo.net Sat Sep 21 08:48:35 2013 From: hph at oslo.net (Hans Petter Holen) Date: Sat, 21 Sep 2013 08:48:35 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> Message-ID: On Friday, September 20, 2013, Randy Bush wrote: > > > if homogenous policy was a goal, why do we need separate RIRs? Very interesting question. Especialy since all the policy foras are open to partocipation - even from other regions - there tends to be inter-region influence between the regional policies. -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 tore at fud.no Sat Sep 21 10:33:53 2013 From: tore at fud.no (Tore Anderson) Date: Sat, 21 Sep 2013 10:33:53 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <9CA6E232-4F69-45A5-A9CB-D2A498F7641D@gmail.com> References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> <523C43CF.9070708@fud.no> <523C616E.5050507@fud.no> <523C7BEF.8010201@fud.no> <35E712B6-050B-4904-A37C-FDDA1B6EEB4C@gmail.com> <523CB329.6060103@fud.no> <6FA8080C-2C47-41E7-A25E-2FD937301D20@gmail.com> <9CA6E232-4F69-45A5-A9CB-D2A498F7641D@gmail.com> Message-ID: <523D59F1.5030700@fud.no> * Filiz Yilmaz > On 21 Sep 2013, at 00:03, "Sander Steffann" > wrote: > >> What is your motivation for adding the 'LIR must demonstrate its >> need for the IPv4 address space' part? > > - Demonstration brings accountability to any claim and makes the > claim (of confirming the intent of making assignments) believable and > supported. [This demonstration can be as simple as a couple of > sentences describing the network and business of the new LIR and does > not need to come in any specific form or shape.] Ok, so let's see how this works: ?I have an iMac. I intend to assign it an IPv4 address.? There. This is the essence of a 100% believable and justified assignment request, and is all that it takes for a new LIR to in turn justify receiving the last /22 allocation. > - Those who intend to lie to the RIPE NCC will be forced to be a bit > more creative and work on their case harder than just clicking a > combo box. Well, I actually have an admission to make - I lied. I don't have an iMac. I'm more of a PC man, truth to be told. I don't consider myself a particularly creative man, yet this particular lie came easy. > Those who really have a need can explain this briefly very > easily and pass the criteria without any hassle. ?I have a PC. I intend to assign it an IPv4 address.? ?I have a server. I intend to assign it an IPv4 address.? There. Those would be the God's honest truth. The point I'm trying to make here is that justifying the single-address assignment necessary to obtain a last /22 is so trivial that anyone can do it. Especially anyone who is motivated enough to fork out ?3800 in the pursuit of said /22. > - RIPE NCC may be able to demonstrate and defend their position why > they allocated space rightfully way better if they have to one day to > some I* organisation, having received some demonstration from LIRs. I do not know what an "I* organisation" is, but this sounds to me to be the same argument as the Dutch Tax Office point that was brought up by the NCC, which was been removed from the last IA due to the addition of the requirement that LIRs confirm their intent to make assignments from any last /8 allocation. Keep in mind that the NCC's job is to implement the Community's bottom-up policies in a neutral and transparent manner. If the Community says "make a checkbox", and the NCC adds this checkbox, the NCC has no reason to "defend their position" for doing so and for allocating space to the members who tick the checkbox. > The LIR may have chosen to lie and fake their demonstration but the > RIR will be still have had asked the right questions to consider > "need" as their justification of who gets the space. As above, *truthfully* justifying a single IPv4 address is so trivial that it is not necessary for anyone to lie. But if someone who spends ?3800 on getting a /22 truly has no equipment which could be used to truthfully justify a single IPv4 address, they could even turn to the NCC for help: ?I have just ordered free RIPE Atlas probe from https://atlas.ripe.net/apply (see ticket #1234). I intend to assign it an IPv4 address.? In spite of this, if the requesting LIR for whatever reason still chooses to lie, this is something the NCC can trivially verify - even in a fully automated fashion. All they need to do is to see whether or not an inetnum object with status ASSIGNED PA has been registered in the database some reasonable time after the covering ALLOCATED PA one was. (The potential for such a check was actually pointed out to me by the NCC during the preparation of the amendment, it is not my idea.) > - Adding this may help getting agreement of those who currently > object the proposal because of the complete removal of justification > of need from the policy, as it is kept for allocations to new LIRs, > while it is removed from assignments, which is the real bureaucracy > on the LIR side. So this looks to me like a compromise between two > conflicting interests/wishes. Sorry. This is where you lose me. The 2nd amendment that went into version 3 of the proposal was added *specifically* to reach a compromise and an acceptable middle ground for the objections made by yourself and Malcolm Hutty: http://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-August/008105.html Note that the check-box in question was actually Malcolm's idea, not mine. I was really trying to give you (as in you the objectors) exactly what you wanted here! Also, I took care to CC-ed explicitly on the above message, because I felt the issue was pretty much the same as the one you raised in this message: http://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-August/008104.html In this message, you wrote, and I quote: ?I advocate for keeping the justification for need ***or some kind of commitment from the requester that the space is to be used on a network shortly and not to be sold to a 3rd party.***? (emphasis mine) This kind of "commitment" you proposed here is *exactly* what the amendment in question implements! In any case, neither you nor Malcolm chose not to respond to the first linked-to message containing an initial draft of what became the 2nd amendment, even though it ended in the explicit question ?Would this be sufficient to remove your concerns??. So I took it back to the NCC and did some wordsmithing with them to ensure we ended up with a text that accomplished precisely what I honestly believed was what you were after. After the completion of this work, I posted the exact text of the draft amendments to the list, while the review phase was still open and there was still a window for further adjustments: http://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-August/008155.html ...accompanied by an introduction that 1) highlights that your objection is one of the points attempted to be addressed by the amendment, and 2) that anyone who would have remaining objections after the amendment please "speak now or forever hold your peace" so as to avoid not asking the NCC to spend lots of time and effort on making another useless IA. You held your peace, Filiz. I am nonplussed as to why. If you still objected to the amended proposal, why did you choose to wait until now with sharing it with the WG? Why didn't you share your views when they were asked for, when we had a perfect window of opportunity to further polish the amendments *before* the previous review period ended? Best regards, Tore Anderson From jan at go6.si Sat Sep 21 11:40:44 2013 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sat, 21 Sep 2013 11:40:44 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <20130919195744.GA23831@cilantro.c4inet.net> References: <20130919195744.GA23831@cilantro.c4inet.net> Message-ID: <523D699C.7020105@go6.si> On 9/19/13 9:57 PM, Sascha Luck wrote: > On Thu, Sep 19, 2013 at 09:52:52AM -1000, Randy Bush wrote: >> and once more unto the breach, dear friends, once more > > Damn, I wanted to write that ;p > > +1 also +1 Still think this is a good exercise and brings more pragmatism in current policy. Cheers, Jan From koalafil at gmail.com Sat Sep 21 13:58:10 2013 From: koalafil at gmail.com (Filiz Yilmaz) Date: Sat, 21 Sep 2013 13:58:10 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523D59F1.5030700@fud.no> References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> <523C43CF.9070708@fud.no> <523C616E.5050507@fud.no> <523C7BEF.8010201@fud.no> <35E712B6-050B-4904-A37C-FDDA1B6EEB4C@gmail.com> <523CB329.6060103@fud.no> <6FA8080C-2C47-41E7-A25E-2FD937301D20@gmail.com> <9CA6E232-4F69-45A5-A9CB-D2A498F7641D@gmail.com> <523D59F1.5030700@fud.no> Message-ID: Tore, Your discussion style preference does not suit me too well, I find the divide-concur-corner strategy tiring because simply my preferred style is to keep a more helicopter perspective in such fora. We just differ there. I also find this 1-1 interaction tiring for others to follow, so I will stick to "views" and "thoughts" and so I will outline my views briefly as an attempt to respond to your last post. However I responded in regards to my intentions in the final part below, as you seem to have questions about it too: 1. You seem to be making a joke out of what I have said about demonstration. In my opinion the RIR system is a lot more credible than what you seem to be portraying in your iMac/PC man example. RIRs did a very good job so far on a daily basis getting their guidance from somewhat not so black and white policies that their communities put in place. I think they still do a very good job. Again, just my views... Joke or not, I agree that what you put there is a lot more transparent and has more substance than just a combo box. Clearly any legitimate need is very easy to demonstrate (as you demonstrated in your iMac/PC man example) and new LIRs will only have to do this ONCE, when they request their initial /22, so it is not a huge bureaucratic burden. And since this is so easy to do, why such simple demonstration cannot be kept there in the policy, so this proposal can finally reach consensus? Of course this just a suggestion, I do not know if others who opposed so far will be OK with this small alteration... 2. With some "I* organisation" I meant any organisation that puts Internet in their mission statement and that would be happy to find all kinds of flaws in the RIR practices in accordance for their agenda. So far ITU had seemed to have criticism against RIRs, and RIRs defended their ground having solid practices. I think there might be more than just one, so I did not want to use a specific org name but used an umbrella term as "I* organisation". This concept was covered by Malcomn before so I did not see the need to elaborate in my previous mail. I hope it is clear now. My point was that if the RIPE NCC has a bit more information in regards to need with substance, this may help the RIR system better overall. 3. Agreed, RIPE NCC's job is to implement the Community's bottom-up policies in a neutral and transparent manner. But I also believe (and I have expressed these before too) that the RIPE Community also has a responsibility to develop good policy and provide the RIPE NCC a good policy ground to base their procedures and implementations on. At the end of the day, RIPE NCC is a legal entity, can be sued, can go bust etc etc, and RIPE Community has a huge impact on what they can and cannot do on a daily basis. 4. I am lost too, welcome to the club! Let me explain where I am coming from: Now you have the 3rd version out there and there seems to be still opposition to the removal of justification from what I can tell seeing McTim's and Sylvain's posts. So I thought this could be an easy remedy, adding a supporting sentence in front of the combo-box suggestion to have them agreed on your proposal too, and so I made the wording suggestion. You are free to ignore this suggestion if you still feel too strong about not having it. In the meanwhile I will continue expressing my views and thoughts as I see fit on this list. Note that you made a proposal and the rest of us are discussing it. I have sent more than 10 mails to this thread, trying to explain what I agree with and what I do not and why in great length and to the best of my effort. I've made quotes from previous policy text as well as from your proposal too to explain clearly my views. It was difficult following so many lengthy mails in this thread, also considering that most of it happened during summer vacation time for a lot of people, which was also mentioned by another member on the list. So lets assume everyone is doing their best and lets not target people individually and stick to what is being said and look at the content of the arguments. Otherwise this has the risk of being perceived as really getting out of proportion and beyond the scope of the proposal discussion. Regards Filiz On 21 Sep 2013, at 10:33, Tore Anderson wrote: > * Filiz Yilmaz > >> On 21 Sep 2013, at 00:03, "Sander Steffann" >> wrote: >> >>> What is your motivation for adding the 'LIR must demonstrate its >>> need for the IPv4 address space' part? >> >> - Demonstration brings accountability to any claim and makes the >> claim (of confirming the intent of making assignments) believable and >> supported. [This demonstration can be as simple as a couple of >> sentences describing the network and business of the new LIR and does >> not need to come in any specific form or shape.] > > Ok, so let's see how this works: > > ?I have an iMac. I intend to assign it an IPv4 address.? > > There. This is the essence of a 100% believable and justified assignment > request, and is all that it takes for a new LIR to in turn justify > receiving the last /22 allocation. > >> - Those who intend to lie to the RIPE NCC will be forced to be a bit >> more creative and work on their case harder than just clicking a >> combo box. > > Well, I actually have an admission to make - I lied. I don't have an > iMac. I'm more of a PC man, truth to be told. I don't consider myself a > particularly creative man, yet this particular lie came easy. > >> Those who really have a need can explain this briefly very >> easily and pass the criteria without any hassle. > > ?I have a PC. I intend to assign it an IPv4 address.? > ?I have a server. I intend to assign it an IPv4 address.? > > There. Those would be the God's honest truth. > > The point I'm trying to make here is that justifying the single-address > assignment necessary to obtain a last /22 is so trivial that anyone can > do it. Especially anyone who is motivated enough to fork out ?3800 in > the pursuit of said /22. > >> - RIPE NCC may be able to demonstrate and defend their position why >> they allocated space rightfully way better if they have to one day to >> some I* organisation, having received some demonstration from LIRs. > > I do not know what an "I* organisation" is, but this sounds to me to be > the same argument as the Dutch Tax Office point that was brought up by > the NCC, which was been removed from the last IA due to the addition of > the requirement that LIRs confirm their intent to make assignments from > any last /8 allocation. > > Keep in mind that the NCC's job is to implement the Community's > bottom-up policies in a neutral and transparent manner. If the Community > says "make a checkbox", and the NCC adds this checkbox, the NCC has no > reason to "defend their position" for doing so and for allocating space > to the members who tick the checkbox. > >> The LIR may have chosen to lie and fake their demonstration but the >> RIR will be still have had asked the right questions to consider >> "need" as their justification of who gets the space. > > As above, *truthfully* justifying a single IPv4 address is so trivial > that it is not necessary for anyone to lie. But if someone who spends > ?3800 on getting a /22 truly has no equipment which could be used to > truthfully justify a single IPv4 address, they could even turn to the > NCC for help: > > ?I have just ordered free RIPE Atlas probe from > https://atlas.ripe.net/apply (see ticket #1234). I intend to assign it > an IPv4 address.? > > In spite of this, if the requesting LIR for whatever reason still > chooses to lie, this is something the NCC can trivially verify - even in > a fully automated fashion. All they need to do is to see whether or not > an inetnum object with status ASSIGNED PA has been registered in the > database some reasonable time after the covering ALLOCATED PA one was. > (The potential for such a check was actually pointed out to me by the > NCC during the preparation of the amendment, it is not my idea.) > >> - Adding this may help getting agreement of those who currently >> object the proposal because of the complete removal of justification >> of need from the policy, as it is kept for allocations to new LIRs, >> while it is removed from assignments, which is the real bureaucracy >> on the LIR side. So this looks to me like a compromise between two >> conflicting interests/wishes. > > Sorry. This is where you lose me. The 2nd amendment that went into > version 3 of the proposal was added *specifically* to reach a compromise > and an acceptable middle ground for the objections made by yourself and > Malcolm Hutty: > > http://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-August/008105.html > > Note that the check-box in question was actually Malcolm's idea, not > mine. I was really trying to give you (as in you the objectors) exactly > what you wanted here! Also, I took care to CC-ed explicitly on the above > message, because I felt the issue was pretty much the same as the one > you raised in this message: > > http://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-August/008104.html > > In this message, you wrote, and I quote: ?I advocate for keeping the > justification for need ***or some kind of commitment from the requester > that the space is to be used on a network shortly and not to be sold to > a 3rd party.***? (emphasis mine) > > This kind of "commitment" you proposed here is *exactly* what the > amendment in question implements! > > In any case, neither you nor Malcolm chose not to respond to the first > linked-to message containing an initial draft of what became the 2nd > amendment, even though it ended in the explicit question ?Would this be > sufficient to remove your concerns??. > > So I took it back to the NCC and did some wordsmithing with them to > ensure we ended up with a text that accomplished precisely what I > honestly believed was what you were after. After the completion of this > work, I posted the exact text of the draft amendments to the list, while > the review phase was still open and there was still a window for further > adjustments: > > http://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-August/008155.html > > ...accompanied by an introduction that 1) highlights that your objection > is one of the points attempted to be addressed by the amendment, and 2) > that anyone who would have remaining objections after the amendment > please "speak now or forever hold your peace" so as to avoid not asking > the NCC to spend lots of time and effort on making another useless IA. > > You held your peace, Filiz. > > I am nonplussed as to why. > > If you still objected to the amended proposal, why did you choose to > wait until now with sharing it with the WG? Why didn't you share your > views when they were asked for, when we had a perfect window of > opportunity to further polish the amendments *before* the previous > review period ended? > > Best regards, > Tore Anderson > From nigel at titley.com Sat Sep 21 14:19:21 2013 From: nigel at titley.com (Nigel Titley) Date: Sat, 21 Sep 2013 13:19:21 +0100 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <523D8EC9.5070407@titley.com> On 19/09/2013 17:07, Richard Hartmann wrote: > Dear all, > > > I still support this proposal and have the slight hope that this will > be the last time I will have to state this. > +1 to both sentiments Nigel From sander at steffann.nl Sat Sep 21 15:09:53 2013 From: sander at steffann.nl (Sander Steffann) Date: Sat, 21 Sep 2013 15:09:53 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> <523C43CF.9070708@fud.no> <523C616E.5050507@fud.no> <523C7BEF.8010201@fud.no> <35E712B6-050B-4904-A37C-FDDA1B6EEB4C@gmail.com> <523CB329.6060103@fud.no> <6FA8080C-2C47-41E7-A25E-2FD937301D20@gmail.com> <9CA6E232-4F69-45A5-A9CB-D2A498F7641D@gmail.com> <523D59F1.5030700@fud.no> Message-ID: <7BBDDD60-F222-40E9-B2AE-B9D54D79E9C7@steffann.nl> Hi, > In my opinion the RIR system is a lot more credible than what you seem to be portraying in your iMac/PC man example. > RIRs did a very good job so far on a daily basis getting their guidance from somewhat not so black and white policies that their communities put in place. > I think they still do a very good job. Again, just my views... > > Joke or not, I agree that what you put there is a lot more transparent and has more substance than just a combo box. Small point here: the policy text suggested in 2013-03 only states "The LIR must confirm it will make assignment(s) from the allocation.". The idea of implementing this with a check/combo-box has been mentioned on this list, but is not part of the policy text. May I suggest that we leave the policy text as-is and leave the implementation details on how the LIR is asked for confirmation that they will be making assignments from their allocation to the NCC? I feel uncomfortable deciding on implementation details here when that is the NCC's responsibility. I know the NCC is following this discussion and considering the good job they did in the past (as Filiz rightfully points out) I trust them to do a good job here as well. Cheers, Sander From tore at fud.no Sat Sep 21 15:10:27 2013 From: tore at fud.no (Tore Anderson) Date: Sat, 21 Sep 2013 15:10:27 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> <523C43CF.9070708@fud.no> <523C616E.5050507@fud.no> <523C7BEF.8010201@fud.no> <35E712B6-050B-4904-A37C-FDDA1B6EEB4C@gmail.com> <523CB329.6060103@fud.no> <6FA8080C-2C47-41E7-A25E-2FD937301D20@gmail.com> <9CA6E232-4F69-45A5-A9CB-D2A498F7641D@gmail.com> <523D59F1.5030700@fud.no> Message-ID: <523D9AC3.8040700@fud.no> * Filiz Yilmaz > Your discussion style preference does not suit me too well The feeling is mutual. > 1. You seem to be making a joke out of what I have said about > demonstration. > > In my opinion the RIR system is a lot more credible than what you > seem to be portraying in your iMac/PC man example. RIRs did a very > good job so far on a daily basis getting their guidance from somewhat > not so black and white policies that their communities put in place. > I think they still do a very good job. Again, just my views... I think the NCC is doing a good job too. I cannot speak for the the other four RIRs, as I have no experience working with those. > Clearly any legitimate need is very easy to demonstrate (as you > demonstrated in your iMac/PC man example) and new LIRs will only have > to do this ONCE, when they request their initial /22, so it is not a > huge bureaucratic burden. Agreed. As I've said repeatedly, changing the way initial /22s for new LIRs are issued is not and has never been a goal of this proposal. > And since this is so easy to do, why such simple demonstration cannot > be kept there in the policy, so this proposal can finally reach > consensus? Of course this just a suggestion, I do not know if others > who opposed so far will be OK with this small alteration... It could. Again, changing the way initial /22s for new LIRs are issued is not something the proposal is aiming at. That's why the 2nd amendment was added. And I would quite possible have been OK with this small alteration or something like it, except for one ting: Timing. So why not, you ask? Because it means another Impact Analysis, and another review phase. In the last review phase, one of solutions you advocated was ?some kind of commitment from the requester that the space is to be used on a network shortly and not to be sold to a 3rd party?. Lo and behold - now we have just that, confirmed by the NCC itself. But all of a sudden that is not good enough for you any longer. So I'm wondering, what will be the thing that is not good enough for you in the 3rd review phase? In the 4th? In the 5th? Why you chose to say *nothing* when asked in the last review phase if the currently proposed text was okay, why you chose to say *nothing* when the WG was asked if there were remaining objections that was not dealt with by the proposed amendments, why you chose to wait in silence for well over a month when the NCC was hard at work making a new Impact Analysis, only to bring up your misgivings about the new text *now*...it is truly beyond my comprehension. > 2. With some "I* organisation" I meant any organisation that puts > Internet in their mission statement and that would be happy to find > all kinds of flaws in the RIR practices in accordance for their > agenda. So far ITU had seemed to have criticism against RIRs, and > RIRs defended their ground having solid practices. I think there > might be more than just one, so I did not want to use a specific org > name but used an umbrella term as "I* organisation". This concept was > covered by Malcomn before so I did not see the need to elaborate in > my previous mail. I hope it is clear now. My point was that if the > RIPE NCC has a bit more information in regards to need with > substance, this may help the RIR system better overall. Indeed. The Impact Analysis for the previous version of the amendment contained the following concern: ?The RIPE NCC has been under increased scrutiny from multiple parties outside the technical community. In many cases, the RIPE NCC has referred to the needs-based principle as evidence of the fairness and transparency of allocations under the RIR system. If this principle were to be eliminated, one of the main argumentative mainstays to defend bottom-up industry self regulation would be gone. The RIPE NCC, as well as the technical community, would have to prepare for increased outreach and education efforts with participants in the Internet Governance debate.? As I described in the summary mail I sent to the WG, alleviating this concern was amongst of the goals of the amendments, and this was being discussed with the NCC folks that helped work on them and confirmed by other NCC reps as having this beneficial effect. The result? The updated Impact Analysis no longer contains the above. > 3. Agreed, RIPE NCC's job is to implement the Community's bottom-up > policies in a neutral and transparent manner. > > But I also believe (and I have expressed these before too) that the > RIPE Community also has a responsibility to develop good policy and > provide the RIPE NCC a good policy ground to base their procedures > and implementations on. Yes indeed. Ensuring that the resulting policy was crystal clear and that there would be no confusions as to how it would be implemented into the NCC's operational procedures is the exact reason why the amendments' exact wording is the result of a *collaborative effort* between myself and the RIPE NCC. > 4. I am lost too, welcome to the club! > > Let me explain where I am coming from: > > Now you have the 3rd version out there and there seems to be still > opposition to the removal of justification from what I can tell > seeing McTim's and Sylvain's posts. So I thought this could be an > easy remedy, adding a supporting sentence in front of the combo-box > suggestion to have them agreed on your proposal too, and so I made > the wording suggestion. > > You are free to ignore this suggestion if you still feel too strong > about not having it. In the meanwhile I will continue expressing my > views and thoughts as I see fit on this list. Your suggestion is not ignored, I've noted it well. But when it comes to McTim's and Sylvain's posts, I have attempted to address the points they've made in my responses to *their* posts. Time will tell if the WG's consensus is that they have been adequately addressed or not. > So lets assume everyone is doing their best and lets not target > people individually and stick to what is being said and look at the > content of the arguments. Otherwise this has the risk of being > perceived as really getting out of proportion and beyond the scope of > the proposal discussion. Limiting the scope of the various sub-threads in the discussion of this proposal, and keeping them on-topic, has been one of the hardest things for me to accomplish. For example, keeping McTim and Sylvain's misgivings about the proposal out of this one. Best regards, Tore Anderson From koalafil at gmail.com Sat Sep 21 18:56:24 2013 From: koalafil at gmail.com (Filiz Yilmaz) Date: Sat, 21 Sep 2013 18:56:24 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523D9AC3.8040700@fud.no> References: <523b0e1b.030a0f0a.65f2.ffffc9ccSMTPIN_ADDED_MISSING@mx.google.com> <523C2626.8000201@x-net.be> <523C43CF.9070708@fud.no> <523C616E.5050507@fud.no> <523C7BEF.8010201@fud.no> <35E712B6-050B-4904-A37C-FDDA1B6EEB4C@gmail.com> <523CB329.6060103@fud.no> <6FA8080C-2C47-41E7-A25E-2FD937301D20@gmail.com> <9CA6E232-4F69-45A5-A9CB-D2A498F7641D@gmail.com> <523D59F1.5030700@fud.no> <523D9AC3.8040700@fud.no> Message-ID: <35CBEC3F-9F5F-47BF-B904-7346FD30FFD0@gmail.com> Tore, On 21 Sep 2013, at 15:10, Tore Anderson wrote: > > Agreed. As I've said repeatedly, changing the way initial /22s for new > LIRs are issued is not and has never been a goal of this proposal. > But your proposal is changing it, regardless if it is the goal or the unintentional end result. Otherwise, really, what are we discussing here? That your proposal is changing the First allocation part of the policy is a fact. This is what I find so hard with your argumentative strategy to follow. You keep responding with "it was not the intention" or "it is not within the scope of this proposal" to these oppositions to a change that your proposal is actually bringing to the current policy. And I think this adds to the confusion and results in lengthy discussions where people get lost. This is an other factor in not reaching consensus as timely as you desire in my opinion in this case. I refrained from pointing these so far because I believe everyone is entitled to their own style, but I must say it is a 2-way street. I wish you were more careful before making judgements about other people's styles, questions, comments and etc before considering all these too. >> And since this is so easy to do, why such simple demonstration cannot >> be kept there in the policy, so this proposal can finally reach >> consensus? Of course this just a suggestion, I do not know if others >> who opposed so far will be OK with this small alteration... > > It could. Again, changing the way initial /22s for new LIRs are issued > is not something the proposal is aiming at. That's why the 2nd amendment > was added. And I would quite possible have been OK with this small > alteration or something like it, except for one ting: Timing. > > So why not, you ask? Because it means another Impact Analysis, and > another review phase. Sure, but we (opposers) cannot be held responsible of this situation. And maybe RIPE NCC can provide a faster answer in this if they also think in fact it is a small amendment. > In the last review phase, one of solutions you > advocated was ?some kind of commitment from the requester that the space > is to be used on a network shortly and not to be sold to a 3rd party?. You keep referring to this, and "my" timing and all. Fine, but then I suggest if you are going to quote me, quote me correctly and under the light of "your" communication in this list too. Exact interaction between us was as follows in that mail you referred to: (http://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-August/008104.html) --- > The relevant community built policy that defines "fairness" at this > point in time is the "last /8 policy", with its strict "one /22 per > applicant" rationing. This does not go away with 2013-03, so in > pragmatical terms, the implementation of "fairness" would remain. > Tore, i do not see how it remains. I gave the example of two new members getting each a /22 if your proposal gets accepted before: One is requesting it to use it on a network soon. The other is requesting it to sell it in 24 months because they cannot sell it before - your proposal leaves this requirement. I dont think this is fair and this will happen if NCC does not ask for justification for need or some word on that a network exists for the IPs to be used on. --- and then the mail continues with: --- I agree with the parts of your proposal that are removing the overhead on LIR level. But I do not see it is much of an overhead to be able to say "i need a last /22 because of this network here.." > Would such an amendment make the proposal more appealing or at least > acceptable to you? If not, what else is needed? Pls see above and few previous mails. Before NCC really runs out and still providing "allocations" I advocate for keeping the justification for need or some kind of commitment from the requester that the space is to be used on a network shortly and not to be sold to a 3rd party. -- So I obviously provided extra context to your question with further suggestions. I think it is clear from the statements of mine before or after your question as "Would such an amendment make the proposal more appealing or at least acceptable to you? If not, what else is needed?" that I am not totally content with the sole combo-box (Yes/NO) suggestion. Otherwise I would have simply answered your question with a "yes'". Now, you chose to take only a certain part of this answer; "or some kind of commitment from the requester", ignoring the rest which was "that the space is to be used on a network shortly and not to be sold to a 3rd party. ". So I think it is quiet unfair on you to tell me that I have not raised this *before*, considering that this was my point in all of the mails I have sent to the list beginning from 25th July, in various forms and with various examples indeed to get my message across. Furthermore and more importantly, after this correspondence, which was on 2nd August, on 6th August, you have sent a mail to the list as follows (as a response to Hans Petter's mail): ----- * Hans Petter Holen > since this is going to be replaced we should probably make sure we are > in line with [goal #1 in section #2 of RFC 2050-bis]. As I explained in my reply to David Conrad, I believe the amendment I'll be proposing in version 3.0 of the proposal will ensure that we are. (In a nutshell: Keep "Need" around in its current form for the final /22 allocations issued by the NCC to its members.) ---- Seeing this, I thought you would keep "the need justification" in the policy. You also were saying in "its current form" . [Current policy says: "Members can receive an initial IPv4 allocation when they have demonstrated a need for IPv4 address space."]. Voila, I thought, we seem to be agreeing, finally! Anyway, so note that at this point (on 6 August) I am thinking that you would keep the "need" in the new version as it is already in the current policy document. And I took some days off (did I mention the summer holidays??), during which you seem to have sent another mail on 7th August. In that mail the details are quite different than what you have said on 6th August though. I am now re-raising it and I think I am entitled to, especially given that I have belief this may be the consensus point for this proposal. Once again I have suggested the following: > Accordingly, I think following will be a more appropriate wording: > > 3. LIR must demonstrate its need for the IPv4 address space and must > confirm it will make assignment(s) from the allocation. > > replacing what you proposed: > 3. The LIR must confirm it will make assignment(s) from the allocation This amendment is right from the current policy which I thought you agreed to keep based on your mail on 6th August. So please stop accusing me as if I am re-inventing a new suggestion here, just to stall the process. To my best knowledge, we had discussed these and agreed on them. I may have misunderstood what you really meant to say on 6th August mail, but surely all this does not mean that I waited on purpose, just to give you grief and I am now re-raising the issue. In fact, it means that I trusted you and what you have said on 6th August and I simply did not see the need to double check this against your mail on 7th August when I got back from my days off. Since I got back I have been waiting to see the new text (v3) and here we are today, now. I hope this now address all the comments below and that there is no conspiracy here. I am finding this insinuation very disturbing to the process and to the proposal's progress too, by the way. > Why you chose to say *nothing* when asked in the last review phase if > the currently proposed text was okay, why you chose to say *nothing* > when the WG was asked if there were remaining objections that was not > dealt with by the proposed amendments, why you chose to wait in silence > for well over a month when the NCC was hard at work making a new Impact > Analysis, only to bring up your misgivings about the new text *now*...it > is truly beyond my comprehension. My best wishes to all for a great weekend! Filiz Yilmaz -------------- next part -------------- An HTML attachment was scrubbed... URL: From cja at daydream.com Sun Sep 22 04:27:33 2013 From: cja at daydream.com (CJ Aronson) Date: Sat, 21 Sep 2013 20:27:33 -0600 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523CAE53.9090508@umn.edu> Message-ID: Randy, You can choose to not listen to whomever you want but this is right from the RIPE webpage. This text below does not state that a requirement to participate is that one must "operate in the RIPE region". Have a great weekend! -----Cathy ----------------------------------------- RIPE Community RIPE (R?seaux IP Europ?ens) is a collaborative forum open to all parties interested in wide area IP networks in Europe and beyond. Randy Bush wrote: > David Farmer wrote: > > +1 to every thing Sylvain said, and -1 to proposal. > > does the university of minnesota operate in the ripe region, or just > have global opinions on how everybody else should operate? > > randy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Sun Sep 22 04:40:14 2013 From: randy at psg.com (Randy Bush) Date: Sat, 21 Sep 2013 16:40:14 -1000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523CAE53.9090508@umn.edu> Message-ID: > You can choose to not listen to whomever you want but this is right > from the RIPE webpage. This text below does not state that a > requirement to participate is that one must "operate in the RIPE > region". > > > RIPE Community > RIPE (R?seaux IP Europ?ens) is a collaborative forum open to all > parties interested in wide area IP networks in Europe and beyond. yep. but 'casting a vote' in a region where you have no presence is considered quite rude. only americans seem to do it, and are notorious, causing american opinions to be discounted in general. one would think that especially arin advisory council members would exercise manners. see you in athens? randy From packetgrrl at gmail.com Sun Sep 22 04:52:14 2013 From: packetgrrl at gmail.com (CJ Aronson) Date: Sat, 21 Sep 2013 20:52:14 -0600 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523CAE53.9090508@umn.edu> Message-ID: On Sat, Sep 21, 2013 at 8:40 PM, Randy Bush wrote: > > You can choose to not listen to whomever you want but this is right > > from the RIPE webpage. This text below does not state that a > > requirement to participate is that one must "operate in the RIPE > > region". > > > > > > RIPE Community > > RIPE (R?seaux IP Europ?ens) is a collaborative forum open to all > > parties interested in wide area IP networks in Europe and beyond. > > yep. but 'casting a vote' in a region where you have no presence is > considered quite rude. only americans seem to do it, and are notorious, > causing american opinions to be discounted in general. > > one would think that especially arin advisory council members would > exercise manners. > > I don't disagree and that's exactly why I mostly read and almost never post on this list. Although when I was RIPE member I was still treated as if my vote was somehow less important than others. Nonetheless it is everyone's right to voice their opinion regardless. > see you in athens? > > Nope I'll be in Vancouver though. Have fun in Athens! ----Cathy > randy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.blessing at despres.co.uk Sun Sep 22 11:53:04 2013 From: james.blessing at despres.co.uk (James Blessing) Date: Sun, 22 Sep 2013 10:53:04 +0100 Subject: [address-policy-wg] 2012-08 Message-ID: Support (I seem to deleted the original thread) J -- James Blessing 07989 039 476 From andy at nosignal.org Sun Sep 22 11:46:38 2013 From: andy at nosignal.org (Andy Davidson) Date: Sun, 22 Sep 2013 09:46:38 +0000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: Message-ID: Hi, Marco Schmidt wrote: > We encourage you to read the draft document text and send > any comments to address-policy-wg at ripe.net before 18 > October 2013. Support. Andy From sylvain.vallerot at opdop.net Sun Sep 22 18:25:34 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Sun, 22 Sep 2013 18:25:34 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523C3F42.3080404@fud.no> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> Message-ID: <523F19FE.6040906@opdop.net> Hi, On 20/09/2013 14:27, Tore Anderson wrote: > Conservation is the natural behaviour in an environment of scarcity. In such an environment the natural behaviour could also be that companies willing to protect their interest are ready to put money on the table to get as much ressource as they can afford. And LIRs could be tempted by selling these ressources without a need being properly justifying it. 2013-03 allows this. Yes it could look stupid if the game was over once the next /22 is filled. But... The transfer market allowing LIRs to transfer allocations, LIRs having such lucrative approach of ressource distribution could also expect to buy more ressources for clients having enough money. It looks quite obvious to me that in such conditions, small companies or non for profit organisations would have severe disadvantages, since the available stock would quite quickly disappear. > The transfer policy is in place already. If you oppose a commercial > transfer market, 2013-03 is the wrong policy proposal to attack, it is > really 2007-08 you should be going after. OK, let me reword our position then. We do not oppose to the principle of allocation transfers despite we might not be in full accordance with its current terms. But we are not welcoming deregulation. The hurt being to be expected from the conjonction of the two. Here the discussion is about 2013-03, however we consider it in the global environment and allocation transfers is part of it. We believe that in this environment, 2013-03 is nocive. We do not want public IP ressources to become deluxe products. > Also, I think it is worth noting that "giving public resources away" is > and has always been one of the (perhaps "the") primary functions of the > NCC. This is true even when the recipient is a private sector LIR who > might at a later time choose to sell the resource on the IPv4 market. There we probably have a big point of divergence. But maybe I'm wrong. However I am quite conviced that I read somewhere that IP ressources did not belong to anybody, and one was not entitled to prevail of any possession rights over it. Wich means they cannot be sold, of course. So this always made me think that the idea of an IPv4 market in itself was in violation with Ripe's rules and policies. If I am wrong and this is not the case, I will deeply reconsider the legitimacy of a private structure, in which participate only private structures, to deal with public vital ressources. > This is how things are today. 2013-03 does not change it one way or the > other. Yes it does, because it says "ok guys, we're finished with controlling the use that is made with this public ressource, just take it and let the market play". And this will impact on transfer conditions also, since these were subject to article 5.3 about additional allocation validation, that disappears with 2013-03. Ripe NCC wouldn't have allocate a new space to a LIR which had wasted the previous one or could not properly explain of ressources we used. And this still is a requirement today for the Ripe to accept a transfer if I am not mistaking myself. This would be over with 2013-03, and this would allow transfers to be asked for tomorrow, that would not be asked for today. > If you want to prohibit private sector entities from being eligible from > receiving resources from the NCC, Of course not. Please. > Furthermore, depletion is a past event in the RIPE region. It cannot be > "accelerated" (or "stopped"). The only thing that remains is the > so-called "last /8" austerity pool, and as I've pointed out above, > 2013-03 upholds the conservation policies covering this pool intact (1 > /22 per LIR; 1 /24-/22 per IXP). Depletion is a word. It is a fake. IPv4 needs proper regulation until we all live in an IPv6 world. This time has not come and in the meanwhile, /22s from last /8 *and transfers* will be the vital ressource for many. I believe free pricing of transfers is a shame, and I believe that 2013-03 drops control of allocation usage worsens its considerably. This is why I still oppose this resolution. Regards, Sylvain From gert at space.net Sun Sep 22 19:52:25 2013 From: gert at space.net (Gert Doering) Date: Sun, 22 Sep 2013 19:52:25 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523F19FE.6040906@opdop.net> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> Message-ID: <20130922175225.GB65295@Space.Net> Hi, On Sun, Sep 22, 2013 at 06:25:34PM +0200, Sylvain Vallerot wrote: > OK, let me reword our position then. [..] > We do not oppose to the principle of allocation transfers despite we > might not be in full accordance with its current terms. But we are not > welcoming deregulation. Who is "our" and "we" here, specifically? On this list, *individuals* voice their opinions... (Though I'm starting to get tempted to request full disclosure of anyone who is directly affiliated with a regional registry, as when judging consensus, I'm going to look very closely at contributions from RIR employees, board members, etc. from different regions that operate in a very different situation as far as remaining IPv4 address space is concerned.) 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 (0)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 nick at inex.ie Sun Sep 22 22:39:58 2013 From: nick at inex.ie (Nick Hilliard) Date: Sun, 22 Sep 2013 21:39:58 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <20130922175225.GB65295@Space.Net> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <20130922175225.GB65295@Space.Net> Message-ID: <523F559E.8000508@inex.ie> On 22/09/2013 18:52, Gert Doering wrote: > Who is "our" and "we" here, specifically? On this list, *individuals* > voice their opinions... I don't think it matters who "our" and "we" are. Sylvain is speaking for himself. Nick From gert at space.net Sun Sep 22 22:45:11 2013 From: gert at space.net (Gert Doering) Date: Sun, 22 Sep 2013 22:45:11 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <35CBEC3F-9F5F-47BF-B904-7346FD30FFD0@gmail.com> References: <523C7BEF.8010201@fud.no> <35E712B6-050B-4904-A37C-FDDA1B6EEB4C@gmail.com> <523CB329.6060103@fud.no> <6FA8080C-2C47-41E7-A25E-2FD937301D20@gmail.com> <9CA6E232-4F69-45A5-A9CB-D2A498F7641D@gmail.com> <523D59F1.5030700@fud.no> <523D9AC3.8040700@fud.no> <35CBEC3F-9F5F-47BF-B904-7346FD30FFD0@gmail.com> Message-ID: <20130922204511.GG65295@Space.Net> Hi, ok, this has been going on for quite a while, and I'm not sure if anyone else is following. Filiz, if I could ask you one thing: is the only reason why you're opposing 2013-03 this particular wording: On Sat, Sep 21, 2013 at 06:56:24PM +0200, Filiz Yilmaz wrote: > > Accordingly, I think following will be a more appropriate wording: > > > > 3. LIR must demonstrate its need for the IPv4 address space and must > > confirm it will make assignment(s) from the allocation. > > > > replacing what you proposed: > > 3. The LIR must confirm it will make assignment(s) from the allocation That is, if that particular sentence were changed in this specific way, you would support the policy change? As it has been a long discussion with *long* mails going back and forth, I'm fairly sure most readers have lost track what it's about, and who missed what deadline for which reason - but it would be very helpful to have a crystal clear statement here. It helps Sander and me to decide how to go forward at the end of the review phase, and it helps people that want to evaluate whether the PDP has been followed properly (as in: the WG chairs collective). thanks, 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 (0)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 nick at inex.ie Sun Sep 22 23:03:51 2013 From: nick at inex.ie (Nick Hilliard) Date: Sun, 22 Sep 2013 22:03:51 +0100 Subject: [address-policy-wg] Contributions from other RIR representatives (was: Re: 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup)) In-Reply-To: <20130922175225.GB65295@Space.Net> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <20130922175225.GB65295@Space.Net> Message-ID: <523F5B37.9010905@inex.ie> On 22/09/2013 18:52, Gert Doering wrote: > (Though I'm starting to get tempted to request full disclosure of anyone > who is directly affiliated with a regional registry, as when judging > consensus, I'm going to look very closely at contributions from RIR > employees, board members, etc. from different regions that operate in > a very different situation as far as remaining IPv4 address space is > concerned.) People who have relationships with other RIRs are part of the RIPE Community, so I don't think there are any formal grounds to dismiss their opinions when evaluating consensus. On the other hand, if someone who has a relationship with a RIR actively takes part in policy discussion in another RIR, it's easy to see how this could be seen as interference - particularly so if the person involved doesn't hold resources from or have any particular relationship to the other RIR. Difficult dilemma. I'd feel more comfortable if we could depend on peoples' tact and common sense when contributing outside their areas, rather than creating rules and guidelines to deal with the situation. The fewer rules, the better. If there are guidelines, they should be RIR organisational guidelines which apply to the RIR representatives rather than to the policy groups where they're contributing to. Nick From richih.mailinglist at gmail.com Sun Sep 22 23:12:09 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Sun, 22 Sep 2013 23:12:09 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <20130922204511.GG65295@Space.Net> References: <523C7BEF.8010201@fud.no> <35E712B6-050B-4904-A37C-FDDA1B6EEB4C@gmail.com> <523CB329.6060103@fud.no> <6FA8080C-2C47-41E7-A25E-2FD937301D20@gmail.com> <9CA6E232-4F69-45A5-A9CB-D2A498F7641D@gmail.com> <523D59F1.5030700@fud.no> <523D9AC3.8040700@fud.no> <35CBEC3F-9F5F-47BF-B904-7346FD30FFD0@gmail.com> <20130922204511.GG65295@Space.Net> Message-ID: On Sun, Sep 22, 2013 at 10:45 PM, Gert Doering wrote: > ok, this has been going on for quite a while, and I'm not sure if anyone > else is following. There are; not happily, though. > but it would be very helpful to have a > crystal clear statement here. I had a draft which asked pretty much the same. Personally, I feel as if a lot of prose is produced, but that if there are any precise and atomic points, they are lost in a sea of words. Filiz, can you try to write a proposed change which covers your concerns and give a short list of supporting arguments, please? I feel as if this would help immensely. Thanks, Richard From gert at space.net Sun Sep 22 23:28:00 2013 From: gert at space.net (Gert Doering) Date: Sun, 22 Sep 2013 23:28:00 +0200 Subject: [address-policy-wg] Contributions from other RIR representatives (was: Re: 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup)) In-Reply-To: <523F5B37.9010905@inex.ie> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <20130922175225.GB65295@Space.Net> <523F5B37.9010905@inex.ie> Message-ID: <20130922212800.GM65295@Space.Net> Hi, On Sun, Sep 22, 2013 at 10:03:51PM +0100, Nick Hilliard wrote: > On 22/09/2013 18:52, Gert Doering wrote: > > (Though I'm starting to get tempted to request full disclosure of anyone > > who is directly affiliated with a regional registry, as when judging > > consensus, I'm going to look very closely at contributions from RIR > > employees, board members, etc. from different regions that operate in > > a very different situation as far as remaining IPv4 address space is > > concerned.) > > People who have relationships with other RIRs are part of the RIPE > Community, so I don't think there are any formal grounds to dismiss their > opinions when evaluating consensus. Please don't misunderstand me. I do not want to dismiss contributions from other RIRs' staff members, AC advisory boards, etc - to the contrary, looking at our policy proposals from the outside might bring aspects into view that we've just overlooked, and policy expertise coming from other backgrounds is welcome. So if the above paragraph hinted at "I will ignore these comments", it wasn't meant that way. OTOH, when it turns out that someone has a background in policy making elsewhere, maybe my expectations on the quality of their reasoning for rejecting one of our policy proposal would be a tad higher... judging rough consensus is always subjective to some extent. 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 (0)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 koalafil at gmail.com Sun Sep 22 23:31:42 2013 From: koalafil at gmail.com (Fil) Date: Sun, 22 Sep 2013 23:31:42 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <20130922204511.GG65295@Space.Net> References: <523C7BEF.8010201@fud.no> <35E712B6-050B-4904-A37C-FDDA1B6EEB4C@gmail.com> <523CB329.6060103@fud.no> <6FA8080C-2C47-41E7-A25E-2FD937301D20@gmail.com> <9CA6E232-4F69-45A5-A9CB-D2A498F7641D@gmail.com> <523D59F1.5030700@fud.no> <523D9AC3.8040700@fud.no> <35CBEC3F-9F5F-47BF-B904-7346FD30FFD0@gmail.com> <20130922204511.GG65295@Space.Net> Message-ID: <2E8ED7EF-69B2-4625-94B3-9FED08E2CD83@gmail.com> Hello, On 22 Sep 2013, at 22:45, Gert Doering wrote: > > Filiz, if I could ask you one thing: is the only reason why you're opposing > 2013-03 this particular wording: > Yes. > On Sat, Sep 21, 2013 at 06:56:24PM +0200, Filiz Yilmaz wrote: >>> Accordingly, I think following will be a more appropriate wording: >>> >>> 3. LIR must demonstrate its need for the IPv4 address space and must >>> confirm it will make assignment(s) from the allocation. >>> >>> replacing what you proposed: >>> 3. The LIR must confirm it will make assignment(s) from the allocation > > > That is, if that particular sentence were changed in this specific way, > you would support the policy change? > Yes. thank you Filiz From koalafil at gmail.com Mon Sep 23 00:08:57 2013 From: koalafil at gmail.com (Fil) Date: Mon, 23 Sep 2013 00:08:57 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <523C7BEF.8010201@fud.no> <35E712B6-050B-4904-A37C-FDDA1B6EEB4C@gmail.com> <523CB329.6060103@fud.no> <6FA8080C-2C47-41E7-A25E-2FD937301D20@gmail.com> <9CA6E232-4F69-45A5-A9CB-D2A498F7641D@gmail.com> <523D59F1.5030700@fud.no> <523D9AC3.8040700@fud.no> <35CBEC3F-9F5F-47BF-B904-7346FD30FFD0@gmail.com> <20130922204511.GG65295@Space.Net> Message-ID: <4FFFC37E-B043-4ADD-A4A7-606108C197F0@gmail.com> Hello, On 22 Sep 2013, at 23:12, Richard Hartmann wrote: > On Sun, Sep 22, 2013 at 10:45 PM, Gert Doering wrote: > >> ok, this has been going on for quite a while, and I'm not sure if anyone >> else is following. > > There are; not happily, though. > > >> but it would be very helpful to have a >> crystal clear statement here. > > I had a draft which asked pretty much the same. > > Personally, I feel as if a lot of prose is produced, but that if there > are any precise and atomic points, they are lost in a sea of words. > > > Filiz, can you try to write a proposed change which covers your > concerns and give a short list of supporting arguments, please? I have given my arguments for demonstration of need in general within all the mails I have sent to this thread, since July 2013. I do not have time to write up an exec summary unfortunately. I have already made the last wording suggestion a couple of days ago, re-mentioned/quoted in other mails in response to Tore, explained my motivation for it in a separate mail upon Sander's request and just re-confirmed the suggested text upon Gert's request. Below you can find my response to Sander's question, which already contains again the suggested text. Hope this helps now. Kind regards, Filiz ------------ On 21 Sep 2013, at 01:41, Filiz Yilmaz wrote: > Hello, > > On 21 Sep 2013, at 00:03, "Sander Steffann" wrote: > >> Hi Filiz, >> >> One question for clarification: >> >>> And to better address the need based concerns objecting your proposal, I >>> think you could consider taking the "intent" you mentioned above one step >>> further and have it explained to the RIPE NCC. >>> >>> Accordingly, I think following will be a more appropriate wording: >>> >>> 3. LIR must demonstrate its need for the IPv4 address space and must >>> confirm it will make assignment(s) from the allocation. >>> >>> replacing what you proposed: >>> 3. The LIR must confirm it will make assignment(s) from the allocation >> >> What is your motivation for adding the 'LIR must demonstrate its need for >> the IPv4 address space' part? > > - Demonstration brings accountability to any claim and makes the claim (of confirming the intent of making assignments) believable and supported. > [This demonstration can be as simple as a couple of sentences describing the network and business of the new LIR and does not need to come in any specific form or shape.] > > - Those who intend to lie to the RIPE NCC will be forced to be a bit more creative and work on their case harder than just clicking a combo box. Those who really have a need can explain this briefly very easily and pass the criteria without any hassle. So policy will still have some substance for some differentiation between bad and good practice. > > - RIPE NCC may be able to demonstrate and defend their position why they allocated space rightfully way better if they have to one day to some I* organisation, having received some demonstration from LIRs. The LIR may have chosen to lie and fake their demonstration but the RIR will be still have had asked the right questions to consider "need" as their justification of who gets the space. > > - Adding this may help getting agreement of those who currently object the proposal because of the complete removal of justification of need from the policy, as it is kept for allocations to new LIRs, while it is removed from assignments, which is the real bureaucracy on the LIR side. So this looks to me like a compromise between two conflicting interests/wishes. > > Filiz ------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Mon Sep 23 01:17:46 2013 From: farmer at umn.edu (David Farmer) Date: Sun, 22 Sep 2013 18:17:46 -0500 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523CAE53.9090508@umn.edu> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523CAE53.9090508@umn.edu> Message-ID: <523F7A9A.1010106@umn.edu> Gert, I want to apologize. Please accept my sincere apology for any appearance of impropriety or other process concerns created by the following email. With hindsight, I should not have sent the following email. In particular I think "-1" on the proposal was inappropriate, as I don't represent any resources within the RIPE Region. I ask you and the WG chairs to please disregard it. However, I stand behind my other email questioning Tore characterization of Sylvain's opposition to the proposal. In particular Tore's suggestion that Sylvain was simply opposing transfers in general and not the changes to transfers resulting from this proposal. I appreciate your response to that email, but I remain unconvinced by Tore's arguments in this regard. In the interest of full disclosure, I am a member of the ARIN Advisory Council, a volunteer position involved in the ARIN Policy Development Process. In my day job, I'm Senior Network Design Engineer at the University of Minnesota, and I'm the University's technical representative to many networking organizations and fora. Again, I apologize and will not be making any further comment on this proposal. Thank you. On 9/20/13 15:21 , David Farmer wrote: > +1 to every thing Sylvain said, and -1 to proposal. > > On 9/20/13 06:19 , Sylvain Vallerot wrote: >> >> Hi all, >> >> Unfortunately we do not support this new proposal, because conservation >> still is a goal to us, as IPv4 public ressource keeps being vital for >> many structures. >> >> Deregulation + commercial transfer make the ressources governed by sole >> market, which we do not agree with. We consider Ripe NCC should stay in >> its regulation role and not give public ressources away to the private >> sector and market. -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From frettled at gmail.com Mon Sep 23 07:07:41 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 23 Sep 2013 07:07:41 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <2E8ED7EF-69B2-4625-94B3-9FED08E2CD83@gmail.com> References: <523C7BEF.8010201@fud.no> <35E712B6-050B-4904-A37C-FDDA1B6EEB4C@gmail.com> <523CB329.6060103@fud.no> <6FA8080C-2C47-41E7-A25E-2FD937301D20@gmail.com> <9CA6E232-4F69-45A5-A9CB-D2A498F7641D@gmail.com> <523D59F1.5030700@fud.no> <523D9AC3.8040700@fud.no> <35CBEC3F-9F5F-47BF-B904-7346FD30FFD0@gmail.com> <20130922204511.GG65295@Space.Net> <2E8ED7EF-69B2-4625-94B3-9FED08E2CD83@gmail.com> Message-ID: On Sun, Sep 22, 2013 at 11:31 PM, Fil wrote: > Hello, > > On 22 Sep 2013, at 22:45, Gert Doering wrote: > > > > Filiz, if I could ask you one thing: is the only reason why you're > opposing > > 2013-03 this particular wording: > > > > Yes. > > > On Sat, Sep 21, 2013 at 06:56:24PM +0200, Filiz Yilmaz wrote: > >>> Accordingly, I think following will be a more appropriate wording: > >>> > >>> 3. LIR must demonstrate its need for the IPv4 address space and must > >>> confirm it will make assignment(s) from the allocation. > >>> > >>> replacing what you proposed: > >>> 3. The LIR must confirm it will make assignment(s) from the allocation > > > > > > That is, if that particular sentence were changed in this specific way, > > you would support the policy change? > > > > Yes. > > Thank you, Gert, for asking the penetrating question, and thank you, Filiz, for the succinct response. Before this, I had read through the proposal and a whole bunch of emails again in order to try to understand what Filiz was on about, and had I just waited a day, this would have been a huge time saver. :) -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogerj at gmail.com Mon Sep 23 08:56:07 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Mon, 23 Sep 2013 08:56:07 +0200 Subject: [address-policy-wg] Contributions from other RIR representatives (was: Re: 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup)) In-Reply-To: <523F5B37.9010905@inex.ie> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <20130922175225.GB65295@Space.Net> <523F5B37.9010905@inex.ie> Message-ID: On Sun, Sep 22, 2013 at 11:03 PM, Nick Hilliard wrote: > On 22/09/2013 18:52, Gert Doering wrote: >> (Though I'm starting to get tempted to request full disclosure of anyone >> who is directly affiliated with a regional registry, as when judging >> consensus, I'm going to look very closely at contributions from RIR >> employees, board members, etc. from different regions that operate in >> a very different situation as far as remaining IPv4 address space is >> concerned.) > > People who have relationships with other RIRs are part of the RIPE > Community, so I don't think there are any formal grounds to dismiss their > opinions when evaluating consensus. > > On the other hand, if someone who has a relationship with a RIR actively > takes part in policy discussion in another RIR, it's easy to see how this > could be seen as interference - particularly so if the person involved > doesn't hold resources from or have any particular relationship to the > other RIR. > > Difficult dilemma. I'd feel more comfortable if we could depend on > peoples' tact and common sense when contributing outside their areas, > rather than creating rules and guidelines to deal with the situation. The > fewer rules, the better. If there are guidelines, they should be RIR > organisational guidelines which apply to the RIR representatives rather > than to the policy groups where they're contributing to. +1 to Nick's post, but I'd like to add that we should be happy that other RIR take interest in discussions going on in our region, and if they chose to post that is also mostly a good thing. They might give us a broader view of thing, add some elements to the discussion we don't see in our RIPE-land mindset? Then there is that line between contributing and trying to influence because it in the end will suite their own goal. So far have I read the posts from "outside" RIPE land more as contributing than trying to influence. -- 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 Sep 23 10:56:04 2013 From: gert at space.net (Gert Doering) Date: Mon, 23 Sep 2013 10:56:04 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523F7A9A.1010106@umn.edu> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523CAE53.9090508@umn.edu> <523F7A9A.1010106@umn.edu> Message-ID: <20130923085604.GT65295@Space.Net> Hi David, On Sun, Sep 22, 2013 at 06:17:46PM -0500, David Farmer wrote: > I want to apologize. Please accept my sincere apology for any > appearance of impropriety or other process concerns created by the > following email. With hindsight, I should not have sent the following > email. In particular I think "-1" on the proposal was inappropriate, as > I don't represent any resources within the RIPE Region. I ask you and > the WG chairs to please disregard it. Thanks for clarifying, and no need for apologies. I have the feeling we all got somewhat lost in the heat of the debate :-) Anyway, your comments are certainly welcome, and I think Tore and the WG chairs might want to revisit parts of the discussion. 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 (0)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 sylvain.vallerot at opdop.net Mon Sep 23 11:59:55 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Mon, 23 Sep 2013 11:59:55 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523F559E.8000508@inex.ie> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <20130922175225.GB65295@Space.Net> <523F559E.8000508@inex.ie> Message-ID: <5240111B.2050607@opdop.net> On 22/09/2013 22:39, Nick Hilliard wrote: > On 22/09/2013 18:52, Gert Doering wrote: >> Who is "our" and "we" here, specifically? On this list, *individuals* >> voice their opinions... > > I don't think it matters who "our" and "we" are. Sylvain is speaking for > himself. Yes you can say that. I will stick with first person from now on, sorry for the confusion. Best regards, Sylvain From cja at daydream.com Sun Sep 22 04:46:26 2013 From: cja at daydream.com (CJ Aronson) Date: Sat, 21 Sep 2013 20:46:26 -0600 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523CAE53.9090508@umn.edu> Message-ID: On Sat, Sep 21, 2013 at 8:40 PM, Randy Bush wrote: > > You can choose to not listen to whomever you want but this is right > > from the RIPE webpage. This text below does not state that a > > requirement to participate is that one must "operate in the RIPE > > region". > > > > > > RIPE Community > > RIPE (R?seaux IP Europ?ens) is a collaborative forum open to all > > parties interested in wide area IP networks in Europe and beyond. > > yep. but 'casting a vote' in a region where you have no presence is > considered quite rude. only americans seem to do it, and are notorious, > causing american opinions to be discounted in general. > > one would think that especially arin advisory council members would > exercise manners. > I don't disagree and that's exactly why I mostly read and almost never post on this list. Although when I was RIPE member I was still treated as if my vote was somehow less important than others. Nonetheless it is everyone's right to voice their opinion regardless. > > see you in athens? > Nope I'll be in Vancouver though. Have fun in Athens! ----Cathy -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe.address-policy-wg at ml.karotte.org Mon Sep 23 13:32:36 2013 From: ripe.address-policy-wg at ml.karotte.org (Sebastian Wiesinger) Date: Mon, 23 Sep 2013 13:32:36 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <201309191448.r8JEm4oR009019@danton.fire-world.de> References: <201309191448.r8JEm4oR009019@danton.fire-world.de> Message-ID: <20130923113236.GB20757@danton.fire-world.de> * Marco Schmidt [2013-09-19 16:48]: > > Dear Colleagues, > > Following the feedback received, the draft documents for the proposal > described in 2013-03 (No Need - Post-Depletion Reality Adjustment and Cleanup) > are edited and published. I support this proposal. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From nick at inex.ie Mon Sep 23 13:46:09 2013 From: nick at inex.ie (Nick Hilliard) Date: Mon, 23 Sep 2013 12:46:09 +0100 Subject: [address-policy-wg] Contributions from other RIR representatives In-Reply-To: <20130922212800.GM65295@Space.Net> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <20130922175225.GB65295@Space.Net> <523F5B37.9010905@inex.ie> <20130922212800.GM65295@Space.Net> Message-ID: <52402A01.8030406@inex.ie> On 22/09/2013 22:28, Gert Doering wrote: > Please don't misunderstand me. I do not want to dismiss contributions > from other RIRs' staff members, AC advisory boards, etc - to the contrary, > looking at our policy proposals from the outside might bring aspects into > view that we've just overlooked, and policy expertise coming from other > backgrounds is welcome. yep, exactly. It's a difficult balance to get right. Standard rules of common sense and diplomacy apply. Nick From sylvain.vallerot at opdop.net Mon Sep 23 14:26:27 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Mon, 23 Sep 2013 14:26:27 +0200 Subject: [address-policy-wg] Contributions from other RIR representatives In-Reply-To: References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <20130922175225.GB65295@Space.Net> <523F5B37.9010905@inex.ie> Message-ID: <52403373.7090807@opdop.net> On 23/09/2013 08:56, Roger J?rgensen wrote: > So far have I read the posts from "outside" RIPE land more as > contributing than trying to influence. So do I, since in the seek of a rought consensus the point is not of being a lot of people anyway, but to have evereyone's concerns properly exposed, understood, and evaluated. Regarding this I fear my very poor english doesn't help me to get perfectly understood, which in my opinion makes english native writers's rewording and explaning really welcome, wherever they stay. I would'nt restrict their contributions to that of course, but I consider this helpful in the discussions. And also, as Goert objected to me lately while I was speaking with "we" or "us" : "On this list, *individuals* voice their opinions..." so I think everybody's contribution is worth reading and understanding, whatever RIR they are related to (and how). Regarding the number of Ripe members, we do not have a very large participation on theses lists, so I believe that a voice making the effort to formulate a contribution is worth listening. Maybe even more carefully when it is from outside the region because it brings other's experience despite having no interest in this. Best regards, Sylvain From nick at inex.ie Mon Sep 23 14:35:01 2013 From: nick at inex.ie (Nick Hilliard) Date: Mon, 23 Sep 2013 13:35:01 +0100 Subject: [address-policy-wg] Contributions from other RIR representatives In-Reply-To: <52403373.7090807@opdop.net> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <20130922175225.GB65295@Space.Net> <523F5B37.9010905@inex.ie> <52403373.7090807@opdop.net> Message-ID: <52403575.3070107@inex.ie> On 23/09/2013 13:26, Sylvain Vallerot wrote: > to formulate a contribution is worth listening. Maybe even more carefully > when it is from outside the region because it brings other's experience > despite having no interest in this. +1 Nick From Olaf.Sonderegger at abraxas.ch Mon Sep 23 14:34:03 2013 From: Olaf.Sonderegger at abraxas.ch (Sonderegger Olaf ABRAXAS INFORMATIK AG) Date: Mon, 23 Sep 2013 12:34:03 +0000 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) Message-ID: <7C49C19C69319E4FB1279CA15A84D18B61DC4076@SAX20244.bia.abraxas.ch> Hi all. +1. I support this proposal. Best regards, Olaf From tore at fud.no Mon Sep 23 16:23:44 2013 From: tore at fud.no (Tore Anderson) Date: Mon, 23 Sep 2013 16:23:44 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523F19FE.6040906@opdop.net> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> Message-ID: <52404EF0.1070506@fud.no> Hi Sylvain, > On 20/09/2013 14:27, Tore Anderson wrote: >> Conservation is the natural behaviour in an environment of scarcity. > > In such an environment the natural behaviour could also be that companies > willing to protect their interest are ready to put money on the table to > get as much ressource as they can afford. I agree - when, and only when, the companies actually *need* the resource in the first place - precisely "to protect their interest". In this case, 2013-03 brings no change from today - such companies are eligible for the being a transfer recipient already. So the ones 2013-03 actually makes a difference for, are companies that have no need and no interest in the resource. What I do not understand, is why anyone would expect that a company that has no need and no interest in IPv4 address space would go out and buy some. Especially, considering that the market demand *dwarfs* the supply, these companies could not pick it them up "a dime a dozen", they would have actually outbid all of those companies that do *need* it - desperately. To me this behaviour seems completely irrational and thus completely unlikely to occur. It's kind of like buying milk if you're lactose intolerant or petrol if you don't have a car. > And LIRs could be tempted by selling these ressources without a need being properly justifying it. (I am assuming we are talking about an LIR's assignment to its End User's here?) As above, why would you expect an End User to buy an assignment (in itself, this is completely OK by today's policy BTW) if he has no need for it? > 2013-03 allows this. Yes it could look stupid if the game was over once > the next /22 is filled. But... > > The transfer market allowing LIRs to transfer allocations, LIRs having > such lucrative approach of ressource distribution could also expect to > buy more ressources for clients having enough money. > > It looks quite obvious to me that in such conditions, small companies > or non for profit organisations would have severe disadvantages, since > the available stock would quite quickly disappear. Yes, this is the natural outcome of a market. However, it is a natural outcome of *today's* market, it is not something brought on by 2013-03. It is already the case *today* that big and wealthy ISPs or corporations with lots of money to spend has a huge advantage over small and non-profit organisations. Today, the RIPE NCC does not make a "priority" list over organisations that are eligible for transfers. In other words, the RIPE NCC will do *nothing* to help the small/non-profit organisations to get what they need from the available market offerings before the big and wealthy ones gets to scoop up the rest. The small and non-profit organisations are on their own, and they are already today in a pretty hopeless situation. > We do not oppose to the principle of allocation transfers despite we > might not be in full accordance with its current terms. But we are not > welcoming deregulation. > > The hurt being to be expected from the conjonction of the two. Here the > discussion is about 2013-03, however we consider it in the global > environment and allocation transfers is part of it. > > We believe that in this environment, 2013-03 is nocive. The only way I can see that 2013-03 would worsen the environment we already have, is if those that have no need for IPv4 address space suddenly starts wanting it and trying to buy it. I just do not see why that would happen. But - for the sake of the argument, let's say that it would happen. That there actually are LIRs, or organisations willing to be come LIRs, that 1) have no need for IPv4 addresses, yet 2) are willing to spend a lot of money on IPv4 addresses. These organisations would need to be *very* resourceful and motivated - keep in mind that they would not have to outbid only small and non-profit organisations, they would also need to outbid the state telcos and big ISPs etc. that do have both "need" *and* lots of money to spend. If these highly motivated and resourceful organisations really do exist, I do not see that they would be significantly hindered by today's "need" requirement in getting what they want. Creating need is easy. The only thing they would need to do is to find one or more organisations that *do* need address space, and make a deal to loan/lease (by assigning) the address space they do manage to buy on the market back to them - because once an LIR has deals and documentation in place to make assignments totalling N addresses, it has also "justified need" for receiving allocations totalling N addresses. Today, more than one year after the NCC ran out, it ought not to be difficult to find End Users willing to receive assignments. 97% of the demand isn't being met by the market. I'm convinced those that do need, but currently aren't getting any, would leap at the opportunity. So in summary I don't really see that our current policy can do much to stop such "non-needy" rich organisations from entering the market in the first place, and therefore I do not really see that 2013-03 would contribute much to opening the door for them significantly more than it already is. While it is true that under 2013-03 they wouldn't have to assign away the address space to End Users, if their motivation for entering the market is to make a profit, I would expect them to be planning to lease out anything they manage to get in anyway - which, as described above, is allowed today. > We do not want public IP ressources to become deluxe products. I sympathise, but I am afraid that train left the platform as of 2007-08 and got up to cruising speed on 2012-09-14. The folks with the deepest pockets gets to fight over the resources, and the small and poor are Shit Outta Luck. That's the world we live in *today*, and I don't see how 2013-03 could reasonably be expected to worsen this situation. > There we probably have a big point of divergence. But maybe I'm wrong. > However I am quite conviced that I read somewhere that IP ressources > did not belong to anybody, and one was not entitled to prevail of any > possession rights over it. Wich means they cannot be sold, of course. > > So this always made me think that the idea of an IPv4 market in itself > was in violation with Ripe's rules and policies. > > If I am wrong and this is not the case, I will deeply reconsider the > legitimacy of a private structure, in which participate only private > structures, to deal with public vital ressources. No, you are quite right. IPv4 addresses are not property in a legal sense. See Article 10.2 the RIPE NCC Standard Service Agreement (ripe-533). So in the case of an allocation transfer, what is being sold is not the addresses themselves, but the right to maintain the allocation - pursuant to the SSA and the RIPE Community's policies. I think of it in the same way that sometimes when a tenant that wants to move is permitted to transfer his tenancy contract to a new tenant; they don't transfer ownership of house/apartment itself, only the right to live there. > I believe free pricing of transfers is a shame, and I believe that 2013-03 > drops control of allocation usage worsens its considerably. > > This is why I still oppose this resolution. I can empathise with you not wanting a situation where money and hard capitalism rules and the small players gets squished out. But that's what we have today, and I do not agree that 2013-03 will significantly change this for the worse (or better ). If you truly want to improve this situation, the only way to go about it that I can see is to submit a policy proposal that simply deletes the section titled "Transfers of Allocations". Such a proposal would not in conflict with 2013-03; "deregulating the market" is not one of its goals. FWIW, the only reason why "need" is being removed for transfers, is that when you remove "need" for assignments (which *is* the goal), "need" at the allocation level becomes a meaningless concept, because the latter builds on the former. Best regards, Tore Anderson From malcolm at linx.net Mon Sep 23 17:54:14 2013 From: malcolm at linx.net (Malcolm Hutty) Date: Mon, 23 Sep 2013 16:54:14 +0100 Subject: [address-policy-wg] 2013-03: Good enough? In-Reply-To: <20130923113236.GB20757@danton.fire-world.de> References: <201309191448.r8JEm4oR009019@danton.fire-world.de> <20130923113236.GB20757@danton.fire-world.de> Message-ID: <52406426.8080405@linx.net> Dear all, Gert has prompted me to reply to the proposal on the table, to confirm whether it meets my earlier objections. Firstly, I'd like to apologise again for not paying closer attention sooner. My thanks again to the co-chairs and to Tore for their hard work and diligence in trying to achieve a consensus. This proposal has gone through three drafts, and I doubt anyone has much appetite for another. Since it seems there is not going to be unanimity, the co-chairs have the unenviable job of determining whether all the reasoned objections have been fully addressed, or whether consensus is simply not available on this issue at the current time. So as someone (Randy?) said weeks ago, the question isn't whether I like this proposal, the question is whether it's good enough, that is, not so seriously flawed as to justify standing in the way of a clear majority so as to prevent a rough consensus? The TL;DR is that I am now willing to withdraw my objection, but would ask that you change the title to remove the words "No need", agree to changes as to how this is presented externally, and to support further work as part of a new PDP. If that is agreeable (and I hope it can be done without going to Version 4, as I am not suggesting any change to the policy itself from Version 3), I would agree my points have been fully addressed and need not stand in the way of announcing a finding of consensus. In case others should be interested, I shall set out more fully my reasons for changing my position before elaborating what I hope will be a compromise everyone could support. It is true that I have never been persuaded by the arguments advanced for this proposal. Sylvain did a demolition job on them (2013-09-20 13:19 UTC+2), and I share many of the same views. However, I don't work at the coalface of allocation requests, as many here who support this policy do. I don't think my being un-persuaded on this is good enough reason to block the policy. Much of what McTim wrote I also agree with, especially this: > Needs based distribution has been a cornerstone of the RIR system > for the last 2 decades or more. It has worked remarkably well, and I > see no need to jettison it now just because there are fewer resources > to distribute. In fact, I see a greater need for it now! I expect > we will have to agree to disagree on this. However he also said: > The primary issue there is incompatibility with other regional > transfer policies. Gert replied that inter-regional compatibility was a closed issue: > I do have the prerogative to ignore certain topics voiced as reason > for opposition to a proposal if I consider them suitably addressed, > and there is sufficient support for a proposal otherwise. > > This is what I did: I consider this point to be suitably addressed, > given the very specific fact that we do not have a cross-RIR > transfer policy today, and this community has not shown interest in > working on one. I am in agreement with Gert on this aspect. Given that we do not have a cross-RIR transfer policy, are not going to get one imminently, and that reverting 2013-03 would be possible as part of the process of creating one, I don't think incompatibility with ARIN is sufficient reason to say No. That leaves the issues that were always the heart of my objection, the political (and possibly legal) impact. My reading of the original NCC Impact Assessment was that the competition law issues were a concern, but not a grave risk: much more serious was the political impact on the credibility of the RIR system of throwing away all basis for a claim that the way the RIRs operate is in the public interest. The latest version of the Impact Analysis says > External Relations > > Adoption of this policy would have a major impact on RIPE NCC > External Relations, and would require the investment of considerable > resources in messaging and defending/explaining this policy shift to > stakeholders both inside and outside the technical community. > Additionally, these activities would need to target not only > stakeholders within the RIPE NCC service region, but also those in > other RIR communities. That's a pretty serious warning, and I think it corroborates everything I have said on this subject. On the previous draft, what concerned me most was the appearance of the RIPE Community abandoning all claim to regulate allocation on the basis of need. This would be tantamount to giving up the RIPE Community's right to create new policies in future on the basis that market effects are causing severe operational problems. Not being able to create new policies to address new problems would be politically unacceptable: if the RIPE Community would not do it, then governments would have to step in. Version 3 provides the compromise Tore offered me: make dealing with those future issues a problem for another day; "kick the can down the road". Do not let those future problems stand in the way of this proposal which is (by assertion) needed now - but retain a placeholder so that we do not close the door on revisiting this issue in the future, if we need to do so. That placeholder is the new assertion in the policy of "fairness", an undefined term. At the moment this either stands in as a loose and probably unenforceable token for the current normative standards, or it has no practical effect on everyday operations at all. But it does have one key virtue: it asserts the community's right to adjust the current policy on the basis of protecting what the community, by consensus, agrees to be fair. That may turn out to be crucial, if we need to respond to problems that may arise in the future. Is that good enough? I think it should be, if we are willing to work together. So I propose the following compromise: 1. 2013-03 be retitled to remove "no need" from the title. Those words are highly detrimental to the NCC's External Relations work, and add nothing useful. 2. No other changes are made to the proposal itself. 3. The accompanying notes, which are not part of the proposal itself but which are a part of the external messaging, should be re-written. The current version of these notes unhelpfully emphasises the removal of the requirement to demonstrate need, as if need were becoming irrelevant. They should describe the effect of 2013-03, which is to remove the *upfront documentation* of need (a form of ex ante regulation), while retaining the concept of fairness, as defined by the community, as a goal of allocation policy. It should be emphasised that the community retains the right to introduce new policies in the future, if deemed necessary, to ensure that this deregulatory initiative does not bring about unfairness. 4. AP-WG should (later, but soon) consider a new policy, as part of a new PDP, that asserts that the fairness goal makes it an objective to maximise the availability of IP addresses for use, and asserts as a community view that it is not fair to artificially restrict supply by hoarding for speculative purposes. The proposal might stop at that, and we could wait until there was evidence of hoarding to create any enforcement mechanism. Alternatively, we could consider introducing an ex post rather than ex ante enforcement. i.e. where someone would have to complain that a given LIR was hoarding before anything could be done, and the NCC could investigate and if necessary that LIR (and only that LIR) would have to justify their need. This would be quite different to the current situation, where every LIR must prove their need up front. Having in place a policy like that outlined in (4) would in my view substantially mitigate the serious political risk referred to in the Impact Analysis, while at the same time achieving the aim of reducing mostly-unnecessary bureaucracy that is the goal of 2013-03. Doing (4) as a new PDP would take it off the critical path for 2013-03, and would also allow the principles expressed therein to be expressed as an interpretive guide to other policies e.g. 2007-08, if thought appropriate. Of course, it is always open to any member of the community to draft a new proposal for a new PDP. What I am asking is that the proposers of 2013-03 support that process, as being an appropriate way of ensuring the reduction in application bureaucracy in 2013-03 does not have the effect of undermining the core values the RIPE community has upheld for decades, rather than criticising such a proposal as being a reversal of "no need". Version 3 of 2013-03 would allow us to move in that direction, if the presentation of how it is introduced is cleaned up. So if these steps are taken, I am willing to accept that my objection has been fully answered and need not stand in the way of a finding of rough consensus. Malcolm. -- 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 sylvain.vallerot at opdop.net Mon Sep 23 18:24:49 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Mon, 23 Sep 2013 18:24:49 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <52404EF0.1070506@fud.no> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <52404EF0.1070506@fud.no> Message-ID: <52406B51.2060208@opdop.net> On 23/09/2013 16:23, Tore Anderson wrote: >> And LIRs could be tempted by selling these ressources without a need >> being properly justifying it. > > (I am assuming we are talking about an LIR's assignment to its End > User's here?) You are right, this is what this discussion is all about : documenting the needs is about assignments, which occurs between LIR and End Users. This is where conservation and needs-based policy make sens. > As above, why would you expect an End User to buy an assignment (in > itself, this is completely OK by today's policy BTW) if he has no need > for it? Because it is a good placement to survive, when you can get the ressource and others can't, they die and you survive. Being a CEO the survival of my company and its ability to have necessary ressources during scarcity periods is a main concern. Fortunately enough my business is not using much IP ressource. Several of my clients do however, and some would be glad to get a /22 to be more "in confidence", while they can hardly justify a /24. > It is already the case *today* that big and wealthy ISPs or corporations > with lots of money to spend has a huge advantage over small and > non-profit organisations. Yes but I do not want to see it worsen, because of... what for by the way? I did not retain many supporting arguments from the rationale. > Today, the RIPE NCC does not make a "priority" list over organisations > that are eligible for transfers. In other words, the RIPE NCC will do > *nothing* to help the small/non-profit organisations to get what they > need from the available market offerings before the big and wealthy ones > gets to scoop up the rest. The small and non-profit organisations are on > their own, and they are already today in a pretty hopeless situation. Which is bad enough. > The only way I can see that 2013-03 would worsen the environment we > already have, is if those that have no need for IPv4 address space > suddenly starts wanting it and trying to buy it. I just do not see why > that would happen. Because 2013-03 allows it : End Users won't have to justify their needs anymore. Simple as that. Might not happen (in a perfect world), but do we choose the right timing to open such a pandora's box here ? And again, for what benefit ? Just spare a little time on documentation. > FWIW, the only reason why "need" is being removed for transfers, > is that when you remove "need" for assignments (which *is* the goal), > "need" at the allocation level becomes a meaningless concept, because > the latter builds on the former. Of course, yes (except for the goal). BTW it works the other way round : would you allow wasting of allocations (obviously last /8 policy does not) ? if not, you should not allow wasting of assignments. Simple logic. A->B is equivalent to /B->/A Best regards, Sylvain From drc at virtualized.org Mon Sep 23 19:16:00 2013 From: drc at virtualized.org (David Conrad) Date: Mon, 23 Sep 2013 10:16:00 -0700 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <52404EF0.1070506@fud.no> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <52404EF0.1070506@fud.no> Message-ID: Tore, On Sep 23, 2013, at 7:23 AM, Tore Anderson wrote: > What I do not understand, is why anyone would expect that a company that has no need and no interest in IPv4 address space would go out and buy some. http://en.wikipedia.org/wiki/Speculation Regards, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From frettled at gmail.com Mon Sep 23 19:48:44 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 23 Sep 2013 19:48:44 +0200 Subject: [address-policy-wg] 2013-03: Good enough? In-Reply-To: <52406426.8080405@linx.net> References: <201309191448.r8JEm4oR009019@danton.fire-world.de> <20130923113236.GB20757@danton.fire-world.de> <52406426.8080405@linx.net> Message-ID: On Mon, Sep 23, 2013 at 5:54 PM, Malcolm Hutty wrote: ? (I did read it all) ? > > The TL;DR is that I am now willing to withdraw my objection, but would > ask that you change the title to remove the words "No need", agree to > changes as to how this is presented externally, and to support further > work as part of a new PDP. > I think your point of view is very well expressed, and even sensible. I think your suggestion for going forward is constructive, and will probably mitigate the risk you highlighted from the impact analysis. I don't know what the proper procedure would be for handling this, but you've got my support. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From frettled at gmail.com Mon Sep 23 19:53:15 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 23 Sep 2013 19:53:15 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <52404EF0.1070506@fud.no> Message-ID: On Mon, Sep 23, 2013 at 7:16 PM, David Conrad wrote: > Tore, > > On Sep 23, 2013, at 7:23 AM, Tore Anderson wrote: > > What I do not understand, is why anyone would expect that a company that > has no need and no interest in IPv4 address space would go out and buy some. > > http://en.wikipedia.org/wiki/Speculation > That, and to hoard/safeguard for possible future use. It happened time and again before we reached the last /8, and I think it would be very weird if it hasn't happened under the current policy. It will also continue to happen under the current policy, if this proposal should fall. I think that is one of the things that the opponents ? including Sylvain ? keep forgetting or ignoring, that everything that's wrong (in their eyes) with the _consequences_ of the proposal, is _already happening_ and has been happening for quite some time. I have a very hard time believing that people will _cease_ speculating or hoarding/safeguarding just because this proposal wouldn't get implemented. And the effort of having to put a few more words somewhere will not change that. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Mon Sep 23 20:48:46 2013 From: tore at fud.no (Tore Anderson) Date: Mon, 23 Sep 2013 20:48:46 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <52404EF0.1070506@fud.no> Message-ID: <52408D0E.3040908@fud.no> * David Conrad > On Sep 23, 2013, at 7:23 AM, Tore Anderson wrote: >> What I do not understand, is why anyone would expect that a company >> that has no need and no interest in IPv4 address space would go out >> and buy some. > > http://en.wikipedia.org/wiki/Speculation We have a 24-month cooling-off period in our transfer policy where a recently received allocation may not be transferred further. I am not sure that I would agree that this is a ?short or medium term? (as it says in the linked-to specification) investment horizon, when we're talking about IPv4. I believe this cooling-off period in itself works as a deterrence against some that would otherwise be interested in engaging in speculation, at least the short-term kind. Nevertheless, it would certainly be possible to engage in more long-term (24 months ++) speculation or "investment" into the IPv4 market. However, as the ulterior motive for any speculator/investor LIR is financial gain, I highly doubt that they would simply "sit on" their inventory for the 24 months required by policy. Rather, I think they would try to make them generate a revenue stream in that period - by leasing them out, for example. In doing so, they would actually be performing the core duty of any LIR and thus end up having "justified need" as valid as any other. While it is true that their End Users (i.e., the lessees) under 2013-03 would not require "need", I highly doubt that an organisation that do not have any need would be interested leasing IPv4 in the first place. There are no shortage of organisations that do have plenty of need in the region; those are the ones that would be willing to actually pay for leasing IPv4 in the first place. So what I think it all comes down to is that the IPv4 market under 2013-03 won't be significantly different from the IPv4 market we have today. Best regards, Tore Anderson From lists-ripe at c4inet.net Mon Sep 23 21:41:57 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 23 Sep 2013 20:41:57 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <52408D0E.3040908@fud.no> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <52404EF0.1070506@fud.no> <52408D0E.3040908@fud.no> Message-ID: <20130923194157.GA40432@cilantro.c4inet.net> On Mon, Sep 23, 2013 at 08:48:46PM +0200, Tore Anderson wrote: >Nevertheless, it would certainly be possible to engage in more long-term >(24 months ++) speculation or "investment" into the IPv4 market. >However, as the ulterior motive for any speculator/investor LIR is >financial gain, I highly doubt that they would simply "sit on" their >inventory for the 24 months required by policy. Rather, I think they >would try to make them generate a revenue stream in that period - by >leasing them out, for example. In doing so, they would actually be >performing the core duty of any LIR and thus end up having "justified >need" as valid as any other. Besides, IPv4 is a pretty dodgy investment. At some stage, IPv6 deployment will have to gain proper traction (if only because the cost of aquiring IPv4 space has become prohibitive) and ipv4 will overnight become worthless. Tbh, one of my motivations for supporting this proposal is that I would like to see IPv4 finally run out, because otherwise we will never see IPv6 deployment take off... rgds, Sascha Luck From lists-ripe at c4inet.net Mon Sep 23 21:54:03 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 23 Sep 2013 20:54:03 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <52406B51.2060208@opdop.net> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <52404EF0.1070506@fud.no> <52406B51.2060208@opdop.net> Message-ID: <20130923195403.GB40432@cilantro.c4inet.net> On Mon, Sep 23, 2013 at 06:24:49PM +0200, Sylvain Vallerot wrote: >You are right, this is what this discussion is all about : documenting >the needs is about assignments, which occurs between LIR and End Users. >This is where conservation and needs-based policy make sens. Assignments to end-users will likely continue to be "needs"-based. Owing to the very scarcity of the resource, a LIR has an interest to make the IPv4 space they still have last as long as possible (and, presumably, to sell it as dearly as possible, too) The Invisible Hand will take care of this one... >Might not happen (in a perfect world), but do we choose the right timing >to open such a pandora's box here ? It is *exactly* the right time. IPv4 is gone. >And again, for what benefit ? Just spare a little time on documentation. Just to spare a *lot* of unproductive paperwork. Which, in all honesty, is 90% lies anyway. I want to run networks, not concoct documentation that will make a RA happy. rgds, Sascha Luck From nick at inex.ie Mon Sep 23 23:43:42 2013 From: nick at inex.ie (Nick Hilliard) Date: Mon, 23 Sep 2013 22:43:42 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <52408D0E.3040908@fud.no> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <52404EF0.1070506@fud.no> <52408D0E.3040908@fud.no> Message-ID: <5240B60E.8050503@inex.ie> On 23/09/2013 19:48, Tore Anderson wrote: > We have a 24-month cooling-off period in our transfer policy where a > recently received allocation may not be transferred further. I am not > sure that I would agree that this is a ?short or medium term? (as it > says in the linked-to specification) investment horizon, when we're > talking about IPv4. I believe this cooling-off period in itself works as > a deterrence against some that would otherwise be interested in engaging > in speculation, at least the short-term kind. I'm not sure why you think this will act as a deterrent to resource transfers, given that we all generally agree that increasing bureaucratic load will generally only serve to push transfer agreements underground. Nick From randy at psg.com Tue Sep 24 01:13:06 2013 From: randy at psg.com (Randy Bush) Date: Mon, 23 Sep 2013 13:13:06 -1000 Subject: [address-policy-wg] black market transfers In-Reply-To: <5240B60E.8050503@inex.ie> Message-ID: > I'm not sure why you think this will act as a deterrent to resource > transfers, given that we all generally agree that increasing > bureaucratic load will generally only serve to push transfer > agreements underground. i am not disagreeing (or agreeing, for that matter) with your assertion. i have a different question, though it is intuitively appealing. as a researcher, how might i measure such a change? how might i tell if some piece of address space has been transferred on the black market? randy From sylvain.vallerot at opdop.net Tue Sep 24 01:21:18 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Tue, 24 Sep 2013 01:21:18 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <20130923194157.GA40432@cilantro.c4inet.net> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <52404EF0.1070506@fud.no> <52408D0E.3040908@fud.no> <20130923194157.GA40432@cilantro.c4inet.net> Message-ID: <5240CCEE.1060203@opdop.net> On 23/09/2013 21:41, Sascha Luck wrote: > Tbh, one of my motivations for supporting this proposal is that I > would like to see IPv4 finally run out, because otherwise we will > never see IPv6 deployment take off... Sasha, IPv4 will, undoubtedly, eventually run out. The question is, is it going to be a soft landing for everybody, or a brutal crash. Landing is usually not an operation during which one pushes motors and invite passengers to detach seatbelts. For everyone's safety I would expect from Ripe NCC, that this process happens in an as controlled as possible manner, requiring everyone's care and self-discipline, garbage-collecting as much unused ressources as possible for those who need them, and requiring every one to be more conservative than ever. We have a "low regime" since last /8 policy is on. But what is that fantasy all of a sudden, to relax measures that had been ruling or everyday life since ages ? I understand your wish : when landing is approaching I just can't wait and I want it to be done because of some irrational fear deep inside. But much more than I want to urge this, I want the pilot to stay calm, everybody to sit and be quite, and nobody gets hurt. Best regards, Sylvain From randy at psg.com Tue Sep 24 02:23:35 2013 From: randy at psg.com (Randy Bush) Date: Mon, 23 Sep 2013 14:23:35 -1000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <5240CCEE.1060203@opdop.net> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <52404EF0.1070506@fud.no> <52408D0E.3040908@fud.no> <20130923194157.GA40432@cilantro.c4inet.net> <5240CCEE.1060203@opdop.net> Message-ID: > IPv4 will, undoubtedly, eventually run out. ipv4 will be around after everyone on this list today is retired. this is not a happy thing. but the arrogant and ops-clue-free fools who designed ipv6 have doomed us to this state. any fool who tells you ipv4 is irrelevant should please make their systems ipv6 only so we no longer have to read their fantasies. what is happening is that the iana and the rirs are are being disintermediated. they are less and less directly involved in the users' (isps and end sites) acquisition of ipv4 space. these monopoly hoarders of integers are losing their hoards. we would like it if the registries acted as registries, i.e. recorded accurately who controls/owns what address space. we thought that was their primary responsibility. the registry system has a choice. it can make it difficult for users to register, transfer, saut?, whatever address space, in which case they have some chance at a reasonable level of accuracy in their registries, or they can make it difficult. in the latter case, they will become vestigial organs whose function we will soon not even be able to remember. and we sure as heck won't be sending money to them. the choice is ours. today, dealing with the registries' petty rules and bureaucracy is a major pita. this policy proposal tries to make it easier. it really makes small difference what we choose. the internet will route around whatever impediments we place. it's a big river now. randy From swmike at swm.pp.se Tue Sep 24 03:57:41 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 24 Sep 2013 03:57:41 +0200 (CEST) Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <5240CCEE.1060203@opdop.net> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <52404EF0.1070506@fud.no> <52408D0E.3040908@fud.no> <20130923194157.GA40432@cilantro.c4inet.net> <5240CCEE.1060203@opdop.net> Message-ID: On Tue, 24 Sep 2013, Sylvain Vallerot wrote: > IPv4 will, undoubtedly, eventually run out. The question is, is it > going to be a soft landing for everybody, or a brutal crash. > > We have a "low regime" since last /8 policy is on. But what is that > fantasy all of a sudden, to relax measures that had been ruling or > everyday life since ages ? Right now, the only thing you need to do to get a /22 out of that /8 is to do a little administration and pay money to RIPE. I don't understand why you think that having RIPE require pre-depletion style paperwork when this just doesn't reflect reality anymore is going to help anything. Individual LIRs just cannot hurt the global resource depletion rate by waste anymore, at least not in the RIPE region. Let's cut down on paperwork for everybody by accepting this policy. -- Mikael Abrahamsson email: swmike at swm.pp.se From ij at beevpn.com Mon Sep 23 16:52:31 2013 From: ij at beevpn.com (Ian Johannesen) Date: Mon, 23 Sep 2013 16:52:31 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <523b0e24.c5510f0a.45be.ffffcd1bSMTPIN_ADDED_MISSING@mx.google.com> References: <523b0e24.c5510f0a.45be.ffffcd1bSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <4E2FD296-1FDC-4169-ABE2-16912AC56C7B@beevpn.com> Hi all, > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 18 October 2013. +1 for this proposal Best regards, Ian Johannesen From hph at oslo.net Tue Sep 24 09:00:22 2013 From: hph at oslo.net (Hans Petter Holen) Date: Tue, 24 Sep 2013 09:00:22 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <52404EF0.1070506@fud.no> <52408D0E.3040908@fud.no> <20130923194157.GA40432@cilantro.c4inet.net> <5240CCEE.1060203@opdop.net> Message-ID: On Tuesday, September 24, 2013, Randy Bush wrote: > > IPv4 will, undoubtedly, eventually run out. > > ipv4 will be around after everyone on this list today is retired. Very good point. I can hate it - but I would not bet much on you beeing wrong - even if I am going to retire a few years after you. (...) > we would like it if the registries acted as registries, i.e. recorded > accurately who controls/owns what address space. we thought that was > their primary responsibility Fully agree. the registry system has a choice. it can make it difficult for users > to register, transfer, saut?, whatever address space, in which case > they have some chance at a reasonable level of accuracy in their > registries, or they can make it difficult. in the latter case, they > will become vestigial organs whose function we will soon not even be > able to remember. and we sure as heck won't be sending money to them. > > the choice is ours. today, dealing with the registries' petty rules > and bureaucracy is a major pita. this policy proposal tries to make > it easier. Since the start of my first encounter with the RIR Ripe 20 years ago we have gradualy reduced the documentation to demonstrate the need for addressess (have had to send receipts for equipment and such a couple times - we do not do that anymore) - thus there is more trust in the LIRs self assesment of need than it used to be. I think the important shift now is that this proposal actualy transfers the responsibility for conservation fully to the LIR - much in the same way as the responsibility for aggregation has been with the LIR for years. (in the end of 80s the central registry even tried to look after aggregation by delivering a then class B - now /16 instead of 4 class C /24) I would argue that we have a strong tradition to move in the direction of deregulation ad more trust in the LIR in this region > it really makes small difference what we choose. the internet will > route around whatever impediments we place. it's a big river now. Right. It is probably fairly easy to transfer IP Addressess from company A to B in most regions trough other means : company -A forms subcidiary A-registry ltd. A-registry Ltd is sold to B and then merged with B. Just is slightly more expensive and keeps the lawyers busy. Actualy - in my country I think I could to the legal work myself - its not that complicated. (and i have a real life example for a /8 that has made its way from Norway in the RIPE region to USA in arin Arin region this way - in a slightly more complicated manner with a few more steps). A side effect of allowing addresses to be more or less freely tranfered is that it could actualy bring more addresses to the market - when early adopers figure out that they can run their entire corporate/governmet network on private addresses between a NAT keeping only their servers offering public services on public addresses - the same way as most companies has had to do for years. As soon as the market price is higher than the cost to redesign and renumber this will start to happen. We should probably take this further and split the policy in 3: - a clear registration policy that applies to everybody and requires addresses to be registered - a transfer policy - focusing on proper identification and authorisation of transfers - an assignment policy for the last /8 from the RIR and whatever address space was returned I belive that if we want to have _need_ included in the policies it should be in the last two - and we need to come up with a needs criteria and documentation of such that can be audited by an independent party - if we want theese to have some real world legitimacy. I think. > randy - hph PS: At the last ICANN meeting the US GAC representative read a long prepared statement on freedom and as little regulation as possible. -- 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 randy at psg.com Tue Sep 24 10:42:53 2013 From: randy at psg.com (Randy Bush) Date: Mon, 23 Sep 2013 22:42:53 -1000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <52404EF0.1070506@fud.no> <52408D0E.3040908@fud.no> <20130923194157.GA40432@cilantro.c4inet.net> <5240CCEE.1060203@opdop.net> Message-ID: > PS: At the last ICANN meeting the US GAC representative read a long > prepared statement on freedom and as little regulation as possible. is there an emoticon for tragic extreme irony? randy From fredrik at resilans.se Tue Sep 24 11:37:40 2013 From: fredrik at resilans.se (Fredrik Widell) Date: Tue, 24 Sep 2013 11:37:40 +0200 (CEST) Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: Message-ID: On Fri, 20 Sep 2013, Daniel Stolpe wrote: > > On Thu, 19 Sep 2013, Randy Bush wrote: > >> > We encourage you to read the draft document text and send any comments >> > to address-policy-wg at ripe.net before 18 October 2013. >> >> and once more unto the breach, dear friends, once more >> >> +1 > > +1 Support here aswell. > > Cheers, > > 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 > > > -- Mvh Fredrik Widell Resilans AB http://www.resilans.se/ mail: info at resilans.se , fredrik at resilans.se phone: +46 8 688 11 82 From richih.mailinglist at gmail.com Tue Sep 24 12:18:33 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Tue, 24 Sep 2013 12:18:33 +0200 Subject: [address-policy-wg] 2013-03: Good enough? In-Reply-To: References: <201309191448.r8JEm4oR009019@danton.fire-world.de> <20130923113236.GB20757@danton.fire-world.de> <52406426.8080405@linx.net> Message-ID: On Mon, Sep 23, 2013 at 7:48 PM, Jan Ingvoldstad wrote: > I think your suggestion for going forward is constructive, and will probably > mitigate the risk you highlighted from the impact analysis. Personally, I feel that point 3) smells a bit like fluff. It's well-known that changes can be proposed and implemented given community support. Stating that in the notes on the process of such a change seems superfluous. Along similar lines, ensuring overall fairness is an oft-stated, and obvious, goal. Pointing it out again in the spirit of consensus can't hurt, either. > I don't know what the proper procedure would be for handling this, but > you've got my support. Ideally, Malcolm or you would start a new PDP to implement the changes you want to see. -- Richard From tore at fud.no Tue Sep 24 12:36:30 2013 From: tore at fud.no (Tore Anderson) Date: Tue, 24 Sep 2013 12:36:30 +0200 Subject: [address-policy-wg] 2013-03: Good enough? In-Reply-To: <52406426.8080405@linx.net> References: <201309191448.r8JEm4oR009019@danton.fire-world.de> <20130923113236.GB20757@danton.fire-world.de> <52406426.8080405@linx.net> Message-ID: <52416B2E.7020602@fud.no> Hello Malcolm, > The TL;DR is that I am now willing to withdraw my objection, but would > ask that you change the title to remove the words "No need", agree to > changes as to how this is presented externally, and to support further > work as part of a new PDP. I'm very happy to hear that! I think you will find that I am willing to work constructively with you on finding solutions to your requests. I'll respond in more detail below. > The latest version of the Impact Analysis says > >> External Relations >> >> Adoption of this policy would have a major impact on RIPE NCC >> External Relations, and would require the investment of considerable >> resources in messaging and defending/explaining this policy shift to >> stakeholders both inside and outside the technical community. >> Additionally, these activities would need to target not only >> stakeholders within the RIPE NCC service region, but also those in >> other RIR communities. > > That's a pretty serious warning, and I think it corroborates everything > I have said on this subject. I don't really see this as a warning, but more a statement of fact. 2013-03 is undeniably a large policy change, and as such it is only to be expected that it will require a correspondingly large effort in external messaging. That does not necessarily mean that it is a *bad* policy change, or that delivering this message would make the RIPE NCC and/or Community "look bad". Put it another way, I think the above paragraph could just as well have been written about 2010-02 (the "last /8" policy). For what it's worth, I have it on good authority that the RIPE NCC Board is much happier about version 3 then they were about version 2. It is worth noting that the Board section in the Impact Analysis went from being full of warnings in the previous version, to being almost absent from the current version. > So I propose the following compromise: > > 1. 2013-03 be retitled to remove "no need" from the title. Those words > are highly detrimental to the NCC's External Relations work, and add > nothing useful. Assuming this does not trigger the need for the NCC to do yet another Impact Analysis, and the Working Group from running another review period (I agree 100% with what you wrote about not having the appetite for that), I have no problems with this at all. The "No Need" moniker was just meant as a nickname for the proposal anyway. From my point of view ("the coalface of assignment requests"), it's descriptive, but I can accept that from other points of view it may appear glib. So then we're left with the title ?Post-depletion reality adjustment and cleanup?, then? > 2. No other changes are made to the proposal itself. NO WAY! UNACCEPTABLE! ...oh, okay then. I suppose can let you have that one. ;-D > 3. The accompanying notes, which are not part of the proposal itself but > which are a part of the external messaging, should be re-written. > The current version of these notes unhelpfully emphasises the removal of > the requirement to demonstrate need, as if need were becoming > irrelevant. They should describe the effect of 2013-03, which is to > remove the *upfront documentation* of need (a form of ex ante > regulation), while retaining the concept of fairness, as defined by the > community, as a goal of allocation policy. It should be emphasised that > the community retains the right to introduce new policies in the future, > if deemed necessary, to ensure that this deregulatory initiative does > not bring about unfairness. Same condition as for #1, as long as it doesn't require another IA, I have problem with this. For what it's worth, I've always considered the rationale text of a proposal more a starting point for the ensuing WG discussion, one that's necessarily biased by the proposer's reasons for submitting the proposal in the first place. There are certainly those who have both opposed and supported proposal for other reasons than those I thought to mention in the accompanying notes. For this reason I wouldn't expect the NCC's External Relations team to feel limited to echoing my specific points made in the proposal notes when creating their slide decks, but also take the WG's deliberations into account, messages such as yours in particular. In any case, I'd need your help with this. You clearly have a pretty good idea of what parts of the notes stand out as "offensive", and what messages are missing. Are you coming to Athens? If so, maybe we could book a meeting room and sit down with the Chairs, someone from the External Relations team, and any other WG members who might be interested in participating here - collaborate on an improved text right there on the projector, and have a version 4 that could be published when going into the final PDP phase. > 4. AP-WG should (later, but soon) consider a new policy, as part of a > new PDP, that asserts that the fairness goal makes it an objective to > maximise the availability of IP addresses for use, and asserts as a > community view that it is not fair to artificially restrict supply by > hoarding for speculative purposes. I have absolutely no problem with this - 2013-03 was never intended as an RIPE equivalent of APNIC's prop-103. I can promise you that I would contribute constructively to such an effort, but I cannot promise that I will spearhead it - simply because I have no good ideas on how the mechanisms that enforces this fairness would look like in a post-depletion world. The "all you can eat buffet" mechanism we had before, obviously doesn't work today when there's no longer enough food around to satiate everyone: https://www.facebook.com/photo.php?fbid=10151520241646002&set=t.754215401&type=3&theater Also, I think I'll need to recuperate for a while before spearheading another RIPE policy proposal. :-) I'm not sure we do need to assert that "hoarding is unfair" in the policy, though. The EU Competition Law analysis that was prepared for the previous version of the proposal suggest that this practise is not only "unfair", but illegal as well. While I have no principal objection to this being stated in the policy too, it does feel a bit redundant to repeat what's the law anyway, especially considering that the police and the courts has much more efficient tools at their disposal to actually enforce the law than the RIPE NCC has. As an added bonus, keep in mind that this community does not foot the bill for the EU prosecutor's attorneys, while we do for the RIPE NCC's. Best regards, Tore Anderson From tore at fud.no Tue Sep 24 13:38:17 2013 From: tore at fud.no (Tore Anderson) Date: Tue, 24 Sep 2013 13:38:17 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <5240B60E.8050503@inex.ie> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <52404EF0.1070506@fud.no> <52408D0E.3040908@fud.no> <5240B60E.8050503@inex.ie> Message-ID: <524179A9.5060907@fud.no> * Nick Hilliard > On 23/09/2013 19:48, Tore Anderson wrote: >> We have a 24-month cooling-off period in our transfer policy where a >> recently received allocation may not be transferred further. I am not >> sure that I would agree that this is a ?short or medium term? (as it >> says in the linked-to specification) investment horizon, when we're >> talking about IPv4. I believe this cooling-off period in itself works as >> a deterrence against some that would otherwise be interested in engaging >> in speculation, at least the short-term kind. > > I'm not sure why you think this will act as a deterrent to resource > transfers, given that we all generally agree that increasing bureaucratic > load will generally only serve to push transfer agreements underground. Hi Nick, First off, I did not say I believe it will act as a deterrent to resource transfers in general, only against the speculative kind - i.e., when an LIR buys an allocation one day for ?N hoping to sell it for >?N a month later - all while having no intention on using the addresses for something in the interim. Such activity is simply not sanctioned by the address policy. The above presumes that the "speculator LIRs" in question will adhere to our address policy, of course. If you start out with the presumption that the "speculator LIRs" will ignore address policy anyway, the whole discussion on the policy's preventive effect against speculators is moot. Secondly, I did not say "will" in future tense, nor did I suggest that this is an *increased* bureaucratic load brought by 2013-03. The 24-month quarantine is there in today's policy, 2013-03 doesn't touch it. The WG could of course debate whether or not the 24-month quarantine itself makes sense or should be removed due to it only contributing to the creation of a "black market", but that's food for another policy proposal. Finally, and just for the record: I do not think the 24-month quarantine is a deterrent to resource transfers to "conventional" LIRs that intend to use the addresses for their End Users and/or their own infrastructure. 24 months is probably a shorter period than the depreciation period of the equipment the addresses would typically be assigned to in this case. Best regards, Tore Anderson From hph at oslo.net Tue Sep 24 13:47:51 2013 From: hph at oslo.net (Hans Petter Holen) Date: Tue, 24 Sep 2013 13:47:51 +0200 Subject: [address-policy-wg] black market transfers In-Reply-To: References: Message-ID: <52417BE7.4050602@oslo.net> On 24.09.2013 01:13, Randy Bush wrote: > as a researcher, how might i measure such a change? how might i tell if > some piece of address space has been transferred on the black market? If we have a strong registry policy and everybody sees the value of keeping the registry updated you look it up in the registry. (must be documented to be a legitimate transaction authorized by the appropriate registrant.) ((but then the colour of the market is probably not meaningful)) If we don't I guess you could look at changes in origin AS, change of hosts and traffic pattern etc.. - but you would have a large error margin both ways. Hans Petter From tore at fud.no Tue Sep 24 14:09:21 2013 From: tore at fud.no (Tore Anderson) Date: Tue, 24 Sep 2013 14:09:21 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <52406B51.2060208@opdop.net> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <52404EF0.1070506@fud.no> <52406B51.2060208@opdop.net> Message-ID: <524180F1.10702@fud.no> Hi Sylvain, Sascha already responded to some of your points, so I'll leave those at that, but I wanted to respond to this one in particular: > Because it is a good placement to survive, when you can get the > ressource and others can't, they die and you survive. Being a CEO the > survival of my company and its ability to have necessary ressources > during scarcity periods is a main concern. Fortunately enough my > business is not using much IP ressource. Several of my clients do > however, and some would be glad to get a /22 to be more "in > confidence", while they can hardly justify a /24. You, as an LIR hostmaster, are completely free to tell this client of yours ?No, you cannot get more than you need, therefore I will only be assigning you a /24 for now. Come back later when you need more.? 2013-03 does not disenfranchise you in any way from doing so. As for what reason to give to the client if he insists on being assigned the /22, the most obvious one you pointed out yourself - being conservative and restrictive about your LIR's remaining IPv4 inventory is essential for your company's future ability to take on new customers and thus its long-term ability to survive. Your survival is in your client's best interest too; his continued use of the addresses you assign him, however many, depends on it. However, you can also point to the address policy when declining the request, by telling your client something along the lines of: ?Giving you a /22 you do not need would be unfair to my future would-be customers, as I would have then have nothing to assign to them. The RIPE address policy mandates that the assignments I make are done fairly, thus I am not at liberty to assign you the /22 you are asking for?. While the fairness requirement in question is a subjective value judgement you will have to make for yourself, your prior messages to this list leaves me with the impression that the above explanation would be fully compatible with your value judgement on what fairness in assignments looks like. Best regards, Tore Anderson From hph at oslo.net Tue Sep 24 13:30:55 2013 From: hph at oslo.net (Hans Petter Holen) Date: Tue, 24 Sep 2013 13:30:55 +0200 Subject: [address-policy-wg] 2013-03: Good enough? In-Reply-To: <52416B2E.7020602@fud.no> References: <201309191448.r8JEm4oR009019@danton.fire-world.de> <20130923113236.GB20757@danton.fire-world.de> <52406426.8080405@linx.net> <52416B2E.7020602@fud.no> Message-ID: <524177EF.8040902@oslo.net> On 24.09.2013 12:36, Tore Anderson wrote: > we're left with the title ?Post-depletion reality adjustment and > cleanup?, then? +1 -hph From info at leadertelecom.ru Tue Sep 24 14:16:40 2013 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Tue, 24 Sep 2013 16:16:40 +0400 Subject: [address-policy-wg] [Ticket#2013092401023461] 2013-03: Good enough? In-Reply-To: <524177EF.8040902@oslo.net> References: <524177EF.8040902@oslo.net><201309191448.r8JEm4oR009019@danton.fire-world.de> <20130923113236.GB20757@danton.fire-world.de> <52406426.8080405@linx.net> <52416B2E.7020602@fud.no> Message-ID: <1380024999.310071.290981658.336720.2@otrs.hostingconsult.ru> I support proposal 2013-03. -- Alexey Ivanov LeaderTelecom -------------- next part -------------- An HTML attachment was scrubbed... URL: From frettled at gmail.com Tue Sep 24 14:36:22 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 24 Sep 2013 14:36:22 +0200 Subject: [address-policy-wg] 2013-03: Good enough? In-Reply-To: <524177EF.8040902@oslo.net> References: <201309191448.r8JEm4oR009019@danton.fire-world.de> <20130923113236.GB20757@danton.fire-world.de> <52406426.8080405@linx.net> <52416B2E.7020602@fud.no> <524177EF.8040902@oslo.net> Message-ID: On Tue, Sep 24, 2013 at 1:30 PM, Hans Petter Holen wrote: > On 24.09.2013 12:36, Tore Anderson wrote: > >> we're left with the title ?Post-depletion reality adjustment and >> cleanup?, then? >> > +1 > That looks good to me, too. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.vallerot at opdop.net Tue Sep 24 16:18:45 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Tue, 24 Sep 2013 16:18:45 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <524180F1.10702@fud.no> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <52404EF0.1070506@fud.no> <52406B51.2060208@opdop.net> <524180F1.10702@fud.no> Message-ID: <52419F45.4080405@opdop.net> Tore, Your message does not answer my concerns, unfortunately. I am not talking about my case because my particular case is of interest, but only to illustrate how LIRs have to face with some demanding customer who do not really care about fairness, but rather about survival in a situation of scarcity. On 24/09/2013 14:09, Tore Anderson wrote: > However, you can also point to the address policy when declining the > request, by telling your client something along the lines of: ?Giving > you a /22 you do not need would be unfair to my future would-be > customers, as I would have then have nothing to assign to them. The RIPE > address policy mandates that the assignments I make are done fairly, > thus I am not at liberty to assign you the /22 you are asking for?. > > While the fairness requirement in question is a subjective value > judgement you will have to make for yourself, Subjective is the word. And conservation goal being removed, and the requirement of justificating assignments being removed also, the LIR becomes in the very incomfortable situation of having to oppose "fair subjective" criteria to a client's request, without being able to back on a RIR's policy anymore. But besides that, I feel this would be a regretable abdication of its regulator role for the Ripe NCC, to authorize any LIR to make whatever they want with the remaining ressource. And because of the consequences this abdication may have on many companies or organisations that will have to face de-regulated behaviors despite we are in a situation of scarcity, I cannot help but consider such a decision will make us (the Ripe community) responsible for some tragic situations. I remember the question of Ripe's responsability had been raised some time ago, maybe it was at Ripe's 65 meeting, last year. I was about the role Ripe had to play, not only as a a private association with its LIR members voting for their interest, but as the owner of a monopolistic power to distribute a vital ressource. And I regret today, that such questions arises again, and so many easy +1 supports go to a proposal for even more deregulation in a crisis situation. I think we have a legitimacy problem for doing this. Best regards, Sylvain From dogwallah at gmail.com Tue Sep 24 16:59:19 2013 From: dogwallah at gmail.com (McTim) Date: Tue, 24 Sep 2013 10:59:19 -0400 Subject: [address-policy-wg] 2013-03: Good enough? In-Reply-To: <52406426.8080405@linx.net> References: <201309191448.r8JEm4oR009019@danton.fire-world.de> <20130923113236.GB20757@danton.fire-world.de> <52406426.8080405@linx.net> Message-ID: Hi Malcolm, On Mon, Sep 23, 2013 at 11:54 AM, Malcolm Hutty wrote: > Much of what McTim wrote I also agree with, especially this: >> Needs based distribution has been a cornerstone of the RIR system >> for the last 2 decades or more. It has worked remarkably well, and I >> see no need to jettison it now just because there are fewer resources >> to distribute. In fact, I see a greater need for it now! I expect >> we will have to agree to disagree on this. > > However he also said: >> The primary issue there is incompatibility with other regional >> transfer policies. Just to be precise "there" in that sentence referred to the impact analysis. My main objection to the proposal is the removal of documented need. I agree with Filiz that some text like: "3. LIR must demonstrate its need for the IPv4 address space and must confirm it will make assignment(s) from the allocation." is essential, because, as she said previously: "- Demonstration brings accountability to any claim and makes the claim (of confirming the intent of making assignments) believable and supported. [This demonstration can be as simple as a couple of sentences describing the network and business of the new LIR and does not need to come in any specific form or shape.]" My rational for this is that the RIRs have always "rationed" resources. the wikipedia definition of rationing is here: http://en.wikipedia.org/wiki/Rationing This "controlled distribution of scarce resources" has always used the demonstration of need as a prerequisite for allocation. In the last /8 phase, we are using a different rationing method. I don't see the logic whereby demonstrating need can be eliminated, as it stands to reason (to me at least) that in a situation of dwindling resources, distribution requirements should be tighter, not looser. This is not traditionalism for the sake of it, it is just my instinct to be more conservative in the face of dwindling resources. For the record, I do not have a policy role, paid or unpaid in any RIR region. I am however serving out my last term on the AFRINIC Nominations Committee this year. I have zero financial interest in any IP block. I think however that having folk from other regions giving input to the PDP is a feature, not a bug. > > > So I propose the following compromise: > > 1. 2013-03 be retitled to remove "no need" from the title. Those words > are highly detrimental to the NCC's External Relations work, and add > nothing useful. +1 > > 2. No other changes are made to the proposal itself. > see #3 above for the change I would like to see. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From sylvain.vallerot at opdop.net Tue Sep 24 17:50:42 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Tue, 24 Sep 2013 17:50:42 +0200 Subject: [address-policy-wg] 2013-03: Good enough? In-Reply-To: <52406426.8080405@linx.net> References: <201309191448.r8JEm4oR009019@danton.fire-world.de> <20130923113236.GB20757@danton.fire-world.de> <52406426.8080405@linx.net> Message-ID: <5241B4D2.8040605@opdop.net> On 23/09/2013 17:54, Malcolm Hutty wrote: > Is that good enough? > I think it should be, if we are willing to work together. So beautiful :-) I was (sincerely) quite "touched" by what Malcolm wrote and proposed, and also his ability to reach the expected rought consensus inside his own head. Please read this at first degree : I am not sarcastic and I do not want my bad english be miss-interpreted, I am sincere. I wish I could too, but unfortunately "supporting arguments" still miss, whereas deregulation obsesses me a little bit. * Malcoms makes some good points however, by proposing the solution of removing the upfront documentation while maintaining the capacity of control of the NCC, thus making fair (still to be defined) use of the ressources a necessity for LIRs, and also ensure they can provide proper documentation when requested to do so. before, after, on-demand ... Who knows anyway how it is made today, with AW ? But what is the difference, actually, between gathering the information and making the proper documentation when you do things, or trying to make it late and under pressure months or years later ? It seems quite obvious to me that, if proper documentation has to be produced on day, the only way is to make it on time. But, OK, whatever suspicious I can be regarding this, why not let each one deal with its paperwork organisation. This also leads me to request a bit more precision : what is the documentation one would expect ? This question also concerns the proposal Filiz made recently, and McTim just recalled : "3. LIR must demonstrate its need for the IPv4 address space and must confirm it will make assignment(s) from the allocation." What demonstration, what documentation ? Note : this is about needs for IP addresse space (not for "an allocation"), and this is about needs for addresses not yet granted by the RIR to the LIR, so we are in a very different context here, from Malcom's post documentation which is about already assigned IP space. And to finish on this point I would personnaly be reassured by knowing that this "past need" on-demand documentation would *quite probably* be requested to justify that past allocations where properly used, and before a new allocation or transfer can be granted. Which might have some encouraging effect. But this would need to be written somewhere. Which brings me to my second point. * My other concern is that point 4. does not modifiy the proposal, but calls for another PDP and another proposal, while agreeing for this one that remain, by definition, not satisfying. Well, I do not see the point of having a separate PDP, if it has to go though the same process anyway. I think they should be merged, so that both give a consensus, or none of them. I would +1 Richard on this, since "promisses only tie those who believe them" (litterally translated from French, sorry), we know what 2013-03 removes, we don't have a clue about what a new PDP will bring. * I feel sorry about exposing more problems that proposing solutions for the proposal. But from my view it is difficult to have a fondamentally wrong idea changed into something acceptable, even by many corrections. Unfortunately Malcoms very constructive contribution and proposition does not solve the problems inside 2013-03, and 2013-03 remains what it is, whatever the PDPs we could imagine to amend it : if we want to amend it so much, then maybe we should not pass it. Best regards, Sylvain From frettled at gmail.com Tue Sep 24 20:05:56 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 24 Sep 2013 20:05:56 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <52419F45.4080405@opdop.net> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <52404EF0.1070506@fud.no> <52406B51.2060208@opdop.net> <524180F1.10702@fud.no> <52419F45.4080405@opdop.net> Message-ID: On Tue, Sep 24, 2013 at 4:18 PM, Sylvain Vallerot < sylvain.vallerot at opdop.net> wrote: > > Tore, > > Your message does not answer my concerns, unfortunately. I am not > talking about my case because my particular case is of interest, > but only to illustrate how LIRs have to face with some demanding > customer who do not really care about fairness, but rather about > survival in a situation of scarcity. To put it bluntly: If a LIR's *survival* now depends on how the specific bureaucratic justification of "need" is formulated for a remaining 1024 IPv4 addresses, then that LIR has lost its way, and has no viable business prospects regardless of what policy we set forth in this WG. Any LIR with a sound business plan has already taken the steps necessary to focus on IPv6. You are probably right in one thing, though: end customers and end users don't care about other's resource problems, they only care about their own. As a group, they have an insatiable sense of need. However, the RIRs are not directly in touch with these end customers and end users, and have no way of judging what is fair, what is (real) need, or what is even justifiable. The LIRs have direct contact, and have a better sense of these things. I don't think your deregulation argument makes much sense. Leaving more responsibility with the LIR is not deregulation, it's a different kind of organisation, but it's still regulated, and in a way that makes practical sense. The LIR model is, in many ways, similar to the registrar model ? in domain name registrations, the registries (the RIRs of domain names) don't meddle with day to day registrations, they leave that to the registrars, and rightly so. As opposed to IPv4 registrations, domain name registrations are in a perpetual state of scarcity, so the similarity to IPv4 depletion proper is more than skin deep. > > But besides that, I feel this would be a regretable abdication of its > regulator role for the Ripe NCC, to authorize any LIR to make whatever > they want with the remaining ressource. > I'm sorry, I don't see how this proposal grants a LIR the power "to make whatever they want". > And because of the consequences this abdication may have on many > companies or organisations that will have to face de-regulated behaviors > despite we are in a situation of scarcity, I cannot help but consider > such a decision will make us (the Ripe community) responsible for some > tragic situations. > > I remember the question of Ripe's responsability had been raised some > time ago, maybe it was at Ripe's 65 meeting, last year. I was about the > role Ripe had to play, not only as a a private association with its LIR > members voting for their interest, but as the owner of a monopolistic > power to distribute a vital ressource. And I regret today, that such > questions arises again, and so many easy +1 supports go to a proposal > for even more deregulation in a crisis situation. I think we have a > legitimacy problem for doing this. > > On what possible grounds do you assume that our "+1" supports are EASY? You imply that only you have thought this through, and that those who just state that they agree have not. I find this unnecessarly offensive, that you cannot state your arguments without making such implication. We are, as far as I know, professionals with a particular *interest* in the policies, that is why we subscribe to this group. I wouldn't dare to assume that anyone here have not read and thought through the implications and consequences. I think you just have to face the fact that most people have thought this through, and that we simply disagree with your assessment. I also think you're over-dramatising, and are far too much concerned with selecting the preferred arrangement of deck chairs on the Titanic instead of figuring out how to best use the life boats. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.vallerot at opdop.net Tue Sep 24 20:29:11 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Tue, 24 Sep 2013 20:29:11 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <52404EF0.1070506@fud.no> <52406B51.2060208@opdop.net> <524180F1.10702@fud.no> <52419F45.4080405@opdop.net> Message-ID: <5241D9F7.8040702@opdop.net> Hi, On 24/09/2013 20:05, Jan Ingvoldstad wrote: > On what possible grounds do you assume that our "+1" supports are EASY? Because it's so short to write and not develop :-) +1 and you're done here. -1 requires long developments and a lot of repetition, as you may have noticed. But it is the game, OK, support is easier to formulate. This comes from the system of someone writing a proposal and this is a "positive" move, so going the counterway requires more writing (and may might seem counter-productive) while going the same direction obviously does not require to re-write the "pro" arguments that are already in the proposal. This is where I regret by the way, the assymetry between supporting and opposing arguments in the rationale. > You imply that only you have thought this through, and that those who just > state that they agree have not. > I find this unnecessarly offensive, that you cannot state your arguments > without making such implication. OK I must admit this is was bit rude, so please accept my apologies. But this was not intedned as personal offense, I appreciate when I am on the other side an just need to say +1 :-) Best regards, Sylvain From sandrabrown at ipv4marketgroup.com Wed Sep 25 14:45:27 2013 From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com) Date: Wed, 25 Sep 2013 05:45:27 -0700 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) Message-ID: <20130925054527.ec289651d84890fcbef5f195936e1217.eb4f6ec6ed.wbe@email17.secureserver.net> +1 ..... I support this proposal. Best Regards, Sandra Brown From dcunningham at airspeed.ie Wed Sep 25 15:54:46 2013 From: dcunningham at airspeed.ie (Donal Cunningham) Date: Wed, 25 Sep 2013 13:54:46 +0000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <20130925054527.ec289651d84890fcbef5f195936e1217.eb4f6ec6ed.wbe@email17.secureserver.net> References: <20130925054527.ec289651d84890fcbef5f195936e1217.eb4f6ec6ed.wbe@email17.secureserver.net> Message-ID: +1 - I support this proposal. D. -- IP Network Engineer, AirSpeed Telecom dcunningham at airspeed.ie : +353 1 428 7531 From achatz at forthnetgroup.gr Wed Sep 25 16:54:27 2013 From: achatz at forthnetgroup.gr (Tassos Chatzithomaoglou) Date: Wed, 25 Sep 2013 17:54:27 +0300 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <20130925054527.ec289651d84890fcbef5f195936e1217.eb4f6ec6ed.wbe@email17.secureserver.net> Message-ID: <5242F923.70501@forthnetgroup.gr> Support! I would have enjoyed even more cleanup! -- Tassos From mike at iptrading.com Wed Sep 25 17:33:40 2013 From: mike at iptrading.com (Mike Burns) Date: Wed, 25 Sep 2013 11:33:40 -0400 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <20130925054527.ec289651d84890fcbef5f195936e1217.eb4f6ec6ed.wbe@email17.secureserver.net> Message-ID: <92722655DE9648B68C9BFA6D6562F1DF@MPC> +1 I support this proposal and hope that if it passes, policymakers at ARIN take note of the fact that both registries who have reached exhaust have recognized that removing the needs test from transfers is completely compatible with the ideals of stewardship. We know that APNIC was browbeaten into restoring the needs test in order to tap the ARIN market. There will be similar pressure applied to RIPE, I am sure, but for my part I will pressure ARIN to remove its needs test for transfers as the best way to facilitate a global market in IPv4 address space. RIPE's implementation of 2013-03 would assist in that effort. Regards, Mike Burns IPTrading.com -----Original Message----- From: Donal Cunningham Sent: Wednesday, September 25, 2013 9:54 AM To: 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 Cleanup) +1 - I support this proposal. D. -- IP Network Engineer, AirSpeed Telecom dcunningham at airspeed.ie : +353 1 428 7531 From jcurran at arin.net Wed Sep 25 18:34:26 2013 From: jcurran at arin.net (John Curran) Date: Wed, 25 Sep 2013 16:34:26 +0000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <92722655DE9648B68C9BFA6D6562F1DF@MPC> References: <20130925054527.ec289651d84890fcbef5f195936e1217.eb4f6ec6ed.wbe@email17.secureserver.net> <92722655DE9648B68C9BFA6D6562F1DF@MPC> Message-ID: <6F9CDDBF-80FD-4DE2-BF18-FACD908860A1@corp.arin.net> On Sep 25, 2013, at 11:33 AM, Mike Burns wrote: > +1 I support this proposal and hope that if it passes, policymakers at ARIN take note of the fact that both registries who have reached exhaust have recognized that removing the needs test from transfers is completely compatible with the ideals of stewardship. We know that APNIC was browbeaten into restoring the needs test in order to tap the ARIN market. There will be similar pressure applied to RIPE, I am sure, but for my part I will pressure ARIN to remove its needs test for transfers as the best way to facilitate a global market in IPv4 address space. RIPE's implementation of 2013-03 would assist in that effort. Mike - It's probably best to address those in the community interested in ARIN policy (i.e. "policymakers at ARIN") via the ARIN Public Policy Mailing List (ppml); that's where policy-related ideas and issues surrounding ARIN policies are discussed by the community, and hence where such notice should be made. To submit a policy proposal for discussion, please follow the directions here - (Any folks in the RIPE community interested in such discussions are quite welcome to participate on the ppml mailing list.) Thanks! /John John Curran President and CEO ARIN From mike at iptrading.com Wed Sep 25 18:52:38 2013 From: mike at iptrading.com (Mike Burns) Date: Wed, 25 Sep 2013 12:52:38 -0400 Subject: [address-policy-wg] 2013-03 New Draft Document and ImpactAnalysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <6F9CDDBF-80FD-4DE2-BF18-FACD908860A1@corp.arin.net> References: <20130925054527.ec289651d84890fcbef5f195936e1217.eb4f6ec6ed.wbe@email17.secureserver.net><92722655DE9648B68C9BFA6D6562F1DF@MPC> <6F9CDDBF-80FD-4DE2-BF18-FACD908860A1@corp.arin.net> Message-ID: <45FD40E04F0043A19EDF4D5D2CDE7B07@MPC> John, You know I am the author of the current ARIN transfer policy. Why clutter the RIPE list with this nonsense? I voiced my support of 2013-03 and addressed the counter-argument related to inter-regional transfers. This will end my replies. Regards, Mike -----Original Message----- From: John Curran Sent: Wednesday, September 25, 2013 12:34 PM To: Mike Burns Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2013-03 New Draft Document and ImpactAnalysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) On Sep 25, 2013, at 11:33 AM, Mike Burns wrote: > +1 I support this proposal and hope that if it passes, policymakers at > ARIN take note of the fact that both registries who have reached exhaust > have recognized that removing the needs test from transfers is completely > compatible with the ideals of stewardship. We know that APNIC was > browbeaten into restoring the needs test in order to tap the ARIN market. > There will be similar pressure applied to RIPE, I am sure, but for my part > I will pressure ARIN to remove its needs test for transfers as the best > way to facilitate a global market in IPv4 address space. RIPE's > implementation of 2013-03 would assist in that effort. Mike - It's probably best to address those in the community interested in ARIN policy (i.e. "policymakers at ARIN") via the ARIN Public Policy Mailing List (ppml); that's where policy-related ideas and issues surrounding ARIN policies are discussed by the community, and hence where such notice should be made. To submit a policy proposal for discussion, please follow the directions here - (Any folks in the RIPE community interested in such discussions are quite welcome to participate on the ppml mailing list.) Thanks! /John John Curran President and CEO ARIN From richih.mailinglist at gmail.com Wed Sep 25 19:34:35 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Wed, 25 Sep 2013 19:34:35 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <5241D9F7.8040702@opdop.net> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <52404EF0.1070506@fud.no> <52406B51.2060208@opdop.net> <524180F1.10702@fud.no> <52419F45.4080405@opdop.net> <5241D9F7.8040702@opdop.net> Message-ID: I tried to limit posting in the 2013-03 threads to cut down on overall noise, but even after a night's sleep, I feel these points have to be addressed, even if arguably off topic. On Tue, Sep 24, 2013 at 8:29 PM, Sylvain Vallerot wrote: > On 24/09/2013 20:05, Jan Ingvoldstad wrote: >> >> On what possible grounds do you assume that our "+1" supports are EASY? > > Because it's so short to write and not develop :-) I agree with Jan that this implies +1 are fire and forget. Contrary to this sentiment, voicing either support or disagreement requires thought. And being subscribed to this list and actively reading the proposals should be enough to prove a certain amount of interest and involvement. > -1 requires long developments and a lot of repetition, as you may > have noticed. If you feel a need for a lot of repetition, this may be a sign of others simply disagreeing with the points you raise. After a certain point, more repetitions may or may not be useful in the general discourse. > But it is the game, OK, support is easier to formulate. This comes > from the system of someone writing a proposal and this is a "positive" > move, so going the counterway requires more writing (and may might seem > counter-productive) while going the same direction obviously does not > require to re-write the "pro" arguments that are already in the proposal. Writing "positive" implies, once again, an inherent advantage of one side over the other. A change needs to gather support whereas the status quo wins by default. Thus, if anything, a proposal is in a weaker position. > This is where I regret by the way, the assymetry between supporting and > opposing arguments in the rationale. I am sure that you would be able to get your arguments listed if you asked Tore and/or the editors. Not that this would imply any more agreement with those points; this proposal still has overwhelming support. > OK I must admit this is was bit rude, so please accept my apologies. > But this was not intedned as personal offense, I appreciate when I am > on the other side an just need to say +1 :-) Much appreciated! Richard From gert at space.net Wed Sep 25 19:59:55 2013 From: gert at space.net (Gert Doering) Date: Wed, 25 Sep 2013 19:59:55 +0200 Subject: [address-policy-wg] on support and opposition, and the amount of arguments needed (was: 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup)) In-Reply-To: <5241D9F7.8040702@opdop.net> References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <52404EF0.1070506@fud.no> <52406B51.2060208@opdop.net> <524180F1.10702@fud.no> <52419F45.4080405@opdop.net> <5241D9F7.8040702@opdop.net> Message-ID: <20130925175955.GV65295@Space.Net> Hi, On Tue, Sep 24, 2013 at 08:29:11PM +0200, Sylvain Vallerot wrote: > But it is the game, OK, support is easier to formulate. This comes > from the system of someone writing a proposal and this is a "positive" > move, so going the counterway requires more writing (and may might seem > counter-productive) while going the same direction obviously does not > require to re-write the "pro" arguments that are already in the proposal. We've discussed this before in one of the address policy WG meetings, and the modus operandi is a +1 agrees to the proposal *and the reasons behind it* so there's no need to find new reasons why one would agree with a proposal (and it's not actually helpful to repeat the reasons already given). Someone objecting, though, needs to provide a reason for his objection, so other members of the community or the proposer have a chance to argue the point, and then either convince the opposer that his point is based on a misunderstanding, possibly amend the proposal to take the points raised into account (which, for example, Tore did with the objections Malcolm raised), or at least provide counterarguments so the WG chairs and the community can see "this point of opposition was read, understood, and answered, even if the opposer might not agree with the argument given". Consensus does not have to be unanimous, but all (reasonable*) arguments brought forward need to be taken into consideration and answered. ("I do not like the proposal because my cat has licked it's left paw, and that's a bad sign!" would not be a reasonable objection, and could be simply ignored). > This is where I regret by the way, the assymetry between supporting and > opposing arguments in the rationale. There is so much inertness built into the current policy system that there already is a strong asymmetry anyway - fighting a proposal through multiple steps of PDP, with headwind in every single phase, is much harder than "just keep what we have, I oppose all change". We *do* need changes to adapt to a changing environment - so this balances things a bit. I hope to have clarified things a bit more, and we can end the meta discussions about the amount of arguments that need to be made either way - but if you feel otherwise, please start a new thread, as this is not really specific to 2013-03 but to general consensus building. thanks, 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 (0)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 mschmidt at ripe.net Thu Sep 26 16:36:24 2013 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 26 Sep 2013 16:36:24 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) Message-ID: Dear colleagues, A proposed change to RIPE Documents ripe-589, "IPv6 Address Allocation and Assignment Policy", ripe-451, "IPv6 Address Space Policy For Internet Exchange Points" and ripe-233, "IPv6 Addresses for Internet Root Servers In The RIPE Region" is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2013-06 We encourage you to review this proposal and send your comments to before 25 October 2013. Regards Marco Schmidt Policy Development Office RIPE NCC From richih.mailinglist at gmail.com Thu Sep 26 16:48:32 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Thu, 26 Sep 2013 16:48:32 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <524446bd.07070e0a.0744.fffff079SMTPIN_ADDED_MISSING@mx.google.com> References: <524446bd.07070e0a.0744.fffff079SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Thu, Sep 26, 2013 at 4:36 PM, Marco Schmidt wrote: > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2013-06 Somewhat off topic, but the links on that page point to i.e. [1] which redirects towards the generic search interface instead of displaying the expected documents. If RIPE NCC itself makes that honest mistake... This is part of what's being addressed on ncc-services-wg as of right now [2], [3]. I can't say if I am for or against the actual proposal, yet. Richard [1] https://www.ripe.net/docs/ripe-589/ [2] https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-September/002531.html [3] https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-September/002533.html From mschmidt at ripe.net Thu Sep 26 17:36:59 2013 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 26 Sep 2013 17:36:59 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <524446bd.07070e0a.0744.fffff079SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <5244549B.9010804@ripe.net> Dear colleagues, As Richard has correctly pointed out, a couple of the links in the policy proposal were not working correctly when we sent out the previous email. This has now been fixed. We are very sorry for any inconvenience. Kind regards Marco Schmidt Policy Development Office RIPE NCC On 9/26/13 4:48 PM, Richard Hartmann wrote: > On Thu, Sep 26, 2013 at 4:36 PM, Marco Schmidt wrote: > >> You can find the full proposal at: >> >> https://www.ripe.net/ripe/policies/proposals/2013-06 > > Somewhat off topic, but the links on that page point to i.e. [1] which > redirects towards the generic search interface instead of displaying > the expected documents. If RIPE NCC itself makes that honest > mistake... > > This is part of what's being addressed on ncc-services-wg as of right > now [2], [3]. > > > I can't say if I am for or against the actual proposal, yet. > > > Richard > > [1] https://www.ripe.net/docs/ripe-589/ > [2] https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-September/002531.html > [3] https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-September/002533.html > > From gert at space.net Thu Sep 26 19:11:55 2013 From: gert at space.net (Gert Doering) Date: Thu, 26 Sep 2013 19:11:55 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <1380206290.2739@mobil.space.net> References: <1380206290.2739@mobil.space.net> Message-ID: <20130926171155.GD65295@Space.Net> Dear AP WG, On Thu, Sep 26, 2013 at 04:36:24PM +0200, Marco Schmidt wrote: > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2013-06 This is "the big IPv6 revolution thing" I promised you somewhat over two years ago :-) - unification of PA and PI into "just numbers, no colours". As I never found time to actually write the specific policy document, it stalled, until these three brave volunteers took over and spent *quite* some amount of discussion and word-smithing to come up with what should be a much easier and cleaner IPv6 policy, without changing the underlying spirit ("who needs addresses gets some"), but removing some of the artificial strings ("addresses of this colour must not be used to do X, for that, you need more expensive ones"). It's a big change, and it's radical, but it's what you asked for when being presented with the idea :-) 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 (0)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 Sep 26 19:35:51 2013 From: randy at psg.com (Randy Bush) Date: Thu, 26 Sep 2013 07:35:51 -1000 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <20130926171155.GD65295@Space.Net> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> Message-ID: fwiw, i agree in principle. i need more spare time to noodle the details. randy From marc.neuckens at belgacom.be Thu Sep 26 19:52:23 2013 From: marc.neuckens at belgacom.be (NEUCKENS Marc (NEO/IPR)) Date: Thu, 26 Sep 2013 17:52:23 +0000 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) Message-ID: I agree with this policy. Current ipv6 policy pushes entreprises to becoming LIR just to obtain a workable assignment. ________________________________ ***** Disclaimer ***** http://www.belgacom.be/maildisclaimer -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis at v4escrow.net Thu Sep 26 19:56:41 2013 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Thu, 26 Sep 2013 19:56:41 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <20130926171155.GD65295@Space.Net> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> Message-ID: <52447559.9060304@v4escrow.net> Hi everyone, I am one of the three volunteers working on this 'big IPv6 revolution thing' for the past three months :-) The first main change that I had in my mind when offering to join the editorial team was that there were a lot of artificial rules attached to the policy and these rules were restricting the IPv6 deployment (in my view). Using PI came with a lot of restrains. You could only use it for your own infrastructure and not to offer any kind of services (other than SaaS) to your customers. That is because of two paragraphs in the (still current) policy. One of the paragraphs was saying that the minimum that can be used in IPv6 (even for a p2p link) is a /64. Second paragraph was saying that PI can not be further assigned. Therefore, with current policy in place, even if you have a customer that needs one IPv6 address for SSL, you can not offer that service to the customer without violating the policy (one of the two paragraphs above). Second main change is that we have removed the difference between PA and PI. IP addresses are now blocks of addresses and these can be allocated by the RIPE NCC to the LIR or to the End User (via Sponsoring LIR). The minimum that can be requested from the RIPE NCC is a /32 (except some special cases). We had the whole PA/PI colour 'thing' which was not visible anywhere else but in the RIPE Database; your equipment, routers, peers could not see whether you are using PI or PA. Third main change is removing the differences between assignments and allocations. Just like with the removal of the PI/PA differences; assignments and allocations were also different colours of the same blocks of IPs. Basically, anyone holding an allocation from the RIPE NCC can sub-allocate a block to either an end-site or to an other customer. The number of sub-allocation levels becomes infinite. We've made this change because we had a few examples where the policy may have been violated even without knowledge. One of the examples where this fixes a problem is when I would receive a /48 assignment from my provider and would allow my cousin to use a /64 for his web server. Last change: all the IPv6 documents have been merged into one single policy document :) Regards, Elvis On 9/26/13 7:11 PM, Gert Doering wrote: > Dear AP WG, > > On Thu, Sep 26, 2013 at 04:36:24PM +0200, Marco Schmidt wrote: >> You can find the full proposal at: >> >> https://www.ripe.net/ripe/policies/proposals/2013-06 > > This is "the big IPv6 revolution thing" I promised you somewhat over two > years ago :-) - unification of PA and PI into "just numbers, no colours". > > As I never found time to actually write the specific policy document, it > stalled, until these three brave volunteers took over and spent *quite* > some amount of discussion and word-smithing to come up with what should > be a much easier and cleaner IPv6 policy, without changing the underlying > spirit ("who needs addresses gets some"), but removing some of the > artificial strings ("addresses of this colour must not be used to do X, > for that, you need more expensive ones"). > > It's a big change, and it's radical, but it's what you asked for when > being presented with the idea :-) > > Gert Doering > -- APWG chair > From nick at inex.ie Thu Sep 26 22:48:44 2013 From: nick at inex.ie (Nick Hilliard) Date: Thu, 26 Sep 2013 21:48:44 +0100 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <20130926171155.GD65295@Space.Net> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> Message-ID: <52449DAC.2030700@inex.ie> On 26/09/2013 18:11, Gert Doering wrote: > This is "the big IPv6 revolution thing" I promised you somewhat over two > years ago :-) - unification of PA and PI into "just numbers, no colours". a cursory look over the changes is giving me a warm fuzzy feeling. I need more time to look over it, but right now there's nothing I can see which stands out as obviously harmful. I'm mildly concerned that you're defining previously undefinable terms like "End User", "End Site" and that sort of thing - if anything, these terms belong in a separate document. Nick From elvis at velea.eu Thu Sep 26 23:12:01 2013 From: elvis at velea.eu (Elvis Velea) Date: Thu, 26 Sep 2013 23:12:01 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <52449DAC.2030700@inex.ie> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> Message-ID: <5244A321.10707@velea.eu> Hi Nick, On 9/26/13 10:48 PM, Nick Hilliard wrote: > On 26/09/2013 18:11, Gert Doering wrote: >> This is "the big IPv6 revolution thing" I promised you somewhat over two >> years ago :-) - unification of PA and PI into "just numbers, no colours". > > a cursory look over the changes is giving me a warm fuzzy feeling. I need > more time to look over it, but right now there's nothing I can see which > stands out as obviously harmful. it's a big change and we will all need to carefully read every word of the new policy text. I am glad that you do not find anything harmful at first glance ;) > I'm mildly concerned that you're defining > previously undefinable terms like "End User", "End Site" and that sort of > thing - if anything, these terms belong in a separate document. the term End Site was already defined and it was completely mixed up with the term End User. We have tried to redefine these two terms as best as we could. If you think the definitions could look better, do share with us your idea. I do think that these terms do need to be defined, and the policy text was the best place for the definitions (in my opinion). Where else would you see them? cheers, elvis From richih.mailinglist at gmail.com Thu Sep 26 23:44:22 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Thu, 26 Sep 2013 23:44:22 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <524446bd.07070e0a.0744.fffff079SMTPIN_ADDED_MISSING@mx.google.com> References: <524446bd.07070e0a.0744.fffff079SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: Dear all, I support the general direction of this proposal. If it included v4, I would still be in favor. That being said, I am not sure about the prefix sizes listed in this proposal. According to section 5.1.2 of the new text, everyone will receive at least a /32 unless the addresses will be used for a special purpose as per section 6. In this case, allocations can be made in allocations of /48: * Operating a TLD: 1-4 * /48 * Operating an ENUM: 1-4 * /48 * Operating an IXP: 1 * /48 * Operating a DNS root server: 1 * /32 There are three concerns with this: 1) Assuming everyone will get at least a /32, why limit core internet infrastructure, i.e. TLDs, ENUMs, and IXPs to a mere /48? The combined amount of those allocations will be dwarfed by the combined amount of LIRs and End Users. 2) While there are a _lot_ of addresses with IPv6, handing a multi-homed End User who will be able to operate on a single /48 for the foreseeable future a whole /32 appears to be wasteful. Maybe that's v4 speaking through me, but still... 3) Becoming a LIR costs several thousand Euros up front and then per year. Not being a LIR and simply getting the same /32 will, under current pricing schemes, cost ?50. Becoming a LIR would become an extremely stupid business move over night. This means the existing LIRs will be stuck with paying whatever price increases happen over the years. That, in turn, means LIRs will start trying to redistribute the cost. And _that_ will become ugly very quickly. I am not saying my suggested answers are perfect, but my gut feeling tells me that while the distinction between "this is PA, hand it to your customers" and "this is PI, don't you dare using it for anyone but yourself" does not make sense, there should still be a distinction between "we need a few v6 addresses" and "we need a lot v6 addresses". Two possible approaches: * Non-LIR allocations could be limited to a single aggregated equivalent of, e.g. a /40 or /41. If someone needed more, let them become a LIR. * Do away with the flat fee of ?50 per Independent Number Resource and charge based on size. This would also somewhat prevent people from grabbing as much IP space as possible. As an aside, reading [1] is needlessly hard. There are several sections where text on the left-hand side does not appear on the right-hand side. New text on the right-hand side is marked in blue; disappearing text on the left-hand side is not marked in any way. This is yet another reminder of why migrating to plain text with an automated storage and diffing back-end ASAP will be a Good Thing. Richard [1] https://www.ripe.net/ripe/docs/other-documents/draft-ipv6-address-allocation-and-assignment-policy-current-policy-text From richih.mailinglist at gmail.com Thu Sep 26 23:46:46 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Thu, 26 Sep 2013 23:46:46 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <5244A321.10707@velea.eu> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <5244A321.10707@velea.eu> Message-ID: On Thu, Sep 26, 2013 at 11:12 PM, Elvis Velea wrote: > I do think that these terms do need to be defined, and the policy text was > the best place for the definitions (in my opinion). Where else would you see > them? Personally, I would like to see a single, canonical, authorative document defining _all_ special terms. In a perfect world, those special terms would then be Always Capitalized When Used Within Documents or MAYBE EVEN ALL UPPER CASE. If there's any interest, I would be willing to spear-head and/or collaborate on this effort. Richard From elvis at v4escrow.net Fri Sep 27 00:24:27 2013 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Fri, 27 Sep 2013 00:24:27 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <524446bd.07070e0a.0744.fffff079SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <5244B41B.1070807@v4escrow.net> Hi Richard, On 9/26/13 11:44 PM, Richard Hartmann wrote: > Dear all, > > > I support the general direction of this proposal. If it included v4, I > would still be in favor. > I didn't even dare touching v4 right now even though I agree that this policy proposal is a good exercise for what should happen in the near future with v4 as well. > > That being said, I am not sure about the prefix sizes listed in this > proposal. According to section 5.1.2 of the new text, everyone will > receive at least a /32 unless the addresses will be used for a special > purpose as per section 6. In this case, allocations can be made in > allocations of /48: > > * Operating a TLD: 1-4 * /48 > * Operating an ENUM: 1-4 * /48 > * Operating an IXP: 1 * /48 > * Operating a DNS root server: 1 * /32 > > There are three concerns with this: > > 1) Assuming everyone will get at least a /32, why limit core internet > infrastructure, i.e. TLDs, ENUMs, and IXPs to a mere /48? The combined > amount of those allocations will be dwarfed by the combined amount of > LIRs and End Users. These were restrictions that existed in the previous version and things seemed to work well with these restrictions/sizes. I hear you and if others think the same, we could change the limits. > > 2) While there are a _lot_ of addresses with IPv6, handing a > multi-homed End User who will be able to operate on a single /48 for > the foreseeable future a whole /32 appears to be wasteful. Maybe > that's v4 speaking through me, but still... Well, someone that does not plan to make any sub-allocations or anyone that still thinks that a /48 will be large enough for the foreseeable future can request a /48. A /32 is provided by default though, so I would not see many organisations specifically requesting a /48 and not the default /32. see 5.1.2: "5.1.2 Initial Allocation Size [...] /48 allocations can be made by the RIPE NCC to End Users that do not expect to ever need more or for special purposes. Special purposes are covered in section 6 of this policy. When an organisation requests a /48 allocation, it must specifically mention in its request that it does not plan to use anything larger in the foreseeable future." > > 3) Becoming a LIR costs several thousand Euros up front and then per > year. Not being a LIR and simply getting the same /32 will, under > current pricing schemes, cost ?50. > Becoming a LIR would become an extremely stupid business move over > night. This means the existing LIRs will be stuck with paying whatever > price increases happen over the years. That, in turn, means LIRs will > start trying to redistribute the cost. And _that_ will become ugly > very quickly. That was our main concern, so.. I already approached a few of the Board Members to discuss this policy proposal and at least announce them that this is coming. My idea was that while the AP-WG can not do anything about the fees (these are decided by AGM) we (the proposers) can discuss during the AGM our following idea: - if the policy proposal gets good feedback from the community, it would be a great exercise to ask the RIPE NCC (Board) to calculate how much would a /32 cost if the prices would be leveled.. - if the price can not be leveled yet, see how much would the membership fee decrease if the non-LIRs would pay double the current price (100?) or 500% more (250?), or something around that price. > > > I am not saying my suggested answers are perfect, but my gut feeling > tells me that while the distinction between "this is PA, hand it to > your customers" and "this is PI, don't you dare using it for anyone > but yourself" does not make sense, there should still be a distinction > between "we need a few v6 addresses" and "we need a lot v6 addresses". I agree, and that is why someone can request a '/48' or a '/32 or larger' > > Two possible approaches: > > * Non-LIR allocations could be limited to a single aggregated > equivalent of, e.g. a /40 or /41. If someone needed more, let them > become a LIR. I had this idea initially. But, then how do we determine how large should this allocation be? By taking an arbitrary number? What if this number is not longer the right number in 2 years? > * Do away with the flat fee of ?50 per Independent Number Resource and > charge based on size. This would also somewhat prevent people from > grabbing as much IP space as possible. > I think this is where we should be looking at. Try to get the 'price per /32' to be equal (or almost equal) to both members and non-members. You get a block, you pay the same price for it whether you are a member or not. Maybe not immediately, maybe not in the next 2-3 years.. but this should be the goal for the future. However, I remember that 'charging per prefix size' discussion did appear in some of the previous policy proposals and if I remember correctly we were told that if the RIPE NCC were to charge based on prefix size, it may lose it's not-for-profit status that it has with the Dutch authorities. We need to be careful so that we do not affect RIPE NCC's status and activity. > > As an aside, reading [1] is needlessly hard. There are several > sections where text on the left-hand side does not appear on the > right-hand side. New text on the right-hand side is marked in blue; > disappearing text on the left-hand side is not marked in any way. This > is yet another reminder of why migrating to plain text with an > automated storage and diffing back-end ASAP will be a Good Thing. > I agree, but let's keep this discussion in the ncc-services-wg, please. > > Richard > > [1] https://www.ripe.net/ripe/docs/other-documents/draft-ipv6-address-allocation-and-assignment-policy-current-policy-text > cheers, Elvis From richih.mailinglist at gmail.com Fri Sep 27 01:45:23 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 27 Sep 2013 01:45:23 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <5244B41B.1070807@v4escrow.net> References: <524446bd.07070e0a.0744.fffff079SMTPIN_ADDED_MISSING@mx.google.com> <5244B41B.1070807@v4escrow.net> Message-ID: On Fri, Sep 27, 2013 at 12:24 AM, Elvis Daniel Velea wrote: > These were restrictions that existed in the previous version and things > seemed to work well with these restrictions/sizes. I hear you and if others > think the same, we could change the limits. If /32 becomes the new default/minimum, keeping those limits seems to be counter-intuitive. > Well, someone that does not plan to make any sub-allocations or anyone that > still thinks that a /48 will be large enough for the foreseeable future can > request a /48. A /32 is provided by default though, so I would not see many > organisations specifically requesting a /48 and not the default /32. > > see 5.1.2: > > "5.1.2 Initial Allocation Size > [...] > /48 allocations can be made by the RIPE NCC to End Users that do not expect > to ever need more or for special purposes. > Special purposes are covered in section 6 of this policy. When an > organisation requests a /48 allocation, it must specifically mention in its > request that it does not plan to use anything larger in the foreseeable > future." True; I missed the crucial part of allowing "/48 allocations [...] not expect to ever need more". Sorry, it seems my comb hasn't been fine-toothed enough... Aside from the difference between "ever need more" and "foreseeable future", this means that End Users will need to decide between /48 and /32. To pick a specific example, FOSDEM will apply for IPv6 PI soon. As they need more than one single /48, under that policy the seem to be _forced_ to a /32. With a corporate hat on, I think it highly unlikely that anyone manager or sales person will be content with less than the absolute maximum they can get even if they don't need it. So save for a few corporations and maybe temporary allocations, I suspect everyone will go for a /32. > That was our main concern, so.. I already approached a few of the Board > Members to discuss this policy proposal and at least announce them that this > is coming. > > My idea was that while the AP-WG can not do anything about the fees (these > are decided by AGM) we (the proposers) can discuss during the AGM our > following idea: > > - if the policy proposal gets good feedback from the community, it would be > a great exercise to ask the RIPE NCC (Board) to calculate how much would a > /32 cost if the prices would be leveled.. > > - if the price can not be leveled yet, see how much would the membership > fee decrease if the non-LIRs would pay double the current price (100?) or > 500% more (250?), or something around that price. That's great to hear. > I had this idea initially. But, then how do we determine how large should > this allocation be? By taking an arbitrary number? What if this number is > not longer the right number in 2 years? Then we change policy to adapt ;) But I see your point and I was not really happy when coming up with /40 or /41. > I think this is where we should be looking at. Try to get the 'price per > /32' to be equal (or almost equal) to both members and non-members. You get > a block, you pay the same price for it whether you are a member or not. > Maybe not immediately, maybe not in the next 2-3 years.. but this should be > the goal for the future. If it's not done after one year at the latest, I fear that would breed dissent. > However, I remember that 'charging per prefix size' discussion did appear in > some of the previous policy proposals and if I remember correctly we were > told that if the RIPE NCC were to charge based on prefix size, it may lose > it's not-for-profit status that it has with the Dutch authorities. We need > to be careful so that we do not affect RIPE NCC's status and activity. Good point; that makes arbitrary cut-off points (/40) appear more appealing, again. > I agree, but let's keep this discussion in the ncc-services-wg, please. AFAIU, the general point of "this proposal is needlessly hard to read" does belong on this list. I am willing to bet that easier consumption will translate directly into more feedback. You are right that the rest of this discussion does not belong here, though. Richard From tore at fud.no Fri Sep 27 08:49:58 2013 From: tore at fud.no (Tore Anderson) Date: Fri, 27 Sep 2013 08:49:58 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <52449DAC.2030700@inex.ie> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> Message-ID: <52452A96.9060405@fud.no> * Nick Hilliard > a cursory look over the changes is giving me a warm fuzzy feeling. I need > more time to look over it, but right now there's nothing I can see which > stands out as obviously harmful. +1 Some comments from the top of my head (probably not exhaustive since I need some more time to digest the totality of the proposal): - I find the new graphics slightly confusing. There is drawn a link between the Sponsoring LIR to between the RIPE NCC and the End User, as expected, but also between the Sponsoring LIR and the 1st and 2nd level End Users (i.e. between the End User holding the allocation and its downstream End Users). Why is that? I don't see that the Sponsoring LIR has any responsibilities on this level? Also, is there some significance to be read into the fact that the line between the 2nd level End User and its End Site is dotted, while between the 1st level End User and its End Site it is solid? - The proposal should update ripe-592 section 5.6.2, bullet 2. This makes a reference to the IPv6 IXP document which this proposal retires, as I understand it. So in order to avoid this reference not pointing anywhere useful, the the original definition into ripe-592 (I believe this would be the PDO's preference), or to update the reference to point to the proposed unified IPv6 document. - I find the precise definition of the term "End User" to be hollowed out to some extent. In the proposed model, the 1st level End User is for all practical purposes operating as an LIR - the only significant difference seems to be related to which organisation it needs to pay for the privilege (i.e. the RIPE NCC or the Sponsoring LIR). To me the implied meaning of "End User" is the "final" recipient, i.e., someone who is actually *using* the addresses, while a 1st level End User certainly meets the definition of IR in section 2.1. I would therefore consider instead calling this role a "Sponsored LIR" or something along those lines. - In a similar vein, the LIRs have some NCC-provided tools at their disposal, such as for example the LIR Portal, which is the only place where at least some information can be updated. RPKI is another. Has it been thought whether the "Sponsored LIRs" will be given direct access to these tools, or if their resources will appear in the interface of the Sponsoring LIR, who will have the responsibility to maintain this information on their behalf (which would be an increased responsibility compared to sponsored PI), or something else such as LIR Portal access being one of the incentives for becoming a "proper" LIR? - When it comes to the counterpoint regarding taking away the incentive to become "proper" LIRs. Well - it's been possible to run consumer-based ISPs on IPv4 PI for quite a while, yet the NCC is failing to turn a deficit even though it allegedly is trying, so I'm not terribly concerned. :-) More seriously though, I don't think this is likely to be much of a problem before the same "Sponsored LIR" concept is backported to IPv4, and not necessarily then either. Tore From frettled at gmail.com Fri Sep 27 08:55:48 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Fri, 27 Sep 2013 08:55:48 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <5244A321.10707@velea.eu> Message-ID: On Thu, Sep 26, 2013 at 11:46 PM, Richard Hartmann < richih.mailinglist at gmail.com> wrote: > On Thu, Sep 26, 2013 at 11:12 PM, Elvis Velea wrote: > > > I do think that these terms do need to be defined, and the policy text > was > > the best place for the definitions (in my opinion). Where else would you > see > > them? > > Personally, I would like to see a single, canonical, authorative > document defining _all_ special terms. > > In a perfect world, those special terms would then be Always > Capitalized When Used Within Documents or MAYBE EVEN ALL UPPER CASE. > > > If there's any interest, I would be willing to spear-head and/or > collaborate on this effort. > As a reasonably fresh novice in this WG and the LIR game, I think that kind of document is an absolute necessity. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From frettled at gmail.com Fri Sep 27 09:01:37 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Fri, 27 Sep 2013 09:01:37 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <524446bd.07070e0a.0744.fffff079SMTPIN_ADDED_MISSING@mx.google.com> <5244B41B.1070807@v4escrow.net> Message-ID: On Fri, Sep 27, 2013 at 1:45 AM, Richard Hartmann < richih.mailinglist at gmail.com> wrote: > On Fri, Sep 27, 2013 at 12:24 AM, Elvis Daniel Velea > wrote: > > > These were restrictions that existed in the previous version and things > > seemed to work well with these restrictions/sizes. I hear you and if > others > > think the same, we could change the limits. > > If /32 becomes the new default/minimum, keeping those limits seems to > be counter-intuitive. > I concur. And I think it's worth keeping in mind that even a /48 is a ludicrously enormously large address space. With a corporate hat on, I think it highly unlikely that anyone > manager or sales person will be content with less than the absolute > maximum they can get even if they don't need it. So save for a few > corporations and maybe temporary allocations, I suspect everyone will > go for a /32. > So do I, especially considering the turn of phrase, which is nearly guaranteed to instill a fear of running out somehow. Nobody should run out with a /48. I think it's somewhat sensible that a LIR should have access to a /32. :) -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From frettled at gmail.com Fri Sep 27 09:08:02 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Fri, 27 Sep 2013 09:08:02 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <52452A96.9060405@fud.no> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> Message-ID: On Fri, Sep 27, 2013 at 8:49 AM, Tore Anderson wrote: > - I find the new graphics slightly confusing. There is drawn a link > between the Sponsoring LIR to between the RIPE NCC and the End User, as > expected, but also between the Sponsoring LIR and the 1st and 2nd level > End Users (i.e. between the End User holding the allocation and its > downstream End Users). Why is that? I don't see that the Sponsoring LIR > has any responsibilities on this level? Also, is there some significance > to be read into the fact that the line between the 2nd level End User > and its End Site is dotted, while between the 1st level End User and its > End Site it is solid? > +1 to that. Although this is a bit like bike shedding, I think there should be a descriptive explanation right next to the graph, which would be helpful to n00bs (like me, really). - I find the precise definition of the term "End User" to be hollowed > out to some extent. In the proposed model, the 1st level End User is for > all practical purposes operating as an LIR - the only significant > difference seems to be related to which organisation it needs to pay for > the privilege (i.e. the RIPE NCC or the Sponsoring LIR). To me the > implied meaning of "End User" is the "final" recipient, i.e., someone > who is actually *using* the addresses, while a 1st level End User > certainly meets the definition of IR in section 2.1. I would therefore > consider instead calling this role a "Sponsored LIR" or something along > those lines. > I agree. This is made even more difficult by apparently changing the scope of the policy from the leftmost 64 bits to all 128 bits, and by restricting suballocations to the smallest atoms to a /64, appears to reduce the IPv6 address space from 128 bits to 64 bits. Section 1, 1.1 Overview has this current sentence that is removed in the proposal: "All bits to the left of /64 are in scope." In one of the previous posts, making things easier for e.g. using separate IP addresses for SSL is an argument for this proposal, but as I read it right now, I would have to sub-allocate a /64 for each SSL certificate, rather than say a /128. I feel reasonably sure that this is not the intention of the authors. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Fri Sep 27 09:13:03 2013 From: tore at fud.no (Tore Anderson) Date: Fri, 27 Sep 2013 09:13:03 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <5244A321.10707@velea.eu> Message-ID: <52452FFF.9060701@fud.no> * Jan Ingvoldstad > As a reasonably fresh novice in this WG and the LIR game, I think that > kind of document is an absolute necessity. FWIW, "End User" is defined here: http://www.ripe.net/ripe/internet-coordination/internet-governance/internet-technical-community/the-rir-system However, as I've already pointed out, the new "Sponsored LIR" class of End Users introduced by this proposal doesn't really fit the original definition. (RFC 7020 uses the terms "child LIRs" / "sub-LIRs" instead.) Tore From richih.mailinglist at gmail.com Fri Sep 27 09:25:50 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 27 Sep 2013 09:25:50 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <52452FFF.9060701@fud.no> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <5244A321.10707@velea.eu> <52452FFF.9060701@fud.no> Message-ID: On Fri, Sep 27, 2013 at 9:13 AM, Tore Anderson wrote: > However, as I've already pointed out, the new "Sponsored LIR" class of > End Users introduced by this proposal doesn't really fit the original > definition. (RFC 7020 uses the terms "child LIRs" / "sub-LIRs" instead.) Sponsored/Sponsoring LIR is easy to confuse. Child LIR does not easily expand (Grandchild LIR?). A Sub-LIR can, if need be, have a Sub-Sub-LIR. -- Richard From frettled at gmail.com Fri Sep 27 10:20:31 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Fri, 27 Sep 2013 10:20:31 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <5244A321.10707@velea.eu> <52452FFF.9060701@fud.no> Message-ID: Yikes, I re-read my messages, and they're a bit more negative than intended. I'd like to say that I support the cleanup work on a general basis; merging the three documents and clearing up the address space allocation policy is a Good Thing. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tero.Toikkanen at nebula.fi Fri Sep 27 10:28:11 2013 From: Tero.Toikkanen at nebula.fi (Tero Toikkanen) Date: Fri, 27 Sep 2013 08:28:11 +0000 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <52452A96.9060405@fud.no> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> Message-ID: <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> > - I find the new graphics slightly confusing. There is drawn a link > between the Sponsoring LIR to between the RIPE NCC and the End User, as > expected, but also between the Sponsoring LIR and the 1st and 2nd level > End Users (i.e. between the End User holding the allocation and its > downstream End Users). Why is that? I don't see that the Sponsoring LIR > has any responsibilities on this level? Also, is there some significance > to be read into the fact that the line between the 2nd level End User > and its End Site is dotted, while between the 1st level End User and its > End Site it is solid? It might be clearer to illustrate all three paths individually (from RIPE NCC to LIR, Sponsoring LIR and End User). I also agree with what Tore Anderson and Richard Hartmann said about somehow clarifying the division between Sponsoring LIR and a possible Sponsored/child/sub-LIR under it. Sponsored/Sponsoring LIR is certainly easily confused, so Sub-LIR might be the way to go. ____________________________________ Tero Toikkanen Nebula Oy From Tero.Toikkanen at nebula.fi Fri Sep 27 11:55:42 2013 From: Tero.Toikkanen at nebula.fi (Tero Toikkanen) Date: Fri, 27 Sep 2013 09:55:42 +0000 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <524446bd.07070e0a.0744.fffff079SMTPIN_ADDED_MISSING@mx.google.com> <5244B41B.1070807@v4escrow.net> Message-ID: <66810E018CDF3344A676D4025D2350700F7BA5@office-exbe-01.office.nbl.fi> > > These were restrictions that existed in the previous version and things > > seemed to work well with these restrictions/sizes. I hear you and if others > > think the same, we could change the limits. > > If /32 becomes the new default/minimum, keeping those limits seems to > be counter-intuitive. I agree. We should propose /48 as the _minimum_ allocation for all special purposes, maybe with possible provisions for more. > Aside from the difference between "ever need more" and "foreseeable > future", this means that End Users will need to decide between /48 and > /32. To pick a specific example, FOSDEM will apply for IPv6 PI soon. > As they need more than one single /48, under that policy the seem to > be _forced_ to a /32. > > With a corporate hat on, I think it highly unlikely that anyone > manager or sales person will be content with less than the absolute > maximum they can get even if they don't need it. So save for a few > corporations and maybe temporary allocations, I suspect everyone will > go for a /32. I agree that the either /48 with no room for expansion or /32 is too strict. I would go as far as to propose that End Users could request anything from /48 to /32 and also be limited to that. However, this may have implications on address reservations in RIPE, as was the case with LIRs being allocated a /32 but reserved a /29. So if to avoid renumbering and to encourage aggregation we end up allocating /48s, but reserving a /32 for each one, we probably will end up at the same point again. Furthermore, as the "LIR incentive", I'd restrict End User allocations to a /32. If you need more, you should become an LIR. ____________________________________ Tero Toikkanen Nebula Oy From Tero.Toikkanen at nebula.fi Fri Sep 27 12:25:13 2013 From: Tero.Toikkanen at nebula.fi (Tero Toikkanen) Date: Fri, 27 Sep 2013 10:25:13 +0000 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <20130926171155.GD65295@Space.Net> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> Message-ID: <66810E018CDF3344A676D4025D2350700F7BE3@office-exbe-01.office.nbl.fi> Dear all, In general I support the direction of this proposal. I have already mentioned some of my observations on other ongoing conversations, but here are a couple more: 5.2.3 "results in a doubling of the address space allocated to it" With larger blocks this seems a bit drastic to me. I.e. if a large corporation needs a new /32, but already has 4 of them, they will automagically get 4 /32s more. I assume this is to enable aggregation, but without making large reservations in the address pool for each End User, it probably wouldn't work for that purpose. In order to assess how reasonable this clause is, we would need to know how addresses are allocated and from where. I my opinion aggregation = good, large reservations for every single End User with a /32 = bad. 5.3.1 "When more than a /48 is to be sub-allocated to the same customer, the LIR or the End User (via the Sponsoring LIR) must request an approval from the RIPE NCC." This is a bit vague wording, which would probably be better by just removing the parentheses. I assume the idea is that the End User submits the request to the Sponsoring LIR, which then hands it over to RIPE NCC? ____________________________________ Tero Toikkanen Nebula Oy From nick at inex.ie Fri Sep 27 17:37:03 2013 From: nick at inex.ie (Nick Hilliard) Date: Fri, 27 Sep 2013 16:37:03 +0100 Subject: [address-policy-wg] black market transfers In-Reply-To: References: Message-ID: <5245A61F.6030001@inex.ie> > as a researcher, how might i measure such a change? how might i tell if > some piece of address space has been transferred on the black market? objectively? no way of telling for sure. Maybe use indicators like different ASN paths, different source asns, changes to registered object, etc? All very subjective though. Nick From andreas.larsen at ip-only.se Fri Sep 27 19:10:32 2013 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Fri, 27 Sep 2013 19:10:32 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <66810E018CDF3344A676D4025D2350700F7BE3@office-exbe-01.office.nbl.fi> Message-ID: I support the general idea of this proposal. 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-09-27 12:25 skrev Tero Toikkanen : >Dear all, > >In general I support the direction of this proposal. > >I have already mentioned some of my observations on other ongoing >conversations, but here are a couple more: > >5.2.3 >"results in a doubling of the address space allocated to it" >With larger blocks this seems a bit drastic to me. I.e. if a large >corporation needs a new /32, but already has 4 of them, they will >automagically get 4 /32s more. I assume this is to enable aggregation, >but without making large reservations in the address pool for each End >User, it probably wouldn't work for that purpose. In order to assess how >reasonable this clause is, we would need to know how addresses are >allocated and from where. I my opinion aggregation = good, large >reservations for every single End User with a /32 = bad. > >5.3.1 >"When more than a /48 is to be sub-allocated to the same customer, the >LIR or the End User (via the Sponsoring LIR) must request an approval >from the RIPE NCC." >This is a bit vague wording, which would probably be better by just >removing the parentheses. I assume the idea is that the End User submits >the request to the Sponsoring LIR, which then hands it over to RIPE NCC? > >____________________________________ >Tero Toikkanen >Nebula Oy > From randy at psg.com Fri Sep 27 19:46:43 2013 From: randy at psg.com (Randy Bush) Date: Fri, 27 Sep 2013 07:46:43 -1000 Subject: [address-policy-wg] black market transfers In-Reply-To: <5245A61F.6030001@inex.ie> References: <5245A61F.6030001@inex.ie> Message-ID: >> as a researcher, how might i measure such a change? how might i tell >> if some piece of address space has been transferred on the black >> market? > objectively? yep > no way of telling for sure. realize that. darned hard to get even a rough estimate > Maybe use indicators like different ASN paths, different source asns, > changes to registered object, etc? All very subjective though. yep. randy From ggiannou at gmail.com Fri Sep 27 19:52:18 2013 From: ggiannou at gmail.com (George Giannousopoulos) Date: Fri, 27 Sep 2013 20:52:18 +0300 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <20130919144556.ED13D11782@tools.opdop.net> <523C2F5C.9000302@opdop.net> <523C3F42.3080404@fud.no> <523F19FE.6040906@opdop.net> <52404EF0.1070506@fud.no> <52406B51.2060208@opdop.net> <524180F1.10702@fud.no> <52419F45.4080405@opdop.net> <5241D9F7.8040702@opdop.net> Message-ID: Hello all, +1 from me too Best regards George -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis at v4escrow.net Mon Sep 30 13:56:03 2013 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Mon, 30 Sep 2013 13:56:03 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <524446bd.07070e0a.0744.fffff079SMTPIN_ADDED_MISSING@mx.google.com> <5244B41B.1070807@v4escrow.net> Message-ID: <524966D3.4060108@v4escrow.net> Hi Richard, On 9/27/13 1:45 AM, Richard Hartmann wrote: > On Fri, Sep 27, 2013 at 12:24 AM, Elvis Daniel Velea wrote: > >> These were restrictions that existed in the previous version and things >> seemed to work well with these restrictions/sizes. I hear you and if others >> think the same, we could change the limits. > > If /32 becomes the new default/minimum, keeping those limits seems to > be counter-intuitive. > correct, let's see what the others think as well. > >> Well, someone that does not plan to make any sub-allocations or anyone that >> still thinks that a /48 will be large enough for the foreseeable future can >> request a /48. A /32 is provided by default though, so I would not see many >> organisations specifically requesting a /48 and not the default /32. >> >> see 5.1.2: >> >> "5.1.2 Initial Allocation Size >> [...] >> /48 allocations can be made by the RIPE NCC to End Users that do not expect >> to ever need more or for special purposes. >> Special purposes are covered in section 6 of this policy. When an >> organisation requests a /48 allocation, it must specifically mention in its >> request that it does not plan to use anything larger in the foreseeable >> future." > > True; I missed the crucial part of allowing "/48 allocations [...] not > expect to ever need more". Sorry, it seems my comb hasn't been > fine-toothed enough... > > Aside from the difference between "ever need more" and "foreseeable > future", this means that End Users will need to decide between /48 and > /32. To pick a specific example, FOSDEM will apply for IPv6 PI soon. > As they need more than one single /48, under that policy the seem to > be _forced_ to a /32. Well, it's a /48 if you are sure you will never need more; otherwise, you can get the /32, as everyone else. > > With a corporate hat on, I think it highly unlikely that anyone > manager or sales person will be content with less than the absolute > maximum they can get even if they don't need it. So save for a few > corporations and maybe temporary allocations, I suspect everyone will > go for a /32. > I suspect the same, I did not want to introduce arbitrary limits between /48 and /32. I think these two limits are enough and adding an other one would complicate the policy. > >> That was our main concern, so.. I already approached a few of the Board >> Members to discuss this policy proposal and at least announce them that this >> is coming. >> >> My idea was that while the AP-WG can not do anything about the fees (these >> are decided by AGM) we (the proposers) can discuss during the AGM our >> following idea: >> >> - if the policy proposal gets good feedback from the community, it would be >> a great exercise to ask the RIPE NCC (Board) to calculate how much would a >> /32 cost if the prices would be leveled.. >> >> - if the price can not be leveled yet, see how much would the membership >> fee decrease if the non-LIRs would pay double the current price (100?) or >> 500% more (250?), or something around that price. > > That's great to hear. > > >> I had this idea initially. But, then how do we determine how large should >> this allocation be? By taking an arbitrary number? What if this number is >> not longer the right number in 2 years? > > Then we change policy to adapt ;) The idea of this policy proposal is that we would like to fix it and not need to change it every year or two. > > But I see your point and I was not really happy when coming up with /40 or /41. Exactly, in the discussions with the other proposers I had also the /40 in mind. But this number is so arbitrary that it will help some and not help others. Let's not put arbitrary numbers in policies. If you need IPv6, you can get as much as you want (even if you are not an LIR). But then, the price for (each) allocation will need to be close to the price an LIR pays for the same IPv6 allocation. > > >> I think this is where we should be looking at. Try to get the 'price per >> /32' to be equal (or almost equal) to both members and non-members. You get >> a block, you pay the same price for it whether you are a member or not. >> Maybe not immediately, maybe not in the next 2-3 years.. but this should be >> the goal for the future. > > If it's not done after one year at the latest, I fear that would breed dissent. > I think that we have two options: 1. ask the board/NCC to calculate what would be the price per allocation if there would be no difference between LIRs and non-LIRs 2. start with a step-by-step approach - as we do not have that many non-LIRs using IPv6 now, I think that the increase from 50 to (arbitrary number from my mind) 500 Euro would be pretty high. The idea would be to come up with a plan that in 3-5 years the price for a /32 to be the same for members and non-members > >> However, I remember that 'charging per prefix size' discussion did appear in >> some of the previous policy proposals and if I remember correctly we were >> told that if the RIPE NCC were to charge based on prefix size, it may lose >> it's not-for-profit status that it has with the Dutch authorities. We need >> to be careful so that we do not affect RIPE NCC's status and activity. > > Good point; that makes arbitrary cut-off points (/40) appear more > appealing, again. > let's see what the NCC and the Board will say about this in the Impact Analysis. > >> I agree, but let's keep this discussion in the ncc-services-wg, please. > > AFAIU, the general point of "this proposal is needlessly hard to read" > does belong on this list. I am willing to bet that easier consumption > will translate directly into more feedback. Correct, the page could have been formatted better. I would not change it now, as we have already started the discussion. I will talk to the NCC if there is a version 2 and the page will clearly show the differences between the current policy and proposed changes. > > You are right that the rest of this discussion does not belong here, though. > > > Richard > cheers, elvis From elvis at v4escrow.net Mon Sep 30 14:17:31 2013 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Mon, 30 Sep 2013 14:17:31 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <52452A96.9060405@fud.no> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> Message-ID: <52496BDB.2080106@v4escrow.net> Hi Tore, On 9/27/13 8:49 AM, Tore Anderson wrote: > Some comments from the top of my head (probably not exhaustive since I > need some more time to digest the totality of the proposal): > > - I find the new graphics slightly confusing. There is drawn a link > between the Sponsoring LIR to between the RIPE NCC and the End User, as > expected, but also between the Sponsoring LIR and the 1st and 2nd level > End Users (i.e. between the End User holding the allocation and its > downstream End Users). Why is that? I don't see that the Sponsoring LIR > has any responsibilities on this level? Also, is there some significance > to be read into the fact that the line between the 2nd level End User > and its End Site is dotted, while between the 1st level End User and its > End Site it is solid? The dotted line between the RIPE NCC and End User shows that this request can be done by the Sponsoring LIR. The dotted line between the End User and End Site is there to show that there can be an infinite number of end users in between. > > - The proposal should update ripe-592 section 5.6.2, bullet 2. This > makes a reference to the IPv6 IXP document which this proposal retires, > as I understand it. So in order to avoid this reference not pointing > anywhere useful, the the original definition into ripe-592 (I believe > this would be the PDO's preference), or to update the reference to point > to the proposed unified IPv6 document. > hum, right.. I did not know that in the IPv4 policy there is a reference to the IPv6 assignments made to IXPs :) Do we need to change the IPv4 policy if this policy proposal is accepted? > - I find the precise definition of the term "End User" to be hollowed > out to some extent. In the proposed model, the 1st level End User is for > all practical purposes operating as an LIR - the only significant > difference seems to be related to which organisation it needs to pay for > the privilege (i.e. the RIPE NCC or the Sponsoring LIR). To me the > implied meaning of "End User" is the "final" recipient, i.e., someone > who is actually *using* the addresses, while a 1st level End User > certainly meets the definition of IR in section 2.1. I would therefore > consider instead calling this role a "Sponsored LIR" or something along > those lines. Well, any end-user will become some sort of an IR. I had the intent to define an other IR (lower than the LIR) but the consent amongst us, the proposers, was that this would complicate too much the proposal. > > - In a similar vein, the LIRs have some NCC-provided tools at their > disposal, such as for example the LIR Portal, which is the only place > where at least some information can be updated. RPKI is another. Has it > been thought whether the "Sponsored LIRs" will be given direct access to > these tools, or if their resources will appear in the interface of the > Sponsoring LIR, who will have the responsibility to maintain this > information on their behalf (which would be an increased responsibility > compared to sponsored PI), or something else such as LIR Portal access > being one of the incentives for becoming a "proper" LIR? This would be out of scope for this proposal, I think 2013-04 touches this service. The RIPE Database objects for current v6PI assignments can be changed by the maintainer, RPKI may be available after 2013-04 is approved. The only thing that I did not think of, and just realised now, is that if an End User needs to make more than a /48 sub-allocation, it will need to request an approval from the RIPE NCC. I am not sure how this approval can be recorded by the RIPE NCC, the Sponsoring LIR and the End User. This will probably be touched by the RIPE NCC in their Impact Analysis. > > - When it comes to the counterpoint regarding taking away the incentive > to become "proper" LIRs. Well - it's been possible to run consumer-based > ISPs on IPv4 PI for quite a while, yet the NCC is failing to turn a > deficit even though it allegedly is trying, so I'm not terribly > concerned. :-) More seriously though, I don't think this is likely to be > much of a problem before the same "Sponsored LIR" concept is backported > to IPv4, and not necessarily then either. I don't think this proposal will cause any problems either. But I've heard this argument so many times, we had to put it in the rationale. cheers, elvis From elvis at velea.eu Mon Sep 30 15:20:02 2013 From: elvis at velea.eu (Elvis Velea) Date: Mon, 30 Sep 2013 15:20:02 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <5244A321.10707@velea.eu> Message-ID: <52497A82.8090509@velea.eu> Hi Jan, On 9/27/13 8:55 AM, Jan Ingvoldstad wrote: > On Thu, Sep 26, 2013 at 11:46 PM, Richard Hartmann [...] > Personally, I would like to see a single, canonical, authorative > document defining _all_ special terms. [...] > > As a reasonably fresh novice in this WG and the LIR game, I think that > kind of document is an absolute necessity. I agree with you, however, such document should be created for all the special terms used within the RIPE Community and should not be specific to this policy. Therefore, I would say that if anyone is interested in creating such a document (and I will join that team if one is formed), an other policy proposal should be made independent of 2013-06. cheers, elvis From mschmidt at ripe.net Mon Sep 30 15:22:17 2013 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 30 Sep 2013 15:22:17 +0200 Subject: [address-policy-wg] 2013-05 New Draft Document and Impact Analysis Published (No Restrictions on End User Assignments in Intra-RIR Transfers) Message-ID: Dear colleagues, The draft document for the proposal described in 2013-05, "No Restrictions on End User Assignments in Intra-RIR Transfers" has been published. The impact analysis that was conducted for this proposal has also been published. You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2013-05 and the draft document at: https://www.ripe.net/ripe/policies/proposals/2013-05/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 29 October 2013. Regards Marco Schmidt Policy Development Office RIPE NCC From elvis at velea.eu Mon Sep 30 15:26:00 2013 From: elvis at velea.eu (Elvis Velea) Date: Mon, 30 Sep 2013 15:26:00 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <524446bd.07070e0a.0744.fffff079SMTPIN_ADDED_MISSING@mx.google.com> <5244B41B.1070807@v4escrow.net> Message-ID: <52497BE8.7070200@velea.eu> Hi Jan, On 9/27/13 9:01 AM, Jan Ingvoldstad wrote: > On Fri, Sep 27, 2013 at 1:45 AM, Richard Hartmann [...] > > If /32 becomes the new default/minimum, keeping those limits seems to > > be counter-intuitive. > > > I concur. noted. > > And I think it's worth keeping in mind that even a /48 is a ludicrously > enormously large address space. Actually, it's not such an enormous large amount, taking into consideration that 64 bits are out of scope. You are left with 16 bits (65K networks/end sites). And let's not forget that the recommendation is to give a customer at least a /56. > > With a corporate hat on, I think it highly unlikely that anyone > > manager or sales person will be content with less than the absolute > > maximum they can get even if they don't need it. So save for a few > > corporations and maybe temporary allocations, I suspect everyone will > > go for a /32. > > > > So do I, especially considering the turn of phrase, which is nearly > guaranteed to instill a fear of running out somehow. > > Nobody should run out with a /48. I am not sure what to understand from the statement above. It is up to the company managing the address space to make sure that they have a contract in place to keep it's sub-allocated space under control. > > I think it's somewhat sensible that a LIR should have access to a /32. :) And the current policy allows even up to a /29 with no questions asked :-) cheers, elvis From elvis at velea.eu Mon Sep 30 15:33:58 2013 From: elvis at velea.eu (Elvis Velea) Date: Mon, 30 Sep 2013 15:33:58 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> Message-ID: <52497DC6.3050103@velea.eu> Hi again Jan, :-) On 9/27/13 9:08 AM, Jan Ingvoldstad wrote: > On Fri, Sep 27, 2013 at 8:49 AM, Tore Anderson > wrote: > > - I find the new graphics slightly confusing. There is drawn a link > between the Sponsoring LIR to between the RIPE NCC and the End User, as > expected, but also between the Sponsoring LIR and the 1st and 2nd level > End Users (i.e. between the End User holding the allocation and its > downstream End Users). Why is that? I don't see that the Sponsoring LIR > has any responsibilities on this level? Also, is there some significance > to be read into the fact that the line between the 2nd level End User > and its End Site is dotted, while between the 1st level End User and its > End Site it is solid? > > > +1 to that. > > Although this is a bit like bike shedding, I think there should be a > descriptive explanation right next to the graph, which would be helpful > to n00bs (like me, really). I've already responded to Tore's e-mail. If you still think it's confusing, please let me know. > > > - I find the precise definition of the term "End User" to be hollowed > out to some extent. In the proposed model, the 1st level End User is for > all practical purposes operating as an LIR - the only significant > difference seems to be related to which organisation it needs to pay for > the privilege (i.e. the RIPE NCC or the Sponsoring LIR). To me the > implied meaning of "End User" is the "final" recipient, i.e., someone > who is actually *using* the addresses, while a 1st level End User > certainly meets the definition of IR in section 2.1. I would therefore > consider instead calling this role a "Sponsored LIR" or something along > those lines. > > > I agree. This is made even more difficult by apparently changing the > scope of the policy from the leftmost 64 bits to all 128 bits, and by > restricting suballocations to the smallest atoms to a /64, appears to > reduce the IPv6 address space from 128 bits to 64 bits. The scope of the policy has not been changed. In the current policy assignments lower than a /64 are not permitted. Therefore, nothing is changed. > > Section 1, 1.1 Overview has this current sentence that is removed in the > proposal: > > "All bits to the left of /64 are in scope." > > In one of the previous posts, making things easier for e.g. using > separate IP addresses for SSL is an argument for this proposal, but as I > read it right now, I would have to sub-allocate a /64 for each SSL > certificate, rather than say a /128. > > I feel reasonably sure that this is not the intention of the authors. You are right, it was not our intention to remove that line from section 1.1. However, even with the old policy, my understanding was that you should have assigned a /64 for the SSL certificate and not a /128. I am not sure that removing that line makes any difference, let's see what the others think and we could add it back if it really changes the policy scope. cheers, elvis From elvis at velea.eu Mon Sep 30 15:38:45 2013 From: elvis at velea.eu (Elvis Velea) Date: Mon, 30 Sep 2013 15:38:45 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <52452FFF.9060701@fud.no> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <5244A321.10707@velea.eu> <52452FFF.9060701@fud.no> Message-ID: <52497EE5.8030409@velea.eu> Hi, On 9/27/13 9:13 AM, Tore Anderson wrote: > * Jan Ingvoldstad > >> As a reasonably fresh novice in this WG and the LIR game, I think that >> kind of document is an absolute necessity. > > FWIW, "End User" is defined here: > > http://www.ripe.net/ripe/internet-coordination/internet-governance/internet-technical-community/the-rir-system I had no idea that this page existed :-) > > However, as I've already pointed out, the new "Sponsored LIR" class of > End Users introduced by this proposal doesn't really fit the original > definition. (RFC 7020 uses the terms "child LIRs" / "sub-LIRs" instead.) looking at the page above, you are right :-) I'll have a look at RFC7020 and discuss with the co-authors to see how we may change the deffinitions/terms in the next version of this proposal. cheers, elvis From elvis at velea.eu Mon Sep 30 15:39:42 2013 From: elvis at velea.eu (Elvis Velea) Date: Mon, 30 Sep 2013 15:39:42 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <5244A321.10707@velea.eu> <52452FFF.9060701@fud.no> Message-ID: <52497F1E.8000502@velea.eu> Hi Richard, On 9/27/13 9:25 AM, Richard Hartmann wrote: > On Fri, Sep 27, 2013 at 9:13 AM, Tore Anderson wrote: > >> However, as I've already pointed out, the new "Sponsored LIR" class of >> End Users introduced by this proposal doesn't really fit the original >> definition. (RFC 7020 uses the terms "child LIRs" / "sub-LIRs" instead.) > > Sponsored/Sponsoring LIR is easy to confuse. > > Child LIR does not easily expand (Grandchild LIR?). > > A Sub-LIR can, if need be, have a Sub-Sub-LIR. > > that sounds like a good idea, I'll talk to the co-authors about this option. cheers, elvis From elvis at velea.eu Mon Sep 30 15:40:30 2013 From: elvis at velea.eu (Elvis Velea) Date: Mon, 30 Sep 2013 15:40:30 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <5244A321.10707@velea.eu> <52452FFF.9060701@fud.no> Message-ID: <52497F4E.9080206@velea.eu> Hi, On 9/27/13 10:20 AM, Jan Ingvoldstad wrote: > Yikes, I re-read my messages, and they're a bit more negative than intended. > > I'd like to say that I support the cleanup work on a general basis; > merging the three documents and clearing up the address space allocation > policy is a Good Thing. thanks, I was getting worried a bit :-) cheers, elvis From tore at fud.no Mon Sep 30 15:51:46 2013 From: tore at fud.no (Tore Anderson) Date: Mon, 30 Sep 2013 15:51:46 +0200 Subject: [address-policy-wg] 2013-05 New Draft Document and Impact Analysis Published (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: References: Message-ID: <524981F2.2010002@fud.no> +1 Tore From erik at bais.name Mon Sep 30 16:21:23 2013 From: erik at bais.name (Erik Bais) Date: Mon, 30 Sep 2013 14:21:23 +0000 Subject: [address-policy-wg] black market transfers In-Reply-To: References: <5245A61F.6030001@inex.ie> Message-ID: <862A73D42343AE49B2FC3C32FDDFE91C811D7AE1@E2010-MBX04.exchange2010.nl> Hi Randy & Nick, >> Maybe use indicators like different ASN paths, different source asns, >> changes to registered object, etc? All very subjective though. > yep. I've had several people ask me questions in regards to changes for PI space. Some even think that changing the Supporting LIR (PI) is sufficient to make the required changes at RIPE to transfer resources ... Others thought that an IP is an IP and that one was also allowed to sell PI space (under the current policy) ... None of the people that came to me were correctly upfront and shocked that what they were doing is not according to the policy or even not a transfer in the actual change of legal entity ... However the look on somebody their face is priceless if you tell them that the 'seller' can just resell the space to someone else as they still hold the ownership according to the registry. Using BGP data to tell if some got his space from the market might give a lot of false positives. Not all IP space that changes from AS, is also a permanent change ... (think about leased IP's, which doesn't require the registry to be updated on the ownership.) Personally I think it might be very hard to identify black market transfers ... especially since pimping ones prefixes to another AS for $$$ is common practice these days. Erik Bais From elvis at velea.eu Mon Sep 30 17:22:52 2013 From: elvis at velea.eu (Elvis Velea) Date: Mon, 30 Sep 2013 17:22:52 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> Message-ID: <5249974C.8050904@velea.eu> Hi Tero, On 9/27/13 10:28 AM, Tero Toikkanen wrote: >> - I find the new graphics slightly confusing. There is drawn a link >> between the Sponsoring LIR to between the RIPE NCC and the End User, as >> expected, but also between the Sponsoring LIR and the 1st and 2nd level >> End Users (i.e. between the End User holding the allocation and its >> downstream End Users). Why is that? I don't see that the Sponsoring LIR >> has any responsibilities on this level? Also, is there some significance >> to be read into the fact that the line between the 2nd level End User >> and its End Site is dotted, while between the 1st level End User and its >> End Site it is solid? > > It might be clearer to illustrate all three paths individually (from RIPE NCC to LIR, Sponsoring LIR and End User). I also agree with what Tore Anderson and Richard Hartmann said about somehow clarifying the division between Sponsoring LIR and a possible Sponsored/child/sub-LIR under it. Sponsored/Sponsoring LIR is certainly easily confused, so Sub-LIR might be the way to go. There are only two paths, from the RIPE NCC to LIR and from the RIPE NCC to End user (we may decide to change the name) via the Sponsoring LIR. cheers, elvis From elvis at velea.eu Mon Sep 30 17:29:39 2013 From: elvis at velea.eu (Elvis Velea) Date: Mon, 30 Sep 2013 17:29:39 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <66810E018CDF3344A676D4025D2350700F7BA5@office-exbe-01.office.nbl.fi> References: <524446bd.07070e0a.0744.fffff079SMTPIN_ADDED_MISSING@mx.google.com> <5244B41B.1070807@v4escrow.net> <66810E018CDF3344A676D4025D2350700F7BA5@office-exbe-01.office.nbl.fi> Message-ID: <524998E3.3010807@velea.eu> Hi Tero, On 9/27/13 11:55 AM, Tero Toikkanen wrote: >>> These were restrictions that existed in the previous version and things >>> seemed to work well with these restrictions/sizes. I hear you and if others >>> think the same, we could change the limits. >> >> If /32 becomes the new default/minimum, keeping those limits seems to >> be counter-intuitive. > > I agree. We should propose /48 as the _minimum_ allocation for all special purposes, maybe with possible provisions for more. currently the policy states that the minimum allocation is a /32 and LIRs can request up to a /29 with no questions asked, this policy proposal does not intend to change that minimum. > >> Aside from the difference between "ever need more" and "foreseeable >> future", this means that End Users will need to decide between /48 and >> /32. To pick a specific example, FOSDEM will apply for IPv6 PI soon. >> As they need more than one single /48, under that policy the seem to >> be _forced_ to a /32. >> >> With a corporate hat on, I think it highly unlikely that anyone >> manager or sales person will be content with less than the absolute >> maximum they can get even if they don't need it. So save for a few >> corporations and maybe temporary allocations, I suspect everyone will >> go for a /32. > > I agree that the either /48 with no room for expansion or /32 is too strict. I would go as far as to propose that End Users could request anything from /48 to /32 and also be limited to that. However, this may have implications on address reservations in RIPE, as was the case with LIRs being allocated a /32 but reserved a /29. So if to avoid renumbering and to encourage aggregation we end up allocating /48s, but reserving a /32 for each one, we probably will end up at the same point again. If someone is sure that they will not need more than a /48, ever, then they can request that /48. If they have any plans to make sub-allocations, then they can receive the /32 and use it for the rest of their life. Creating different levels/limits will complicate the policy again and our aim was to make it as simple as possible. - small allocations - /48 - large allocations - /32 or more > > Furthermore, as the "LIR incentive", I'd restrict End User allocations to a /32. If you need more, you should become an LIR. I don't think adding this limitation will work. If someone does not want to become an LIR, they will simply setup a new company (it costs 50? in most of Europe) and get an other /32 on that company's name. So, I don't think that limiting the size of the allocation the End User/Sub-LIR can receive is a good idea. cheers, elvis From elvis at velea.eu Mon Sep 30 17:49:51 2013 From: elvis at velea.eu (Elvis Velea) Date: Mon, 30 Sep 2013 17:49:51 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <66810E018CDF3344A676D4025D2350700F7BE3@office-exbe-01.office.nbl.fi> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <66810E018CDF3344A676D4025D2350700F7BE3@office-exbe-01.office.nbl.fi> Message-ID: <52499D9F.2030305@velea.eu> Hi again Tero, On 9/27/13 12:25 PM, Tero Toikkanen wrote: > Dear all, > > In general I support the direction of this proposal. > thank you :) > I have already mentioned some of my observations on other ongoing conversations, but here are a couple more: > > 5.2.3 > "results in a doubling of the address space allocated to it" > With larger blocks this seems a bit drastic to me. I.e. if a large corporation needs a new /32, but already has 4 of them, they will automagically get 4 /32s more. I assume this is to enable aggregation, but without making large reservations in the address pool for each End User, it probably wouldn't work for that purpose. In order to assess how reasonable this clause is, we would need to know how addresses are allocated and from where. I my opinion aggregation = good, large reservations for every single End User with a /32 = bad. > This sentence is part of the current policy and has work find until now. Actually, I think that the RIPE NCC has not had (any?) that many additional allocation requests to actually test this part of the policy. As far as I know, currently, the RIPE NCC allocates /32s to each LIR (up to a /29) and reserves 3 bits. I believe they make the same reservation to current PI users, no matter what is the size of that assignment. So, I think that if the RIPE NCC continues with the same practices, part of your question has been answered. Regarding the second part, I agree that an LIR (due to mergers, acquisitions, takeovers, etc) may end up with multiple IPv6 allocations. These are rare cases and may not involve too many LIRs. And even if an LIR has 4 /29s, requesting an additional allocation will mean that for each of the /29s they will need to have reach the hd-ratio limit. When the LIR has reached the hd-ratio limit for multiple allocations, I think it would be fair to just double (if possible) all those allocations. That will give them enough space to continue sub-allocating. > 5.3.1 > "When more than a /48 is to be sub-allocated to the same customer, the LIR or the End User (via the Sponsoring LIR) must request an approval from the RIPE NCC." > This is a bit vague wording, which would probably be better by just removing the parentheses. I assume the idea is that the End User submits the request to the Sponsoring LIR, which then hands it over to RIPE NCC? > The End-user/Sub-LIR will not be able to directly request the approval from the RIPE NCC. It must be done via the Sponsoring LIR. I don't think it makes any difference with or without the parentheses. cheers, elvis From richih.mailinglist at gmail.com Mon Sep 30 18:01:59 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Mon, 30 Sep 2013 18:01:59 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <52497A82.8090509@velea.eu> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <5244A321.10707@velea.eu> <52497A82.8090509@velea.eu> Message-ID: On Mon, Sep 30, 2013 at 3:20 PM, Elvis Velea wrote: > I agree with you, however, such document should be created for all the > special terms used within the RIPE Community and should not be specific to > this policy. Of course. That was the intention. > Therefore, I would say that if anyone is interested in creating such a > document (and I will join that team if one is formed), an other policy > proposal should be made independent of 2013-06. There's already some initial work going on off-list. If anyone wants to join in, please contact me. Richard From tore at fud.no Mon Sep 30 18:41:14 2013 From: tore at fud.no (Tore Anderson) Date: Mon, 30 Sep 2013 18:41:14 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <5249974C.8050904@velea.eu> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> Message-ID: <5249A9AA.8080308@fud.no> * Elvis Velea > There are only two paths, from the RIPE NCC to LIR and from the RIPE NCC > to End user (we may decide to change the name) via the Sponsoring LIR. Hi Elvis, Just thinking out loud here, so don't mistake this for opposition to the current proposal, it's not, but we are in the bikeshe^Wdiscussion phase after all... I'm thinking that the "Sponsoring LIR" concept is an NCC operational issue that perhaps doesn't really belong in address policy to begin with. Perhaps it would result in a more concise and elegant policy if instead of "unifying" PA with PI, this proposal simply just removed the PI concept altogether? Simply just delete section 7 of the policy document and leave it at that - as far as the policy document goes anyway. Then you would have only one path and no confusion: RIR[RIPE NCC] -> LIR -> End User Everything that follows below could be considered operational issues that's for the NCC/AGM/Board to decide on...but just to elaborate a bit more on where I'm thinking something like this could lead to: Q: But what about existing PI holders and their blocks? A: Just start considering them to be LIRs. Upon implementation of the new policy, the NCC could automatically convert all existing inet6num in the database with status ASSIGNED PI to ones with status "ASSIGNED" (PA), and add a congruent object with status ALLOCATED-BY-RIR. Q: They wouldn't want to pay the full membership price for being LIRs! A: We don't have to make them. It could be possible to be a RIPE region LIR even though you're not a direct/full member of the RIPE NCC. RIPE NCC members could be seen as "sponsors of LIR status" instead of "sponsors for PI blocks". It could even cost the same ?50 as before. Q: How would that work? A: We could end up with two levels of RIPE NCC membership, e.g. "full" like we have today, and "associate". Both would be fully-blown LIRs, but to keep the operational overhead in NCC billing/finance low, the membership fee for these "associate" members would be charged by the NCC to the full members who are sponsoring them (just like with PI). Q: Why would anyone want to be a full member then? A: Access to certain NCC services such as the LIR Portal, Atlas credit boost, etc. could be limited to full members only. In any case - those would be operational and mercantile issues we could leave out of the policy (but perhaps provide suggestions/guidance on in the supporting notes). Maybe I'm off my rocker, but this is what was going through my head on the bus back home today... :-) Tore From nick at inex.ie Mon Sep 30 18:47:59 2013 From: nick at inex.ie (Nick Hilliard) Date: Mon, 30 Sep 2013 17:47:59 +0100 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <5249A9AA.8080308@fud.no> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> Message-ID: <5249AB3F.2080808@inex.ie> On 30/09/2013 17:41, Tore Anderson wrote: > Then you would have only one path and no confusion: > > RIR[RIPE NCC] -> LIR -> End User you would have confusion about who the address space holder was and what the end user's rights and obligations were to the ripe ncc. If you're going to suggest this, talk to the RIPE NCC legal eagles because it's a difficult area. Nick From tore at fud.no Mon Sep 30 19:00:10 2013 From: tore at fud.no (Tore Anderson) Date: Mon, 30 Sep 2013 19:00:10 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <5249AB3F.2080808@inex.ie> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <5249AB3F.2080808@inex.ie> Message-ID: <5249AE1A.6050609@fud.no> * Nick Hilliard > On 30/09/2013 17:41, Tore Anderson wrote: >> Then you would have only one path and no confusion: >> >> RIR[RIPE NCC] -> LIR -> End User > > you would have confusion about who the address space holder was and what > the end user's rights and obligations were to the ripe ncc. If you're > going to suggest this, talk to the RIPE NCC legal eagles because it's a > difficult area. All existing PI holders would become simultaneously both the LIR *and* the End User in the above chain, so I'm not sure where this confusion would come from? It would essential be the same as if a current LIR assigns its entire allocation to itself (its own infrastructure) and has no external End Users. I have a feeling this already happens a quite a bit in IPv4 these days... Tore From gert at space.net Mon Sep 30 19:31:41 2013 From: gert at space.net (Gert Doering) Date: Mon, 30 Sep 2013 19:31:41 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <5249A9AA.8080308@fud.no> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> Message-ID: <20130930173141.GF65295@Space.Net> Hi, (no hats) On Mon, Sep 30, 2013 at 06:41:14PM +0200, Tore Anderson wrote: > Q: How would that work? > A: We could end up with two levels of RIPE NCC membership, e.g. "full" > like we have today, and "associate". Both would be fully-blown LIRs, but > to keep the operational overhead in NCC billing/finance low, the > membership fee for these "associate" members would be charged by the NCC > to the full members who are sponsoring them (just like with PI). I'm not exactly sure what the difference between an "associate member" and today's "consumer of resources provided by a sponsoring LIR" would then be, except for the title on the contract. On the contrary, some enterprises just don't want to deal with the RIPE NCC if they can make a contract with their friendly neighbouring LIR instead... So I'm not sure it's worth abandoning the established concept of sponsoring LIR right away (especially since doing away with it would affect IPv4 PI as well...). It wouldn't make a difference anyway :-) - if we want to give people the option to take a /48 because it's big enough for them, we'd then still have "two standard sizes"... So, yes, another avenue could be "abandon /48 assignments/allocations", but *that* brings up another can of worms (what about an enterprise that has 5 locations that all have local ISP upstreams and want to do BGP multihoming? 5x /48 suits them well today, 1x /32 with someone blocking more-specifics from that because no site is announcing the /32 aggregate would not be that good). I'm repeating the "no hats" bit, just contributing to the discussion as someone who has fought IPv6 policy for a while now :-) - and this is discussion phase, so take this all as "brain dump", not as "advice from the chair". 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 (0)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 Mon Sep 30 21:02:21 2013 From: tore at fud.no (Tore Anderson) Date: Mon, 30 Sep 2013 21:02:21 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <20130930173141.GF65295@Space.Net> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <20130930173141.GF65295@Space.Net> Message-ID: <5249CABD.4030603@fud.no> * Gert Doering > On Mon, Sep 30, 2013 at 06:41:14PM +0200, Tore Anderson wrote: >> Q: How would that work? >> A: We could end up with two levels of RIPE NCC membership, e.g. "full" >> like we have today, and "associate". Both would be fully-blown LIRs, but >> to keep the operational overhead in NCC billing/finance low, the >> membership fee for these "associate" members would be charged by the NCC >> to the full members who are sponsoring them (just like with PI). > > I'm not exactly sure what the difference between an "associate member" > and today's "consumer of resources provided by a sponsoring LIR" would > then be, except for the title on the contract. On the contrary, some > enterprises just don't want to deal with the RIPE NCC if they can make > a contract with their friendly neighbouring LIR instead... The difference would be that an "associate member" (which is just an idea, and outside the scope of APWG anyway) would be an LIR, and would therefore be able to assign address space to its customer in turn. PI holders currently cannot assign address space to their customers, and that's what I understand this proposal to be all about changing, but it does it in a way that defines a new "breed" of End User who a) does not at all fit the original definition of an End User, while b) does completely fit the definition of an Internet Registry. Put it another way, the new (1st level) type of End User created by the proposal appears to me to be an LIR in all but name. So what I'm thinking is that it's better to call a spade a spade as far as address policy go, and instead have the NCC/AGM/Board decide exactly how they want to go about charging for the different flavours of spades. But that's just my ?0.02. Like I said earlier, this should not be mistaken for opposition to the current proposal, just a suggestion. > So I'm not sure it's worth abandoning the established concept of sponsoring > LIR right away (especially since doing away with it would affect IPv4 PI > as well...). It wouldn't make a difference anyway :-) - if we want to > give people the option to take a /48 because it's big enough for them, > we'd then still have "two standard sizes"... Or we could simply tell the requesters to pick their favourite number between 28 and 49... as long as policy says it's should be possible to extend up to and including /29 it doesn't really matter what they start out with as far as keeping delegations aggregated go (and routing is another matter entirely). > So, yes, another avenue could be "abandon /48 assignments/allocations", > but *that* brings up another can of worms (what about an enterprise that > has 5 locations that all have local ISP upstreams and want to do BGP > multihoming? 5x /48 suits them well today, 1x /32 with someone blocking > more-specifics from that because no site is announcing the /32 aggregate > would not be that good). But that's the route6 object, not the inet6num. If someone is filtering on the inet6num without accepting more specifics they're already asking for trouble (their users would surely complain about lack of connectivity to the more-specifics inside 2a02:26f0::/32, for starters). Tore From lists-ripe at c4inet.net Mon Sep 30 21:27:20 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 30 Sep 2013 20:27:20 +0100 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <5249974C.8050904@velea.eu> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> Message-ID: <20130930192720.GA70419@cilantro.c4inet.net> On Mon, Sep 30, 2013 at 05:22:52PM +0200, Elvis Velea wrote: >There are only two paths, from the RIPE NCC to LIR and from the RIPE >NCC to End user (we may decide to change the name) via the Sponsoring >LIR. I would be in favour of converting all resources into "independent resources" and the path going, in all cases: RIR -> Sponsoring LIR -> End User. Advantages: - End Users can transfer "their" resources to a different Sponsoring LIR - Specialist LIRs can be established that have the necessary skills to manage resources properly, End Users wouldn't have to worry about resource management and it may result in reducing the work-load on the RIR.. Disadvantages: - This opens the door to the establishment of "N(ational)IRs", something which some states have expressed an interest in. - There is a probability of de-aggregation of resources as they move between Sponsoring LIRs - could possibly be mitigated by making the minimum assignments big enough. - RIR membership will likely decline - this could also be an advantage. rgds, Sascha Luck PS: in such a scenario I would even consider supporting 2012-08 ;) From gert at space.net Mon Sep 30 22:12:46 2013 From: gert at space.net (Gert Doering) Date: Mon, 30 Sep 2013 22:12:46 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <5249CABD.4030603@fud.no> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <20130930173141.GF65295@Space.Net> <5249CABD.4030603@fud.no> Message-ID: <20130930201246.GI65295@Space.Net> Hi, without actually wanting to drive the direction anywhere, just adding something that you might have missed :-) On Mon, Sep 30, 2013 at 09:02:21PM +0200, Tore Anderson wrote: > PI holders currently cannot assign address space to their customers, and > that's what I understand this proposal to be all about changing, but it > does it in a way that defines a new "breed" of End User who a) does not > at all fit the original definition of an End User, while b) does > completely fit the definition of an Internet Registry. Put it another > way, the new (1st level) type of End User created by the proposal > appears to me to be an LIR in all but name. Well, there are still "just plain" end users of "PI space" out there, that do not do "LIR things", but just run a (multihomed) network - we have a couple of these under our sponsoring LIR, and they are quite happy not having to deal with the RIPE NCC (because they are smaller german enterprises, not willing to deal with international contracts, etc.). The whole thing that started this PA/PI unification project is that the distinction between "ISP" (=LIR, PA) and "end user" (=not LIR, PI) has become less and less clear over time, and as such, it became mostly confusing to "people out there" not regularily dealing in RIPE policy. So - based on "some people will want to operate more like an ISP" and "other people will be happy to number primarily their own network, and maybe a server of their neighbour next door", it seemed to make sense to keep the distinction of "full LIR" and "address space flowing via a sponsoring LIR to folks not really doing LIR things" - and those might not be interested at all in having to deal more with the RIPE NCC. OTOH, I really should stay out of this discussion now, as it's not my role to push this any specific way - while I *did* get this started, now Elvis is the one driving it, and the community has to decide what they (you!) want, while I focus on the chairing thing - guiding the discussion and such. Gert Doering -- some hats -- 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 (0)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 nick at inex.ie Mon Sep 30 22:39:28 2013 From: nick at inex.ie (Nick Hilliard) Date: Mon, 30 Sep 2013 21:39:28 +0100 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <5249AE1A.6050609@fud.no> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <5249AB3F.2080808@inex.ie> <5249AE1A.6050609@fud.no> Message-ID: <5249E180.2000602@inex.ie> On 30/09/2013 18:00, Tore Anderson wrote: > All existing PI holders would become simultaneously both the LIR *and* > the End User in the above chain, so I'm not sure where this confusion > would come from? So how could you convince the existing ipv6 PI holders that the cost increase from ?50/year to LIR membership fees would be worth it? IOW, there are two problems here: an addressing flavour issue, which relates to the RIPE community, and a billing issue which is the responsibility of the RIPE NCC. For sure, you couldn't do this to just the ipv6 PI assignments - it would have to be to all address space, but then you get into the thorny issue of billing. Let me pull out a paper napkin for a moment and hand-wave the possibility that all PI holders became LIRs and all LIRs paid the same fees. The 2014 budget is ?21.7m (practical). All LIRs pay the same (ncc member policy). There are about 9500 members and 33000 assigned pi resources (reality), probably with lots of overlap (reasonable speculation). Let's pluck a figure out of thin air and say that there are 35000 distinct end users + lirs (wild speculation), who need to pay an equal share of a budget of ?21.7 million. This means you have maybe 25000-30000 organisations around the ripe ncc service region who are going to see their fees increase from (wholesale) ?50 to ?650 per annum. This won't fly. We need to be practical about a workable policy proposal here. Whether we like it or not, there is a strong history of cost differentiation in terms of how ip addresess are handled, and I don't see a practical way of levelling the field within the constraints of what's workable and what we'd ultimately like. Nick From tore at fud.no Mon Sep 30 22:55:49 2013 From: tore at fud.no (Tore Anderson) Date: Mon, 30 Sep 2013 22:55:49 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <20130930201246.GI65295@Space.Net> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <20130930173141.GF65295@Space.Net> <5249CABD.4030603@fud.no> <20130930201246.GI65295@Space.Net> Message-ID: <5249E555.7090205@fud.no> * Gert Doering > On Mon, Sep 30, 2013 at 09:02:21PM +0200, Tore Anderson wrote: >> PI holders currently cannot assign address space to their customers, and >> that's what I understand this proposal to be all about changing, but it >> does it in a way that defines a new "breed" of End User who a) does not >> at all fit the original definition of an End User, while b) does >> completely fit the definition of an Internet Registry. Put it another >> way, the new (1st level) type of End User created by the proposal >> appears to me to be an LIR in all but name. > > Well, there are still "just plain" end users of "PI space" out there, > that do not do "LIR things", but just run a (multihomed) network - we > have a couple of these under our sponsoring LIR, and they are quite > happy not having to deal with the RIPE NCC (because they are smaller > german enterprises, not willing to deal with international contracts, > etc.). I didn't miss these, but maybe I wasn't clear enough. Perhaps I should have called them "non-member LIRs" rather than "associate members". So the process would be that your LIR (which is a member of the RIPE NCC) would sponsor your customers to also become LIRs. Contracts are between you and them, no direct RIPE NCC dealings there, while the NCC charges you a fee for each LIR you sponsor in such a way. Just like with PI today. Address blocks would be delegated straight from the RIPE NCC to your customers, also just like with PI today. Assuming these customers of yours only wants to run a multihomed network, they'd just make an assignment to themselves (or you'd help them with that, or the NCC could do it based on their request forms when registering the delegation), and that's that. > The whole thing that started this PA/PI unification project is that the > distinction between "ISP" (=LIR, PA) and "end user" (=not LIR, PI) has > become less and less clear over time, and as such, it became mostly > confusing to "people out there" not regularily dealing in RIPE policy. > > So - based on "some people will want to operate more like an ISP" and > "other people will be happy to number primarily their own network, and > maybe a server of their neighbour next door", it seemed to make sense > to keep the distinction of "full LIR" and "address space flowing via a > sponsoring LIR to folks not really doing LIR things" - and those might > not be interested at all in having to deal more with the RIPE NCC. But...the address space isn't flowing via a sponsoring LIR with PI. The role of the sponsoring LIR is merely a contractual one. AIUI, PI is direct assignments from the RIPE NCC to the End Users, just like PA is direct allocations from the RIPE NCC to the LIRs. Tore From elvis at velea.eu Mon Sep 30 22:59:21 2013 From: elvis at velea.eu (Elvis Velea) Date: Mon, 30 Sep 2013 22:59:21 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <5244A321.10707@velea.eu> <52497A82.8090509@velea.eu> Message-ID: <5249E629.7050508@velea.eu> Hi Richard, On 9/30/13 6:01 PM, Richard Hartmann wrote: > On Mon, Sep 30, 2013 at 3:20 PM, Elvis Velea wrote: > >> I agree with you, however, such document should be created for all the >> special terms used within the RIPE Community and should not be specific to >> this policy. > > Of course. That was the intention. > ok :-) > >> Therefore, I would say that if anyone is interested in creating such a >> document (and I will join that team if one is formed), an other policy >> proposal should be made independent of 2013-06. > > There's already some initial work going on off-list. If anyone wants > to join in, please contact me. > I've sent you a message. cheers, elvis From tore at fud.no Mon Sep 30 23:21:23 2013 From: tore at fud.no (Tore Anderson) Date: Mon, 30 Sep 2013 23:21:23 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <5249E180.2000602@inex.ie> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <5249AB3F.2080808@inex.ie> <5249AE1A.6050609@fud.no> <5249E180.2000602@inex.ie> Message-ID: <5249EB53.6060703@fud.no> * Nick Hilliard > So how could you convince the existing ipv6 PI holders that the cost > increase from ?50/year to LIR membership fees would be worth it? Quoting myself from before: Q: They wouldn't want to pay the full membership price for being LIRs! A: We don't have to make them. It could be possible to be a RIPE region LIR even though you're not a direct/full member of the RIPE NCC. RIPE NCC members could be seen as "sponsors of LIR status" instead of "sponsors for PI blocks". It could even cost the same ?50 as before. This proposal, the way I see it, creates a new class of End Users who are for all practical purposes LIRs. Quoting the definition from the policy document: 2.1 Internet Registry (IR) An Internet Registry is an organisation that is responsible for distributing IP address space to its members or customers and for registering those distributions. IRs are classified according to their primary function and territorial scope within the hierarchical structure depicted in the figure above. [...] 2.3 Local Internet Registry (LIR) A Local Internet Registry (LIR) is an IR that primarily sub-allocates address space to the users of the network services that it provides. If you look at the figure in section 2.0, the "End User" box on the right adjacent to the "Sponsoring LIR" one ... that End User is an LIR. It exactly matches the definition, at least - the only difference appears to be in the name. If it walks like an LIR, talks like an LIR... So let's try replacing the "End User" label on that box with "LIR". Now the two trees below the RIPE NCC are identical, except for the presence of the "Sponsoring LIR" box on the right. But that's a contractual/billing-related mechanism that doesn't really have anything to do with the internet registry system per se. So I think we can just as well remove it from the address policy?, and we are left with two completely identical hierarchies. [1] Not saying it should be removed as a contractual/billing-related mechanism as currently used, but I don't think it is necessary to specify it in the policy document just like we don't specify the RIPE NCC fees in there either. > This won't fly. We need to be practical about a workable policy proposal > here. Whether we like it or not, there is a strong history of cost > differentiation in terms of how ip addresess are handled, and I don't see a > practical way of levelling the field within the constraints of what's > workable and what we'd ultimately like. I'm not saying we should start charging the traditional PI holders more than we do today. Just that if we're going to grant them "LIR powers", which this proposal does (and I don't disagree with that), we might as well start calling them "LIRs" as well. A spade is a spade. Tore From elvis at velea.eu Mon Sep 30 23:38:27 2013 From: elvis at velea.eu (Elvis Velea) Date: Mon, 30 Sep 2013 23:38:27 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <5249A9AA.8080308@fud.no> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> Message-ID: <5249EF53.2070604@velea.eu> Hi Tore, I'll respond below to all the suggestions. On 9/30/13 6:41 PM, Tore Anderson wrote: > * Elvis Velea > >> There are only two paths, from the RIPE NCC to LIR and from the RIPE NCC >> to End user (we may decide to change the name) via the Sponsoring LIR. > > Hi Elvis, > > Just thinking out loud here, so don't mistake this for opposition to the > current proposal, it's not, but we are in the bikeshe^Wdiscussion phase > after all... right :) > > I'm thinking that the "Sponsoring LIR" concept is an NCC operational > issue that perhaps doesn't really belong in address policy to begin > with. Perhaps it would result in a more concise and elegant policy if > instead of "unifying" PA with PI, this proposal simply just removed the > PI concept altogether? Simply just delete section 7 of the policy > document and leave it at that - as far as the policy document goes anyway. > > Then you would have only one path and no confusion: > > RIR[RIPE NCC] -> LIR -> End User Nick already responded to this, and actually, my personal belief is that we should aim to have everyone pay the same fee but not force everyone to become an LIR. Some companies will/can not be members of other organisations (RIPE NCC). The scheme we have right now works fine: RIPE NCC -> LIR -> End User ->[...] -> End Site (this is already possible with the LIR sub-allocating to the end user even with the current policy) RIPE NCC -> End User ->[...] -> End Site this is basically the big thing introduced by this policy proposal, allowing the non-LIRs to offer services over IPv6 to any kind of customers they may have. > > Everything that follows below could be considered operational issues > that's for the NCC/AGM/Board to decide on...but just to elaborate a bit > more on where I'm thinking something like this could lead to: > > Q: But what about existing PI holders and their blocks? > A: Just start considering them to be LIRs. Upon implementation of the > new policy, the NCC could automatically convert all existing inet6num in > the database with status ASSIGNED PI to ones with status "ASSIGNED" > (PA), and add a congruent object with status ALLOCATED-BY-RIR. This will happen anyway, all the ASSIGNED PI will become ALLOCATED. > > Q: They wouldn't want to pay the full membership price for being LIRs! > A: We don't have to make them. It could be possible to be a RIPE region > LIR even though you're not a direct/full member of the RIPE NCC. RIPE > NCC members could be seen as "sponsors of LIR status" instead of > "sponsors for PI blocks". It could even cost the same ?50 as before. > This is what will happen with this current proposal. However, the RIPE NCC will make the allocation to the End User and not to the LIR. > Q: How would that work? > A: We could end up with two levels of RIPE NCC membership, e.g. "full" > like we have today, and "associate". Both would be fully-blown LIRs, but > to keep the operational overhead in NCC billing/finance low, the > membership fee for these "associate" members would be charged by the NCC > to the full members who are sponsoring them (just like with PI). We will have two levels, just not two levels of membership. We will have members and non-members. The non-members will have to pay the invoice for maintenance of these resources to their Sponsoring LIR. > > Q: Why would anyone want to be a full member then? > A: Access to certain NCC services such as the LIR Portal, Atlas credit > boost, etc. could be limited to full members only. > > In any case - those would be operational and mercantile issues we could > leave out of the policy (but perhaps provide suggestions/guidance on in > the supporting notes). Maybe I'm off my rocker, but this is what was > going through my head on the bus back home today... :-) > Correct, if someone wants to become a member they can benefit from all the services the RIPE NCC can offer. Otherwise, they can just request an allocation via the Sponsoring LIR and (maybe) pay (a bit) less. cheers, elvis From elvis at velea.eu Mon Sep 30 23:45:23 2013 From: elvis at velea.eu (Elvis Velea) Date: Mon, 30 Sep 2013 23:45:23 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <5249AB3F.2080808@inex.ie> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <5249AB3F.2080808@inex.ie> Message-ID: <5249F0F3.9070402@velea.eu> Hi, On 9/30/13 6:47 PM, Nick Hilliard wrote: > On 30/09/2013 17:41, Tore Anderson wrote: >> Then you would have only one path and no confusion: >> >> RIR[RIPE NCC] -> LIR -> End User > > you would have confusion about who the address space holder was and what > the end user's rights and obligations were to the ripe ncc. If you're > going to suggest this, talk to the RIPE NCC legal eagles because it's a > difficult area. > > Nick I agree Nick, however, Tore does have a point, we may have to find a definition to the current holder of PI. This organisation will now be able to sub-allocate and will essentially become a 'sub-lir' cheers, elvis From elvis at velea.eu Mon Sep 30 23:52:19 2013 From: elvis at velea.eu (Elvis Velea) Date: Mon, 30 Sep 2013 23:52:19 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <5249AE1A.6050609@fud.no> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <5249AB3F.2080808@inex.ie> <5249AE1A.6050609@fud.no> Message-ID: <5249F293.4010001@velea.eu> Hi, On 9/30/13 7:00 PM, Tore Anderson wrote: > * Nick Hilliard > >> On 30/09/2013 17:41, Tore Anderson wrote: >>> Then you would have only one path and no confusion: >>> >>> RIR[RIPE NCC] -> LIR -> End User >> >> you would have confusion about who the address space holder was and what >> the end user's rights and obligations were to the ripe ncc. If you're >> going to suggest this, talk to the RIPE NCC legal eagles because it's a >> difficult area. > > All existing PI holders would become simultaneously both the LIR *and* > the End User in the above chain, so I'm not sure where this confusion > would come from? > sorry, what? I'm confused :-) > It would essential be the same as if a current LIR assigns its entire > allocation to itself (its own infrastructure) and has no external End > Users. I have a feeling this already happens a quite a bit in IPv4 these > days... Note that assignments will no longer exist under the proposed policy. Additionally, I don't really understand the comparison in the context of the question. Just having one path means that only the LIR will receive address space from the RIPE NCC and they can do whatever they want (provided they follow the policy) with that address space. It removes the independence of the current PI holder status. Anyway, I do not think this is the right way to go forward and this proposal would dramatically change the whole policy which is not what we really aim for. Enough drama with the removal of PI and assignments :-) my 2 cents elvis From elvis at velea.eu Mon Sep 30 23:59:17 2013 From: elvis at velea.eu (Elvis Velea) Date: Mon, 30 Sep 2013 23:59:17 +0200 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <20130930173141.GF65295@Space.Net> References: <1380206290.2739@mobil.space.net> <20130926171155.GD65295@Space.Net> <52449DAC.2030700@inex.ie> <52452A96.9060405@fud.no> <66810E018CDF3344A676D4025D2350700F7B64@office-exbe-01.office.nbl.fi> <5249974C.8050904@velea.eu> <5249A9AA.8080308@fud.no> <20130930173141.GF65295@Space.Net> Message-ID: <5249F435.40603@velea.eu> Hi Gert, On 9/30/13 7:31 PM, Gert Doering wrote: > Hi, > > (no hats) > > On Mon, Sep 30, 2013 at 06:41:14PM +0200, Tore Anderson wrote: >> Q: How would that work? >> A: We could end up with two levels of RIPE NCC membership, e.g. "full" >> like we have today, and "associate". Both would be fully-blown LIRs, but >> to keep the operational overhead in NCC billing/finance low, the >> membership fee for these "associate" members would be charged by the NCC >> to the full members who are sponsoring them (just like with PI). > > I'm not exactly sure what the difference between an "associate member" > and today's "consumer of resources provided by a sponsoring LIR" would > then be, except for the title on the contract. On the contrary, some > enterprises just don't want to deal with the RIPE NCC if they can make > a contract with their friendly neighbouring LIR instead... exactly, I think that there's no difference between 'associate member' and customer of 'Sponsoring LIR' (whether we call it Sub-LIR, Portable Internet Registry or get enough support to keep calling it End User) > > So I'm not sure it's worth abandoning the established concept of sponsoring > LIR right away (especially since doing away with it would affect IPv4 PI > as well...). It wouldn't make a difference anyway :-) - if we want to > give people the option to take a /48 because it's big enough for them, > we'd then still have "two standard sizes"... The Sponsoring LIR concept has been a battle won after quite a few years(remember 2007-01?) . I really do not want to throw it away as I believe it's a very valuable concept and it has taken two years of intense discussions in the community. > > So, yes, another avenue could be "abandon /48 assignments/allocations", > but *that* brings up another can of worms (what about an enterprise that > has 5 locations that all have local ISP upstreams and want to do BGP > multihoming? 5x /48 suits them well today, 1x /32 with someone blocking > more-specifics from that because no site is announcing the /32 aggregate > would not be that good). I wouldn't worry about this can of worms, see section 5.2.1 "A /32 (or larger when documented) additional allocation may be provided when different routing requirements are demonstrated." We could change this to "An additional allocation may be provided when different routing requirements are demonstrated." and leave it to the decision of the enterprise to request either a /48 or a /32 or larger. > > I'm repeating the "no hats" bit, just contributing to the discussion as > someone who has fought IPv6 policy for a while now :-) - and this is > discussion phase, so take this all as "brain dump", not as "advice from > the chair". > thanks ;) > gert > cheers, elvis