From tore at fud.no Thu Aug 1 08:38:24 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 01 Aug 2013 08:38:24 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51F91087.5040104@linx.net> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> Message-ID: <51FA0260.8050303@fud.no> * Malcolm Hutty > 1. The main argument in favour of 2013-03, as I understand it, is in the > title "Post-Depletion Reality Adjustment and Clean up". It has been > expressed in the summary > > /'The goal that precipitated the requirement to demonstrate need for > delegations is explicitly stated in section 3.0.3 of the policy, which > reads: > > Conservation: Public IPv4 address space must be fairly distributed to > the End Users operating networks. To maximise the lifetime of the public > IPv4 address space, addresses must be distributed according to need, and > stockpiling must be prevented. > > Following the depletion of the IANA free pool on the 3rd of February > 2011, and the subsequent depletion of the RIPE NCC free pool on the 14th > of September 2012, the "lifetime of the public IPv4 address space" in > the RIPE NCC region has reached zero, making the stated goal > unattainable and therefore obsolete. This proposal attempts to recognise > this fact by removing all policy requirements that was working > exclusively towards attaining this "Conservation" goal.'/ > > However this argument is fallacious. The Conservation policy, even as > stated, expresses *two separate* policy objectives: 'fair distribution', > and maximising the lifetime of the public address pool. Depletion means > that reality has superseded the second objective, but not necessarily > the first. Hi again Malcom, Having slept on it, I have a suggestion that hopefully will make us reach common ground. How about, instead of removing the old Conservation goal completely, we rewrite it as follows: ?Fair use: Public IPv4 address space must be fairly distributed to the End Users operating networks.? This would only remove the second "reality-superseded" objective, but not the first. It would also continue to provide the philosophical foundation on which we may build "enforcement" policies in the future, so we certainly would not be "closing the door" on any such discussion. Furthermore, it might even help the NCC in their political/government interactions, as they can truthfully maintain that their goal with regards to IPv4 is still to provide for fair distribution and fair use. Would such an amendment make the proposal more appealing to you, at least enough to make reach the "I can live with this" point? (This question goes for the others who have noted their reservation towards the proposal too, feel free to chime in!) For what it's worth, such an amendment would not make the proposal less appealing to me - the proposal's ambition was never "take away fairness", but "take away [reality-superseded] bureaucracy" - something which there seems to be little disagreement about, and which an updated proposal would continue to do just as much as before. Best regards, Tore Anderson From gert at space.net Thu Aug 1 09:25:20 2013 From: gert at space.net (Gert Doering) Date: Thu, 1 Aug 2013 09:25:20 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51F91087.5040104@linx.net> References: <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> Message-ID: <20130801072520.GU65295@Space.Net> Hi, On Wed, Jul 31, 2013 at 02:26:31PM +0100, Malcolm Hutty wrote: > I don't support the approval of 2013-03 "No need" at this time. While you're free to do so, I'm just so slightly annoyed that you're doing this *again* - wait until the very last second, and then state fundamental objections. Generally speaking, this sort of blunt "the fundamental principle is wrong" statement of opposition at the very end of the review phase is wasting lots of effort that has gone into making the policy text, creating the impact analysis (lots of time spent at the NCC), and in the preceding discussions. Fundamental opposition really should be voiced in the intitial phase of a proposal, where we try to find common ground to then build the specific text that is then evaluated for the impact analysis. (Technically speaking, your opposition was actually voiced *after the end* of the review phase - which was on July 30. But since we intended to extend the review phase anyway, based on the ongoing discussion, this point is somewhat moot) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From frettled at gmail.com Thu Aug 1 09:47:46 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Thu, 1 Aug 2013 09:47:46 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FA0260.8050303@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> Message-ID: On Thu, Aug 1, 2013 at 8:38 AM, Tore Anderson wrote: > Having slept on it, I have a suggestion that hopefully will make us > reach common ground. How about, instead of removing the old Conservation > goal completely, we rewrite it as follows: > > ?Fair use: Public IPv4 address space must be fairly distributed to the > End Users operating networks.? > That looks sensible enough to me, it doesn't appear to add red tape. :) -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Thu Aug 1 18:24:19 2013 From: nick at inex.ie (Nick Hilliard) Date: Thu, 01 Aug 2013 17:24:19 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FA0260.8050303@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> Message-ID: <51FA8BB3.60202@inex.ie> On 01/08/2013 07:38, Tore Anderson wrote: > ?Fair use: Public IPv4 address space must be fairly distributed to the > End Users operating networks.? Sounds good to me! One minor nit: can you define "fair"? Nick From tore at fud.no Thu Aug 1 19:27:14 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 01 Aug 2013 19:27:14 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FA8BB3.60202@inex.ie> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> Message-ID: <51FA9A72.3040708@fud.no> * Nick Hilliard > On 01/08/2013 07:38, Tore Anderson wrote: >> ?Fair use: Public IPv4 address space must be fairly distributed to the >> End Users operating networks.? > > can you define "fair"? Well *that* is the million dollar question, isn't it. In a state of scarcity, what is "fair"? This is a question that neither I, Malcom, 2013-03, nor ripe-592, presume to have an answer for. However, I understood the crux of Malcom's objection to be that if we remove this stated objective of "fairness", then we lose our principles in the process, and it becomes hard to add it back later (presumably along with a precise definition of "fair"). Therefore I was hoping that retaining this sentence (which is there in today's policy as well) would help move the discussion forward in the direction of consensus. Tore From hph at oslo.net Thu Aug 1 19:43:59 2013 From: hph at oslo.net (Hans Petter Holen) Date: Thu, 1 Aug 2013 19:43:59 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FA9A72.3040708@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> Message-ID: On Saturday, July 27, 2013, Randy Bush wrote: > http://www.ietf.org/id/draft-resnick-on-consensus-02.txt > > may be of help definitely for me the following are open issues for me -1 how it will affect inter region transfers - if this is important to the community -2 how will it affect reclamation of address space by RIRs - and is this important -3 how wil it affet the critics of the RIRs 1 - presently it will not be simple to establish an inter-RIR transfer policy with Arin. Personally - based on previous discussion at Ripe meeting and other places - I do not think the Arin communicty will change opinion on this, at least until they run out. This could be an issue as the "hidden reserves" of "legacy" assignments are in the Arin region. 2 - I think reclamation by the RIPE NCC will decay over time. 3 - the traders will be happy - he ITUs and critical governments will probably make more noice. how much of an issue is this to us? I liked the proposal initialy - but I do not buy the initial argument that since we have run out, conservation is not important. Since we have run out of unused addresses conservation is in many ways more important - unless we belive v6 can take over. Maybe this proposal will increase the number of transfers for money - thus putting more focus on conservation (all businesses tend to focus on conserving cash) It is not clear to me that theese aspects are well undrestood by the majority, but ai might be wrong. -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 Fri Aug 2 00:00:56 2013 From: tore at fud.no (Tore Anderson) Date: Fri, 02 Aug 2013 00:00:56 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> Message-ID: <51FADA98.9080407@fud.no> * Hans Petter Holen > for me the following are open issues for me > -1 how it will affect inter region transfers - if this is important > to the community 1 - presently it will not be simple to establish an > inter-RIR transfer policy with Arin. Personally - based on previous > discussion at Ripe meeting and other places - I do not think the > Arin communicty will change opinion on this, at least until they run > out. To answer the "is it important to the community" you don't have to look further than to proposal 2012-02, which, if accepted, would allow for inter-region transfers with ARIN (and APNIC). However, this proposal has gone nowhere; there appears to be practically no interest in it. Sandra Brown, the author of 2012-02, even stated in an earlier message that the proposal had been withdrawn. The www.ripe.net PDP pages does not (yet?) reflect this, but nevertheless the proposal is beyond any doubt "on ice". So the answer seems to be a resounding "NO". > This could be an issue as the "hidden reserves" of "legacy" > assignments are in the Arin region. Up until the moment of depletion, APNIC was using IPv4 faster than any other RIR by a huge margin. I think it reasonable to conclude that by now there must be a huge unmet need for IPv4 space in the APNIC region. APNIC and ARIN happens to share compatible inter-region transfer policies. Yet, the number of inter-region transfers going from the ARIN region to the APNIC region is negligible - at RIPE66 the total amount of transfers was reported to be 11 (5 per annum, if extrapolating linearly). So the notion that there is some big hidden reserve sitting around in the ARIN region, ripe for the taking and ready to transform our current our state of scarcity into one of abundance (if we only pass an inter-region transfer policy!), seems extremely implausible to me. At least it has not worked out that way for the APNIC region. That said, if having an inter-region transfer policy that is compatible with ARIN's becomes important to us at a later stage, it is quite possible to add back whatever "need basis" is necessary to placate ARIN then. APNIC prop-096 is a demonstration of exactly this being done. > -2 how will it affect reclamation of address space by RIRs - and is > this important 2 - I think reclamation by the RIPE NCC will decay > over time. While I concur that the NCC's reclamation rate will likely decay over time, I doubt 2013-03 will make any difference whatsoever in this regard. There is by now enough unmet demand in our region that all addresses that are likely to be offered on the market would have no problem finding a new owner ("need" requirement notwithstanding). Or to put it another way, the notion that an LIR that wants to sell an allocation would be unable to find a *single* willing buyer strikes me as completely unrealistic. So whatever the motivation an LIR might have for voluntarily surrendering an unused allocation to the NCC instead of selling it might be - I don't see how the removal of the need requirement on the buyer's part could possibly have anything to it. > -3 how wil it affet the critics of the RIRs 3 - the traders will be > happy - he ITUs and critical governments will probably make more > noice. how much of an issue is this to us? I don't doubt the ITU and "critical governments" will make whatever noise they can, on whatever grounds they can, regardless of the validity of the arguments they may muster. This is nothing new, though, it's an ongoing struggle that we'll have to deal with anyway. Put it another way, I highly doubt that *not* passing 2013-03 is likely to make the ITU and critical government cease to be a thorn in our side. (They might as well take any failure of 2013-03 to form another attack: ?Your IPv4 policies are clearly out of touch with reality and your community has proven itself unable to fix them. We'll take it from here, thankyouverymuch...?) Furthermore, there are plenty of other policies, services, and events that these critical entities could use to mount attacks in some way or another. Some examples: 2006-02, 2007-08, 2009-06, 2010-02, 2012-02, the IPv4 Transfer Listing Service, the Recognised IPv4 Transfer Brokers listing, Resource Certification, the IPv4 depletion event itself, and indeed 2013-03. I'm not claiming that any attacks against the NCC or the community based on argumentation stemming from any of the above would be at all valid - just that 2013-03 is not unique in this regard. In the end I don't think we should make (or not make) policies in order to kowtow to the ITU or any government entity, in the hope that they will not try to "take away our toys". If they want our toys, they'll come after them anyway, and we'll have to stand up to them. What gives us legitimacy as a community (and by extension the NCC), is that the policies we make are for the benefit of the Internet, and not in the pursuit of any political power struggle goals. Best regards, Tore Anderson From nick at inex.ie Fri Aug 2 00:31:08 2013 From: nick at inex.ie (Nick Hilliard) Date: Thu, 01 Aug 2013 23:31:08 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FA9A72.3040708@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> Message-ID: <51FAE1AC.1050803@inex.ie> On 01/08/2013 18:27, Tore Anderson wrote: > Well *that* is the million dollar question, isn't it. In a state of > scarcity, what is "fair"? honestly, I have no idea. > Therefore I was hoping that retaining this sentence (which is there in > today's policy as well) would help move the discussion forward in the > direction of consensus. There is a balance in the current policy, which states fairness as an objective and then effectively defines the term as assignment by stated requirement. In the environment of plenty, there was broad consensus that stated requirement was probably a pretty reasonable way of handling address assignment and there were credible reasons to assign the term "fair" to it. No-one ever believed that it was perfect, but it worked well enough. We're no longer in that world: stated requirement will probably no longer work as a reassignment mechanism so we're currently thinking that maybe an open market is the best way to handle future ip assignment requirements. Is this fair? I don't think so, but I don't think it's unfair either. Probably it's unrelated to the concept of fairness. But at least we know where we stand: transfers are the business of the transferer and transferee and the RIPE NCC will merely keep a record of the old and new holders. >From this point of view, I think the policy proposal would not benefit from a statement declaring that fairness is a policy objective, because it isn't. If we pretend it is, then we are not being honest with ourselves. Nick From jcurran at arin.net Fri Aug 2 01:10:10 2013 From: jcurran at arin.net (John Curran) Date: Thu, 1 Aug 2013 23:10:10 +0000 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FADA98.9080407@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FADA98.9080407@fud.no> Message-ID: <5339C484-D678-48BC-98D6-D22ADCBBAA26@corp.arin.net> On Aug 1, 2013, at 6:00 PM, Tore Anderson wrote: > APNIC and ARIN happens to share compatible inter-region transfer > policies. Yet, the number of inter-region transfers going from the ARIN > region to the APNIC region is negligible - at RIPE66 the total amount of > transfers was reported to be 11 (5 per annum, if extrapolating > linearly). ARIN Inter-RIR Transfer statistics are available here: Presently there have been 16 transfers in the period of time of that compatible policy has been in place (approximately 1 year); the blocks transferred range in size from /24 to /15, and are listed on the transfer statistics page. > So the notion that there is some big hidden reserve sitting > around in the ARIN region, ripe for the taking and ready to transform > our current our state of scarcity into one of abundance (if we only pass > an inter-region transfer policy!), seems extremely implausible to me. At > least it has not worked out that way for the APNIC region. I am not asserting any relation between the ARIN/APNIC transfer rate to the desirability for IP transfers to those in the RIPE region, but provide the above information solely for a factual basis of the discussion since the question was raised. FYI, /John John Curran President and CEO ARIN From koalafil at gmail.com Fri Aug 2 10:59:09 2013 From: koalafil at gmail.com (Filiz Yilmaz) Date: Fri, 2 Aug 2013 10:59:09 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FA9A72.3040708@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> Message-ID: On 01 Aug 2013, at 19:27, Tore Anderson wrote: > * Nick Hilliard > >> On 01/08/2013 07:38, Tore Anderson wrote: >>> ?Fair use: Public IPv4 address space must be fairly distributed to the >>> End Users operating networks.? >> >> can you define "fair"? > > Well *that* is the million dollar question, isn't it. In a state of > scarcity, what is "fair"? I do not know it is such a million dollar question. Scarcity (remember the switch from classful delegations to CIDR?) had been a (maybe perceived) issue in the past too. Basically we dealt with it by putting our trust on the RIRs that they would ensure that through policies which bared "justification of the need". In other words, this was always the case, RIRs had been made the judge of this "fairness" through their community built policies. Now the real problem here 2013-03 is suggesting to remove this judgement of fairness role from the RIPE NCC in the RIPE region, by removing the justification of need from the policy, without coming up with a real alternative, while obviously sense of fairness is still important to various members. Filiz > > This is a question that neither I, Malcom, 2013-03, nor ripe-592, > presume to have an answer for. > > However, I understood the crux of Malcom's objection to be that if we > remove this stated objective of "fairness", then we lose our principles > in the process, and it becomes hard to add it back later (presumably > along with a precise definition of "fair"). > > Therefore I was hoping that retaining this sentence (which is there in > today's policy as well) would help move the discussion forward in the > direction of consensus. > > Tore > > > > From tore at fud.no Fri Aug 2 11:56:36 2013 From: tore at fud.no (Tore Anderson) Date: Fri, 02 Aug 2013 11:56:36 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> Message-ID: <51FB8254.2090700@fud.no> * Filiz Yilmaz > Scarcity (remember the switch from classful delegations to CIDR?) had > been a (maybe perceived) issue in the past too. Basically we dealt > with it by putting our trust on the RIRs that they would ensure that > through policies which bared "justification of the need". > > In other words, this was always the case, RIRs had been made the > judge of this "fairness" through their community built policies. > > Now the real problem here 2013-03 is suggesting to remove this > judgement of fairness role from the RIPE NCC in the RIPE region, by > removing the justification of need from the policy, without coming up > with a real alternative, while obviously sense of fairness is still > important to various members. 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. The stated philosophical goal of fairness does go away with the current version of 2013-03 though, as Malcom identified. While I think this makes little *practical* difference as long as the "last /8 policy" remains, I concede that on a philosophical level it could be considered problematic to remove the explicit fairness objective from the policy. This is why I have suggested to roll a new version of the proposal that would leave the fairness goal intact. This way we can maintain both the philosophical objective of fairness and the actual implementation of it, without conflicting with 2013-03's main goals which is to remove the LIRs' bureaucratic overhead and to clean up old and out of date policy text. Would such an amendment make the proposal more appealing or at least acceptable to you? If not, what else is needed? As Gert mentioned earlier, changing the proposal text at this stage of the PDP isn't a trivial thing to do, but if it turns out to be unavoidable, I would at the very least want to avoid having to do it more than once. Best regards, Tore Anderson From richih.mailinglist at gmail.com Fri Aug 2 14:47:36 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 2 Aug 2013 14:47:36 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FB8254.2090700@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FB8254.2090700@fud.no> Message-ID: Could RIPE NCC chime in on if such a small change with no real world implications would allow for reduced, or no, re-evaluations? I agree that implications and intentions should be laid out clearly, but I agree with Gert even more that at this stage, some feedback can be.. annoyingly frustrating.. Richard Sent by mobile; excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From malcolm at linx.net Fri Aug 2 15:26:02 2013 From: malcolm at linx.net (Malcolm Hutty) Date: Fri, 02 Aug 2013 14:26:02 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <20130801072520.GU65295@Space.Net> References: <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <20130801072520.GU65295@Space.Net> Message-ID: <51FBB36A.9090703@linx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/08/2013 08:25, Gert Doering wrote: > While you're free to do so, I'm just so slightly annoyed that > you're doing this *again* - wait until the very last second, and > then state fundamental objections. I understand, and sympathise with your situation, but I'm not intentionally "waiting until the very last second". I think your criticism is a touch unfair. FWIW, on RPKI I had been raising concerns *for years* in WG meetings. It was only "at the very last second" that anybody explained to me that I was being deliberately ignored on the grounds that "if it's not said on the list, I didn't happen". Without such explanation, I had assumed the meetings were authoritative and the mailing list was merely supplementary co-ordination - which is how a many/most organisations work. Once I was informed of the procedure, I followed it immediately. As for this, well I don't read the APWG mailing list normally. I simply don't have time, it's not central to my job, and for most of its work I would have nothing useful to contribute. A LINX member told me about 2013-03 just a couple of weeks ago, and asked me to consider speaking up against it. I did so as soon as I had sanity checked what I intended to say. So I'm sorry the issue didn't come to my attention sooner, but I can't really apologise for doing my own job. But to be honest, there's no need to focus on me. Whereas my input on RPKI did stir up a whole load of new issues, and prompted entirely new objections from others, on this you've already had most of the points I raised mentioned in some form by other people. I just lent my support to their concerns, and collated and marshalled some of them into a unified argument. If you hadn't realised these "fundamental objections" were already lying in the way of achieving rough consensus, because you hadn't realised that those comments touched upon something at the heart of the proposal, well I'm glad I was able to assist. - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlH7s2oACgkQJiK3ugcyKhS4+gCeNmvaq5c0wVRmfxJ6dCxVprhq qY0AmQHhqubKw2GKN5okt+Msb7zz8GpZ =tVwD -----END PGP SIGNATURE----- From nick at inex.ie Fri Aug 2 15:41:01 2013 From: nick at inex.ie (Nick Hilliard) Date: Fri, 02 Aug 2013 14:41:01 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FB8254.2090700@fud.no> Message-ID: <51FBB6ED.4020403@inex.ie> On 02/08/2013 13:47, Richard Hartmann wrote: > Could RIPE NCC chime in on if such a small change with no real world > implications would allow for reduced, or no, re-evaluations? in the year 540ad, St. Benedict wrote in his rule of monastic life "credimus eminam vini per singulos sufficere per diem", which roughly translates as "we believe that a hemina of wine daily is sufficient for each monk". Unfortunately he neglected to write down how much a hemina of wine actually was. The consequence of not defining this term was 1500 years of heated theological debate in the Benedictine order. It was a salutary lesson in being careful to provide a reasonable definition of any lofty goals which might end up as policy. Nick From malcolm at linx.net Fri Aug 2 15:57:22 2013 From: malcolm at linx.net (Malcolm Hutty) Date: Fri, 02 Aug 2013 14:57:22 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FA0260.8050303@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> Message-ID: <51FBBAC2.2030609@linx.net> On 01/08/2013 07:38, Tore Anderson wrote: > * Malcolm Hutty > >> >> However this argument is fallacious. The Conservation policy, even as >> stated, expresses *two separate* policy objectives: 'fair distribution', >> and maximising the lifetime of the public address pool. Depletion means >> that reality has superseded the second objective, but not necessarily >> the first. > > Hi again Malcom, > > Having slept on it, I have a suggestion that hopefully will make us > reach common ground. How about, instead of removing the old Conservation > goal completely, we rewrite it as follows: > > ?Fair use: Public IPv4 address space must be fairly distributed to the > End Users operating networks.? > > This would only remove the second "reality-superseded" objective, but > not the first. It would also continue to provide the philosophical > foundation on which we may build "enforcement" policies in the future, > so we certainly would not be "closing the door" on any such discussion. > > Furthermore, it might even help the NCC in their political/government > interactions, as they can truthfully maintain that their goal with > regards to IPv4 is still to provide for fair distribution and fair use. > > Would such an amendment make the proposal more appealing to you, at > least enough to make reach the "I can live with this" point? (This > question goes for the others who have noted their reservation towards > the proposal too, feel free to chime in!) Tore, Firstly, thank you for being so willing to engage with a view to meeting objections, rather than just defending your proposal. I hope my answer meets you in the same spirit. That amendment would *definitely* make the proposal more appealing to me. To my mind, this moves us from "2013-03 looks bad" to "2013-03 seems broadly OK but needs thought to see whether a little further wordsmithing is needed". Which is, I think you'll agree, major progress. How long do we reasonably have to think about that wording? I realise we're at a late stage, but I would welcome introducing more eyeballs to this problem. In particular, I'm not sure I like limiting fairness to End Users, as you have done. Referring back to your other comments on fairness, to the effect that "fairness" has already been abandoned in the last /8 for NCC->LIR, I don't necessarily agree or think it should be presented like that. On the contrary, we could assert the fairness of the current policy, something like: "In order to ensure fair access to IPv4 address space, and in particular that as many parties have access to IPv4 address space as possible, no LIR shall be assigned more than 1024 addresses from the last /8. For the purpose of efficiency, any LIR [with a legitimate need for IPv4 address space][for their own use] shall be deemed to need 1024 addresses." The text in the first set of square brackets represents that bit of the current policy that an unaltered 2013-03 would remove. The text in the second set set of square brackets represents something that isn't currently policy, but perhaps should be (or perhaps not), and which couldn't be policy unless we retain the principle. I suspect if we adopted the text above without alteration the effect would be to still require a documented need for at least a single IP address. We could further refine it to remove even that - but it has already been mentioned that this is a negligible requirement; how would you feel about leaving it in, given that it's so little? Taken together with the bit in the second set of square brackets, this policy would exclude those that apply simply in order to re-sell, but nobody else. I would think that a simple checkbox "Do you intend to use at least one of these IP addresses on a network you operate?" should satisfy the documentation requirement. Now, you're fully entitled to think that the above policy isn't really all that fair. But it asserts a community view of what is fair, and provides a suitable hook for the community to debate and amend its view by changing the policy in the future. Meanwhile, the NCC will be able to continue to claim that the community aims at fair and efficient distribution, maximising the availability of resources where needed, despite the challenging circumstances - and to carry on saying the same thing if the definition of what is fair changes again. 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 koalafil at gmail.com Fri Aug 2 15:57:00 2013 From: koalafil at gmail.com (Filiz Yilmaz) Date: Fri, 2 Aug 2013 15:57:00 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FB8254.2090700@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FB8254.2090700@fud.no> Message-ID: Hi, On 02 Aug 2013, at 11:56, Tore Anderson wrote: > * Filiz Yilmaz > >> Scarcity (remember the switch from classful delegations to CIDR?) had >> been a (maybe perceived) issue in the past too. Basically we dealt >> with it by putting our trust on the RIRs that they would ensure that >> through policies which bared "justification of the need". >> >> In other words, this was always the case, RIRs had been made the >> judge of this "fairness" through their community built policies. >> >> Now the real problem here 2013-03 is suggesting to remove this >> judgement of fairness role from the RIPE NCC in the RIPE region, by >> removing the justification of need from the policy, without coming up >> with a real alternative, while obviously sense of fairness is still >> important to various members. > > 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. > The stated philosophical goal of fairness does go away with the current > version of 2013-03 though, as Malcom identified. While I think this > makes little *practical* difference as long as the "last /8 policy" > remains, I concede that on a philosophical level it could be considered > problematic to remove the explicit fairness objective from the policy. > > This is why I have suggested to roll a new version of the proposal that > would leave the fairness goal intact. This way we can maintain both the > philosophical objective of fairness and the actual implementation of it, > without conflicting with 2013-03's main goals which is to remove the > LIRs' bureaucratic overhead and to clean up old and out of date policy text. > 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. I am happy if the secondary market brings already allocated space to those who need it. But the space that NCC still holds should goto those in need, not to an organisation to sell it to the one in need. Again, I am fine with the other cleanup your proposal is doing: removal of txt on AWs, further allocations etc.. > As Gert mentioned > earlier, changing the proposal text at this stage of the PDP isn't a > trivial thing to do, I should have missed this but as far as i know a review phase can be repeated or extended with an updated text. Happy to see the new text. And for those who find some of the feedback frustrating - as the word keeps coming up and being used here and there... Well, welcome to a bottom-up process. Ideas and perspectives vary, we have the process in place to hear all those ideas so nobody here is to be hushed or discouraged to speak. From my point of view, there had been views here that I do not fully agree but I encourage them too, because an open discussion for these issues is the right tool and this is what PDP is for. Filiz > but if it turns out to be unavoidable, I would at > the very least want to avoid having to do it more than once. > > Best regards, > Tore Anderson From tore at fud.no Sat Aug 3 12:47:40 2013 From: tore at fud.no (Tore Anderson) Date: Sat, 03 Aug 2013 12:47:40 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FBBAC2.2030609@linx.net> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FBBAC2.2030609@linx.net> Message-ID: <51FCDFCC.6070104@fud.no> * Malcolm Hutty > Firstly, thank you for being so willing to engage with a view to > meeting objections, rather than just defending your proposal. I hope > my answer meets you in the same spirit. Yep, and thank you for being constructive as well! > That amendment would *definitely* make the proposal more appealing to > me. To my mind, this moves us from "2013-03 looks bad" to "2013-03 > seems broadly OK but needs thought to see whether a little further > wordsmithing is needed". Which is, I think you'll agree, major > progress. Absolutely! > How long do we reasonably have to think about that wording? I realise > we're at a late stage, but I would welcome introducing more eyeballs > to this problem. Since we're still discussing, the review period will be extended with another couple of weeks, so there is some time. Hopefully we've have a text we're happy with by then, which will then as I understand it be sent to the NCC which will have to re-do the Impact Analysis. The first IA took 11 weeks to complete, so I *really* hope that we only have to ask them to re-do it once. (As you probably can imagine my first preference would be not to do it at all, as I consider myself a pragmatist and I think these changes have minimal *practical* impact, but oh well...) > In particular, I'm not sure I like limiting fairness to End Users, as > you have done. Actually, those words aren't mine, they are there in the current policy document (ripe-592) as well. This was 100% intentional, as I would strongly prefer for the proposal to not change previously established consensus on any topic that is not "core" to the proposal itself, or to introduce any new lofty principles/goals/ambitions. Nick's cautionary "a hemina of wine" example is highly relevant here. If we try to define *new* principles, we'll probably need further wordsmithing, which may in turn lead to bikeshedding and thus grinding the progress of the proposal to a standstill. Another risk is that even though we find agreement on a new text, the NCC may say in its IA that they interpret this to mean X, while our intention was Y - and we'll have to start over again. So while I have no desire whatsoever to stifle any discussion on any new goals and principles and any tools or mechanisms that would enforce those, I would strongly prefer if this discussion could be done in another policy proposal independent of 2013-03. With that in mind - can you live with simply retaining the "fairness goal" as stated in our current policy document and nothing more? I'm not necessarily asking for your *support* of the proposal here (although that would of course be very welcome too!); "I no longer have any objections" or "I abstain" is sufficient. (BTW: I don't think it is a problem limiting fairness to the End Users. The whole point of the Internet Registries is to get the resources into the hands of the End Users. Internet Registries aren't using the resources themselves, so they have no need for "fairness". Of course, often a single organisation will be both an Internet Registry and an End User, but in that case it will be covered by the fairness goal anyway.) > Referring back to your other comments on fairness, to the effect > that "fairness" has already been abandoned in the last /8 for > NCC->LIR, I don't necessarily agree or think it should be presented > like that. That's fortunately just my personal and pragmatic opinion, and not something I have any intention of putting into the policy. :-) > I suspect if we adopted the text above without alteration the effect > would be to still require a documented need for at least a single IP > address. We could further refine it to remove even that - but it has > already been mentioned that this is a negligible requirement; how > would you feel about leaving it in, given that it's so little? Taken > together with the bit in the second set of square brackets, this > policy would exclude those that apply simply in order to re-sell, > but nobody else. I would think that a simple checkbox "Do you intend > to use at least one of these IP addresses on a network you operate?" > should satisfy the documentation requirement. (Filiz: I understood that this is essentially the same issue you described in your last post to the list. Therefore I'm CC-ing you in here rather than replying to your message directly, hope that's OK.) I have no strong feelings against this, no, the amount of red tape is minimal and in any case something an LIR will have to deal with at most *once*. The main reason I have resisted this is that in practical terms it is nearly meaningless as a barrier against those who would abuse it, and asking the NCC to re-do the IA just to get it in there would IMHO be a waste of time and effort. However, if we need to change the proposal and re-do the IA anyway, might as well do this one too. So here's my suggested text. In the proposed section 5.1 (http://www.ripe.net/ripe/docs/other-documents/draft-v2-ipv4-address-allocation-and-assignment-policies-for-the-ripe-ncc-service-region-new-policy-text/#allocations-made-by-the-ripe-ncc-to-lirs) we add a new point: ?4. In order to qualify for receiving the allocation, the LIR must state an intent to use it for making assignments to one or more End Users.? I think this describes the current status quo pretty well, and should result in a check-box like the one you described in the request form (something I'll try to confirm with Andrea *before* the whole updated proposal is sent back to the NCC). Would this be sufficient to remove your concerns? Best regards, Tore Anderson From mueller at syr.edu Sat Aug 3 15:11:21 2013 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 3 Aug 2013 13:11:21 +0000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51F91087.5040104@linx.net> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> Message-ID: <855077AC3D7A7147A7570370CA01ECD248E6E8@SUEX10-mbx-10.ad.syr.edu> Malcolm: I find your arguments against 2013-3 to be unusually off target. Let's begin with this: -----Original Message----- > I am not convinced by the the principle argument being made in favour of abolishing the concept of "need" The policy change does not "abolish the concept of need" it only removes it for the remaining scraps of the last /8 in IPv4, and for transfers of that space. My understanding is that some kind of demonstrated need would still be in place for IPv6. > Finally, as noted by the RIPE NCC, this takes away a key message the RIRs have used to justify their independence > from government. That may not be sufficient reason to oppose the policy if it is otherwise necessary, > but it does seem to me to indicate caution and counsel against acting precipitously. This argument I simply don't understand. The presence or absence of needs assessment has absolutely nothing to do with the status of RIRs as independent membership nonprofit who administer a shared private resource space. Waving the bloody flag of the ITU really doesn't cut it here. As a private organization, RIRs have to be very careful about competition policy considerations. In this respect, needs assessment, which is completely nontransparent and could in some respects be considered more easily manipulated than a market, puts RIRs in much more danger of external scrutiny than an open and uncontrolled market for IPv4 transfers. When you say there are governments out there who want to take over number allocation, you are correct. But as someone who is as familiar with that environment as you are, I can tell you with complete confidence that these governments don't care a whit whether RIRs eliminate needs assessment or not: they want power in the hands of states, and neither passing nor not passing this policy will have any impact on the course of that debate. Indeed, your view could backfire. It would not be difficult to make a case that continued controls on allocations keep the price of number blocks artificially low for buyers, and by the same token suppress the market for sellers by eliminating many potential buyers from the market. Since most of the dues-paying members of RIRs are ISPs/buyers, it would not be too hard to paint a picture of this situation as a buyers' cartel, which would be actionable under antitrust law. If you think needs assessments are protecting RIRs from external interest and possible intervention, you are 180 degrees off the mark. >The Conservation policy, even as stated, expresses *two separate* > policy objectives: 'fair distribution', and maximising the lifetime of the public address pool. > Depletion means that reality has superseded the second objective, but not necessarily the first. > So my first question to Tore is: "Why should 'fair distribution' of addresses between users no longer be > considered an overarching objective of IPv4 address management?" The simple answer to your question is that needs assessment are not "fairness assessments." If there are 50 ISPs contending for the same number block, needs assessment only tells you whether they cross some threshold (largely theoretical and unenforced) of operational justification. It may be the case that 2 or 3 of those ISPs have far greater merit in their claim than the other 47 or 48. Current practice doesn't care about that. Your argument falls on this simple fact alone. > 2. "Fair distribution" establishes a basic goal for IPv4 address management policy. > Other policies exist to pursue that goal. Your second statement here is an unjustified logical leap. There is nothing in the current policy that either defines what "fairness" is or that makes it the overriding concern, more important than efficiency and conservation. One could argue that when there is scarcity it is more fair for people willing to pay the highest price to get the resource. I know that that logic doesn't always work, and doesn't always seem fair, but it does work for about 90% of the economy as a whole. My view is that when we are dealing with the final scraps of the v4 space and thousands of claimants can all claim that they "need" numbers, it is indeed the most fair option to give it to the person who bids the highest. Not that this is a wonderful option, only that it is better than the alternatives, including arbitrary, nontransparent, bureaucratically demanding needs assessments. > limiting the maximum allocation size directly relies upon the notion of fairness > (we're only giving you X, even though you want Y, so that the next guy can have some at all). Yes, we still have the one /22 restriction. Indeed, the last /8 policy giving one small block to a customer is based on a fairness principle. That policy is not fundamentally changed by the elimination of needs assessment; the most important aspect of the policy is the limitation of one block per customer. Absence of needs assessment will not have much impact on that basic operation of that policy. And so you have completely refuted your own argument that there is no "fairness" left in the system if 2013-3 passes. > With the introduction of a transfer mechanism, it is possible that market pressures > may prove adequate to ensure efficient and fair allocation of IPv4 addresses; in this > transition period, the consequences of run-out are uncertain. RIPE has chosen not > to act pre-emptively, to give market mechanisms a chance to succeed. However if > market mechanisms prove inadequate to safeguard the fair and efficient use of IPv4 > address space, RIPE stands ready to introduce new measures as necessary." So, you are suggesting that we pass 2013-3 with this language added? The idea is not an entirely bad one, but as currently drafted the statement is unclear. It should read something more like this: > With the introduction of a transfer mechanism and the elimination of needs assessments > for IPv4, we are assuming that market pressures > will prove adequate to ensure efficient and fair allocation of IPv4 addresses. > However if market mechanisms prove inadequate to safeguard the fair and > efficient use of IPv4 address space, RIPE stands ready to introduce new measures as necessary." Such a disclaimer may not be necessary, because RIPE can always change its policies. But if it gains more support to put it that way, go ahead! --MM From mueller at syr.edu Sat Aug 3 15:14:28 2013 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 3 Aug 2013 13:14:28 +0000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> Message-ID: <855077AC3D7A7147A7570370CA01ECD248E701@SUEX10-mbx-10.ad.syr.edu> >From my perspective it does add "red tape" How do you determine whether v4 numbers are "fairly distributed to end users operating networks" unless you do a needs assessment? I like Malcolm's idea better: Add a disclaimer at the end that says if it doesn't work or causes unforeseen problems, we will change it. From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Jan Ingvoldstad Sent: Thursday, August 1, 2013 3:48 AM To: RIPE Address Policy WG Subject: Re: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) On Thu, Aug 1, 2013 at 8:38 AM, Tore Anderson > wrote: Having slept on it, I have a suggestion that hopefully will make us reach common ground. How about, instead of removing the old Conservation goal completely, we rewrite it as follows: That looks sensible enough to me, it doesn't appear to add red tape. :) -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Sat Aug 3 15:17:42 2013 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 3 Aug 2013 13:17:42 +0000 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> Message-ID: <855077AC3D7A7147A7570370CA01ECD248E711@SUEX10-mbx-10.ad.syr.edu> > I liked the proposal initialy - but I do not buy the initial argument that since we have run > out, conservation is not important. Since we have run out of unused addresses conservation > is in many ways more important - unless we belive v6 can take over. I don't understand why people confuse the elimination of needs assessment with the elimination of conservation. Market prices are the most systemically powerful and efficient conservation mechanism ever devised. Needs assessments are a very primitive conservation mechanism: 10,000 people can all prove that they "need" as resource but that isn't helpful when only 10 of them can have it. Let's not continue this confusion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Sat Aug 3 17:58:32 2013 From: tore at fud.no (Tore Anderson) Date: Sat, 03 Aug 2013 17:58:32 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD248E6E8@SUEX10-mbx-10.ad.syr.edu> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <855077AC3D7A7147A7570370CA01ECD248E6E8@SUEX10-mbx-10.ad.syr.edu> Message-ID: <51FD28A8.4070202@fud.no> * Milton L Mueller > [...] But if it gains more support to put it that way, go ahead! Exactly. I'm sure we all could discuss these topics for decades without finding full agreement. Fortunately we don't have to, all we have to do is to converge on a text that has consensus as acceptable (or better). It's to that end I proposed the two amendments, which I hope will bring Malcom and Filiz on board with the proposal: 1) retain the philosophical "fairness" goal from our current policy, and 2) make LIRs that want to obtain their "last /8" /22 pledge to use it for their End Users (a continuation of current practice). I understand that you're mostly interested in the second-hand transfer market, so I'd like to point out that 2013-03's impact on the transfer policy will not change due to these two amendments. Even though you may find them unnecessary, I hope you'll also find them acceptable, and not something that would prevent you from continuing to support the overall proposal. Best regards, Tore Anderson From mueller at syr.edu Sat Aug 3 20:23:57 2013 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 3 Aug 2013 18:23:57 +0000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FD28A8.4070202@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <855077AC3D7A7147A7570370CA01ECD248E6E8@SUEX10-mbx-10.ad.syr.edu> <51FD28A8.4070202@fud.no> Message-ID: <855077AC3D7A7147A7570370CA01ECD248FE44@SUEX10-mbx-10.ad.syr.edu> Yes, it would be acceptable to me if acceptable to Malcolm and Filiz -----Original Message----- From: Tore Anderson [mailto:tore at fud.no] Sent: Saturday, August 3, 2013 11:59 AM To: Milton L Mueller Cc: Malcolm Hutty; Sander Steffann; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) * Milton L Mueller > [...] But if it gains more support to put it that way, go ahead! Exactly. I'm sure we all could discuss these topics for decades without finding full agreement. Fortunately we don't have to, all we have to do is to converge on a text that has consensus as acceptable (or better). It's to that end I proposed the two amendments, which I hope will bring Malcom and Filiz on board with the proposal: 1) retain the philosophical "fairness" goal from our current policy, and 2) make LIRs that want to obtain their "last /8" /22 pledge to use it for their End Users (a continuation of current practice). I understand that you're mostly interested in the second-hand transfer market, so I'd like to point out that 2013-03's impact on the transfer policy will not change due to these two amendments. Even though you may find them unnecessary, I hope you'll also find them acceptable, and not something that would prevent you from continuing to support the overall proposal. Best regards, Tore Anderson From nick at inex.ie Sat Aug 3 21:53:23 2013 From: nick at inex.ie (Nick Hilliard) Date: Sat, 03 Aug 2013 20:53:23 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FCDFCC.6070104@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FBBAC2.2030609@linx.net> <51FCDFCC.6070104@fud.no> Message-ID: <51FD5FB3.60802@inex.ie> On 03/08/2013 11:47, Tore Anderson wrote: > So here's my suggested text. In the proposed section 5.1 > (http://www.ripe.net/ripe/docs/other-documents/draft-v2-ipv4-address-allocation-and-assignment-policies-for-the-ripe-ncc-service-region-new-policy-text/#allocations-made-by-the-ripe-ncc-to-lirs) > we add a new point: > > ?4. In order to qualify for receiving the allocation, the LIR must state > an intent to use it for making assignments to one or more End Users.? I may be wrong, but this seems to be quite a substantial shift away from v1 and v2. The previous two versions completely removed any requirement for stated intent, but this change would partially bring it back. This isn't a complaint, btw - just an observation. As an aside, I don't think it will make too much practical difference whether this statement is included or not, at least from the point of view of speculation. The language is vague enough that any respectable lawyer could easily side-step it. If the intent is to ensure that the LIR transferee makes the assignments, then the language could be tightened up. Nick From tore at fud.no Sun Aug 4 10:58:05 2013 From: tore at fud.no (Tore Anderson) Date: Sun, 04 Aug 2013 10:58:05 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FD5FB3.60802@inex.ie> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FBBAC2.2030609@linx.net> <51FCDFCC.6070104@fud.no> <51FD5FB3.60802@inex.ie> Message-ID: <51FE179D.1070308@fud.no> * Nick Hilliard >> ?4. In order to qualify for receiving the allocation, the LIR must >> state an intent to use it for making assignments to one or more >> End Users.? > > I may be wrong, but this seems to be quite a substantial shift away > from v1 and v2. The previous two versions completely removed any > requirement for stated intent, but this change would partially bring > it back. This isn't a complaint, btw - just an observation. If you "zoom in" on the last /8 policy, I suppose you could say that. On the other hand, changing the last /8 policy isn't an objective of 2013-03. v1 and v2 only did so via a layer of indirection; the "need" requirement isn't part of the last /8 policy, but the "pre-depletion" policy, which the last /8 policy in turn partially "imports". So when 2013-03 cleaned away the "pre-depletion" policy, this had some ramifications on the last /8 policy too. (When writing the proposal I didn't see these ramifications as problematic because, from a practical point of view, the remaining "need requirement" is just a formality that anyone could satisfy.) The main objectives of 2013-03 is to reduce LIR/EU bureaucracy and clean away obsoleted policy, and the above statement doesn't run counter to this. So when looking at the proposal as a whole, the change wouldn't be a "significant shift", IMHO. > As an aside, I don't think it will make too much practical difference > whether this statement is included or not, at least from the point of > view of speculation. The language is vague enough that any > respectable lawyer could easily side-step it. Fully agreed, it would be trivial for an LIR to side-step the requirement if it runs counter to their ulterior motives for obtaining the /22. But then again, the same is true for today's policy. As I understood Filiz and Malcom, it would be more about "sending a message" than anything else. Not only to the applicant LIR, but also something the NCC could use to counter hostile arguments from the ITU/governments. Both of which is fine by me. > If the intent is to ensure that the LIR transferee makes the > assignments, then the language could be tightened up. Definitively not the intention. Anyone wanting to transform the NCC into an enforcing "IPv4 Police" will have to make their own proposal to that effect. Tore From nigel at titley.com Sun Aug 4 15:27:52 2013 From: nigel at titley.com (Nigel Titley) Date: Sun, 04 Aug 2013 14:27:52 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD248E6E8@SUEX10-mbx-10.ad.syr.edu> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <855077AC3D7A7147A7570370CA01ECD248E6E8@SUEX10-mbx-10.ad.syr.edu> Message-ID: <51FE56D8.3010708@titley.com> On 03/08/2013 14:11, Milton L Mueller wrote: > This argument I simply don't understand. The presence or absence of > needs assessment has absolutely nothing to do with the status of RIRs > as independent membership nonprofit who administer a shared private > resource space. Waving the bloody flag of the ITU really doesn't cut > it here. With due respect, our lawyers (specifically expert in EU competition law) disagree with you. I'd prefer to give *some* credence to their opinions, which is why the impact analysis specifically passed on their comments. It is, of course, up to the RIPE community to take this opinion into account, or not, as they wish. Nigel From farmer at umn.edu Sun Aug 4 15:41:01 2013 From: farmer at umn.edu (David Farmer) Date: Sun, 04 Aug 2013 08:41:01 -0500 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FA9A72.3040708@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> Message-ID: <51FE59ED.4000004@umn.edu> On 8/1/13 12:27 , Tore Anderson wrote: > * Nick Hilliard > >> On 01/08/2013 07:38, Tore Anderson wrote: >>> ?Fair use: Public IPv4 address space must be fairly distributed to the >>> End Users operating networks.? >> >> can you define "fair"? I believe the primary definition of fairness the RIR communities have been using is, "only those that have *verified operational need* get Internet number resources". > Well *that* is the million dollar question, isn't it. In a state of > scarcity, what is "fair"? Furthermore, I believe that now that everyone's operational need can no longer be meet, a state of scarcity, that fairness is doubly important. How does verified operational need provide fairness in a state of scarcity? If someone without verified operational need were to receive Internet number resources, presumably through a transfer, and you have verifiable operational need that can no longer be meet; it would add insult to injury that someone without that verifiable operational need receives Internet number resources when you can't. Therefore, verifying operational need for transfers, still provides some minimal amount of fairness to those that are not going to receive Internet number resources. > This is a question that neither I, Malcom, 2013-03, nor ripe-592, > presume to have an answer for. This is where you create a problem for me. If you propose to remove the current mechanism of fairness, verified operational need, then it is incumbent on you to propose a replacement. You are saying that "verified operational need" doesn't work in a state of a state of scarcity, I disagree, it may not be perfect, but it will do something. And, that it is no longer necessary because the free pool is gone, again I disagree. But, the crux of my issue isn't that you are removing verified operational need, it is that you seem to claim it isn't your problem to find a replacement for the fairness it provides, even if it isn't perfect fairness. > However, I understood the crux of Malcom's objection to be that if we > remove this stated objective of "fairness", then we lose our principles > in the process, and it becomes hard to add it back later (presumably > along with a precise definition of "fair"). > > Therefore I was hoping that retaining this sentence (which is there in > today's policy as well) would help move the discussion forward in the > direction of consensus. While this is a start, just saying fairness is necessary, is a hollow jester, without verified operational need or some other replacement mechanism to provides the fairness you are saying is necessary. > Tore -- ================================================ 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 Sun Aug 4 16:35:25 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Sun, 4 Aug 2013 16:35:25 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FE59ED.4000004@umn.edu> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> Message-ID: On Sun, Aug 4, 2013 at 3:41 PM, David Farmer wrote: > On 8/1/13 12:27 , Tore Anderson wrote: > >> * Nick Hilliard >> >> On 01/08/2013 07:38, Tore Anderson wrote: >>> >>>> ?Fair use: Public IPv4 address space must be fairly distributed to the >>>> End Users operating networks.? >>>> >>> >>> can you define "fair"? >>> >> > I believe the primary definition of fairness the RIR communities have been > using is, "only those that have *verified operational need* get Internet > number resources". Uhm, if that has been the definition of fairness, then it certainly has NOT been enforced or used in the past few years. Perhaps never. It is, as you state later on, one of those hollow "jesters". Furthermore, I believe that now that everyone's operational need can no > longer be meet, a state of scarcity, that fairness is doubly important. > How does verified operational need provide fairness in a state of > scarcity? If someone without verified operational need were to receive > Internet number resources, presumably through a transfer, and you have > verifiable operational need that can no longer be meet; it would add insult > to injury that someone without that verifiable operational need receives > Internet number resources when you can't. This is how Internet number resources have been handled for years; organizations without verified operational needs have received Internet number resources, some in huge quantities. One could easily argue that this is one of the root problems with former Internet number resource handling. Fortunately, IPv6 came to the rescue. > Therefore, verifying operational need for transfers, still provides some > minimal amount of fairness to those that are not going to receive Internet > number resources. If the verification is going to be at the level it used to be, that fairness is so minimal that you can't poke a stick at it. It is, at best, an illusion. While this is a start, just saying fairness is necessary, is a hollow > jester, without verified operational need or some other replacement > mechanism to provides the fairness you are saying is necessary. > If you want to introduce verification of the operational need, I suggest you write your own proposal to the RIPE community, so that we can discuss and handle the proposed changes accordingly. But I cannot, for the life of me, understand what this has to do with 2013-03, sorry. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Sun Aug 4 16:48:28 2013 From: tore at fud.no (Tore Anderson) Date: Sun, 04 Aug 2013 16:48:28 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FE59ED.4000004@umn.edu> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> Message-ID: <51FE69BC.1080503@fud.no> * David Farmer > I believe the primary definition of fairness the RIR communities have > been using is, "only those that have *verified operational need* get > Internet number resources". Do you have a link or reference? (Tried Google, no hits.) > Furthermore, I believe that now that everyone's operational need can no > longer be meet, a state of scarcity, that fairness is doubly important. > How does verified operational need provide fairness in a state of > scarcity? If someone without verified operational need were to receive > Internet number resources, presumably through a transfer, and you have > verifiable operational need that can no longer be meet; it would add > insult to injury that someone without that verifiable operational need > receives Internet number resources when you can't. Therefore, verifying > operational need for transfers, still provides some minimal amount of > fairness to those that are not going to receive Internet number resources. Let me get this straight, are you saying here that our current goal of fairness in our current state of scarcity is to protect the *feelings* of the LIRs who return home from the second-hand market empty-handed? (Currently 96-97% of them.) In a similar vein, and somewhat tongue in cheek: If you're trying to buy an apartment, but get outbid by someone, do you get upset unless you can see some proof that guy did buy it plans on moving in there? Or do you assume that's probably the case and move on? Tore From bmanning at vacation.karoshi.com Sun Aug 4 16:59:12 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 4 Aug 2013 14:59:12 +0000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> Message-ID: <20130804145912.GA19854@vacation.karoshi.com.> On Sun, Aug 04, 2013 at 04:35:25PM +0200, Jan Ingvoldstad wrote: > On Sun, Aug 4, 2013 at 3:41 PM, David Farmer wrote: > > > On 8/1/13 12:27 , Tore Anderson wrote: > > > >> * Nick Hilliard > >> > >> On 01/08/2013 07:38, Tore Anderson wrote: > >>> > >>>> +Fair use: Public IPv4 address space must be fairly distributed to the > >>>> End Users operating networks.; > >>>> > >>> can you define "fair"? > >>> > > I believe the primary definition of fairness the RIR communities have been > > using is, "only those that have *verified operational need* get Internet > > number resources". > > This is how Internet number resources have been handled for years; > organizations without verified operational needs have received Internet > number resources, some in huge quantities. > > One could easily argue that this is one of the root problems with former > Internet number resource handling. > > Fortunately, IPv6 came to the rescue. Pragmatically, there is zero chance of verification of operational need for anything larger than a /96 in IPv6 space.... So the rules for v6 allocation actually are fairly close to the original v4 allocation policies. The concept of verified operational need arose in times of scarcity, when there was -no- other option. Those times have past and its not clear to me why there remains this slavish devotion to having an unlicensed regulator second guess the viability of a given operational model. As usual, YMMV. /bill From farmer at umn.edu Sun Aug 4 18:48:13 2013 From: farmer at umn.edu (David Farmer) Date: Sun, 04 Aug 2013 11:48:13 -0500 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> Message-ID: <51FE85CD.2020804@umn.edu> On 8/4/13 09:35 , Jan Ingvoldstad wrote: > On Sun, Aug 4, 2013 at 3:41 PM, David Farmer > wrote: > > On 8/1/13 12:27 , Tore Anderson wrote: > > * Nick Hilliard > > On 01/08/2013 07:38, Tore Anderson wrote: > > ?Fair use: Public IPv4 address space must be fairly > distributed to the > End Users operating networks.? > > can you define "fair"? > > I believe the primary definition of fairness the RIR communities > have been using is, "only those that have *verified operational > need* get Internet number resources". > > Uhm, if that has been the definition of fairness, then it certainly has > NOT been enforced or used in the past few years. Perhaps never. There has allows been a need component, prior to IPv4 each network "needed" a network identifier, equivalent to a /8 today. With IPv4 pre-CIDR, this changed to three class of network identifiers; classes A, B, and C, /8s, /16s, and /24s today. You had to meet additional criteria to get a class A or B, otherwise you got a C. This is still based on need, but a little more granularity. By today's standards were most of those class As or Bs needed, maybe not, but there were needed by the standards of the day. RFCs 1366, 1466, 2050, document the criteria used and its evolution, until the RIR policy process take over. > It is, as you state later on, one of those hollow "jesters". They may have also been hollow gestures, but not a hollow as saying that fairness is necessary without and kind of mechanism providing it. (Sorry, I can't spell for shirt :) , see http://tinyurl.com/l3cop8b ) > Furthermore, I believe that now that everyone's operational need can > no longer be meet, a state of scarcity, that fairness is doubly > important. How does verified operational need provide fairness in a > state of scarcity? If someone without verified operational need > were to receive Internet number resources, presumably through a > transfer, and you have verifiable operational need that can no > longer be meet; it would add insult to injury that someone without > that verifiable operational need receives Internet number resources > when you can't. > > This is how Internet number resources have been handled for years; > organizations without verified operational needs have received Internet > number resources, some in huge quantities. If you mean address were handed out without need by today's standards, sure, but hind sight is allows 20-20. But, if you mean addresses were handed out without need by the standards of the day then I have to disagree. > One could easily argue that this is one of the root problems with former > Internet number resource handling. > > Fortunately, IPv6 came to the rescue. I sure hope IPv6 comes to the rescue, but I'm not sure we have been rescued just yet. I'm only able to get ~40% of my traffic via IPv6, this is moving the the right direction but, we're not rescued yet. > Therefore, verifying operational need for transfers, still > provides some minimal amount of fairness to those that are not going > to receive Internet number resources. > > If the verification is going to be at the level it used to be, that > fairness is so minimal that you can't poke a stick at it. It is, at > best, an illusion. > > While this is a start, just saying fairness is necessary, is a > hollow jester, without verified operational need or some other > replacement mechanism to provides the fairness you are saying is > necessary. > > If you want to introduce verification of the operational need, I suggest > you write your own proposal to the RIPE community, so that we can > discuss and handle the proposed changes accordingly. I'm not introducing anything new, I'm objecting to the removal of something that has always been there, as are others. > But I cannot, for the life of me, understand what this has to do with > 2013-03, sorry. It is in the very title of the proposal "No Need - Post-Depletion Reality Adjustment". > -- > Jan -- ================================================ 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 Sun Aug 4 19:15:50 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Sun, 4 Aug 2013 19:15:50 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FE85CD.2020804@umn.edu> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE85CD.2020804@umn.edu> Message-ID: On Sun, Aug 4, 2013 at 6:48 PM, David Farmer wrote: > I'm not introducing anything new, I'm objecting to the removal of > something that has always been there, as are others. As I understand it, there has "always" been a requirement for need. I don't disagree that this is nothing new. However, you used the phrase "verified operational need", which is something different. I am a n00b in the RIPE community, so I have certainly not read everything there is, but from what I have seen, read and understand, this verification thing is new. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Sun Aug 4 19:52:13 2013 From: farmer at umn.edu (David Farmer) Date: Sun, 04 Aug 2013 12:52:13 -0500 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE85CD.2020804@umn.edu> Message-ID: <51FE94CD.3060206@umn.edu> On 8/4/13 12:15 , Jan Ingvoldstad wrote: > On Sun, Aug 4, 2013 at 6:48 PM, David Farmer > wrote: > > I'm not introducing anything new, I'm objecting to the removal of > something that has always been there, as are others. > > > As I understand it, there has "always" been a requirement for need. I > don't disagree that this is nothing new. > > However, you used the phrase "verified operational need", which is > something different. > > I am a n00b in the RIPE community, so I have certainly not read > everything there is, but from what I have seen, read and understand, > this verification thing is new. If you wanted more than the minimum it was always necessary to provide a story that passed a smell test. Also, if you wanted another batch of numbers you always had to explain what did with the old ones you were given, usually providing some data, much of the "bureaucracy" 2013-3 wants to eliminate. Verified: 1. Make sure or demonstrate that (something) is true, accurate, or justified. 2. Swear to or support (a statement) by affidavit. Justified: 1. Having, done for, or marked by a good or legitimate reason. 2. Declared or made righteous in the sight of God. So, please tell me how "verified operational need" is that different. If you would prefer justified or validated operational need. OK, what ever. -- ================================================ 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 Sun Aug 4 20:01:00 2013 From: farmer at umn.edu (David Farmer) Date: Sun, 04 Aug 2013 13:01:00 -0500 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FE69BC.1080503@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE69BC.1080503@fud.no> Message-ID: <51FE96DC.8000304@umn.edu> On 8/4/13 09:48 , Tore Anderson wrote: > * David Farmer > >> I believe the primary definition of fairness the RIR communities have >> been using is, "only those that have *verified operational need* get >> Internet number resources". > > Do you have a link or reference? (Tried Google, no hits.) Try goal #1 in section #1 of RFC 2050. See https://tools.ietf.org/html/rfc2050#section-1 And in slightly different words, try goal #1 in section #2 of RFC 2050-bis. See http://tools.ietf.org/html/draft-housley-rfc2050bis-02#section-2 >> Furthermore, I believe that now that everyone's operational need can no >> longer be meet, a state of scarcity, that fairness is doubly important. >> How does verified operational need provide fairness in a state of >> scarcity? If someone without verified operational need were to receive >> Internet number resources, presumably through a transfer, and you have >> verifiable operational need that can no longer be meet; it would add >> insult to injury that someone without that verifiable operational need >> receives Internet number resources when you can't. Therefore, verifying >> operational need for transfers, still provides some minimal amount of >> fairness to those that are not going to receive Internet number resources. > > Let me get this straight, are you saying here that our current goal of > fairness in our current state of scarcity is to protect the *feelings* > of the LIRs who return home from the second-hand market empty-handed? > (Currently 96-97% of them.) You always have to look at fairness from the perspective of those who don't get what they want. Fairness isn't usually an issue raised by those that get what they want. And, as I said I'm not saying operational need is perfect, in the current situation, but it is something and you are proposing to take even that little bit away without saying what replaces it. Personally, I'm not fundamentally opposed to operational need going away, especially the current overly bureaucratic way it is determined, if you can find something that replaces it that provides some sense of fairness that you seem to agree is necessary. -- ================================================ 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 Sun Aug 4 20:21:17 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Sun, 4 Aug 2013 20:21:17 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FE94CD.3060206@umn.edu> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE85CD.2020804@umn.edu> <51FE94CD.3060206@umn.edu> Message-ID: On Sun, Aug 4, 2013 at 7:52 PM, David Farmer wrote: > > If you wanted more than the minimum it was always necessary to provide a > story that passed a smell test. Yes, and that story was, typically, "I'm a new service provider and need an IP address for my service", or "I want to provide addresses for others by becoming a LIR". It may have been written in more words, but it's not like you had to show that you had contracts with others or whatnot. You said you had a need, and that was sufficient. > Also, if you wanted another batch of numbers you always had to explain > what did with the old ones you were given, usually providing some data, > much of the "bureaucracy" 2013-3 wants to eliminate. > Yep, you had to say "I've used them all up, I need more to expand my operations." > > Verified: 1. Make sure or demonstrate that (something) is true, accurate, > or justified. 2. Swear to or support (a statement) by affidavit. > > Justified: 1. Having, done for, or marked by a good or legitimate reason. > 2. Declared or made righteous in the sight of God. > > So, please tell me how "verified operational need" is that different. If > you would prefer justified or validated operational need. OK, what ever. You have already demonstrated that it is that different, by having to bang my head with cherry-picked dictionary definitions to explain how I and others should understand what "verified" might mean, and by suggesting different adjectives. Others have already pointed out why innocuous-seeming changes like these can have an impact in how documents are read, also off-list. If what you really want is to stick with the old phrase and old meaning, then I think it's better to say that you don't want to change the old phrase and meaning, instead of introducting a third option. When we get too many different suggestions for minute, superficial changes to the proposal to discuss, we quickly lose track of what the proposed change is about. And that's bad. But maybe that's just me. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe at opteamax.de Sun Aug 4 20:52:17 2013 From: ripe at opteamax.de (Opteamax GmbH - RIPE-Team) Date: Sun, 04 Aug 2013 20:52:17 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE85CD.2020804@umn.edu> <51FE94CD.3060206@umn.edu> Message-ID: <3f6cd5c0-913c-4e79-a07f-daade08ed35e@email.android.com> Jan Ingvoldstad schrieb: >On Sun, Aug 4, 2013 at 7:52 PM, David Farmer wrote: > >> >> If you wanted more than the minimum it was always necessary to >provide a >> story that passed a smell test. > > >Yes, and that story was, typically, "I'm a new service provider and >need an >IP address for my service", or "I want to provide addresses for others >by >becoming a LIR". It may have been written in more words, but it's not >like >you had to show that you had contracts with others or whatnot. > Actually this is not true, I had to send copies of contacts and approvals that customers are returning space to other LIRs ... BR Jens From tore at fud.no Sun Aug 4 21:11:50 2013 From: tore at fud.no (Tore Anderson) Date: Sun, 04 Aug 2013 21:11:50 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FE96DC.8000304@umn.edu> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE69BC.1080503@fud.no> <51FE96DC.8000304@umn.edu> Message-ID: <51FEA776.40506@fud.no> * David Farmer > On 8/4/13 09:48 , Tore Anderson wrote: >> * David Farmer >> >>> I believe the primary definition of fairness the RIR communities >>> have been using is, "only those that have *verified operational >>> need* get Internet number resources". >> >> Do you have a link or reference? (Tried Google, no hits.) > > Try goal #1 in section #1 of RFC 2050. See > https://tools.ietf.org/html/rfc2050#section-1 Written in a time of abundance long ago, where the fairness of the RIRs' "all you can eat buffet" worked as there was enough for everyone. That's not the world we live in today, and besides the document is about to be superseded by the 2050-bis: > And in slightly different words, try goal #1 in section #2 of RFC > 2050-bis. See > http://tools.ietf.org/html/draft-housley-rfc2050bis-02#section-2 ...which happens to contain exactly 0 occurrences of the string "fair". >> Let me get this straight, are you saying here that our current goal >> of fairness in our current state of scarcity is to protect the >> *feelings* of the LIRs who return home from the second-hand market >> empty-handed? (Currently 96-97% of them.) > > You always have to look at fairness from the perspective of those > who don't get what they want. Fairness isn't usually an issue raised > by those that get what they want. Yes, I'm sure that the LIRs that didn't get the resources they wanted (and "needed") feel it's a great consolation to know that their competitors with deeper pockets also "needed" the resources in order to absorb the customer growth they now are unable to take on themselves. Or how starving folks around the globe surely must feel that their situation is "fair", as Tore and David managed to finish all the food on their dinner plates today. (We "needed" it, after all.) Sorry. I just don't at all buy the argument that the unprivileged are treated "fair" just because the privileged happened to "need". Everyone "needs", yet not everyone gets. The way I see it, the scarcity situation is going to result in unfairness no matter what and there's nothing our current policy nor 2013-03 can do about it. > Personally, I'm not fundamentally opposed to operational need going > away, especially the current overly bureaucratic way it is > determined, if you can find something that replaces it that provides > some sense of fairness that you seem to agree is necessary. Personally I don't think it is at all necessary to keep the philosophical "fairness" goal in the policy, as we have no working mechanism in the policy that actually ensure any form of fair distribution in this time of scarcity. That's my pragmatic view. However there were a couple of other WG participants who felt that it should be left in there for high-level philosophical and political reasons, and to ensure the door is kept open for a potential future discussion of "what is fair nowadays and how do we go about enforcing it exactly"? I have no problem with that per se, hence my offer to leave it in there. Tore From farmer at umn.edu Sun Aug 4 21:38:46 2013 From: farmer at umn.edu (David Farmer) Date: Sun, 04 Aug 2013 14:38:46 -0500 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FEA776.40506@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE69BC.1080503@fud.no> <51FE96DC.8000304@umn.edu> <51FEA776.40506@fud.no> Message-ID: <51FEADC6.4090007@umn.edu> On 8/4/13 14:11 , Tore Anderson wrote: > * David Farmer >] >> And in slightly different words, try goal #1 in section #2 of RFC >> 2050-bis. See >> http://tools.ietf.org/html/draft-housley-rfc2050bis-02#section-2 > > ...which happens to contain exactly 0 occurrences of the string "fair". No the string "fair" isn't there any longer, but the string "operational need" didn't go any where, and you asked about "operational need" not "fairness"; 1) Allocation Pool Management: Due to the fixed lengths of IP addresses and AS numbers, the pools from which these resources are allocated are finite. As such, allocations must be made in accordance with the *operational needs* of those running the networks that make use of these number resources and by taking into consideration pool limitations at the time of allocation. Furthermore, from now on I will just use "operational need", since people are getting stuck on the issue of verified/justified/valid as something that is supposedly new. -- ================================================ 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 tvest at eyeconomics.com Sun Aug 4 21:35:25 2013 From: tvest at eyeconomics.com (Tom Vest) Date: Sun, 4 Aug 2013 15:35:25 -0400 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <20130804145912.GA19854@vacation.karoshi.com.> References: <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <20130804145912.GA19854@vacation.karoshi.com.> Message-ID: <7CFEF368-0DEE-4832-B625-D02EB5CAD855@eyeconomics.com> On Aug 4, 2013, at 10:59 AM, bmanning at vacation.karoshi.com wrote: > On Sun, Aug 04, 2013 at 04:35:25PM +0200, Jan Ingvoldstad wrote: >> On Sun, Aug 4, 2013 at 3:41 PM, David Farmer wrote: >> >>> On 8/1/13 12:27 , Tore Anderson wrote: >>> >>>> * Nick Hilliard >>>> >>>> On 01/08/2013 07:38, Tore Anderson wrote: >>>>> >>>>>> +Fair use: Public IPv4 address space must be fairly distributed to the >>>>>> End Users operating networks.; >>>>>> >>>>> can you define "fair"? >>>>> >>> I believe the primary definition of fairness the RIR communities have been >>> using is, "only those that have *verified operational need* get Internet >>> number resources". >> >> This is how Internet number resources have been handled for years; >> organizations without verified operational needs have received Internet >> number resources, some in huge quantities. >> >> One could easily argue that this is one of the root problems with former >> Internet number resource handling. >> >> Fortunately, IPv6 came to the rescue. > > Pragmatically, there is zero chance of verification of operational need > for anything larger than a /96 in IPv6 space.... So the rules for v6 > allocation actually are fairly close to the original v4 allocation policies. > > The concept of verified operational need arose in times of scarcity, when > there was -no- other option. Those times have past and its not clear to me > why there remains this slavish devotion to having an unlicensed regulator > second guess the viability of a given operational model. Hi Bill, Out of curiosity, about how many Class As would you say had been assigned before that scarcity came to be widely recognized, and the concept of "verified operational need" was first articulated? At that time, was promptly doling out all of the remaining Class As on a first first-come-first served basis *not* considered an option? If not, why not? If the prospect of creating an operating environment in which critical number resources were collectively, indefinitely controlled by a relatively small minority of the total number of operators who could such resources to similarly good use (and whose commercial/existential viability would forevermore be contingent on the terms of their access to someone else's number resources) was not considered a viable option back then, what makes it any more palatable now? Granted, both the numerator (resource-haves) and the denominator (have-nots) numbers have grown several orders of magnitude over the ensuing years, but how exactly does that matter if the resulting fraction remains broadly unchanged? Curiously, TV > As usual, YMMV. > > /bill > From koalafil at gmail.com Sun Aug 4 21:46:12 2013 From: koalafil at gmail.com (Fil) Date: Sun, 4 Aug 2013 21:46:12 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE85CD.2020804@umn.edu> Message-ID: <19492A2A-D61B-4388-BAEC-0AE073B90223@gmail.com> Dear Jan, Sent from my iPad On 4 Aug 2013, at 19:15, Jan Ingvoldstad wrote: > On Sun, Aug 4, 2013 at 6:48 PM, David Farmer wrote: >> I'm not introducing anything new, I'm objecting to the removal of something that has always been there, as are others. > > As I understand it, there has "always" been a requirement for need. I don't disagree that this is nothing new. > > However, you used the phrase "verified operational need", which is something different. > > I am a n00b in the RIPE community, so I have certainly not read everything there is, but from what I have seen, read and understand, this verification thing is new. It is not really new. I've quoted from the current policy document before and some others too: "Conservation: Public IPv4 address space must be fairly distributed to the End Users operating networks..." "Operating networks" is not there for no reason and normally an LIR's network is considered as an end network in the context of having a piece of their overall allocation too. Also note that this was written at a time when it was all thought that only those people into operational networks (as an LIR helping end users or for their own need..) would become LIRs and ask for space from the NCC. Otherwise if you did not have a network or if you did not have a customer with a network, why would you want to get those IPs in the first place... Accordingly, what you may be calling as a fuss currently is a deep understanding for a lot of people even if it was not articulated with certain words in the policy text because the policy of the time was written with a certain understanding who the readers of the policy were. Now there is a proposal to change it, and the proposal takes big chunks of that text out and does not bring alternatives, all these subtle, distributed within the text details are to be lost too, while they were there since the beginning. Filiz > Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Sun Aug 4 21:56:51 2013 From: tore at fud.no (Tore Anderson) Date: Sun, 04 Aug 2013 21:56:51 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FEADC6.4090007@umn.edu> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE69BC.1080503@fud.no> <51FE96DC.8000304@umn.edu> <51FEA776.40506@fud.no> <51FEADC6.4090007@umn.edu> Message-ID: <51FEB203.8070502@fud.no> * David Farmer > you asked about "operational need" not "fairness"; [citation needed] I seem to remember my question being: ?In a state of scarcity, what is "fair"?? While discussing the amendment: ?Fair use: Public IPv4 address space must be fairly distributed to the End Users operating networks.? And finally asking you to provide a reference to the ?primary definition of fairness the RIR communities have been using?. So the discussion was never about "fairness"? Hmm. English is only a secondary language of mine, so I guess I must have misunderstood you. Apologies. > 1) Allocation Pool Management: Due to the fixed lengths of IP > addresses and AS numbers, the pools from which these resources > are allocated are finite. As such, allocations must be made in > accordance with the *operational needs* of those running the > networks that make use of these number resources and by taking > into consideration pool limitations at the time of allocation. So depending on how you look at it, either: A (if ignoring the "last /8 pool"): The RIPE NCC's allocation pool is empty. No point in talking about the Management of an Allocation Pool that does not exist. B (if including the "last /8 pool"): I've proposed to retain the current requirement that LIRs must use the last /22 allocation for making assignments to its End Users. Either way, case closed? Tore From farmer at umn.edu Sun Aug 4 21:58:47 2013 From: farmer at umn.edu (David Farmer) Date: Sun, 04 Aug 2013 14:58:47 -0500 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51fe6c98.87883c0a.534e.5ccfSMTPIN_ADDED_BROKEN@mx.google.com> References: <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51fe6c98.87883c0a.534e.5ccfSMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: <51FEB277.2000900@umn.edu> On 8/4/13 09:59 , bmanning at vacation.karoshi.com wrote: > Pragmatically, there is zero chance of verification of operational need > for anything larger than a /96 in IPv6 space.... So the rules for v6 > allocation actually are fairly close to the original v4 allocation policies. I disagree, /64 is easily justified by how the protocols are defined, so is a /56 and probably a /48 for a business customer. You may want to argue if the protocols should have been defined to use a whole /64 for a single Ethernet. But that is not an RIR policy question, that is an IETF protocol question. The RIR's have to work with the protocols as the IETF defines them. I'm not saying you are necessary wrong, just that this isn't the forum. > The concept of verified operational need arose in times of scarcity, when > there was -no- other option. Again I disagree, if you wanted a Class A or B you needed to justify the request, it was relatively easy by comparison for sure. And if you wanted more you had to explain what you did with the ones you had. But justification didn't just come in with conservation or scarcity, it always been there, what has changed is the standards for the justification. I'm not stuck on the current standards for justification, but eliminating both "operational need" and any concept of "fairness" to replace it is an issue for me. -- ================================================ 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 Sun Aug 4 22:51:42 2013 From: farmer at umn.edu (David Farmer) Date: Sun, 04 Aug 2013 15:51:42 -0500 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FEB203.8070502@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE69BC.1080503@fud.no> <51FE96DC.8000304@umn.edu> <51FEA776.40506@fud.no> <51FEADC6.4090007@umn.edu> <51FEB203.8070502@fud.no> Message-ID: <51FEBEDE.8000809@umn.edu> On 8/4/13 14:56 , Tore Anderson wrote: > * David Farmer > >> you asked about "operational need" not "fairness"; > > [citation needed] Gladly, --- On 8/4/13 13:01 , David Farmer wrote:> On 8/4/13 09:48 , Tore Anderson wrote: >> * David Farmer >> >>> I believe the primary definition of fairness the RIR communities have >>> been using is, "only those that have *verified operational need* get >>> Internet number resources". >> >> Do you have a link or reference? (Tried Google, no hits.) > > Try goal #1 in section #1 of RFC 2050. > See https://tools.ietf.org/html/rfc2050#section-1 > > And in slightly different words, try goal #1 in section #2 of RFC 2050-bis. > See http://tools.ietf.org/html/draft-housley-rfc2050bis-02#section-2 --- > I seem to remember my question being: > > ?In a state of scarcity, what is "fair"?? > > While discussing the amendment: > > ?Fair use: Public IPv4 address space must be fairly distributed to the > End Users operating networks.? > > And finally asking you to provide a reference to the ?primary definition > of fairness the RIR communities have been using?. I said, "I believe the primary definition of fairness the RIR communities have been using is, "only those that have *verified operational need* get Internet number resources" > So the discussion was never about "fairness"? Hmm. English is only a > secondary language of mine, so I guess I must have misunderstood you. > Apologies. By asking me for a quotation, I interpreted that as to not only being about "fairness", but also about my tie of "fairness" to "operational need". The concept of "operational need" still remains in RFC 2050-bis even though the "fairness" was dropped. But I think RFC 2050-bis and "operational need" remains relevant. >> 1) Allocation Pool Management: Due to the fixed lengths of IP >> addresses and AS numbers, the pools from which these resources >> are allocated are finite. As such, allocations must be made in >> accordance with the *operational needs* of those running the >> networks that make use of these number resources and by taking >> into consideration pool limitations at the time of allocation. > > So depending on how you look at it, either: > > A (if ignoring the "last /8 pool"): The RIPE NCC's allocation pool is > empty. No point in talking about the Management of an Allocation Pool > that does not exist. > > B (if including the "last /8 pool"): I've proposed to retain the current > requirement that LIRs must use the last /22 allocation for making > assignments to its End Users. > > Either way, case closed? I believe you are incorrectly equating "Allocation Pool" with "Free Pool", there is nothing that says the "Allocation Pool" doesn't include resources that are available for "Re-Allocation". Now, I'll grant you that there is nothing that says it includes resources that are available for "Re-Allocation" either. So, I would suggest that is an open question for the community to decide, and you can't necessarily say case closed. Furthermore, the statements in 2050-bis apply are intended to apply to the whole Internet Registry System, IANA, the RIRs, and LIRs, so even if you consider RIPE's Allocation Pool empty, the LIR's Allocation Pool isn't empty and operational need should still apply to the LIR making the Re-allocation of resources. -- ================================================ 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 Mon Aug 5 00:17:53 2013 From: tore at fud.no (Tore Anderson) Date: Mon, 05 Aug 2013 00:17:53 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FEBEDE.8000809@umn.edu> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE69BC.1080503@fud.no> <51FE96DC.8000304@umn.edu> <51FEA776.40506@fud.no> <51FEADC6.4090007@umn.edu> <51FEB203.8070502@fud.no> <51FEBEDE.8000809@umn.edu> Message-ID: <51FED311.3090007@fud.no> * David Farmer > By asking me for a quotation, I interpreted that as to not only being > about "fairness", but also about my tie of "fairness" to "operational > need". The concept of "operational need" still remains in RFC 2050-bis > even though the "fairness" was dropped. But I think RFC 2050-bis and > "operational need" remains relevant. I wanted to know where you'd seen this "primary definition of fairness". I don't dispute that 2050-bis mentions "operational need", but I do dispute that it says it is the "definition of fairness". If you didn't mean to make that claim I suppose we were talking past each other. > I believe you are incorrectly equating "Allocation Pool" with "Free > Pool", there is nothing that says the "Allocation Pool" doesn't include > resources that are available for "Re-Allocation". If already allocated resources are to be considered as part of the allocation pool, then the pool would essentially be infinite and limitless as you can re-allocate the same addresses over and over and over and over again. So IMHO this is quite a stretch. > Furthermore, the statements in 2050-bis apply are intended to apply to > the whole Internet Registry System, IANA, the RIRs, and LIRs, so even if > you consider RIPE's Allocation Pool empty, the LIR's Allocation Pool > isn't empty and operational need should still apply to the LIR making > the Re-allocation of resources. In the RIPE region LIRs don't allocate, they assign. (Sub-allocations being the extremely rarely used exception.) Tore From farmer at umn.edu Mon Aug 5 01:04:52 2013 From: farmer at umn.edu (David Farmer) Date: Sun, 04 Aug 2013 18:04:52 -0500 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FED311.3090007@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE69BC.1080503@fud.no> <51FE96DC.8000304@umn.edu> <51FEA776.40506@fud.no> <51FEADC6.4090007@umn.edu> <51FEB203.8070502@fud.no> <51FEBEDE.8000809@umn.edu> <51FED311.3090007@fud.no> Message-ID: <51FEDE14.50700@umn.edu> On 8/4/13 17:17 , Tore Anderson wrote: > * David Farmer >> Furthermore, the statements in 2050-bis apply are intended to apply to >> the whole Internet Registry System, IANA, the RIRs, and LIRs, so even if >> you consider RIPE's Allocation Pool empty, the LIR's Allocation Pool >> isn't empty and operational need should still apply to the LIR making >> the Re-allocation of resources. > > In the RIPE region LIRs don't allocate, they assign. > > (Sub-allocations being the extremely rarely used exception.) RIPE-582, section 5.5 specifically refers to Transfers to another LIR as a Re-Allocation. -- ================================================ 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 drc at virtualized.org Mon Aug 5 02:09:27 2013 From: drc at virtualized.org (David Conrad) Date: Sun, 4 Aug 2013 17:09:27 -0700 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FED311.3090007@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE69BC.1080503@fud.no> <51FE96DC.8000304@umn.edu> <51FEA776.40506@fud.no> <51FEADC6.4090007@umn.edu> <51FEB203.8070502@fud.no> <51FEBEDE.8000809@umn.edu> <51FED311.3090007@fud.no> Message-ID: <5FBC4E3C-6A16-47BA-AB74-6CC27403383E@virtualized.org> Hi, On Aug 4, 2013, at 3:17 PM, Tore Anderson wrote: > I don't dispute that 2050-bis mentions "operational need", but I do > dispute that it says it is the "definition of fairness". Just to be clear: "operational need" has absolutely nothing to do with "fairness". The former is, at least in theory, objectively verifiable by, e.g., measuring requester utilization efficiency, customer growth patterns, etc. (ignoring this has never been done and the IANA/RIR system is not capable of doing this -- the entire system relies on trust and passing the giggle test). The latter is a purely subjective value judgement. The intent of goal #1 in 2050bis is to encourage people to look at the free pool availability when considering allocation policies. In cases where the allocation pool is tightly constrained, I believe it safe to say it was the consensus opinion of the authors that "the operational needs of those running the networks that make use of the number resources" should be a key consideration. In my personal view, this should true even if it is considered "unfair" by some. >> I believe you are incorrectly equating "Allocation Pool" with "Free >> Pool", there is nothing that says the "Allocation Pool" doesn't include >> resources that are available for "Re-Allocation". > > If already allocated resources are to be considered as part of the > allocation pool, then the pool would essentially be infinite and > limitless as you can re-allocate the same addresses over and over and > over and over again. So IMHO this is quite a stretch. An "allocation pool" is the source from which resources are taken. Once a resource is allocated, it is removed from the allocation pool. As mentioned in 2050bis, "the pools from which these resources are allocated are finite." It is, of course, true that the allocation pool can be replenished, e.g., when someone returns a block of addresses to some part of the Internet registry system, however that is a relatively rare occurrence. AFAICT, the question 2013-03 revolves around is whether or not the RIPE community considers the free ("allocation") pool exhausted. If it is exhausted, questions of "fairness" or "operational need" are irrelevant in allocation pool management -- the allocation pool size is zero so there is nothing to consider. >> Furthermore, the statements in 2050-bis apply are intended to apply to >> the whole Internet Registry System, IANA, the RIRs, and LIRs, so even if >> you consider RIPE's Allocation Pool empty, the LIR's Allocation Pool >> isn't empty and operational need should still apply to the LIR making >> the Re-allocation of resources. The statements in 2050bis are goals and recommendations of a small number of people interested in address allocation policy, not laws or axioms. One of my reasons for helping with 2050bis was to get away from the "quotations from holy text" approach of address policy making that has infected the community as a result of 2050 and instead, encourage people to evolve policies through "an open, transparent, and broad multi-stakeholder manner". I would personally be distressed to see the Old Testament replaced by the New Testament. Regards, -drc From tore at fud.no Mon Aug 5 07:56:16 2013 From: tore at fud.no (Tore Anderson) Date: Mon, 05 Aug 2013 07:56:16 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <5FBC4E3C-6A16-47BA-AB74-6CC27403383E@virtualized.org> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE69BC.1080503@fud.no> <51FE96DC.8000304@umn.edu> <51FEA776.40506@fud.no> <51FEADC6.4090007@umn.edu> <51FEB203.8070502@fud.no> <51FEBEDE.8000809@umn.edu> <51FED311.3090007@fud.no> <5FBC4E3C-6A16-47BA-AB74-6CC27403383E@virtualized.org> Message-ID: <51FF3E80.6000308@fud.no> David, Thank you for sharing this very informative message. * David Conrad > Just to be clear: "operational need" has absolutely nothing to do > with "fairness". > > The former is, at least in theory, objectively verifiable by, e.g., > measuring requester utilization efficiency, customer growth patterns, > etc. (ignoring this has never been done and the IANA/RIR system is > not capable of doing this -- the entire system relies on trust and > passing the giggle test). [...] > An "allocation pool" is the source from which resources are taken. > Once a resource is allocated, it is removed from the allocation pool. > As mentioned in 2050bis, "the pools from which these resources are > allocated are finite." > > It is, of course, true that the allocation pool can be replenished, > e.g., when someone returns a block of addresses to some part of the > Internet registry system, however that is a relatively rare > occurrence. > > AFAICT, the question 2013-03 revolves around is whether or not the > RIPE community considers the free ("allocation") pool exhausted. If > it is exhausted, questions of "fairness" or "operational need" are > irrelevant in allocation pool management -- the allocation pool size > is zero so there is nothing to consider. The old "all you can eat; unlimited second servings" allocation pool is without question exhausted and sized zero. This condition is permanent, as any returns/reclaims are absorbed by the "last /8" allocation pool. The last /8 pool has a very blunt definition of "operational need"; it equates it to 1024 addresses. The "giggle test" applied to this pool is essentially ?do you need anything at all? yes/no?. The current version of 2013-03 proposes to remove this giggle test (but not the one-size-fits-all definition of "operational need"). A few folks pointed out that it is desirable to retain the "giggle test" for philosophical and political reasons, and I've offered to amend the proposal accordingly. Based on your explanations above, I'd say that this amendment would make 2013-03 "compliant" with 2050-bis' Allocation Pool Management goal (assuming the same could be said for our current policy as well). Tore From gert at space.net Mon Aug 5 09:38:31 2013 From: gert at space.net (Gert Doering) Date: Mon, 5 Aug 2013 09:38:31 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: Message-ID: <20130805073831.GA58827@Space.Net> Dear AP WG, as you might have noticed... On Tue, Jul 02, 2013 at 03:28:05PM +0200, Emilio Madaio wrote: > The second version of the draft document for the policy proposal > 2013-03 has been published, along with an impact analysis carried out > by the RIPE NCC. [..] > We encourage you to read the draft document text and send any comments > to before 30 July 2013. ... the discussion phase for 2013-03 formally ended about a week ago. In the light of the ongoing discussion, the WG chairs have decided to extend the review phase by two weeks, so we're not cutting short any input from the community. Emilio will send the formal announcement on this later today. After this extention, from where we stand in the discussion today, it's likely that we'll see a new proposal text, new impact analysis, and new review phase - that is, if those that objected to the current proposal can agree with Tore's proposed modifications. In the light of the strong community support otherwise (at least 11 persons voicing support without any restrictions for the current text), I would certainly welcome if those that are sceptical could agree to some middle ground... Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From emadaio at ripe.net Mon Aug 5 10:32:44 2013 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 05 Aug 2013 10:32:44 +0200 Subject: [address-policy-wg] 2013-03 Review Period extended until 14 August (No Need - Post-Depletion Reality Adjustment and Cleanup) Message-ID: Dear Colleagues, The Review Period for the proposal 2013-03, "No Need - Post-Depletion Reality Adjustment and Cleanup", has been extended until 14 August. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2013-03 We encourage you to review this policy proposal and send your comments to . Regards, Emilio Madaio Policy Development Officer RIPE NCC From mueller at syr.edu Mon Aug 5 12:41:02 2013 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 5 Aug 2013 10:41:02 +0000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FE56D8.3010708@titley.com> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <855077AC3D7A7147A7570370CA01ECD248E6E8@SUEX10-mbx-10.ad.syr.edu> <51FE56D8.3010708@titley.com> Message-ID: <855077AC3D7A7147A7570370CA01ECD249642B@SUEX10-mbx-10.ad.syr.edu> Nigel, Thanks, interesting. I had not read the full analysis before With due respect, I think the legal analysis in the impact statement is confused or at least unconvincing. The analysis says: "From an EU competition point of view, it is important that IPv4 allocations and transfers are conducted in a way that cannot be seen as discriminatory or exclusionary." This I agree with. And a no-need policy, which eliminates the RIPE-NCC's judgment from the picture, also eliminates the possibility that RIPE-NCC's judgment could be construed as discriminatory or exclusionary. But the statement goes on to say: "The fact that the allocation of IP addresses by the RIPE NCC occurred on the basis of the proof of objective need, rather than purely economic considerations, has protected the RIPE NCC from competition law claims." First, I would ask for evidence. Has anyone ever threatened NCC with competition law claims before and had their case thrown out based on th existence of needs assessment? I strongly suspect not, but if so, let us know. It seems obvious to me that RIPE-NCC is more likely to be challenged legally if it is directly responsible for making the decision as to who gets and does not get addresses. A court might uphold their methods of assessing need, but this does not tell us anything about whether they would be more or less subject to such challenges if needs assessment goes away. Second, the statement says "Removing the needs-based requirement would create an exposure to competition law claims based on discriminatory treatment or refusal to supply." This is just wrong. If RIPE is not involved in a transfer of number blocks, it simply cannot be accused of discriminatory treatment. It offers no "treatment" whatsoever. Indeed, the legal analysis suggests the correct conclusion: "Competition law claims would be mainly addressed to LIRs that could be seen as coordinating in stockpiling and applying discriminatory practices." In other words, a more market-based allocation regime might involve competition policy claims against individual buyers of IP numbers who are stockpiling addresses for anti-competitive purposes. But RIPE would not be liable. The statement adds, "Such claims may also be addressed to the RIPE NCC, if only in order to make more publicity for the claim." In other words, these claims would have no legal merit and might be filed only for publicity purposes. But if publicity is the object, then the existence of needs assessment will not protect RIPE either - a litigant could sue RIPE-NCC to gain publicity either way. QED -----Original Message----- From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Nigel Titley Sent: Sunday, August 4, 2013 9:28 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 Clean up) On 03/08/2013 14:11, Milton L Mueller wrote: > This argument I simply don't understand. The presence or absence of > needs assessment has absolutely nothing to do with the status of RIRs > as independent membership nonprofit who administer a shared private > resource space. Waving the bloody flag of the ITU really doesn't cut > it here. With due respect, our lawyers (specifically expert in EU competition law) disagree with you. I'd prefer to give *some* credence to their opinions, which is why the impact analysis specifically passed on their comments. It is, of course, up to the RIPE community to take this opinion into account, or not, as they wish. Nigel From nigel at titley.com Mon Aug 5 12:59:15 2013 From: nigel at titley.com (Nigel Titley) Date: Mon, 05 Aug 2013 11:59:15 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD249642B@SUEX10-mbx-10.ad.syr.edu> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <855077AC3D7A7147A7570370CA01ECD248E6E8@SUEX10-mbx-10.ad.syr.edu> <51FE56D8.3010708@titley.com> <855077AC3D7A7147A7570370CA01ECD249642B@SUEX10-mbx-10.ad.syr.edu> Message-ID: <51FF8583.3050208@titley.com> On 05/08/2013 11:41, Milton L Mueller wrote: > Nigel, > Thanks, interesting. I had not read the full analysis before With due respect, I think the legal analysis in the impact statement is confused or at least unconvincing. > > The analysis says: > "From an EU competition point of view, it is important that IPv4 allocations and transfers are conducted in a way that cannot be seen as discriminatory or exclusionary." > > This I agree with. And a no-need policy, which eliminates the RIPE-NCC's judgment from the picture, also eliminates the possibility that RIPE-NCC's judgment could be construed as discriminatory or exclusionary. > But the statement goes on to say: > > "The fact that the allocation of IP addresses by the RIPE NCC occurred on the basis of the proof of objective need, rather than purely economic considerations, has protected the RIPE NCC from competition law claims." > > First, I would ask for evidence. Has anyone ever threatened NCC with competition law claims before and had their case thrown out based on th existence of needs assessment? I strongly suspect not, but if so, let us know. It seems obvious to me that RIPE-NCC is more likely to be challenged legally if it is directly responsible for making the decision as to who gets and does not get addresses. A court might uphold their methods of assessing need, but this does not tell us anything about whether they would be more or less subject to such challenges if needs assessment goes away. I'm always wary of statements about legal matters that start "it seems obvious to me". Whilst it might seem, to the layman, that the law is an ass, we unfortunately have to deal with it in its own strange twilight zone, with its own rules. As a layman, I agree with you. Unfortunately in the twilight zone we have to rely on the guides that we have engaged. > Second, the statement says "Removing the needs-based requirement would create an exposure to competition law claims based on discriminatory treatment or refusal to supply." This is just wrong. If RIPE is not involved in a transfer of number blocks, it simply cannot be accused of discriminatory treatment. It offers no "treatment" whatsoever. > > Indeed, the legal analysis suggests the correct conclusion: > > "Competition law claims would be mainly addressed to LIRs that could be seen as coordinating in stockpiling and applying discriminatory practices." > > In other words, a more market-based allocation regime might involve competition policy claims against individual buyers of IP numbers who are stockpiling addresses for anti-competitive purposes. But RIPE would not be liable. > > The statement adds, "Such claims may also be addressed to the RIPE NCC, if only in order to make more publicity for the claim." In other words, these claims would have no legal merit and might be filed only for publicity purposes. But if publicity is the object, then the existence of needs assessment will not protect RIPE either - a litigant could sue RIPE-NCC to gain publicity either way. Our twilight zone guides think not, and I personally wouldn't presume to have an opinion one way or the other. All the impact analysis says is "if this proposal goes through then you *may* wish to think about putting aside a small additional pot to pay your lawyers". The RIPE NCC will almost certainly be doing so in the next budget, if this proposal goes through. It probably won't be a huge amount, but we'll do it because we run the RIPE NCC in an extremely conservative manner. > QED > Remember that the Romans met their final fate at the hands of the barbarian hordes. Nigel From tore at fud.no Mon Aug 5 13:13:14 2013 From: tore at fud.no (Tore Anderson) Date: Mon, 05 Aug 2013 13:13:14 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD249642B@SUEX10-mbx-10.ad.syr.edu> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <855077AC3D7A7147A7570370CA01ECD248E6E8@SUEX10-mbx-10.ad.syr.edu> <51FE56D8.3010708@titley.com> <855077AC3D7A7147A7570370CA01ECD249642B@SUEX10-mbx-10.ad.syr.edu> Message-ID: <51FF88CA.3030707@fud.no> * Milton L Mueller > "Competition law claims would be mainly addressed to LIRs that could > be seen as coordinating in stockpiling and applying discriminatory > practices." That's a feature, not a bug. :-) I'd much rather have LIRs that would engage in stockpiling and applying discriminatory practices in breach of competition laws *not* be able to defend themselves with ?don't look at us, the RIPE NCC said it was OK!? Tore From mueller at syr.edu Mon Aug 5 13:24:13 2013 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 5 Aug 2013 11:24:13 +0000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FF88CA.3030707@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <855077AC3D7A7147A7570370CA01ECD248E6E8@SUEX10-mbx-10.ad.syr.edu> <51FE56D8.3010708@titley.com> <855077AC3D7A7147A7570370CA01ECD249642B@SUEX10-mbx-10.ad.syr.edu> <51FF88CA.3030707@fud.no> Message-ID: <855077AC3D7A7147A7570370CA01ECD249646B@SUEX10-mbx-10.ad.syr.edu> >> "Competition law claims would be mainly addressed to LIRs that could >> be seen as coordinating in stockpiling and applying discriminatory >> practices." > > That's a feature, not a bug. :-) I'd much rather have LIRs that would engage in stockpiling and applying > discriminatory practices in breach of competition laws *not* be able to defend themselves with look at us, the RIPE NCC said it was OK!> MM: Exactly my point! The existence of a needs assessment, which gives RIPE-NCC's imprimatur to the outcome, is much more likely to entangle the NCC in these things than its absence. The staff's legal assessment needs to be re-thought. Addressing also Nigel Titley's argument, it's unfortunate that he has seized on the existence of a single phrase ("it seems obvious to me"), a phrase not at all essential to the point being made, to avoid the real discussion. Take that phrase out and the same refutations apply to your lawyers' statement. They need to explain a) whether there is any REAL litigation in which the existence of needs assessment has actually shielded RIPE-NCC from a claim; b) how the use of needs assessments make any less likely claims made purely for "publicity" purposes; c) why RIPE-NCC's involvement in allocations of a highly scarce and increasingly contested resource via needs assessment wouldn't make it _more_ likely to be entangled in litigation From jim at rfc1035.com Mon Aug 5 14:00:36 2013 From: jim at rfc1035.com (Jim Reid) Date: Mon, 5 Aug 2013 13:00:36 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD249646B@SUEX10-mbx-10.ad.syr.edu> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <855077AC3D7A7147A7570370CA01ECD248E6E8@SUEX10-mbx-10.ad.syr.edu> <51FE56D8.3010708@titley.com> <855077AC3D7A7147A7570370CA01ECD249642B@SUEX10-mbx-10.ad.syr.edu> <51FF88CA.3030707@fud.no> <855077AC3D7A7147A7570370CA01ECD249646B@SUEX10-mbx-10.ad.syr.edu> Message-ID: <8FABBCA7-59EE-4F4C-86B3-4DC88F244D13@rfc1035.com> On 5 Aug 2013, at 12:24, Milton L Mueller wrote: > They [NCC's lawyers? - JR] need to explain > a) whether there is any REAL litigation in which the existence of needs assessment has actually shielded RIPE-NCC from a claim; > b) how the use of needs assessments make any less likely claims made purely for "publicity" purposes; > c) why RIPE-NCC's involvement in allocations of a highly scarce and increasingly contested resource via needs assessment wouldn't make it _more_ likely to be entangled in litigation Not quite. None of us here are practising lawyers AFAIK, far less lawyers who understand Dutch/EU law on this particular topic. It would be wise to defer to the experts -- presumably the NCC engaged a law firm who know this field -- instead of continuing our amateur speculations. If further clarifications and explanations are needed, I suggest we start at the beginning by asking the NCC to publish the brief given to its legal advisers and their response. This way we will know if the right questions were asked at the outset. Everyone can then choose to hire their own lawyers to advise on the correctness and completeness of the reply. Or do some research of their own in a law library, assuming people do that sort of thing these days. Or we could just take the advice of the NCC's lawyers on trust: that's what they get paid to do after all. I have no idea if the things on your wish list above are necessary or sufficient to address the issues (excuse the pun). For this non-lawyer, they do seem to be putting the cart before the horse. From nigel at titley.com Mon Aug 5 14:08:53 2013 From: nigel at titley.com (Nigel Titley) Date: Mon, 05 Aug 2013 13:08:53 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD249646B@SUEX10-mbx-10.ad.syr.edu> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <855077AC3D7A7147A7570370CA01ECD248E6E8@SUEX10-mbx-10.ad.syr.edu> <51FE56D8.3010708@titley.com> <855077AC3D7A7147A7570370CA01ECD249642B@SUEX10-mbx-10.ad.syr.edu> <51FF88CA.3030707@fud.no> <855077AC3D7A7147A7570370CA01ECD249646B@SUEX10-mbx-10.ad.syr.edu> Message-ID: <51FF95D5.9000601@titley.com> On 05/08/2013 12:24, Milton L Mueller wrote: > > MM: Exactly my point! The existence of a needs assessment, which gives RIPE-NCC's imprimatur to the outcome, is much more likely to entangle the NCC in these things than its absence. The staff's legal assessment needs to be re-thought. Just for the record and to be pedantic, the legal assessment was made by external legal consultants. We do not have an expert in EU competition law on the staff. > > Addressing also Nigel Titley's argument, it's unfortunate that he has seized on the existence of a single phrase ("it seems obvious to me"), a phrase not at all essential to the point being made, to avoid the real discussion. Take that phrase out and the same refutations apply to your lawyers' statement. I'm sorry, I'd forgotten that you seem to have little or no sense of humour. My apologies, I'll try and remember in future. > > They need to explain > a) whether there is any REAL litigation in which the existence of needs assessment has actually shielded RIPE-NCC from a claim; No, we have never seen any REAL litigation. This is a feature and not a bug. It would be perfectly possible to argue that the existence of needs assessment has meant that we have seen no litigation at all. We prefer it this way. > b) how the use of needs assessments make any less likely claims made purely for "publicity" purposes; This wasn't what the legal advice said. It said that needs assessment would likely result in fewer claims, full stop. And in the event of fewer claims there is a lower probability that the the RIPE NCC would be involved "for publicity purposes" or indeed for any purposes whatsoever. > > c) why RIPE-NCC's involvement in allocations of a highly scarce and increasingly contested resource via needs assessment wouldn't make it _more_ likely to be entangled in litigation > because we have a different legal environment in the EU to the US. Frivolous claims tend to be dismissed much earlier in the process and the existence of a well documented and well established process which has worked well in the past tends to act as a deterrent. Milton, I'm happy to listen to you argue as an economist, but you are neither a lawyer nor an expert in EU legal practice. Neither am I and I would expect those listening to me to take whatever I say on legal issues with a shovelful of salt. I've stepped way outside my area of expertise in this matter, which is why the RIPE NCC pays lawyers to give legal advice and not me. My initial posting in this thread was merely to bring the details of the advice to your attention. You now have actually read the impact assessment and I'm happy that you are now better informed. I'll now step back again. Nigel Chairman, RIPE NCC board From bmanning at vacation.karoshi.com Mon Aug 5 15:00:37 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 5 Aug 2013 13:00:37 +0000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FE94CD.3060206@umn.edu> References: <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE85CD.2020804@umn.edu> <51FE94CD.3060206@umn.edu> Message-ID: <20130805130037.GA1181@vacation.karoshi.com.> On Sun, Aug 04, 2013 at 12:52:13PM -0500, David Farmer wrote: > On 8/4/13 12:15 , Jan Ingvoldstad wrote: > >On Sun, Aug 4, 2013 at 6:48 PM, David Farmer >> wrote: > > > > I'm not introducing anything new, I'm objecting to the removal of > > something that has always been there, as are others. > > > > > >As I understand it, there has "always" been a requirement for need. I > >don't disagree that this is nothing new. > > > >However, you used the phrase "verified operational need", which is > >something different. > > > >I am a n00b in the RIPE community, so I have certainly not read > >everything there is, but from what I have seen, read and understand, > >this verification thing is new. > > If you wanted more than the minimum it was always necessary to provide a > story that passed a smell test. Also, if you wanted another batch of > numbers you always had to explain what did with the old ones you were > given, usually providing some data, much of the "bureaucracy" 2013-3 > wants to eliminate. > > Verified: 1. Make sure or demonstrate that (something) is true, > accurate, or justified. 2. Swear to or support (a statement) by affidavit. > > Justified: 1. Having, done for, or marked by a good or legitimate > reason. 2. Declared or made righteous in the sight of God. > > So, please tell me how "verified operational need" is that different. > If you would prefer justified or validated operational need. OK, what ever. > persuant to your comments and David Conrads contribution, I'd suggest that the "smell test" criteria has changed dramatically over the years. Nearly all the IPv4 space I have requested has passed the "verified operational need" using the Warren Buffet test. (he's a man of good character) These days it sometimes goes as far as explaining a business model, showing signed contracts, bank statements, customer lists and credit reports on clients. There is a argument to be made that RIRs have gone too far into delving into a request... boardering on harrassment and restraint of trade. Not saying that the Buffet test alone is good either. /bill From bmanning at vacation.karoshi.com Mon Aug 5 15:15:19 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 5 Aug 2013 13:15:19 +0000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <7CFEF368-0DEE-4832-B625-D02EB5CAD855@eyeconomics.com> References: <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <20130804145912.GA19854@vacation.karoshi.com.> <7CFEF368-0DEE-4832-B625-D02EB5CAD855@eyeconomics.com> Message-ID: <20130805131519.GB1181@vacation.karoshi.com.> On Sun, Aug 04, 2013 at 03:35:25PM -0400, Tom Vest wrote: > > On Aug 4, 2013, at 10:59 AM, bmanning at vacation.karoshi.com wrote: > > > On Sun, Aug 04, 2013 at 04:35:25PM +0200, Jan Ingvoldstad wrote: > >> On Sun, Aug 4, 2013 at 3:41 PM, David Farmer wrote: > >> > >>> On 8/1/13 12:27 , Tore Anderson wrote: > >>> > >>>> * Nick Hilliard > >>>> > >>>> On 01/08/2013 07:38, Tore Anderson wrote: > >>>>> > >>>>>> +Fair use: Public IPv4 address space must be fairly distributed to the > >>>>>> End Users operating networks.; > >>>>>> > >>>>> can you define "fair"? > >>>>> > >>> I believe the primary definition of fairness the RIR communities have been > >>> using is, "only those that have *verified operational need* get Internet > >>> number resources". > >> > >> This is how Internet number resources have been handled for years; > >> organizations without verified operational needs have received Internet > >> number resources, some in huge quantities. > >> > >> One could easily argue that this is one of the root problems with former > >> Internet number resource handling. > >> > >> Fortunately, IPv6 came to the rescue. > > > > Pragmatically, there is zero chance of verification of operational need > > for anything larger than a /96 in IPv6 space.... So the rules for v6 > > allocation actually are fairly close to the original v4 allocation policies. > > > > The concept of verified operational need arose in times of scarcity, when > > there was -no- other option. Those times have past and its not clear to me > > why there remains this slavish devotion to having an unlicensed regulator > > second guess the viability of a given operational model. > > Hi Bill, > > Out of curiosity, about how many Class As would you say had been assigned before that scarcity came to be widely recognized, and the > concept of "verified operational need" was first articulated? At that time, was promptly doling out all of the remaining Class As on a first first-come-first served basis *not* considered an option? If not, why not? If the prospect of creating an operating environment in which critical number resources were collectively, indefinitely controlled by a relatively small minority of the total number of operators who could such resources to similarly good use (and whose commercial/existential viability would forevermore be contingent on the terms of their access to someone else's number resources) was not considered a viable option back then, what makes it any more palatable now? > > Granted, both the numerator (resource-haves) and the denominator (have-nots) numbers have grown several orders of magnitude over the ensuing years, but how exactly does that matter if the resulting fraction remains broadly unchanged? > > Curiously, > > TV /8, pre or post classfull addressing? pre-classful, all there was were /8's. Kind of like all there are now are /64s in v6 land. when ~10% of the total v4 pool was allocated, scarcity triggered the creation of classful addressing, which gave us /16 and /24 space in v4-land. at ~40% of the total v4 pool, scarcity created CIDR and started on developing v6-land. I'd suggest that with the viablity of IPv6, that the remaining v4 pool is simply vestigal and its getting far more traction than it deserves. We are clearly not in a position of scarcity when we hand out, to individual devices, the functional equivalent of the -entire- v4 pool, raised to the 32nd power. That is the most profligate waste of address space I have ever seen and these petty "verified operational use" arguments seem farcical and almost hypocritical in comparison. /bill From bmanning at vacation.karoshi.com Mon Aug 5 15:19:58 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 5 Aug 2013 13:19:58 +0000 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FEB277.2000900@umn.edu> References: <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51fe6c98.87883c0a.534e.5ccfSMTPIN_ADDED_BROKEN@mx.google.com> <51FEB277.2000900@umn.edu> Message-ID: <20130805131958.GC1181@vacation.karoshi.com.> On Sun, Aug 04, 2013 at 02:58:47PM -0500, David Farmer wrote: > On 8/4/13 09:59 , bmanning at vacation.karoshi.com wrote: > > Pragmatically, there is zero chance of verification of operational > > need > > for anything larger than a /96 in IPv6 space.... So the rules for v6 > > allocation actually are fairly close to the original v4 allocation > > policies. > > I disagree, /64 is easily justified by how the protocols are defined, so > is a /56 and probably a /48 for a business customer. You may want to > argue if the protocols should have been defined to use a whole /64 for a > single Ethernet. But that is not an RIR policy question, that is an > IETF protocol question. The RIR's have to work with the protocols as > the IETF defines them. I'm not saying you are necessary wrong, just > that this isn't the forum. perhaps. but wasted space is wasted space. > > The concept of verified operational need arose in times of scarcity, > > when there was -no- other option. > > Again I disagree, if you wanted a Class A or B you needed to justify the > request, it was relatively easy by comparison for sure. And if you > wanted more you had to explain what you did with the ones you had. But > justification didn't just come in with conservation or scarcity, it > always been there, what has changed is the standards for the > justification. see previous post. then, verification was the Buffet test... simply by making the request was verification of need. today, the verification process boarders on harrassment and restraint of trade. I think either extream is fraught with peril. > I'm not stuck on the current standards for justification, but > eliminating both "operational need" and any concept of "fairness" to > replace it is an issue for me. Good thing there is the forum for public dialog. :) /bill From lists-ripe at c4inet.net Mon Aug 5 15:29:45 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 5 Aug 2013 14:29:45 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FF88CA.3030707@fud.no> References: <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <855077AC3D7A7147A7570370CA01ECD248E6E8@SUEX10-mbx-10.ad.syr.edu> <51FE56D8.3010708@titley.com> <855077AC3D7A7147A7570370CA01ECD249642B@SUEX10-mbx-10.ad.syr.edu> <51FF88CA.3030707@fud.no> Message-ID: <20130805132945.GA6688@cilantro.c4inet.net> On Mon, Aug 05, 2013 at 01:13:14PM +0200, Tore Anderson wrote: >That's a feature, not a bug. :-) I'd much rather have LIRs that would >engage in stockpiling and applying discriminatory practices in breach of >competition laws *not* be able to defend themselves with ?don't look at >us, the RIPE NCC said it was OK!? I think this discussion has come off the rails a wee bit. As I read the proposal, it is (correct me if I'm wrong) simply about removing a phrase -and associated bureaucratic process that causes work and delay for operators- that has become meaningless in practice even before IPv4 depletion. All the "needs assessment" consists of is a check that the application conforms somewhat to the letter of the policy (the aforementioned "giggle test"). There is even a specialised skill in creating assignment/allocation requests that will pass the "needs assessment" with minimum hassle. (Full disclosure: This skill has paid my bills a few times) Since there is no point in keeping around a meaningless procedure, there are, in my opinion, two options: 1) implement 2013-03 and give policy standing to a situation that obtains anyway. 2) actually assess the needs of each application on its merits, as some participants in this debate seem to be hinting at. This is something that not many network architects are qualified to do, let alone RAs (with no offence to RAs intended). Even assuming the NCC hired highly qualified networkers to perform these assessments, the process would still be largely arbitrary (ask any two networkers about the "right" way to build a network and you will get three opinions), expensive and totally disproportional in effort, especially considering that there is not that much IPv4 space left to distribute in whichever way. As far as hoarding and speculation is concerned, I'm not sure this is such a massive problem. IPv4 space is a risky speculative investment, as soon as IPv6 usage gains significant traction, it is likely to become progressively worthless and the effort and cost to obtain large amounts for speculation (remember, 1024 IPs per LIR) should make it unattractive. [Caveat: IANAEconomist] For the avoidance of doubt, in case this wasn't clear from the above, I hereby restate my support for 2013-03. rgds, Sascha Luck From lists-ripe at c4inet.net Mon Aug 5 15:37:53 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 5 Aug 2013 14:37:53 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <20130805130037.GA1181@vacation.karoshi.com.> References: <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE85CD.2020804@umn.edu> <51FE94CD.3060206@umn.edu> <20130805130037.GA1181@vacation.karoshi.com.> Message-ID: <20130805133753.GB6688@cilantro.c4inet.net> On Mon, Aug 05, 2013 at 01:00:37PM +0000, bmanning at vacation.karoshi.com wrote: > persuant to your comments and David Conrads contribution, > I'd suggest that the "smell test" criteria has changed > dramatically over the years. Nearly all the IPv4 space I have > requested has passed the "verified operational need" using the > Warren Buffet test. (he's a man of good character) These days > it sometimes goes as far as explaining a business model, showing > signed contracts, bank statements, customer lists and credit reports on clients. Interesting. I've never experienced anything like that, but I've not made applications since "Last /8" came in. I should think that asking for bank statements and credit reports would be a data protection issue to say the least. If this is the case (and again, I've not experienced such requests myself) it is all the more reason to strongly support 2013-03... rgds, Sascha Luck From tvest at eyeconomics.com Tue Aug 6 04:23:45 2013 From: tvest at eyeconomics.com (Tom Vest) Date: Mon, 5 Aug 2013 22:23:45 -0400 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <20130805131519.GB1181@vacation.karoshi.com.> References: <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <20130804145912.GA19854@vacation.karoshi.com.> <7CFEF368-0DEE-4832-B625-D02EB5CAD855@eyeconomics.com> <20130805131519.GB1181@vacation.karoshi.com.> Message-ID: <29C32722-B8B2-4053-9498-D2645D9BD637@eyeconomics.com> On Aug 5, 2013, at 9:15 AM, bmanning at vacation.karoshi.com wrote: > On Sun, Aug 04, 2013 at 03:35:25PM -0400, Tom Vest wrote: >> >> On Aug 4, 2013, at 10:59 AM, bmanning at vacation.karoshi.com wrote: >> >>> On Sun, Aug 04, 2013 at 04:35:25PM +0200, Jan Ingvoldstad wrote: >>>> On Sun, Aug 4, 2013 at 3:41 PM, David Farmer wrote: >>>> >>>>> On 8/1/13 12:27 , Tore Anderson wrote: >>>>> >>>>>> * Nick Hilliard >>>>>> >>>>>> On 01/08/2013 07:38, Tore Anderson wrote: >>>>>>> >>>>>>>> +Fair use: Public IPv4 address space must be fairly distributed to the >>>>>>>> End Users operating networks.; >>>>>>>> >>>>>>> can you define "fair"? >>>>>>> >>>>> I believe the primary definition of fairness the RIR communities have been >>>>> using is, "only those that have *verified operational need* get Internet >>>>> number resources". >>>> >>>> This is how Internet number resources have been handled for years; >>>> organizations without verified operational needs have received Internet >>>> number resources, some in huge quantities. >>>> >>>> One could easily argue that this is one of the root problems with former >>>> Internet number resource handling. >>>> >>>> Fortunately, IPv6 came to the rescue. >>> >>> Pragmatically, there is zero chance of verification of operational need >>> for anything larger than a /96 in IPv6 space.... So the rules for v6 >>> allocation actually are fairly close to the original v4 allocation policies. >>> >>> The concept of verified operational need arose in times of scarcity, when >>> there was -no- other option. Those times have past and its not clear to me >>> why there remains this slavish devotion to having an unlicensed regulator >>> second guess the viability of a given operational model. >> >> Hi Bill, >> >> Out of curiosity, about how many Class As would you say had been assigned before that scarcity came to be widely recognized, and the >> concept of "verified operational need" was first articulated? At that time, was promptly doling out all of the remaining Class As on a first first-come-first served basis *not* considered an option? If not, why not? If the prospect of creating an operating environment in which critical number resources were collectively, indefinitely controlled by a relatively small minority of the total number of operators who could such resources to similarly good use (and whose commercial/existential viability would forevermore be contingent on the terms of their access to someone else's number resources) was not considered a viable option back then, what makes it any more palatable now? >> >> Granted, both the numerator (resource-haves) and the denominator (have-nots) numbers have grown several orders of magnitude over the ensuing years, but how exactly does that matter if the resulting fraction remains broadly unchanged? >> >> Curiously, >> >> TV > > /8, pre or post classfull addressing? > pre-classful, all there was were /8's. Kind of like all there are now > are /64s in v6 land. > > when ~10% of the total v4 pool was allocated, scarcity triggered the creation > of classful addressing, which gave us /16 and /24 space in v4-land. > > at ~40% of the total v4 pool, scarcity created CIDR and started on developing v6-land. > > I'd suggest that with the viablity of IPv6, that the remaining v4 pool is simply > vestigal and its getting far more traction than it deserves. We are clearly > not in a position of scarcity when we hand out, to individual devices, the functional > equivalent of the -entire- v4 pool, raised to the 32nd power. > > That is the most profligate waste of address space I have ever seen and these petty > "verified operational use" arguments seem farcical and almost hypocritical in > comparison. > > /bill Hi Bill, I agree that, *once* the viability of IPv6 has been established widely, including as a stand-alone alternative to IPv4 for new entrants who have no IPv4 of their own*, IPv4 issues will indeed become vestigial. In the mean time, I interpret your use of "profligate waste" to mean something like "possessing exclusive right to use (of addresses) in quantities that vastly exceed 'operational need,' or capability to put to productive use." I could understand a general distaste for "waste" of this kind on purely aesthetic grounds, but given your visceral reaction I can only assume that you believe that such waste has a cost -- and since exclusive of possession of "profligate" quantities of number resources can be privately beneficial to the possessor under certain conditions, I'm tempted to assume that the costs of profligacy that concern you are the costs that are imposed by the "profligate" on everyone else, in the form of needlessly accelerated scarcity and/or exhaustion of resources that could otherwise be put to productive use by others... If that interpretation is not too far off-base, then I guess you must know something about the state of IPv6 usage* that I don't know -- or maybe, your definition of "waste" excludes anything that has been paid for, even if the purchased/idle stockpiles serve no other purpose than to exacerbate demand/scarcity among others... ? TV From frettled at gmail.com Tue Aug 6 07:40:08 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 6 Aug 2013 07:40:08 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <29C32722-B8B2-4053-9498-D2645D9BD637@eyeconomics.com> References: <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <20130804145912.GA19854@vacation.karoshi.com.> <7CFEF368-0DEE-4832-B625-D02EB5CAD855@eyeconomics.com> <20130805131519.GB1181@vacation.karoshi.com.> <29C32722-B8B2-4053-9498-D2645D9BD637@eyeconomics.com> Message-ID: On Tue, Aug 6, 2013 at 4:23 AM, Tom Vest wrote: > If that interpretation is not too far off-base, then I guess you must know > something about the state of IPv6 usage* that I don't know -- or maybe, > your definition of "waste" excludes anything that has been paid for, even > if the purchased/idle stockpiles serve no other purpose than to exacerbate > demand/scarcity among others... ? > > Well, in a historic and current perspective, what do e.g. Apple, Daimler AG, DuPont, Eli Lilly, Ford, Halliburton, HP (twice!), IBM, Prudential Securities, UK Ministry of Defence, UK Work & Pensions need millions of public IP addresses for, each? Perhaps there are one or few others, who in historic times got huge blocks, but which don't need them. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nigel at titley.com Tue Aug 6 10:53:30 2013 From: nigel at titley.com (Nigel Titley) Date: Tue, 06 Aug 2013 09:53:30 +0100 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FF88CA.3030707@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <855077AC3D7A7147A7570370CA01ECD248E6E8@SUEX10-mbx-10.ad.syr.edu> <51FE56D8.3010708@titley.com> <855077AC3D7A7147A7570370CA01ECD249642B@SUEX10-mbx-10.ad.syr.edu> <51FF88CA.3030707@fud.no> Message-ID: <5200B98A.6090905@titley.com> And by the way, with my personal hat on, and with Tore's "operational use" amendment I'm reasonably happy with this proposal. Nigel From hph at oslo.net Tue Aug 6 17:20:53 2013 From: hph at oslo.net (Hans Petter Holen) Date: Tue, 6 Aug 2013 17:20:53 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FE96DC.8000304@umn.edu> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE69BC.1080503@fud.no> <51FE96DC.8000304@umn.edu> Message-ID: On Sunday, August 4, 2013, David Farmer wrote: > On 8/4/13 09:48 , Tore Anderson wrote: > >> * David Farmer >> >> I believe the primary definition of fairness the RIR communities have >>> been using is, "only those that have *verified operational need* get >>> Internet number resources". >>> >> >> Do you have a link or reference? (Tried Google, no hits.) >> > > Try goal #1 in section #1 of RFC 2050. > See https://tools.ietf.org/html/**rfc2050#section-1 since this is going to be replaced we should probably make sure we are in line with: > > And in slightly different words, try goal #1 in section #2 of RFC 2050-bis. > See http://tools.ietf.org/html/**draft-housley-rfc2050bis-02#**section-2 another question is if rfc2050 is "binding" and "limiting" for the RIRs and if draft-housley is going to be it may have go go trough some RIR processes too? -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 Tue Aug 6 17:43:46 2013 From: tore at fud.no (Tore Anderson) Date: Tue, 06 Aug 2013 17:43:46 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE69BC.1080503@fud.no> <51FE96DC.8000304@umn.edu> Message-ID: <520119B2.60902@fud.no> * 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.) > another question is if rfc2050 is "binding" and "limiting" for the RIRs > and if draft-housley is going to be it may have go go trough some RIR > processes too? I think David Conrad answered this already by clearly stating that draft-housley is not intended to be "the New Testament". Tore From farmer at umn.edu Tue Aug 6 18:09:56 2013 From: farmer at umn.edu (David Farmer) Date: Tue, 06 Aug 2013 11:09:56 -0500 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE69BC.1080503@fud.no> <51FE96DC.8000304@umn.edu> Message-ID: <52011FD4.8030804@umn.edu> On 8/6/13 10:20 , Hans Petter Holen wrote: > > On Sunday, August 4, 2013, David Farmer wrote: > > On 8/4/13 09:48 , Tore Anderson wrote: > > * David Farmer > > I believe the primary definition of fairness the RIR > communities have > been using is, "only those that have *verified operational > need* get > Internet number resources". > > > Do you have a link or reference? (Tried Google, no hits.) > > > Try goal #1 in section #1 of RFC 2050. > See https://tools.ietf.org/html/__rfc2050#section-1 > > > > since this is going to be replaced we should probably make sure we are > in line with: > > > And in slightly different words, try goal #1 in section #2 of RFC > 2050-bis. > See > http://tools.ietf.org/html/__draft-housley-rfc2050bis-02#__section-2 > > > > another question is if rfc2050 is "binding" and "limiting" for the RIRs and > if draft-housley is going to be it may have go go trough some RIR > processes too? I never said RFC 2050 is binding on the RIR's. I've been saying it articulates fairness and why operational need is important. RIPE and any other RIRs can and have ignored many parts of it, and are fee to continue to do so. However, RFC 2050 and the upcoming 2050-bis are the only common statement of goals or principles other than ICP-2 that there is for the Internet Registry System and the RIRs as a whole. If we ignore those goals and principles, without careful consideration, bad things are likely to happen. If you are suggesting it would be a good thing for there to be a common set of goals and/or principles for all the RIRs that have gone through the RIR's policy processes or maybe the global policy process, that may not be a bad idea. Note: Within the ARIN Region there is such a discussion going one see ARIN-2013-4, right now the scope is intended to be within the ARIN region only. https://www.arin.net/policy/proposals/2013_4.html I believe that operational need is one of the few useful concept of fairness we have from a Internet number resources policy perspective. Impartiality and community consensus supporting policy being the only others I can think of as useful concepts of fairness. -- ================================================ 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 dburk at burkov.aha.ru Tue Aug 6 18:31:19 2013 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Tue, 6 Aug 2013 20:31:19 +0400 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <52011FD4.8030804@umn.edu> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE69BC.1080503@fud.no> <51FE96DC.8000304@umn.edu> <52011FD4.8030804@umn.edu> Message-ID: <5EB20C87-C4C7-42C1-941A-FB08FCE0275B@burkov.aha.ru> On Aug 6, 2013, at 8:09 PM, David Farmer wrote: > On 8/6/13 10:20 , Hans Petter Holen wrote: >> >> >> another question is if rfc2050 is "binding" and "limiting" for the RIRs and >> if draft-housley is going to be it may have go go trough some RIR >> processes too? > > I never said RFC 2050 is binding on the RIR's. I've been saying it articulates fairness and why operational need is important. RIPE and any other RIRs can and have ignored many parts of it, and are fee to continue to do so. > > However, RFC 2050 and the upcoming 2050-bis are the only common statement of goals or principles other than ICP-2 that there is for the Internet Registry System and the RIRs as a whole. If we ignore those goals and principles, without careful consideration, bad things are likely to happen. I always think that 2050 is just reflect current situation and don't define any goals and principles If you will insist that it should be policy document it will break the whole RIR PDP bottom-up system. > > If you are suggesting it would be a good thing for there to be a common set of goals and/or principles for all the RIRs that have gone through the RIR's policy processes or maybe the global policy process, that may not be a bad idea. It is how existing system works. Dmitry From tore at fud.no Wed Aug 7 15:24:05 2013 From: tore at fud.no (Tore Anderson) Date: Wed, 07 Aug 2013 15:24:05 +0200 Subject: [address-policy-wg] 2013-03: Summary of amendments for version 3.0 Message-ID: <52024A75.20300@fud.no> Hi APWG, As you all know, during the Review phase a couple of potentially problematic issues in the proposal was brought up, which I've offered to improve on by amending the proposal. I want to detail the individual amendments and how they impact the proposal, so that you can all review them before we send the new version of the proposal back to the NCC. I welcome your opinions on the amendments, but please also realise it is not an invitation to bikeshedding - I'm trying to find a middle ground the WG will find acceptable, not necessarily perfect. In doing so I hope that we can ensure that we won't be sending Emilio off on a wild goose chase when we ask him to create a new Impact Analysis - so if you are completely unable to live with any of this, then do speak now or forever hold your peace. I'd like to especially thank Filiz Yilmaz and Malcom Hutty for highlighting and elaborating on the issues that resulted in the first two amendments, and to Andrea, Emilio, and Marco from the NCC for collaborating with me on writing the texts of the last two amendments and confirming that there will be no misunderstandings as to their intent and interpretation. Amendment 1: Retain "Fairness" goal =================================== This amendment retains our community's overall philosophical and moral goal of fair distribution of IPv4 address space to end users operating networks. Our current IPv4 policy lumps together a "Fairness" and a "Conservation" goal (unlike our IPv6 policy, which separates the two). Seeking only to remove the latter, the current version of 2013-03 accidentally removed the former as well. The amendment makes no attempt to define what constitutes "fair distribution" in our current environment of scarcity - this will remain a value judgement each LIR has to make for themselves, just like it is today. The benefits of this amendment include: * Avoids throwing the baby out with the bathwater. * Guides LIRs to assign address space to end users who are operating networks, as well as to base any value judgement they would need to make related to this on their own notion of fairness. * Ensures that we keep the door open for a potential future discussion on how to define and possibly enforce fair distribution in an environment of scarcity. * Provides "ammunition" for the NCC in their talks and interactions with critical governments, regulators, or similar entities. The exact amendment, which is to be inserted into section 3.0 of the proposed policy, reads: ?Fairness: Public IPv4 address space must be fairly distributed to the End Users operating networks.? Note that except for the title, this is the exact same phrase as is found in our current policy. This is fully intentional, as 2013-03 has no ambition to alter previously agreed upon consensus in this regard. I chose the title "Fairness" to match the one used in the IPv6 policy document (ripe-589). Amendment 2: Retain "Need" for final /22 allocations ==================================================== This amendment retains the current practice of requiring the LIRs that seek to obtain their final /22 from the austerity ("last /8") allocation pool to use it for making assignments to their end users or their own infrastructure. This is not in conflict with 2013-03's "No Need" moniker, as changing the "last /8 policy" is not its ambition. That the current version of the proposal does so was only due to a layer of indirection, in which the "last /8" policy made a reference to the "old policy" which 2013-03 did remove as part of its overall clean-up efforts. In practical terms, the amendment will result in a "check box" or a "yes/no" question in the allocation request form, where LIRs would be required to declare this to be their intent in order to receive the allocation. This interpretation has been confirmed by the NCC. The benefits of this amendment include: * Ensures our RIR-to-LIR allocation policy remains pursuant to the "Fairness" goal described in amendment 1. * Avoids any confusion leading to an impression that 2013-03 would make the RIPE NCC start to "sell IPv4 addresses". This in turn leads to the following benefits: -- Alleviates concerns that the RIPE NCC may lose its status as a non-profit membership association with the Dutch tax authorities, -- Shields the NCC from some of the legal concerns and impacts noted in the current Impact Analysis' EU Competition Law report, -- Provides "ammunition for the NCC in their talks and interactions with critical governments, regulators, or similar entities. * Ensures the proposed policy remains as much in line with RFC 2050bis' Allocation Pool Management goal as our current policy is. * Prevents LIRs from obtaining their last /22 for other purposes than "networking"; in particular re-sale, stockpiling, or hoarding. This amendment reads as follows, and is to be inserted as a new bullet point in the proposed policy's section 5.1: ?The LIR must confirm it will make assignment(s) from the allocation? Amendment 3: Clarify criteria for IXP assignment expansions =========================================================== The NCC noted in its Impact Analysis for the current version of the proposal that the precise criteria for when an IXP may request an expansion of its peering LAN assignment from "last /8 IXP assignments" was lost and thus left undefined. This was unintentional and happened due to the exact same "layer of indirection" problem described above. As 2013-03 has no ambition to change the "last /8 policy", including the parts specific to IXPs, and the proposed amendment seeks only to document and uphold the status quo. The argument in favour of this amendment is of course to ensure we continue to provide the NCC and its hostmasters with clear guidance on how our policies should be implemented. The amendment will be inserted into section 6.1, replacing the fourth bullet point, and reads as follows: ?New IXPs will be assigned a /24. Should they require a larger assignment, they must return their current assignment (or existing PI used as an IXP peering LAN) and receive a replacement /23 or /22. After one year the utilisation of the new assignment must be at least 50%, unless special circumstances are defined? The RIPE NCC has confirmed that this text accurately describes today's practice, and that it will merely uphold the current status quo. The amendments are also attached in unified diff format. Best regards, Tore Anderson -------------- next part -------------- --- 2013-03-v2.txt 2013-08-06 21:25:31.425520553 +0200 +++ 2013-03-v3pre.txt 2013-08-07 15:15:44.614150212 +0200 @@ -127,7 +127,9 @@ 2. Aggregation: Distributing IPv4 addresses in an hierarchical manner permits the aggregation of routing information. This helps to ensure proper operation of Internet routing. - 3. Registration: The provision of a public registry documenting address + 3. Fairness: Public IPv4 address space must be fairly distributed to + the End Users operating networks. + 4. Registration: The provision of a public registry documenting address space allocations and assignments must exist. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels. @@ -178,7 +180,8 @@ 2. The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof). - 3. Allocations will only be made to LIRs if they have already received an + 3. The LIR must confirm it will make assignment(s) from the allocation. + 4. Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC. @@ -313,9 +316,11 @@ * IXPs holding other PI IPv4 space for their peering LAN (i.e. they are seeking a larger assignment), must return their old peering LAN resources back to this pool within 180 days of assignment. - * New IXPs will be assigned a /24. IXPs may return this /24 (or existing - PI used as an IXP peering LAN) should they run out of space and - receive a larger (/23, or /22 if utilisation requires) assignment. + * New IXPs will be assigned a /24. Should they require a larger + assignment, they must return their current assignment (or existing PI + used as an IXP peering LAN) and receive a replacement /23 or /22. After + one year the utilisation of the new assignment must be at least 50%, + unless special circumstances are defined. * IP space returned by IXPs will be added to the reserved pool maintained for IXP use. * Assignments will only be made to IXPs who have already applied for, or From tomasz.slaski at gmail.com Wed Aug 7 23:49:36 2013 From: tomasz.slaski at gmail.com (=?UTF-8?B?VG9tYXN6IMWabMSFc2tpIEdNQUlM?=) Date: Wed, 07 Aug 2013 23:49:36 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <007301ce8de4$2bf9e3a0$83edaae0$@a2b-internet.com> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C2BB31.5060701@fud.no> <51C2E753.50307@schiefner.de> <51C303C6.5040408@opteamax.de> <51C30D04.8090809@titley.com> <51DFFA30.7070707@schiefner.de> <51E03458.2090701@titley.com> <51E5BEF1.3000507@schiefner.de> <51E67244.3090908@titley.com> <51F8D404.8070703@schiefner.de> <007301ce8de4$2bf9e3a0$83edaae0$@a2b-internet.com> Message-ID: <5202C0F0.5010705@gmail.com> W dniu 2013-07-31 13:50, Erik Bais pisze: > Hi Carsten, > > I'm in favor of LIR's being able to change the PI status to PA for their own assigned PI space. (Infrastructure) > > I think that the whole PI and PA discussion itself will take some time to complete, but this particular change should be fairly easy to implement imho. > > Regards, > Erik Bais I think that is very simple, requiring only a decision which no one yet wants to take. Do we have any new ideas on this subject? Personally, I think that: 1. If an organization wants to become LIR status and declares, that alerady has the PI resources equal or more than /22, it should no longer receive the "initial" allocation of the /22 from the lat /8, but should be able to convert all, what was received before becoming the LIR status. 2. Existing LIRs should be able to convert his PI resources to PA regardless of the block size. All the best Tomasz From sylvain.vallerot at opdop.net Sun Aug 11 12:03:49 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Sun, 11 Aug 2013 12:03:49 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> Message-ID: <52076185.2020601@opdop.net> Hi, sorry for my late contribution (and my poor english) On 20/06/2013 09:49, andrea wrote: > A. Allow LIRs to change the status of their PI assignments to PA allocations > (if equal or larger than the minimum allocation size) I do not support this since blindly allowing LIRs to change PI to PA would lead to very permissive reuse of space that was assigned in an exception mode to the aggregation principle for very specific reasons. So I consider if the purpose of this assignment is no valid anymore then it should be returned to free pool in the general case, not reused for whatever else. This is enforced by the ability for LIRs to transfer (I mean, to sell) PA space. Obviously converting PI to PA and sell it would be the right choice for anybody having unused PI subnets today. I know convervation looks like an old fashioned and void policy for many LIRs today, however free IPv4 still is a rare public ressource needed by many to survive. So available IPs should be returned to RIR. Best regards, Sylvain fr.opdop From sylvain.vallerot at opdop.net Sun Aug 11 13:13:44 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Sun, 11 Aug 2013 13:13:44 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD248E711@SUEX10-mbx-10.ad.syr.edu> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <855077AC3D7A7147A7570370CA01ECD248E711@SUEX10-mbx-10.ad.syr.edu> Message-ID: <520771E8.4080702@opdop.net> On 03/08/2013 15:17, Milton L Mueller wrote: > > >> I liked the proposal initialy - but I do not buy the initial argument that since we have run >> out, conservation is not important. Since we have run out of unused addresses conservation >> is in many ways more important - unless we belive v6 can take over. > > I don't understand why people confuse the elimination of needs assessment with the > elimination of conservation. Because they're linked. The requirement of justifying and documenting is a lever for us today, to get serious cooperation from our clients in ordre to get their needs correctly evaluated, and /24s (or more) not being wasted in careless (and preventive) over-subscriptions of adresses. This helps us preventing a rush to our allocation depletion and thus, from requesting the last /22. And thereafter, to create a new LIR to satisfy these needs we would let run. Am I wrong if I suspect commercial teams would happily distribute large bunches of undocumented adresses to their asking customers if the Ripe allowed it. As far as I can see, commercials do appreciate to be able to satisfy their customers requests. From sylvain.vallerot at opdop.net Sun Aug 11 13:26:12 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Sun, 11 Aug 2013 13:26:12 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FA8BB3.60202@inex.ie> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> Message-ID: <520774D4.7050508@opdop.net> On 01/08/2013 18:24, Nick Hilliard wrote: > On 01/08/2013 07:38, Tore Anderson wrote: >> ?Fair use: Public IPv4 address space must be fairly distributed to the >> End Users operating networks.? > > Sounds good to me! One minor nit: can you define "fair"? Fair means with equity, and our measure for equity is need (e.g. the contrary of waste). Which implies a need should be evaluated. Once this evaluation is done should it be dropped to the next trash ? Writing it down in a file is easy, simple, and almost an evidence. This file being organised with sections and filled with a bit of explanations and contexts looks like an evidence also. This is ripe-583. So what is the problem with this file ? To me, this form is not a burocratic overhead, it is a tool is use as a guideline when making a new assignment. From sylvain.vallerot at opdop.net Sun Aug 11 14:11:09 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Sun, 11 Aug 2013 14:11:09 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FE69BC.1080503@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE69BC.1080503@fud.no> Message-ID: <52077F5D.4000304@opdop.net> On 04/08/2013 16:48, Tore Anderson wrote: > In a similar vein, and somewhat tongue in cheek: If you're trying to buy > an apartment, but get outbid by someone, do you get upset unless you can > see some proof that guy did buy it plans on moving in there? Or do you > assume that's probably the case and move on? We got something in France that is called the right to housing. The question is not, of course, but is not fully disconnected of knowing if does Ripe wants to tend to protect the public right of weaks to get a place. You asked repetedly here for precise statements to explain how 2013-03 would, on its own, make things worse. And you explained many times that wrong things could already be done independantly from 2013-03 being accepted or not. Things cannot be split that way in my mind. My point is, that 2013-03 is part of a much larger evolution that is progressively making the deal completely different. I cannot help but consider thinks together and observe a general move that breaches yesterday's principles : - the ability to resell IPv4 allocations - the proposal to allow v4 PI changed to PA (aggregation breach) - the suppression of the conservation goal - the documentation need removal To me, the general picture looks like is that considerable ground is given to a fully commercial hand over the public ressource management. This seems to be motivated by kind of a hurry to get rid of the burden of the IPv4 administrative work. Which I feel hard to understand since lots of operators still need a proper and fair ressource attribution to continue or to start their business today (which is being more critical because of scarcity) and also because Ripe members still pay membership fees to finance it. Sorry I went quite far from simple 2013-03 discussion here. However reducing the discussion field does not allow to build a global policy that is consistent and has a coherent philosophy, I think. Best regards, Sylvain > > Tore > -- http://www.opdop.fr - mutualiser et interconnecter en coop?rative -- ManyOnes.COM SARL - RCS Paris B 449 031 574 - TVA n?FR56449031574 en cours de mutation comme Soci?t? Coop?rative d'Inter?t Collectif -- ManyOnes, c/o Sylvain Vallerot, 3 rue Erckmann Chatrian, 75018 Paris From ebais at a2b-internet.com Sun Aug 11 14:18:01 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Sun, 11 Aug 2013 14:18:01 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <52076185.2020601@opdop.net> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <52076185.2020601@opdop.net> Message-ID: <33F76431-4396-4132-8349-35C7D8B22E48@a2b-internet.com> Hi Sylvain, If the goal is to resell space, it will happen anyway. There are companies that start with PI space and become an LIR later. The policy for PI space stated that if you could justify 1 IP address, you would get a single /24. Anyone can justify a single IP address for their infrastructure. This change will allow PI space holders that are a LIR themselves to use the remaining space that might not be allowed under the PI assignment policy ( like sub-assignment to third-parties / customers ) Voting against this will not make these policy voilations go away ... And PI space will not go back to the free pool... Conservation is not a goal anymore by itself, as our RIR has depleted its free pool. Fair distribution isn't a task anymore, the primairy task keeping the registry correct. Will people sell space ( even if the policy won't allow it ?) YES !! I have seen incidents of people buying PI space and not changing the holder, side letters in place etc. If we have clear policies and procedures that would allow these situations to at least reflect in the registry, the registry will have a much better change of being accurate. This proposed change will remove limitations that were valid in a pre-depletion era .. However, times have changed. Regards, Erik Bais Verstuurd vanaf mijn iPad Op 11 aug. 2013 om 12:03 heeft Sylvain Vallerot het volgende geschreven: > > Hi, sorry for my late contribution (and my poor english) > > On 20/06/2013 09:49, andrea wrote: >> A. Allow LIRs to change the status of their PI assignments to PA allocations >> (if equal or larger than the minimum allocation size) > > I do not support this since blindly allowing LIRs to change PI to PA would > lead to very permissive reuse of space that was assigned in an exception mode > to the aggregation principle for very specific reasons. > > So I consider if the purpose of this assignment is no valid anymore then it should > be returned to free pool in the general case, not reused for whatever else. > > This is enforced by the ability for LIRs to transfer (I mean, to sell) PA space. > Obviously converting PI to PA and sell it would be the right choice for anybody > having unused PI subnets today. > > I know convervation looks like an old fashioned and void policy for many LIRs > today, however free IPv4 still is a rare public ressource needed by many to > survive. So available IPs should be returned to RIR. > > Best regards, > Sylvain > fr.opdop > From ripe at opteamax.de Sun Aug 11 14:19:11 2013 From: ripe at opteamax.de (Opteamax GmbH - RIPE-Team) Date: Sun, 11 Aug 2013 14:19:11 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <52076185.2020601@opdop.net> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <52076185.2020601@opdop.net> Message-ID: Hi Sylvain, Maybe the definition must be taken a little different: conversion for own use. The reason is that some PI-Owner became LIR, e.g. because the size of their business grew, that it became reasonable. Earlier it didn't make sense for me to become LIR as two /24 were sufficient. With an eye on the "Last /8 Policy", your proposal would mean, these LIRs would have to return their space without having a chance to get new pa to satisfy their current need. Anyway, even if I'd return a /22 and receive another PA (my "last /22") this wouldn't give more aggregation. The only thing that changes, would be a huge amount of work for me... or (if not converting my PI to PA I have to pay 50 EUR more than e.g. Deutsche Telekom which holds many many more IPv4 than me, only that because my initial assignment has the label PI... BR Jens Sylvain Vallerot schrieb: > >Hi, sorry for my late contribution (and my poor english) > >On 20/06/2013 09:49, andrea wrote: >> A. Allow LIRs to change the status of their PI assignments to PA >allocations >> (if equal or larger than the minimum allocation size) > >I do not support this since blindly allowing LIRs to change PI to PA >would >lead to very permissive reuse of space that was assigned in an >exception mode >to the aggregation principle for very specific reasons. > >So I consider if the purpose of this assignment is no valid anymore >then it should >be returned to free pool in the general case, not reused for whatever >else. > >This is enforced by the ability for LIRs to transfer (I mean, to sell) >PA space. >Obviously converting PI to PA and sell it would be the right choice for >anybody >having unused PI subnets today. > >I know convervation looks like an old fashioned and void policy for >many LIRs >today, however free IPv4 still is a rare public ressource needed by >many to >survive. So available IPs should be returned to RIR. > >Best regards, >Sylvain >fr.opdop > > >!DSPAM:637,520763c7296831255961281! -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.vallerot at opdop.net Sun Aug 11 14:37:57 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Sun, 11 Aug 2013 14:37:57 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <33F76431-4396-4132-8349-35C7D8B22E48@a2b-internet.com> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <52076185.2020601@opdop.net> <33F76431-4396-4132-8349-35C7D8B22E48@a2b-internet.com> Message-ID: <520785A5.20205@opdop.net> On 11/08/2013 14:18, Erik Bais wrote: >Conservation is not a goal anymore by itself, as our RIR has depleted its free pool. Except you're wrong, conservation is still a goal, and depletion is not done (otherwise I think we would have CEO suicide records a bit everywhere). According to the "math" I read in another list, with the current policies last /8 full depletion could take more than 10 years. It won't, for sure, but this and survival of the weakest will depend on the way we change these policies today and for the time dual stack will still be necessary. > Fair distribution isn't a task anymore, the primairy task keeping the registry correct. Sorry, I can't continue discussing with this. Regards, Sylvain From mueller at syr.edu Sun Aug 11 17:45:22 2013 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 11 Aug 2013 15:45:22 +0000 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <520771E8.4080702@opdop.net> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <855077AC3D7A7147A7570370CA01ECD248E711@SUEX10-mbx-10.ad.syr.edu> <520771E8.4080702@opdop.net> Message-ID: <855077AC3D7A7147A7570370CA01ECD2499D27@SUEX10-mbx-10.ad.syr.edu> But if they have to pay a price that reflects the relative scarcity of the resource they have a much stronger incentive to conserve that the alternative situation you describe. "Commercials" cannot simply provide all the addresses their customers want when they cannot replenish their stock without paying a rising price. -----Original Message----- > I don't understand why people confuse the elimination of needs > assessment with the elimination of conservation. Because they're linked. The requirement of justifying and documenting is a lever for us today, to get serious cooperation from our clients in ordre to get their needs correctly evaluated, and /24s (or more) not being wasted in careless (and preventive) over-subscriptions of adresses. This helps us preventing a rush to our allocation depletion and thus, from requesting the last /22. And thereafter, to create a new LIR to satisfy these needs we would let run. Am I wrong if I suspect commercial teams would happily distribute large bunches of undocumented adresses to their asking customers if the Ripe allowed it. As far as I can see, commercials do appreciate to be able to satisfy their customers requests. From sylvain.vallerot at opdop.net Sun Aug 11 20:29:10 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Sun, 11 Aug 2013 20:29:10 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD2499D27@SUEX10-mbx-10.ad.syr.edu> References: <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <855077AC3D7A7147A7570370CA01ECD248E711@SUEX10-mbx-10.ad.syr.edu> <520771E8.4080702@opdop.net> <855077AC3D7A7147A7570370CA01ECD2499D27@SUEX10-mbx-10.ad.syr.edu> Message-ID: <20130811182859.GB30823@eugenie.romuald.fdn.fr> On Sun, Aug 11, 2013 at 03:45:22PM +0000, Milton L Mueller wrote: > But if they have to pay a price that reflects the relative scarcity of the > resource they have a much stronger incentive to conserve that the alternative > situation you describe. "Commercials" cannot simply provide all the addresses > their customers want when they cannot replenish their stock without paying a > rising price. We are talking about 1,75 ? per address and per year. I guess this wouldn't stop any commercial from reselling to a client who asks for it, and certainly can pay for it, if conservation is abandonned. Best regards, Sylvain From mueller.syr.edu at gmail.com Sun Aug 11 22:37:41 2013 From: mueller.syr.edu at gmail.com (Milton Mueller) Date: Sun, 11 Aug 2013 16:37:41 -0400 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <855077AC3D7A7147A7570370CA01ECD248E711@SUEX10-mbx-10.ad.syr.edu> <520771E8.4080702@opdop.net> <855077AC3D7A7147A7570370CA01ECD2499D27@SUEX10-mbx-10.ad.syr.edu> Message-ID: I see now why people are confused about the conservation issue. Sylvain, the price in a market is not known in advance. I will be set by competitive bidding and reflect supply and demand. I don't know where you got this 1,75 Euro number or what on earth gives you the idea that the price will remain fixed. As supply diminishes, the price goes up. That creates powerful and effective conservation incentives. On Sun, Aug 11, 2013 at 2:29 PM, Sylvain Vallerot < sylvain.vallerot at opdop.net> wrote: > On Sun, Aug 11, 2013 at 03:45:22PM +0000, Milton L Mueller wrote: > > But if they have to pay a price that reflects the relative scarcity of > the > > resource they have a much stronger incentive to conserve that the > alternative > > situation you describe. "Commercials" cannot simply provide all the > addresses > > their customers want when they cannot replenish their stock without > paying a > > rising price. > > We are talking about 1,75 ? per address and per year. > > I guess this wouldn't stop any commercial from reselling to a client who > asks for it, and certainly can pay for it, if conservation is abandonned. > > Best regards, > Sylvain > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.vallerot at opdop.net Mon Aug 12 13:34:56 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Mon, 12 Aug 2013 13:34:56 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <855077AC3D7A7147A7570370CA01ECD248E711@SUEX10-mbx-10.ad.syr.edu> <520771E8.4080702@opdop.net> <855077AC3D7A7147A7570370CA01ECD2499D27@SUEX10-mbx-10.ad.syr.edu> Message-ID: <5208C860.8000603@opdop.net> On 11/08/2013 22:37, Milton Mueller wrote: > Sylvain, the price in a market is not known in advance. I will be set by > competitive bidding and reflect supply and demand. I don't know where you > got this 1,75 Euro number Until complete /8 depletion a LIR cost is 1800 ?/annum to easily get a /22 that is 1024 addresses. 1800 / 1024 = 1.75 ? per address and per year. This will be the guideline for max pricing until complete depletion if we abort fairness rules. But you are right after this period prices may evolve considerably (this is not a period I am interested in for the moment). My point was this 1.75 cost-price is low enough to allow commercial abuses if the fair distribution, documentation and conservation rules are removed from Ripe policies. Which is another deregulation signal I do not expect from Ripe. From ripe at opteamax.de Mon Aug 12 13:54:29 2013 From: ripe at opteamax.de (Opteamax GmbH - RIPE-Team) Date: Mon, 12 Aug 2013 13:54:29 +0200 Subject: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <5208C860.8000603@opdop.net> References: <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <855077AC3D7A7147A7570370CA01ECD248E711@SUEX10-mbx-10.ad.syr.edu> <520771E8.4080702@opdop.net> <855077AC3D7A7147A7570370CA01ECD2499D27@SUEX10-mbx-10.ad.syr.edu> <5208C860.8000603@opdop.net> Message-ID: Sylvain Vallerot schrieb: > > >On 11/08/2013 22:37, Milton Mueller wrote: >> Sylvain, the price in a market is not known in advance. I will be set >by >> competitive bidding and reflect supply and demand. I don't know where >you >> got this 1,75 Euro number > >Until complete /8 depletion a LIR cost is 1800 ?/annum to easily get >a /22 that is 1024 addresses. > >1800 / 1024 = 1.75 ? per address and per year. This calculation is IMHO a little to simple, as each legal entity may become only once LIR. So you'd also need to add the costs of setting up some more legal entities ... > > > >My point was this 1.75 cost-price is low enough to allow commercial >abuses if the fair distribution, documentation and conservation rules >are removed from Ripe policies. > >Which is another deregulation signal I do not expect from Ripe. Abuse and missuse of setting up LIRs is not a question for adress-policy but for rules how to become LIR and I think that these rules are already well defined, to prevent such abuse. Best Regards Jens From sylvain.vallerot at opdop.net Mon Aug 12 22:51:57 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Mon, 12 Aug 2013 22:51:57 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <51FF3E80.6000308@fud.no> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE69BC.1080503@fud.no> <51FE96DC.8000304@umn.edu> <51FEA776.40506@fud.no> <51FEADC6.4090007@umn.edu> <51FEB203.8070502@fud.no> <51FEBEDE.8000809@umn.edu> <51FED311.3090007@fud.no> <5FBC4E3C-6A16-47BA-AB74-6CC27403383E@virtualized.org> <51FF3E80.6000308@fud.no> Message-ID: <52094AED.8080601@opdop.net> Hi, Since I did not mention it clearly so far, please let me state *i do not support 2013-3*. Unfortunately the late amendments proposed here to reach a consensus look like cosmetics to me, and do not address many of the objections that were raised here. On 05/08/2013 07:56, Tore Anderson wrote: >> An "allocation pool" is the source from which resources are taken. >> Once a resource is allocated, it is removed from the allocation pool. >> As mentioned in 2050bis, "the pools from which these resources are >> allocated are finite." Aren't allocation transfers to be considered as part of this pool, since they are (so far) supposed to be made of empty allocs, and subject to the same conditions than direct allocations from the Ripe NCC ? > The last /8 pool has a very blunt definition of "operational need"; it > equates it to 1024 addresses. The "giggle test" applied to this pool is > essentially ?do you need anything at all? yes/no?. The current version > of 2013-03 proposes to remove this giggle test (but not the > one-size-fits-all definition of "operational need"). That "one-size-fits-all" is a myth because of allocation transfer mechanism in my opinion. And also because of the PI to PA migration projet, BTW. But also 2013-3 does not apply to such a small space, since, as Tore said, in another mail in this thread the "few" returns to the pool since "depletion" amount to about 4,600 /22s (to be compared to the 16,000 remaining ones in the Ripe's pool). Last /8 policy being set in order to deal with scarcity of the public ressource I guess the importance of the ressource is a point everyone admits (and no one knows how long it will remain vital). However when I read through discussions here I feel like a "come on, IPv4 is over, let's just stop the administrative burden", which reminds me the last days at school before holidays when nobody was minding about being still nor teaching or learning since it was the end anyway... Which makes me ask two questions 1. why should Ripe NCC consider *now* that these rare ressources need less attention and protection than previous ones, and not to be treated in respect to previous conservation principles, since these quite free and subject-to-be-returned addresses do not represent a ridiculous pool ? Turned another way : when did reducing charges become more important than the conservation goal ? 2. why, if IPv4 free pools were completely depleted, would Ripe NCC be discharged of the responsability to supervise assignments for what still is a vital and public ressource (yes they are, despite AW made it much easier for everyone) ? It might be a wrong impression really, and sorry for that but I feel like if Ripe NCC would not really want to mind with IPv4 anymore, and just wanted to turn away, being OK to just drop responsability to the market, whatever happens. Hope I'm wrong. Best regards, Sylvain From sander at steffann.nl Mon Aug 12 23:03:32 2013 From: sander at steffann.nl (Sander Steffann) Date: Mon, 12 Aug 2013 23:03:32 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <52094AED.8080601@opdop.net> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE69BC.1080503@fud.no> <51FE96DC.8000304@umn.edu> <51FEA776.40506@fud.no> <51FEADC6.4090007@umn.edu> <51FEB203.8070502@fud.no> <51FEBEDE.8000809@umn.edu> <51FED311.3090007@fud.no> <5FBC4E3C-6A16-47BA-AB74-6CC27403383E@virtualized.org> <51FF3E80.6000308@fud.no> <52094AED.8080601@opdop.net> Message-ID: Hi, > It might be a wrong impression really, and sorry for that but I feel > like if Ripe NCC would not really want to mind with IPv4 anymore Just making one important point here: the RIPE NCC doesn't want anything here. The community / this working group sets the policies, not the RIPE NCC. They only implement them once this working group declares consensus on the proposed policy. Cheers, Sander APWG co-chair From tore at fud.no Mon Aug 12 23:18:35 2013 From: tore at fud.no (Tore Anderson) Date: Mon, 12 Aug 2013 23:18:35 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: <52094AED.8080601@opdop.net> References: <51EF95B3.4030705@fud.no> <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE69BC.1080503@fud.no> <51FE96DC.8000304@umn.edu> <51FEA776.40506@fud.no> <51FEADC6.4090007@umn.edu> <51FEB203.8070502@fud.no> <51FEBEDE.8000809@umn.edu> <51FED311.3090007@fud.no> <5FBC4E3C-6A16-47BA-AB74-6CC27403383E@virtualized.org> <51FF3E80.6000308@fud.no> <52094AED.8080601@opdop.net> Message-ID: <5209512B.4040204@fud.no> >>> An "allocation pool" is the source from which resources are taken. >>> Once a resource is allocated, it is removed from the allocation pool. >>> As mentioned in 2050bis, "the pools from which these resources are >>> allocated are finite." > > Aren't allocation transfers to be considered as part of this pool, No. While you incorrectly attributed the above quote to me, it was actually written by one of the authors of 2050bis. Tore From sylvain.vallerot at opdop.net Mon Aug 12 23:26:35 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Mon, 12 Aug 2013 23:26:35 +0200 Subject: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up) In-Reply-To: References: <51EFD4CC.9000006@fud.no> <965997CB-07D2-49B9-BD9A-74E230F13724@gmail.com> <51F005B9.3050408@fud.no> <9B5CCA06-8857-40F6-ADAF-EFE870F54F1B@gmail.com> <20130725102841.GM65295@Space.Net> <51F12B45.2010603@inex.ie> <51F139B7.9060703@fud.no> <51F15E60.5000003@inex.ie> <51F18141.1080609@fud.no> <33EAE2DB-97B3-4399-890A-A56FC59992F5@steffann.nl> <51F91087.5040104@linx.net> <51FA0260.8050303@fud.no> <51FA8BB3.60202@inex.ie> <51FA9A72.3040708@fud.no> <51FE59ED.4000004@umn.edu> <51FE69BC.1080503@fud.no> <51FE96DC.8000304@umn.edu> <51FEA776.40506@fud.no> <51FEADC6.4090007@umn.edu> <51FEB203.8070502@fud.no> <51FEBEDE.8000809@umn.edu> <51FED311.3090007@fud.no> <5FBC4E3C-6A16-47BA-AB74-6CC27403383E@virtualized.org> <51FF3E80.6000308@fud.no> <52094AED.8080601@opdop.net> Message-ID: <5209530B.1030802@opdop.net> On 12/08/2013 23:03, Sander Steffann wrote: > Hi, > >> It might be a wrong impression really, and sorry for that but I feel >> like if Ripe NCC would not really want to mind with IPv4 anymore > > Just making one important point here: the RIPE NCC doesn't want anything > here. The community / this working group sets the policies, not the RIPE > NCC. They only implement them once this working group declares consensus > on the proposed policy. Agreed. But since I do not want to project my perceptions as intents on someone in particular either... Please replace subject "Ripe NCC" by a subject "the proposal". From ingrid at ripe.net Wed Aug 14 10:47:37 2013 From: ingrid at ripe.net (Ingrid Wijte) Date: Wed, 14 Aug 2013 10:47:37 +0200 Subject: [address-policy-wg] Draft proposal: Guidance Requested: Reassigning Referenced ASNs Message-ID: <520B4429.4080805@ripe.net> Dear colleagues, Thank you for your feedback on this issue. Based on the input we have received we propose taking the following action: - The RIPE NCC will send an email to the maintainer and contacts of the RIPE Database objects in which the returned AS numbers are referenced, asking for the reference to be removed. - The RIPE NCC will send three additional reminders, at intervals of three weeks from each other, for a total of four emails. - If after four emails the reference is still in place, the RIPE NCC will update the RIPE Database object itself, removing the reference. - If the reference is being recreated within one month from deletion (possibly due to automatic updates), the RIPE NCC will contact the organisation through means of communication other than email. The total number of RIPE Database objects that reference returned AS numbers is currently about 2000. All references are in the policy attributes of aut-num objects. No route(6) objects are involved. Thank you again and best regards, Ingrid Wijte RIPE NCC From denis at ripe.net Wed Aug 14 15:50:43 2013 From: denis at ripe.net (Denis Walker) Date: Wed, 14 Aug 2013 15:50:43 +0200 Subject: [address-policy-wg] Draft proposal: Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <520B4429.4080805@ripe.net> References: <520B4429.4080805@ripe.net> Message-ID: <520B8B33.8000403@ripe.net> Dear Colleagues Following this thread I see many comments about 'expected' or 'understood' behaviour of the RIPE Database software. I would like to clarify these points with a clear statement of what the software does and does not do. In this email I won't touch on any of the issues under discussion or suggested solutions. It is just a technical summary of business rules. In general there are very few checks on AS numbers in the various RPSL attributes where they can be used. This was a deliberate and intentional aspect of the design of the first RPSL based RIPE Database software back in the late nineties. At that time it was considered too complicated and too difficult to manage any cleanup. If strict rules had been enforced without the corresponding cleanup process, it would not be possible to delete an aut-num object. What can be done? -Only RIPE NCC can create and delete an aut-num object from the ASN ranges allocated for use in the RIPE region by IANA -Anyone can create and delete aut-num objects from non RIPE ASN ranges -Any ASN can be referenced in any appropriate attribute in an aut-num object, regardless of region or if the referenced aut-num object exists -Any referenced ASN can be removed from an aut-num regardless of the existence of the referenced aut-num -An aut-num object can be deleted regardless of any reference in any attribute of any other object (aut-num, route, route6, sets) For example AS1 can be deleted even when these objects exist with these references: aut-num: AS2 import: from AS1 export: to AS1 route: 1.1.1.1/16 origin: AS1 route6: 2001:600::/48 origin: AS1 as-set: AS-LIST:AS1 members: AS1 -An aut-num object can be created regardless of any references in any other object -Any set object can be created referencing any ASN in the (hierarchical) set name regardless of the existence of the referenced aut-num -Any ASN can be referenced in a "members:" attribute of any set regardless of the existence of the referenced aut-num What cannot be done? -Users cannot (accidentally) delete their RIPE ASN aut-num object -A route or route6 object cannot be created without authorisation from the originating aut-num and address space, or from an exact matching or less specific route(6) -A set object cannot be deleted if an aut-num references it in a "member-of:" attribute. -You cannot add a "member-of:" to an aut-num and reference a non existing set -You cannot remove a mntner from the "mnt-by:" of an aut-num if that mntner is a "mbrs-by-ref:" of a set that the aut-num is a member of Regards, Denis Walker Business Analyst RIPE NCC Database Team On 14/08/2013 10:47, Ingrid Wijte wrote: > Dear colleagues, > > Thank you for your feedback on this issue. Based on the input we have > received we propose taking the following action: > > - The RIPE NCC will send an email to the maintainer and contacts of the > RIPE Database objects in which the returned AS numbers are referenced, > asking for the reference to be removed. > - The RIPE NCC will send three additional reminders, at intervals of > three weeks from each other, for a total of four emails. > - If after four emails the reference is still in place, the RIPE NCC > will update the RIPE Database object itself, removing the reference. > - If the reference is being recreated within one month from deletion > (possibly due to automatic updates), the RIPE NCC will contact the > organisation through means of communication other than email. > > The total number of RIPE Database objects that reference returned AS > numbers is currently about 2000. All references are in the policy > attributes of aut-num objects. No route(6) objects are involved. > > Thank you again and best regards, > > Ingrid Wijte > RIPE NCC > > From swmike at swm.pp.se Wed Aug 14 16:38:53 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 14 Aug 2013 16:38:53 +0200 (CEST) Subject: [address-policy-wg] regarding housecleaning efforts in absurdum Message-ID: First and foremost, I must say I am all for keeping the database up to date and making sure all resources are documented correctly. However, I know of at least one specific case where a PI network that was operationally handed over around the year 2000 (MNT object etc), is currently properly documented and the operational holder is willing to do everything needed to become the properly documented holder, but can't, because he can't produce transfer documents by the company initially holding it, because that company doesn't have any operational staff anymore. The staff at the time the PI network was operationally transfered is available, but isn't currently employed by the original company so they can't sign the required paperwork on the original company letterhead. RIPE NCC is now saying they're going to de-register the PI network and reclaim it because transfer documents for the handover done 13 years ago can't be produced. I think this is wrong. There should be some kind of statue of limitation on time for producing documents. The dispute isn't between the original company and the current operational holder, the dispute is solely between RIPE NCC and the current operational holder. What policy documents need to change for this to happen? -- Mikael Abrahamsson email: swmike at swm.pp.se From nick at inex.ie Wed Aug 14 16:57:40 2013 From: nick at inex.ie (Nick Hilliard) Date: Wed, 14 Aug 2013 15:57:40 +0100 Subject: [address-policy-wg] regarding housecleaning efforts in absurdum In-Reply-To: References: Message-ID: <520B9AE4.9000700@inex.ie> On 14/08/2013 15:38, Mikael Abrahamsson wrote: > What policy documents need to change for this to happen? Does this need to be handled via a policy change? I.e. has this been escalated inside the RIPE NCC and if that was unsuccessful, handed over to the arbitration panel for their opinion? Nick From swmike at swm.pp.se Wed Aug 14 17:08:31 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 14 Aug 2013 17:08:31 +0200 (CEST) Subject: [address-policy-wg] regarding housecleaning efforts in absurdum In-Reply-To: <520B9AE4.9000700@inex.ie> References: <520B9AE4.9000700@inex.ie> Message-ID: On Wed, 14 Aug 2013, Nick Hilliard wrote: > Does this need to be handled via a policy change? I.e. has this been > escalated inside the RIPE NCC and if that was unsuccessful, handed over > to the arbitration panel for their opinion? No, that hasn't happened because the person didn't know about it. Personally I dislike a policy that requires someone to know innards of RIPE NCC in order to get reasonable treatment. As far as I can tell, the hostmaster in question didn't offer these alternatives. The only alternatives were "produce documents on original companys letterhead authorizing the transfer" and when the response was that it can't be done (with a reasonable explanation), the only path forward was said to be reclamation of the resource or to become LIR himself. No talk about escalation path or "arbitration panel". How are "normal" people going to know about this? -- Mikael Abrahamsson email: swmike at swm.pp.se From ingrid at ripe.net Wed Aug 14 17:10:17 2013 From: ingrid at ripe.net (Ingrid Wijte) Date: Wed, 14 Aug 2013 17:10:17 +0200 Subject: [address-policy-wg] regarding housecleaning efforts in absurdum In-Reply-To: References: Message-ID: <520B9DD9.5030907@ripe.net> Dear Mikael, Registration Services is contacting many 2007-01 resources daily and each case is different. Could you please contact me off-list and inform me which resources you are referring to so we can look at the process followed and the documentation provided? Thanks in advance, Ingrid Wijte RIPE NCC On 8/14/13 4:38 PM, Mikael Abrahamsson wrote: > > First and foremost, I must say I am all for keeping the database up to > date and making sure all resources are documented correctly. > > However, I know of at least one specific case where a PI network that > was operationally handed over around the year 2000 (MNT object etc), > is currently properly documented and the operational holder is willing > to do everything needed to become the properly documented holder, but > can't, because he can't produce transfer documents by the company > initially holding it, because that company doesn't have any > operational staff anymore. The staff at the time the PI network was > operationally transfered is available, but isn't currently employed by > the original company so they can't sign the required paperwork on the > original company letterhead. > > RIPE NCC is now saying they're going to de-register the PI network and > reclaim it because transfer documents for the handover done 13 years > ago can't be produced. > > I think this is wrong. There should be some kind of statue of > limitation on time for producing documents. The dispute isn't between > the original company and the current operational holder, the dispute > is solely between RIPE NCC and the current operational holder. > > What policy documents need to change for this to happen? > From nick at inex.ie Wed Aug 14 17:20:18 2013 From: nick at inex.ie (Nick Hilliard) Date: Wed, 14 Aug 2013 16:20:18 +0100 Subject: [address-policy-wg] regarding housecleaning efforts in absurdum In-Reply-To: References: <520B9AE4.9000700@inex.ie> Message-ID: <520BA032.1080204@inex.ie> On 14/08/2013 16:08, Mikael Abrahamsson wrote: > No, that hasn't happened because the person didn't know about it. It's the same as dispute resolution everywhere else: if there is an issue which isn't resolved on the front desk, then you escalate. The Arbitration / dispute resolution process is not as well known as it might be, but it has existed for donkeys years: http://www.ripe.net/lir-services/ncc/legal/arbitration > Personally I dislike a policy that requires someone to know innards of RIPE > NCC in order to get reasonable treatment. As far as I can tell, the > hostmaster in question didn't offer these alternatives. It sounds like there may be scope for the IPRA team to educate PI holders on their options, and this might be something that the RIPE NCC management to think about. This will end up being fairer for the PI holders, and will also protect the RIPE NCC from allegations of unfair practice. Phase three of 2007-01 will produce difficult cases. Could someone from the RIPE NCC comment on general procedures surrounding what they might do in circumstances where there the holdership of the PI resources is unclear? And what the escalation options are? Nick From niall.oreilly at ucd.ie Wed Aug 14 17:16:01 2013 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Wed, 14 Aug 2013 16:16:01 +0100 Subject: [address-policy-wg] regarding housecleaning efforts in absurdum In-Reply-To: References: Message-ID: On 14 Aug 2013, at 15:38, Mikael Abrahamsson wrote: > RIPE NCC is now saying they're going to de-register the PI network and reclaim it because transfer documents for the handover done 13 years ago can't be produced. > > I think this is wrong. Your reaction seems reasonable, but I'm only aware of your side of the story so far. > There should be some kind of statue of limitation on time for producing documents. The dispute isn't between the original company and the current operational holder, the dispute is solely between RIPE NCC and the current operational holder. > > What policy documents need to change for this to happen? I'm not certain that this can be dealt with by changing policy documents. The problem seems to be one of procedure, and to need to be escalated to someone at the RIPE NCC who has authority to make the call that this is (if so it be) a case where following the standard procedure is inappropriate and to decide what is the right thing to do. I'm pretty sure that such a someone can be found at the RIPE NCC. If you've already sought to have the problem escalated to that level, and have been frustrated, it's probably the moment for your posting on this list. Otherwise, I'ld see your posting as premature. I hope this helps Niall O'Reilly From jim at rfc1035.com Wed Aug 14 17:41:52 2013 From: jim at rfc1035.com (Jim Reid) Date: Wed, 14 Aug 2013 16:41:52 +0100 Subject: [address-policy-wg] regarding housecleaning efforts in absurdum In-Reply-To: References: Message-ID: <313308EE-B2FC-4664-AED4-E1C3718E34D2@rfc1035.com> On 14 Aug 2013, at 15:38, Mikael Abrahamsson wrote: > RIPE NCC is now saying they're going to de-register the PI network and reclaim it because transfer documents for the handover done 13 years ago can't be produced. > > I think this is wrong. +1. OTOH the company which originally got the space still exists. So there's no obvious reason why some sort of paperwork can't be produced to give the NCC enough of a comfort level to get these resources transferred to their current user/operator. > There should be some kind of statue of limitation on time for producing documents. I disagree. For one thing, whatever time limit gets chosen -- good luck getting consensus on that! -- will be abitrary. And anyone hoping to sneakily inherit/acquire space would just need to wait until that time interval had passed before claiming "lack of documentation" as the pretext for changing a MNT object or whatever. That said, these sorts of historical issues do crop up from time to time and can usually be solved. For the case you outlined, it seems like some common sense needs to be applied and/or there's been a misunderstanding or two along the way. IMO that's not strong enough justification for making a policy change. > The dispute isn't between the original company and the current operational holder, the dispute is solely between RIPE NCC and the current operational holder. Without knowing the specific details, it's hard to know if that's the case or not. IIUC, in these cases the NCC generally tries to take a more pragmatic approach. Surely there's somebody at the original company who can put something in writing to confirm that the address space moved when the network was transferred all those years ago? For all we know an officer of that company might have been in contact with the NCC and told a different story from the one given by the current user of the space. From swmike at swm.pp.se Wed Aug 14 17:48:38 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 14 Aug 2013 17:48:38 +0200 (CEST) Subject: [address-policy-wg] regarding housecleaning efforts in absurdum In-Reply-To: <313308EE-B2FC-4664-AED4-E1C3718E34D2@rfc1035.com> References: <313308EE-B2FC-4664-AED4-E1C3718E34D2@rfc1035.com> Message-ID: On Wed, 14 Aug 2013, Jim Reid wrote: > IIUC, in these cases the NCC generally tries to take a more pragmatic > approach. Well, that didn't seem to happen in this case. > Surely there's somebody at the original company who can put something in > writing to confirm that the address space moved when the network was > transferred all those years ago? *sigh*. Yes, that is the stance RIPE NCC has taken it seems. And when that person who *surely* exists can't be produced or won't sign because they know nothing about this, the space will be reclaimed. > For all we know an officer of that company might have been in contact > with the NCC and told a different story from the one given by the > current user of the space. Speculation doesn't really help. -- Mikael Abrahamsson email: swmike at swm.pp.se From gert at space.net Thu Aug 15 22:27:06 2013 From: gert at space.net (Gert Doering) Date: Thu, 15 Aug 2013 22:27:06 +0200 Subject: [address-policy-wg] 2013-03 Review Period extended until 14 August (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: Message-ID: <20130815202706.GA1838@Space.Net> Dear APWG, On Mon, Aug 05, 2013 at 10:32:44AM +0200, Emilio Madaio wrote: > The Review Period for the proposal 2013-03, "No Need - Post-Depletion > Reality Adjustment and Cleanup", has been extended until 14 August. The extended review period has ended. Given your feedback, the discussions between Filiz, Malcolm and Tore, and the reactions to the amendments to the proposal proposed by Tore (= none, which I take as agreement) the WG chairs and the proposer have decided to go for a version 3.0 of the proposal. This new text will now undergo a new Impact Analysis at the RIPE NCC, and as soon as this is done, a new review period will start. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From ingrid at ripe.net Fri Aug 16 16:02:03 2013 From: ingrid at ripe.net (Ingrid Wijte) Date: Fri, 16 Aug 2013 16:02:03 +0200 Subject: [address-policy-wg] regarding housecleaning efforts in absurdum In-Reply-To: <520BA032.1080204@inex.ie> References: <520B9AE4.9000700@inex.ie> <520BA032.1080204@inex.ie> Message-ID: <520E30DB.3010006@ripe.net> Dear Nick and others, As requested, I am writing to provide clarification about the process the RIPE NCC follows to establish the legitimate holder of PI address space, and to outline how a case may be escalated. As mentioned earlier, Registration Services is currently in contact with hundreds of potential PI resource holders. For the most part, the more straightforward cases have already been resolved. What is left now are those cases where things are not quite so clear-cut: a resource may have changed hands several times, and there is often no paper trail documenting this. In many cases, these resources have never been announced or have not been announced for a very long time, etc. Every potential resource holder is given three months to produce documentation that demonstrates the legitimacy of their claim. We sometimes give extensions when we feel that good progress is being made. However, at some point we do have to start the de-registration procedure. From here, the potential resource holder still has an additional 90 days to find the required documentation. We explore a number of options to find a satisfactory solution. In cases where all available options have been exhausted but the IPRA feels reasonably certain about the legitimacy of the claim, they may escalate the request to management for a final decision. Similarly, the IPRA may also escalate the matter, either at the request of the other party or following internal procedures if the communication becomes difficult. If no agreement can be reached even after the matter has been escalated, we inform the potential resource holder that they can ask their potential sponsoring LIR to object to our decision via the Arbiters Panel. During arbitration, all ongoing processes are frozen. You can find out more about the RIPE NCC's Arbitration Process here: http://www.ripe.net/lir-services/ncc/legal/arbitration Finally, I would like to highlight that out of the thousands of resources we have dealt with as part of the 2007-01 project, very few cases that have come this far. In the overwhelming majority of (legitimate) cases, we are able to resolve matters satisfactorily for both parties. Regarding the request that started this thread, please note that we will do our best to resolve this matter with the other party. Kind regards Ingrid Wijte RIPE NCC On 8/14/13 5:20 PM, Nick Hilliard wrote: > On 14/08/2013 16:08, Mikael Abrahamsson wrote: >> No, that hasn't happened because the person didn't know about it. > It's the same as dispute resolution everywhere else: if there is an issue > which isn't resolved on the front desk, then you escalate. The Arbitration > / dispute resolution process is not as well known as it might be, but it > has existed for donkeys years: > > http://www.ripe.net/lir-services/ncc/legal/arbitration > >> Personally I dislike a policy that requires someone to know innards of RIPE >> NCC in order to get reasonable treatment. As far as I can tell, the >> hostmaster in question didn't offer these alternatives. > It sounds like there may be scope for the IPRA team to educate PI holders > on their options, and this might be something that the RIPE NCC management > to think about. This will end up being fairer for the PI holders, and will > also protect the RIPE NCC from allegations of unfair practice. Phase three > of 2007-01 will produce difficult cases. > > Could someone from the RIPE NCC comment on general procedures surrounding > what they might do in circumstances where there the holdership of the PI > resources is unclear? And what the escalation options are? > > Nick > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Fri Aug 16 16:14:12 2013 From: gert at space.net (Gert Doering) Date: Fri, 16 Aug 2013 16:14:12 +0200 Subject: [address-policy-wg] 2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: References: Message-ID: <20130816141412.GA15113@Space.Net> Dear AP WG, in the heated discussion about 2013-03 ("no need"), I think this proposal might have escaped your attention. On Mon, Jul 22, 2013 at 03:08:26PM +0200, Emilio Madaio wrote: > A proposed change to RIPE Policy Document ripe-592, "IPv4 Address > Allocation and Assignment Policies for the RIPE NCC Service Region", > is now available for discussion. > > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2013-05/ This is an amendment to the transfer policy which solves real-world problems for real-world LIRs - namely: abandon the requirement that a transferred block of addresses must be empty, because that conflicts with real-world scenarios, like a customer of a given LIR opening his own LIR later on, both parties agree to transfer the addresses the customer uses to the new LIR (= the customer's LIR of the customer using the addresses already), and the NCC then tells them "no, you can't do that". The proposal is in *discussion* phase, so if you want to discuss, now is the time. (If you just "+1" it, that's also a clear signal :-) ). regards, Gert Doering, APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From nigel at titley.com Fri Aug 16 16:18:53 2013 From: nigel at titley.com (Nigel Titley) Date: Fri, 16 Aug 2013 15:18:53 +0100 Subject: [address-policy-wg] 2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: <20130816141412.GA15113@Space.Net> References: <20130816141412.GA15113@Space.Net> Message-ID: <520E34CD.9000302@titley.com> On 16/08/2013 15:14, Gert Doering wrote: > Dear AP WG, > > in the heated discussion about 2013-03 ("no need"), I think this proposal > might have escaped your attention. > > On Mon, Jul 22, 2013 at 03:08:26PM +0200, Emilio Madaio wrote: >> A proposed change to RIPE Policy Document ripe-592, "IPv4 Address >> Allocation and Assignment Policies for the RIPE NCC Service Region", >> is now available for discussion. >> >> >> You can find the full proposal at: >> >> https://www.ripe.net/ripe/policies/proposals/2013-05/ > > This is an amendment to the transfer policy which solves real-world > problems for real-world LIRs - namely: abandon the requirement that a > transferred block of addresses must be empty, because that conflicts > with real-world scenarios, like a customer of a given LIR opening > his own LIR later on, both parties agree to transfer the addresses > the customer uses to the new LIR (= the customer's LIR of the customer > using the addresses already), and the NCC then tells them "no, you > can't do that". > > The proposal is in *discussion* phase, so if you want to discuss, now is > the time. (If you just "+1" it, that's also a clear signal :-) ). > I think this is actually quite sensible, so +1 Nigel From niall.oreilly at ucd.ie Fri Aug 16 16:40:55 2013 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Fri, 16 Aug 2013 15:40:55 +0100 Subject: [address-policy-wg] 2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: <520E34CD.9000302@titley.com> References: <20130816141412.GA15113@Space.Net> <520E34CD.9000302@titley.com> Message-ID: On 16 Aug 2013, at 15:18, Nigel Titley wrote: > On 16/08/2013 15:14, Gert Doering wrote: >>> >>> https://www.ripe.net/ripe/policies/proposals/2013-05/ >> >> This is an amendment to the transfer policy which solves real-world >> problems for real-world LIRs - namely: abandon the requirement that a >> transferred block of addresses must be empty, because that conflicts >> with real-world scenarios, like a customer of a given LIR opening >> his own LIR later on, both parties agree to transfer the addresses >> the customer uses to the new LIR (= the customer's LIR of the customer >> using the addresses already), and the NCC then tells them "no, you >> can't do that". >> >> The proposal is in *discussion* phase, so if you want to discuss, now is >> the time. (If you just "+1" it, that's also a clear signal :-) ). >> > I think this is actually quite sensible, so +1 +1 from me too /Niall From frettled at gmail.com Fri Aug 16 16:41:21 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Fri, 16 Aug 2013 16:41:21 +0200 Subject: [address-policy-wg] 2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: References: Message-ID: On Mon, Jul 22, 2013 at 3:08 PM, Emilio Madaio wrote: > > > Dear Colleagues, > > A proposed change to RIPE Policy Document ripe-592, "IPv4 Address > Allocation and Assignment Policies for the RIPE NCC Service Region", > is now available for discussion. > > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2013-05/ > The proposal is very clear and easily read, and eminently sensible. I support it. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From boggits at gmail.com Fri Aug 16 16:42:32 2013 From: boggits at gmail.com (boggits) Date: Fri, 16 Aug 2013 15:42:32 +0100 Subject: [address-policy-wg] 2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: References: Message-ID: On 16 August 2013 15:41, Jan Ingvoldstad wrote: > > On Mon, Jul 22, 2013 at 3:08 PM, Emilio Madaio wrote: >> >> https://www.ripe.net/ripe/policies/proposals/2013-05/ > > > The proposal is very clear and easily read, and eminently sensible. > > I support it. +1 -- James Blessing 07989 039 476 From dcunningham at airspeed.ie Fri Aug 16 17:08:06 2013 From: dcunningham at airspeed.ie (Donal Cunningham) Date: Fri, 16 Aug 2013 15:08:06 +0000 Subject: [address-policy-wg] 2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: References: Message-ID: > The proposal is very clear and easily read, and eminently sensible. > I support it. +1. D. -- Donal Cunningham IP Network Engineer, AirSpeed Telecom dcunningham at airspeed.ie | +353 1 428 7531 Airspeed Telecom From sylvain.vallerot at opdop.net Fri Aug 16 18:18:01 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Fri, 16 Aug 2013 18:18:01 +0200 Subject: [address-policy-wg] 2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: References: Message-ID: <520E50B9.8060607@opdop.net> On 16/08/2013 17:08, Donal Cunningham wrote: >> The proposal is very clear and easily read, and eminently sensible. >> I support it. > > +1. +1 Regards, SVT From farmer at umn.edu Fri Aug 16 20:20:17 2013 From: farmer at umn.edu (David Farmer) Date: Fri, 16 Aug 2013 13:20:17 -0500 Subject: [address-policy-wg] 2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: <20130816141412.GA15113@Space.Net> References: <20130816141412.GA15113@Space.Net> Message-ID: <520E6D61.2030408@umn.edu> On 8/16/13 09:14 , Gert Doering wrote: > Dear AP WG, > > in the heated discussion about 2013-03 ("no need"), I think this proposal > might have escaped your attention. > > On Mon, Jul 22, 2013 at 03:08:26PM +0200, Emilio Madaio wrote: >> A proposed change to RIPE Policy Document ripe-592, "IPv4 Address >> Allocation and Assignment Policies for the RIPE NCC Service Region", >> is now available for discussion. >> >> >> You can find the full proposal at: >> >> https://www.ripe.net/ripe/policies/proposals/2013-05/ > > > This is an amendment to the transfer policy which solves real-world > problems for real-world LIRs - namely: abandon the requirement that a > transferred block of addresses must be empty, because that conflicts > with real-world scenarios, like a customer of a given LIR opening > his own LIR later on, both parties agree to transfer the addresses > the customer uses to the new LIR (= the customer's LIR of the customer > using the addresses already), and the NCC then tells them "no, you > can't do that". > > The proposal is in *discussion* phase, so if you want to discuss, now is > the time. (If you just "+1" it, that's also a clear signal :-) ). > > regards, > > Gert Doering, > APWG chair I support the intent of the proposal, there are situations where it seems reasonable to allow transfers of blocks with end users in them, and the current blanket exclusion prevents this. However, I also support the original intent of the language that would be removed. I believe the intent of the original language was to prevent an LIR selling off a block that has active End Users in it, at least without notice or consent, etc... For the example case given in the proposal, it seems that consent should be readily obtainable. So, would a better solution be to add "without consent of the End User(s)" to the current text. This provides flexibility without abandoning the protection the current text provides to End Users. Thanks. -- ================================================ 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 randy at psg.com Fri Aug 16 21:49:52 2013 From: randy at psg.com (Randy Bush) Date: Sat, 17 Aug 2013 04:49:52 +0900 Subject: [address-policy-wg] 2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: <20130816141412.GA15113@Space.Net> References: <20130816141412.GA15113@Space.Net> Message-ID: >> https://www.ripe.net/ripe/policies/proposals/2013-05/ the internet will come to an end if this is adopted !!!! oops! wrong proposal. +1 randy From tim at haitabu.net Fri Aug 16 21:57:44 2013 From: tim at haitabu.net (Tim Kleefass) Date: Fri, 16 Aug 2013 21:57:44 +0200 Subject: [address-policy-wg] 2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: <520E34CD.9000302@titley.com> References: <20130816141412.GA15113@Space.Net> <520E34CD.9000302@titley.com> Message-ID: <520E8438.302@haitabu.net> On 16.08.2013 4:18 PM, Nigel Titley wrote: >> The proposal is in *discussion* phase, so if you want to discuss, now is >> the time. (If you just "+1" it, that's also a clear signal :-) ). >> > I think this is actually quite sensible, so +1 +1 -tim From sp at iphh.net Fri Aug 16 23:13:34 2013 From: sp at iphh.net (Sascha E. Pollok) Date: Fri, 16 Aug 2013 23:13:34 +0200 (CEST) Subject: [address-policy-wg] 2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: <520E6D61.2030408@umn.edu> References: <20130816141412.GA15113@Space.Net> <520E6D61.2030408@umn.edu> Message-ID: David, thanks for your comments. On Fri, 16 Aug 2013, David Farmer wrote: >> in the heated discussion about 2013-03 ("no need"), I think this proposal >> might have escaped your attention. >> >> On Mon, Jul 22, 2013 at 03:08:26PM +0200, Emilio Madaio wrote: >>> A proposed change to RIPE Policy Document ripe-592, "IPv4 Address >>> Allocation and Assignment Policies for the RIPE NCC Service Region", >>> is now available for discussion. >>> >>> >>> You can find the full proposal at: >>> >>> https://www.ripe.net/ripe/policies/proposals/2013-05/ >> >> >> This is an amendment to the transfer policy which solves real-world >> problems for real-world LIRs - namely: abandon the requirement that a >> transferred block of addresses must be empty, because that conflicts >> with real-world scenarios, like a customer of a given LIR opening >> his own LIR later on, both parties agree to transfer the addresses >> the customer uses to the new LIR (= the customer's LIR of the customer >> using the addresses already), and the NCC then tells them "no, you >> can't do that". >> >> The proposal is in *discussion* phase, so if you want to discuss, now is >> the time. (If you just "+1" it, that's also a clear signal :-) ). >> >> regards, >> >> Gert Doering, >> APWG chair > > I support the intent of the proposal, there are situations where it seems > reasonable to allow transfers of blocks with end users in them, and the > current blanket exclusion prevents this. > > However, I also support the original intent of the language that would be > removed. I believe the intent of the original language was to prevent an LIR > selling off a block that has active End Users in it, at least without notice > or consent, etc... > > For the example case given in the proposal, it seems that consent should be > readily obtainable. So, would a better solution be to add "without consent > of the End User(s)" to the current text. This provides flexibility without > abandoning the protection the current text provides to End Users. In the rationale I used this expressions: "... it should be possible to transfer a continuous block from one LIR into an allocation and correct assignments of the new LIR while preserving the assignments." - I wanted to make clear that the new LIR would of course inherit End-User assignments and also the responsibilities for them. You think the End-Users should get involved into a planned transfer of an allocation to a new LIR? It might not be realistic to ask hundreds of End-Users for permission to transfer an allocation. Is that what you were suggesting? Thanks Sascha -- Sascha E. Pollok E-Mail: sp at iphh.net Manager Network Design and Operations Tel: +49 (0)40 374919-10 IPHH Internet Port Hamburg GmbH Fax: +49 (0)40 374919-29 Wendenstrasse 408 AG Hamburg, HRB 76071 20537 Hamburg, Germany CEO: Axel G. Kroeger From tore at fud.no Sat Aug 17 00:32:08 2013 From: tore at fud.no (Tore Anderson) Date: Sat, 17 Aug 2013 00:32:08 +0200 Subject: [address-policy-wg] 2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: <520E6D61.2030408@umn.edu> References: <20130816141412.GA15113@Space.Net> <520E6D61.2030408@umn.edu> Message-ID: <520EA868.2050303@fud.no> * David Farmer > I support the intent of the proposal, there are situations where it > seems reasonable to allow transfers of blocks with end users in them, > and the current blanket exclusion prevents this. +1 > However, I also support the original intent of the language that would > be removed. I believe the intent of the original language was to > prevent an LIR selling off a block that has active End Users in it, at > least without notice or consent, etc... > > For the example case given in the proposal, it seems that consent should > be readily obtainable. So, would a better solution be to add "without > consent of the End User(s)" to the current text. This provides > flexibility without abandoning the protection the current text provides > to End Users. I don't see how this "protection" works in practise? If an LIR wants to get out of the internet registry business and sell off its allocations, it can always just purge them of assignments first (even with your requirement in place). The End Users probably won't be very pleased about being kicked out on the street so to speak, but c'est la vie... Tore From farmer at umn.edu Sat Aug 17 01:28:13 2013 From: farmer at umn.edu (David Farmer) Date: Fri, 16 Aug 2013 18:28:13 -0500 Subject: [address-policy-wg] 2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: <520EA868.2050303@fud.no> References: <20130816141412.GA15113@Space.Net> <520E6D61.2030408@umn.edu> <520EA868.2050303@fud.no> Message-ID: <520EB58D.7050607@umn.edu> On 8/16/13 17:32 , Tore Anderson wrote: > * David Farmer > >> I support the intent of the proposal, there are situations where it >> seems reasonable to allow transfers of blocks with end users in them, >> and the current blanket exclusion prevents this. > > +1 > >> However, I also support the original intent of the language that would >> be removed. I believe the intent of the original language was to >> prevent an LIR selling off a block that has active End Users in it, at >> least without notice or consent, etc... >> >> For the example case given in the proposal, it seems that consent should >> be readily obtainable. So, would a better solution be to add "without >> consent of the End User(s)" to the current text. This provides >> flexibility without abandoning the protection the current text provides >> to End Users. > > I don't see how this "protection" works in practise? > > If an LIR wants to get out of the internet registry business and sell > off its allocations, it can always just purge them of assignments first > (even with your requirement in place). The End Users probably won't be > very pleased about being kicked out on the street so to speak, but c'est > la vie... If you really think it is OK for an LIR to drop an End User's assignments when every they want to, then why isn't it OK for RIPE to drop an LIR's allocations and auction them off to the highest bidders? C'est la vie and what's sauce for the goose is sauce for the gander too. Societal rules of conduct don't usually prevent anyone from breaking them, and many times people aren't directly punished for breaking these rules, but that doesn't mean society is a better place without such rules. 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 sylvain.vallerot at opdop.net Sat Aug 17 02:36:05 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Sat, 17 Aug 2013 02:36:05 +0200 Subject: [address-policy-wg] 2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: <520EA868.2050303@fud.no> References: <20130816141412.GA15113@Space.Net> <520E6D61.2030408@umn.edu> <520EA868.2050303@fud.no> Message-ID: <520EC575.8090209@opdop.net> Hi, On 17/08/2013 00:32, Tore Anderson wrote: > If an LIR wants to get out of the internet registry business and sell > off its allocations, it can always just purge them of assignments first > (even with your requirement in place). It looks to me that to break contracts with End-Users could be much more difficult for a LIR than just reselling these contracts to another LIR which would be forced to continue executing these contracts (maybe this is not true everywhere in the Ripe regions however). So this probably actually makes a difference, and good point for David, kind of a "protection" to the end users. Now, the question is, did the End Users conclude a contract with their LIR, that forbids him to resell this contract to another provider ? If yes, then the protections stands in the contrat. If not, should the Ripe policy (that does not require the End Users to agree) take care of such aspects of the relation between LIR and End User ? I don't think so, because this matter really seems (to me) to out exceed a Ripes' policy scope, for many reasons. The first of these reasons may be that End Users may have very different relations to their LIRs, and that the Ripe policy is not tying End Users, but only LIRs and Ripe. Another reason may be that we are not really sure that it would be a real protection for End Users to stop theyr LIR from transfering to another LIR. This could avoid them to have to renumber, by example. On the other hand it could be a company buying the IP space to stifle another concurrent company. But shouldn't courts be handling this actually ? So is such a limitation a real protection for End Users, or a dangerous rigidity that could avoid End Users to continue their activity ? Probably this is a too much complicated subject for Ripe policies to take part in a relation that is out of scope and involves a third party. From farmer at umn.edu Sat Aug 17 05:04:55 2013 From: farmer at umn.edu (David Farmer) Date: Fri, 16 Aug 2013 22:04:55 -0500 Subject: [address-policy-wg] 2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: References: <20130816141412.GA15113@Space.Net> <520E6D61.2030408@umn.edu> Message-ID: <520EE857.2010809@umn.edu> On 8/16/13 16:13 , Sascha E. Pollok wrote: > David, thanks for your comments. > > On Fri, 16 Aug 2013, David Farmer wrote: >> I support the intent of the proposal, there are situations where it >> seems reasonable to allow transfers of blocks with end users in them, >> and the current blanket exclusion prevents this. >> >> However, I also support the original intent of the language that would >> be removed. I believe the intent of the original language was to >> prevent an LIR selling off a block that has active End Users in it, at >> least without notice or consent, etc... >> >> For the example case given in the proposal, it seems that consent >> should be readily obtainable. So, would a better solution be to add >> "without consent of the End User(s)" to the current text. This >> provides flexibility without abandoning the protection the current >> text provides to End Users. > > In the rationale I used this expressions: > > "... it should be possible to transfer a continuous block from one LIR > into an allocation and correct assignments of the new LIR while > preserving the assignments." - I wanted to make clear that the new LIR > would of course inherit End-User assignments and also the > responsibilities for them. The whole sentence in the rationale was; In case a new LIR is created by a company that is currently using PA space from an existing LIR, it should be possible to transfer a continuous block from one LIR into an allocation and correct assignments of the new LIR while preserving the assignments. I think the first part adds significant context. I interpreted the transfer in question was to an organization that was previously assigned the block as an end user and is now the new LIR in question. I was simply saying in the use case presented "consent should be readily obtainable." In my opinion this use case provides clear justification for a transfer with the assignments in tact, but doesn't necessarily justify abandoning the original intent of the language, it can be accommodated without such a radical change. > You think the End-Users should get involved into a planned transfer of > an allocation to a new LIR? It might not be realistic to ask hundreds > of End-Users for permission to transfer an allocation. Is that what you > were suggesting? The specific use case provided in the rationale, as I interpret it, doesn't involve hundreds of End Users. Maybe I misunderstand or misinterpreted the use case. If there are other cases you want to cover maybe include some of the other use cases in the rationale as well. Maybe these other use cases would justify abandoning the original intent of the current language. Thanks. -- ================================================ 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 Sat Aug 17 09:45:08 2013 From: tore at fud.no (Tore Anderson) Date: Sat, 17 Aug 2013 09:45:08 +0200 Subject: [address-policy-wg] 2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: <520EB58D.7050607@umn.edu> References: <20130816141412.GA15113@Space.Net> <520E6D61.2030408@umn.edu> <520EA868.2050303@fud.no> <520EB58D.7050607@umn.edu> Message-ID: <520F2A04.1060105@fud.no> * David Farmer > On 8/16/13 17:32 , Tore Anderson wrote: >> If an LIR wants to get out of the internet registry business and sell >> off its allocations, it can always just purge them of assignments first >> (even with your requirement in place). The End Users probably won't be >> very pleased about being kicked out on the street so to speak, but c'est >> la vie... > > If you really think it is OK The direction *my* moral compass is pointing is irrelevant (and for the record not stated either). > for an LIR to drop an End User's assignments when every they want to, Our current IPv4 policy doesn't prohibit this, so it is indeed "OK" and sanctioned by our current IPv4 policy. It actually takes care to point out that PA assignments are *not* irrevocable: ?End Users requesting PA space should be given this or a similar warning: Assignment of this IP space is valid as long as the criteria for the original assignment are met and only for the duration of the service agreement between yourself and us. We have the right to reassign the address space to another user upon termination of this agreement or an agreed period thereafter. This means that you will have to re-configure the addresses of all equipment using this IP space if you continue to require global uniqueness of those addresses.? As I think Sylvain was saying too, the only true protection afforded an End User against having his assignments being revoked for whatever reason, is the contractual terms he has negotiated in the service agreement with his LIR. > then why isn't it OK for RIPE to drop an LIR's allocations and auction > them off to the highest bidders? Because that is not sanctioned by the RIPE Community's policies. > Societal rules of conduct don't usually prevent anyone from breaking > them, and many times people aren't directly punished for breaking these > rules, but that doesn't mean society is a better place without such rules. The proposal does not remove any social rules of conduct as far as I can tell. I think the proposal is fine as it is, and that tacking on a "the End Users must agree" condition isn't likely to accomplish anything that's actually helpful to the End Users. I think it would be more likely to either result in an ultimatum: "agree or be kicked out" (and if they do agree they'll probably end up being kicked out by the new allocation holder a few days later instead); or that the transferring LIR simply doesn't want the bother and instead just purges all assignments before the transfer is registered. In a nutshell: If the new holder's plans for the allocation doesn't include the old End Users, they're screwed anyway (regardless of 2013-05 being in place or not). However if the new holder does want to keep the old End Users and their assignments around, then this proposal is actually beneficial for all involved parties. Tore From randy at psg.com Sat Aug 17 11:11:34 2013 From: randy at psg.com (Randy Bush) Date: Sat, 17 Aug 2013 18:11:34 +0900 Subject: [address-policy-wg] 2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: <520F2A04.1060105@fud.no> References: <20130816141412.GA15113@Space.Net> <520E6D61.2030408@umn.edu> <520EA868.2050303@fud.no> <520EB58D.7050607@umn.edu> <520F2A04.1060105@fud.no> Message-ID: > If the new holder's plans for the allocation doesn't include the old > End Users, they're screwed anyway (regardless of 2013-05 being in > place or not). However if the new holder does want to keep the old > End Users and their assignments around, then this proposal is > actually beneficial for all involved parties. that's my read can we keep the nit-picking paranoia over in arin, please, where i don't read it. randy From sylvain.vallerot at opdop.net Sun Aug 18 01:41:21 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Sun, 18 Aug 2013 01:41:21 +0200 Subject: [address-policy-wg] 2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: <520F2A04.1060105@fud.no> References: <20130816141412.GA15113@Space.Net> <520E6D61.2030408@umn.edu> <520EA868.2050303@fud.no> <520EB58D.7050607@umn.edu> <520F2A04.1060105@fud.no> Message-ID: <52100A21.4020904@opdop.net> On 17/08/2013 09:45, Tore Anderson wrote: > The proposal does not remove any social rules of conduct as far as > I can tell. Social rules are bullshit when commercial contracts prevail on everything else. This is certainly not something I appreciate but it is the reality, and if on one hand we cannot do much about it, maybe on the other hand we could propose something more explicitely transparent and obvious for end users. Didn't Ripe "IPv4 alloc & assign" policy, for example, insist on making it super-clear for PI requesters, about the risks they are taking when requesting such ressources (and even ask for LIRs to confirm they made it clear in the request form) ? Is the risk smaller if End Users can be kicked from assigned IPs and they are not correctly informed about their (quite often really mistaken, as far as I can see) "owning" of the adresses they have base they business on ? So was it just a disclaimer or was it a warning to End Users saying "hey guys, watch it carefully". This is a point where I'm very glad to David for his remark, because maybe whe have a lack (but a responsability) in making things more transparent to End Users, beyond just delegating Ripes' workload on LIRs (which are not non-for-profit nor democratic structures). However, despite 2013-05 could look like an occasion to restore a bit of the missing protection, by allowing not empty allocs to be transferred *if* and *only if* some protection conditions are met, I am still not convinced this is dangerous in the general case (do operators want to sell their clients when they have another choice ?) Simply, sometimes suppleness is best for survival. So, still supporting 2013-05. Which doesn't mean we would'nt amend it another time with a more End User protecting general proposal. Definitely need more input for this, if someone has ideas about this (in another thread probably). Best regards, Sylvain From nick at inex.ie Sun Aug 18 18:56:27 2013 From: nick at inex.ie (Nick Hilliard) Date: Sun, 18 Aug 2013 17:56:27 +0100 Subject: [address-policy-wg] regarding housecleaning efforts in absurdum In-Reply-To: <520E30DB.3010006@ripe.net> References: <520B9AE4.9000700@inex.ie> <520BA032.1080204@inex.ie> <520E30DB.3010006@ripe.net> Message-ID: <5210FCBB.1050206@inex.ie> Hi Ingrid, Thanks for clarifying this. Would it be possible to put this information up on the web site? I had a quick look around, but couldn't find anything related to 2007-01 phase 3 procedures other than ripe-569. This document gave some information on the general process from the RIPE NCC point of view, but doesn't explain clearly what the End Users' rights were, or provide information about what escalation procedures are available. Nick On 16/08/2013 15:02, Ingrid Wijte wrote: > > Dear Nick and others, > > As requested, I am writing to provide clarification about the process the > RIPE NCC follows to establish the legitimate holder of PI address space, > and to outline how a case may be escalated. > > As mentioned earlier, Registration Services is currently in contact with > hundreds of potential PI resource holders. For the most part, the more > straightforward cases have already been resolved. What is left now are > those cases where things are not quite so clear-cut: a resource may have > changed hands several times, and there is often no paper trail documenting > this. In many cases, these resources have never been announced or have not > been announced for a very long time, etc. > > Every potential resource holder is given three months to produce > documentation that demonstrates the legitimacy of their claim. We sometimes > give extensions when we feel that good progress is being made. However, at > some point we do have to start the de-registration procedure. From here, > the potential resource holder still has an additional 90 days to find the > required documentation. > > We explore a number of options to find a satisfactory solution. In cases > where all available options have been exhausted but the IPRA feels > reasonably certain about the legitimacy of the claim, they may escalate the > request to management for a final decision. Similarly, the IPRA may also > escalate the matter, either at the request of the other party or following > internal procedures if the communication becomes difficult. If no agreement > can be reached even after the matter has been escalated, we inform the > potential resource holder that they can ask their potential sponsoring LIR > to object to our decision via the Arbiters Panel. During arbitration, all > ongoing processes are frozen. > > You can find out more about the RIPE NCC's Arbitration Process here: > http://www.ripe.net/lir-services/ncc/legal/arbitration > > Finally, I would like to highlight that out of the thousands of resources > we have dealt with as part of the 2007-01 project, very few cases that have > come this far. In the overwhelming majority of (legitimate) cases, we are > able to resolve matters satisfactorily for both parties. Regarding the > request that started this thread, please note that we will do our best to > resolve this matter with the other party. > > Kind regards > > Ingrid Wijte > RIPE NCC > > > On 8/14/13 5:20 PM, Nick Hilliard wrote: >> On 14/08/2013 16:08, Mikael Abrahamsson wrote: >>> No, that hasn't happened because the person didn't know about it. >> It's the same as dispute resolution everywhere else: if there is an issue >> which isn't resolved on the front desk, then you escalate. The Arbitration >> / dispute resolution process is not as well known as it might be, but it >> has existed for donkeys years: >> >> http://www.ripe.net/lir-services/ncc/legal/arbitration >> >>> Personally I dislike a policy that requires someone to know innards of RIPE >>> NCC in order to get reasonable treatment. As far as I can tell, the >>> hostmaster in question didn't offer these alternatives. >> It sounds like there may be scope for the IPRA team to educate PI holders >> on their options, and this might be something that the RIPE NCC management >> to think about. This will end up being fairer for the PI holders, and will >> also protect the RIPE NCC from allegations of unfair practice. Phase three >> of 2007-01 will produce difficult cases. >> >> Could someone from the RIPE NCC comment on general procedures surrounding >> what they might do in circumstances where there the holdership of the PI >> resources is unclear? And what the escalation options are? >> >> Nick >> >> >> > -- Network Ability Ltd. | Chief Technical Officer | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie From ingrid at ripe.net Mon Aug 19 11:02:39 2013 From: ingrid at ripe.net (Ingrid Wijte) Date: Mon, 19 Aug 2013 11:02:39 +0200 Subject: [address-policy-wg] regarding housecleaning efforts in absurdum In-Reply-To: <5210FCBB.1050206@inex.ie> References: <520B9AE4.9000700@inex.ie> <520BA032.1080204@inex.ie> <520E30DB.3010006@ripe.net> <5210FCBB.1050206@inex.ie> Message-ID: <5211DF2F.3060902@ripe.net> Hi Nick, We published information and procedures for Phase 3 at the following URL but possibly it could be more prominent and easy to find: http://www.ripe.net/lir-services/resource-management/2007-01-phase-3/implementing-phase-3-ripe-policy-proposal-2007-01 We will look at improving the location of this page and adding some additional information. Best regards, Ingrid Wijte RIPE NCC On 8/18/13 6:56 PM, Nick Hilliard wrote: > Hi Ingrid, > > Thanks for clarifying this. Would it be possible to put this information > up on the web site? I had a quick look around, but couldn't find anything > related to 2007-01 phase 3 procedures other than ripe-569. This document > gave some information on the general process from the RIPE NCC point of > view, but doesn't explain clearly what the End Users' rights were, or > provide information about what escalation procedures are available. > > Nick > > On 16/08/2013 15:02, Ingrid Wijte wrote: >> Dear Nick and others, >> >> As requested, I am writing to provide clarification about the process the >> RIPE NCC follows to establish the legitimate holder of PI address space, >> and to outline how a case may be escalated. >> >> As mentioned earlier, Registration Services is currently in contact with >> hundreds of potential PI resource holders. For the most part, the more >> straightforward cases have already been resolved. What is left now are >> those cases where things are not quite so clear-cut: a resource may have >> changed hands several times, and there is often no paper trail documenting >> this. In many cases, these resources have never been announced or have not >> been announced for a very long time, etc. >> >> Every potential resource holder is given three months to produce >> documentation that demonstrates the legitimacy of their claim. We sometimes >> give extensions when we feel that good progress is being made. However, at >> some point we do have to start the de-registration procedure. From here, >> the potential resource holder still has an additional 90 days to find the >> required documentation. >> >> We explore a number of options to find a satisfactory solution. In cases >> where all available options have been exhausted but the IPRA feels >> reasonably certain about the legitimacy of the claim, they may escalate the >> request to management for a final decision. Similarly, the IPRA may also >> escalate the matter, either at the request of the other party or following >> internal procedures if the communication becomes difficult. If no agreement >> can be reached even after the matter has been escalated, we inform the >> potential resource holder that they can ask their potential sponsoring LIR >> to object to our decision via the Arbiters Panel. During arbitration, all >> ongoing processes are frozen. >> >> You can find out more about the RIPE NCC's Arbitration Process here: >> http://www.ripe.net/lir-services/ncc/legal/arbitration >> >> Finally, I would like to highlight that out of the thousands of resources >> we have dealt with as part of the 2007-01 project, very few cases that have >> come this far. In the overwhelming majority of (legitimate) cases, we are >> able to resolve matters satisfactorily for both parties. Regarding the >> request that started this thread, please note that we will do our best to >> resolve this matter with the other party. >> >> Kind regards >> >> Ingrid Wijte >> RIPE NCC >> >> >> On 8/14/13 5:20 PM, Nick Hilliard wrote: >>> On 14/08/2013 16:08, Mikael Abrahamsson wrote: >>>> No, that hasn't happened because the person didn't know about it. >>> It's the same as dispute resolution everywhere else: if there is an issue >>> which isn't resolved on the front desk, then you escalate. The Arbitration >>> / dispute resolution process is not as well known as it might be, but it >>> has existed for donkeys years: >>> >>> http://www.ripe.net/lir-services/ncc/legal/arbitration >>> >>>> Personally I dislike a policy that requires someone to know innards of RIPE >>>> NCC in order to get reasonable treatment. As far as I can tell, the >>>> hostmaster in question didn't offer these alternatives. >>> It sounds like there may be scope for the IPRA team to educate PI holders >>> on their options, and this might be something that the RIPE NCC management >>> to think about. This will end up being fairer for the PI holders, and will >>> also protect the RIPE NCC from allegations of unfair practice. Phase three >>> of 2007-01 will produce difficult cases. >>> >>> Could someone from the RIPE NCC comment on general procedures surrounding >>> what they might do in circumstances where there the holdership of the PI >>> resources is unclear? And what the escalation options are? >>> >>> Nick >>> >>> >>> > From gert at space.net Thu Aug 22 20:55:17 2013 From: gert at space.net (Gert Doering) Date: Thu, 22 Aug 2013 20:55:17 +0200 Subject: [address-policy-wg] 2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: References: Message-ID: <20130822185517.GA69770@Space.Net> Dear AP WG, On Mon, Jul 22, 2013 at 03:08:26PM +0200, Emilio Madaio wrote: > A proposed change to RIPE Policy Document ripe-592, "IPv4 Address > Allocation and Assignment Policies for the RIPE NCC Service Region", > is now available for discussion. [..] > We encourage you to review this proposal and send your comments to > before 19 August 2013. The discussion phase has ended. Based on your feedback, we have decided to move the proposal forward to review phase - there was sufficiently positive feedback, and only one request for changes. The rationale in the proposal text will be extended to talk about the different real-world cases that have been seen, both by the proposer and by the RIPE NCC registration service, to help decide whether this is "good as it is" or changes are indeed necessary. The proposal is now at Impact Analysis at the RIPE NCC. When that is finished, Emilio will announce the new phase (review phase) here. regards, Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From yoann at recreatech.com Wed Aug 28 15:39:36 2013 From: yoann at recreatech.com (Yoann Bohbot) Date: Wed, 28 Aug 2013 15:39:36 +0200 Subject: [address-policy-wg] =?windows-1252?q?enforcing_abuse_requests_for?= =?windows-1252?q?_counterfeit_goods=2C_child_pornography=2C_etc=85?= Message-ID: Hi everyone, I have come across over a dozen "hosting" providers that host a slew of sites that are clearly selling illegal items. These "hosting" providers provide a contact address that is not checked, or at least not acted upon. I believe there should be policy enforcing your clients to respond to requests or they can have their ip addresses suspended. Using regular methods of law enforcement is almost useless, and they are not equipped with knowledge or equipment to handle these type of problems (counterfeit goods.) Domain resolutions take months and cost thousands. The only other option is you. Please consider. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-wgs.cs at schiefner.de Wed Aug 28 17:13:23 2013 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Wed, 28 Aug 2013 17:13:23 +0200 Subject: [address-policy-wg] =?windows-1252?q?enforcing_abuse_requests_for?= =?windows-1252?q?_counterfeit_goods=2C_child_pornography=2C_etc=85?= In-Reply-To: References: Message-ID: <521E1393.3080003@schiefner.de> Dear Yohann, On 28.08.2013 15:39, Yoann Bohbot wrote: > I have come across over a dozen "hosting" providers that host a slew of > sites that are clearly selling illegal items. > > These "hosting" providers provide a contact address that is not checked, > or at least not acted upon. > > I believe there should be policy enforcing your clients to respond to > requests or they can have their ip addresses suspended. > > Using regular methods of law enforcement is almost useless, and they are > not equipped with knowledge or equipment to handle these type of > problems (counterfeit goods.) > > Domain resolutions take months and cost thousands. > > The only other option is you. Please consider. thank you very much for your contribution. Please be so kind and name the RIPE policies and/or documents you would specifically have in mind if it is for a policy change and/or extension. Or you may want to start from scratch the creation of a new policy. Either way, please send text following RIPE's PDP according to ripe-500 (https://www.ripe.net/ripe/docs/ripe-500). Current RIPE policies you would find here: http://www.ripe.net/ripe/docs/current-ripe-documents/ripe-policies Current policy proposals to check whether your intention(s) might be covered already in somebody else's proposal you would find here: https://www.ripe.net/ripe/policies/current-proposals/current-policy-proposals Thanks and kind regards, Carsten From yoann at recreatech.com Wed Aug 28 19:34:10 2013 From: yoann at recreatech.com (Yoann Bohbot) Date: Wed, 28 Aug 2013 19:34:10 +0200 Subject: [address-policy-wg] =?windows-1252?q?enforcing_abuse_requests_for?= =?windows-1252?q?_counterfeit_goods=2C_child_pornography=2C_etc=85?= In-Reply-To: <521E1393.3080003@schiefner.de> References: <521E1393.3080003@schiefner.de> Message-ID: Hello, yes, sorry about that. It's for Policy ripe-563. -- Yoann Bohbot RECRE at TECH recreatech.com On Wed, Aug 28, 2013 at 5:13 PM, Carsten Schiefner wrote: > Dear Yohann, > > > On 28.08.2013 15:39, Yoann Bohbot wrote: > >> I have come across over a dozen "hosting" providers that host a slew of >> sites that are clearly selling illegal items. >> >> These "hosting" providers provide a contact address that is not checked, >> or at least not acted upon. >> >> I believe there should be policy enforcing your clients to respond to >> requests or they can have their ip addresses suspended. >> >> Using regular methods of law enforcement is almost useless, and they are >> not equipped with knowledge or equipment to handle these type of >> problems (counterfeit goods.) >> >> Domain resolutions take months and cost thousands. >> >> The only other option is you. Please consider. >> > > thank you very much for your contribution. > > Please be so kind and name the RIPE policies and/or documents you would > specifically have in mind if it is for a policy change and/or extension. > > Or you may want to start from scratch the creation of a new policy. > > Either way, please send text following RIPE's PDP according to ripe-500 ( > https://www.ripe.net/ripe/**docs/ripe-500 > ). > > Current RIPE policies you would find here: > http://www.ripe.net/ripe/docs/**current-ripe-documents/ripe-**policies > > Current policy proposals to check whether your intention(s) might be > covered already in somebody else's proposal you would find here: > https://www.ripe.net/ripe/**policies/current-proposals/** > current-policy-proposals > > Thanks and kind regards, > > Carsten > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Thu Aug 29 15:19:20 2013 From: sander at steffann.nl (Sander Steffann) Date: Thu, 29 Aug 2013 15:19:20 +0200 Subject: [address-policy-wg] =?windows-1252?q?enforcing_abuse_requests_for?= =?windows-1252?q?_counterfeit_goods=2C_child_pornography=2C_etc=85?= In-Reply-To: References: <521E1393.3080003@schiefner.de> Message-ID: <6C8C72B9-956C-45ED-8B68-83F1E83F3778@steffann.nl> Hi, > It's for Policy ripe-563. That policy came out of the Anti-Abuse working group. Changes to it should probably be discussed there. The web page of the working group is http://www.ripe.net/ripe/groups/wg/anti-abuse and you can subscribe to the mailing at http://www.ripe.net/mailman/listinfo/anti-abuse-wg/ Cheers, Sander