From 8lb.7zin81 at gmail.com Sat Oct 1 12:51:51 2016 From: 8lb.7zin81 at gmail.com (8lb. 7zin) Date: Sat, 1 Oct 2016 13:51:51 +0300 Subject: [address-policy-wg] (no subject) Message-ID: Monday, June 9, 2014 at 14:49:33 +0200, Joao Damas wrote: > At a recent meeting RIPE 68 there was a discussion about the issues > On the return of the recovered version for 16-bit ASNs by the NCC and RIPE > Possible modifications to the content of the qualities related guidance in > Data RIPE database objects, a guidance autnum politics features >. As is set things > > The consensus was noted during the meeting include: > > - The National Coordinating Committee RIPE not to remove all references to recovered ASNs for > Import and export lines, not Kkainat- SET. Directive > Policies owner of the object world and have nothing to do > Personalization data. > - NCC RIPE inform the maintainer of the object that contains > Outdated for this reference signal. The NCC also offer RIPE > Support for the breadwinner to delete the reference. > - NCC RIPE start reset referred to numbers once and > It is a reference gathering of 16-bit AS numbers have been exhausted. > > We would like to close the case, and be able to provide clear guidance > NCC RIPE so we would like to get confirmation of this result > Also from the mailing lists of the Working Group. This is not a matter of policy: > We have been dealing with the redistribution of ASNs for recovered with by the APWG, and > The current number of modifications to the database objects associated with the RIPE > Return to the rechargeable customization resources. We suggest 15 days > Comment period, ending June 24, 2014. I love that. Best Regards, Function -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Fri Oct 7 11:02:23 2016 From: gert at space.net (Gert Doering) Date: Fri, 7 Oct 2016 11:02:23 +0200 Subject: [address-policy-wg] APWG agenda for Madrid - first draft Message-ID: <20161007090223.GU79185@Space.Net> Hi APWG folks, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Madrid in the following time slots: Wednesday, Oct 26, 10:00 - 11:30 (+1 hour!!) Wednesday, Oct 26, 12:00 - 13:30 If you have anything else you want to see on the agenda, or if we need to change anything, please let us know. So far, the agenda is fairly light - if you have something you want to address, or that bothers you, let us know and we make room for you :-) The distribution of items to the two timeslot is somewhat subject to the time spent on discussion - but we'll try to stick to what's published. regards, Gert Doering & Sander Steffann, APWG chairs ---------------------------------------------------------------------- Wednesday, 10:00-11:30 ---------------------------------------------------------------------- A. Administrative Matters 5 min (welcome, thanking the scribe, approving the minutes, etc.) C. Current Policy Topics - Marco Schmidt, NCC PDO 20 min - global policy overview "what's going on?" - common policy topics in all regions (end of IPv4, transfers, ...) - overview over concluded proposals in the RIPE region since RIPE 72 - brief overview over new proposals (if any) F. Discussion of open policy proposals 50 min 2015-04 RIPE Resource Transfer Policies Erik Bais 2016-03 Locking Down the Final /8 Policy Remco van Mook G. consequences of the end of IPv4 15 min Erik Bais (presentation only, think about over coffee, discuss later) ---------------------------------------------------------------------- Wednesday, 12:00-13:30 ---------------------------------------------------------------------- Welcome back G. consequences of the end of IPv4 30 min Erik Bais (discussion with the group) D. Feedback From NCC Registration Service - Andrea Cima 45 min (+ discussion with the group) Y. Open Policy Hour 15 min The Open Policy Hour is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity. Z. AOB -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mschmidt at ripe.net Tue Oct 11 16:13:55 2016 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 11 Oct 2016 16:13:55 +0200 Subject: [address-policy-wg] New on RIPE Labs: Supporting IPv6 Deployment Through Policy Message-ID: Dear colleagues, It was about a year ago that the RIPE community reached consensus on a policy proposal that introduced additional criteria for initial IPv6 allocations. We thought it was time to look back the origins of this proposal and see how the change has worked out since: https://labs.ripe.net/Members/marco_schmidt/supporting-ipv6-deployment-through-policy Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From ebais at a2b-internet.com Thu Oct 13 23:25:37 2016 From: ebais at a2b-internet.com (Erik Bais) Date: Thu, 13 Oct 2016 23:25:37 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: Message-ID: <00cd01d22598$5ac74070$1055c150$@a2b-internet.com> Hi, I would like to ask you to also read the 4th version of the RIPE Resource Transfer Policies and ... provide you feedback (even if that is only a +1 ) on the list ... This phase ends 26 October 2016 (right in the middle of the RIPE73 meeting in Madrid ) ... > You can find the full proposal and the impact analysis at: > https://www.ripe.net/participate/policies/proposals/2015-04 I'm looking forward to see you all in Madrid. Regards, Erik Bais From tore at fud.no Sat Oct 15 12:13:46 2016 From: tore at fud.no (Tore Anderson) Date: Sat, 15 Oct 2016 12:13:46 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <00cd01d22598$5ac74070$1055c150$@a2b-internet.com> References: <00cd01d22598$5ac74070$1055c150$@a2b-internet.com> Message-ID: <20161015121346.081e3ea5@envy.e1.y.home> * Erik Bais > I would like to ask you to also read the 4th version of the RIPE > Resource Transfer Policies and ... provide you feedback (even if that > is only a +1 ) on the list ... Hi Erik, I've now re-read the proposal and its impact analysis. Consolidating the transfer policies is a big editorial improvement, the way I see it. The few minor adjustments in actual/effective policy that this proposal introduces all strike me as perfectly sensible. The NCC's impact analysis shows that the proposal won't have any unintentional or otherwise negative side-effects. I think it's good to go. Thanks for making this effort, Erik. +1 Tore From ebais at a2b-internet.com Sat Oct 15 22:02:17 2016 From: ebais at a2b-internet.com (Erik Bais - A2B Internet) Date: Sat, 15 Oct 2016 22:02:17 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <20161015121346.081e3ea5@envy.e1.y.home> References: <00cd01d22598$5ac74070$1055c150$@a2b-internet.com> <20161015121346.081e3ea5@envy.e1.y.home> Message-ID: Thnx Tore. > Op 15 okt. 2016 om 12:13 heeft Tore Anderson het volgende geschreven: > > * Erik Bais > >> I would like to ask you to also read the 4th version of the RIPE >> Resource Transfer Policies and ... provide you feedback (even if that >> is only a +1 ) on the list ... > > Hi Erik, > > I've now re-read the proposal and its impact analysis. > > Consolidating the transfer policies is a big editorial improvement, the > way I see it. > > The few minor adjustments in actual/effective policy that this proposal > introduces all strike me as perfectly sensible. > > The NCC's impact analysis shows that the proposal won't have any > unintentional or otherwise negative side-effects. > > I think it's good to go. Thanks for making this effort, Erik. +1 > > Tore > From gert at space.net Mon Oct 17 08:33:52 2016 From: gert at space.net (Gert Doering) Date: Mon, 17 Oct 2016 08:33:52 +0200 Subject: [address-policy-wg] APWG agenda for Madrid - second draft In-Reply-To: <20161007090223.GU79185@Space.Net> References: <20161007090223.GU79185@Space.Net> Message-ID: <20161017063352.GA48184@Space.Net> Hi APWG folks, below you can find the second draft for the RIPE address policy WG meeting's agenda, which will take place in Madrid in the following time slots: Wednesday, Oct 26, 10:00 - 11:30 (+1 hour!!) Wednesday, Oct 26, 12:00 - 13:30 If you have anything else you want to see on the agenda, or if we need to change anything, please let us know. The distribution of items to the two timeslot is somewhat subject to the time spent on discussion - but we'll try to stick to what's published (as you can see by comparing with the previous version, we already had to shuffle around things a bit due to conflicts with Connect WG). regards, Gert Doering & Sander Steffann, APWG chairs ---------------------------------------------------------------------- Wednesday, 10:00-11:30 ---------------------------------------------------------------------- A. Administrative Matters 5 min (welcome, thanking the scribe, approving the minutes, etc.) C. Current Policy Topics - Marco Schmidt, NCC PDO 20 min - global policy overview "what's going on?" - common policy topics in all regions (end of IPv4, transfers, ...) - overview over concluded proposals in the RIPE region since RIPE 72 - brief overview over new proposals (if any) F. Discussion of open policy proposals 50 min (more specifically: presentation on the status of the open policy proposals and Q&A, discussion will take place on the list) 2015-04 RIPE Resource Transfer Policies Erik Bais 2016-03 Locking Down the Final /8 Policy Remco van Mook 2016-04 (to be announced) H. Supermarket Checkouts, Airline Hand-Luggage and Other Trivia 15min Nick Hilliard (+ discussion with the group) ---------------------------------------------------------------------- Wednesday, 12:00-13:30 ---------------------------------------------------------------------- Welcome back D. Feedback From NCC Registration Service - Andrea Cima 45 min (+ discussion with the group) G. consequences of the end of IPv4 40 min Erik Bais (+ discussion with the group) Y. Open Policy Hour 5 min The Open Policy Hour is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity. [IF TIME PERMITS] Z. AOB -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From gert at space.net Mon Oct 17 08:57:16 2016 From: gert at space.net (Gert Doering) Date: Mon, 17 Oct 2016 08:57:16 +0200 Subject: [address-policy-wg] APWG agenda for Madrid - second draft In-Reply-To: <20161017063352.GA48184@Space.Net> References: <20161007090223.GU79185@Space.Net> <20161017063352.GA48184@Space.Net> Message-ID: <20161017065716.GD79185@Space.Net> Hi, On Mon, Oct 17, 2016 at 08:33:52AM +0200, Gert Doering wrote: > F. Discussion of open policy proposals 50 min > (more specifically: presentation on the status of the open policy > proposals and Q&A, discussion will take place on the list) > > 2015-04 RIPE Resource Transfer Policies > Erik Bais > > 2016-03 Locking Down the Final /8 Policy > Remco van Mook > > 2016-04 (to be announced) Some "heads up" on this one. We used to take our time to discuss these proposals in depth, and I still think that this is a valuable use of our time. Nevertheless, we've seriously overrun the meeting slots last time, something which is hard to avoid if there are a number of "open discussion" blocks on the list (and I do not want to cut off a productive discussion right in the middle). So, what we'll do this time for "item F" is: - presentation - Q&A - which is really "I do not understand that aspect, please explain?" and not "I do not like this, can you please change ...?" - "show of hands" quick feedback about the direction the proposal should take ("move forward" vs. "opposition") detailed discussion and consensus finding takes place on the list. The *other* items marked with "discussion" need the discussion time at the meeting, because these are not proposals *yet*, and we need more direct input to decide whether to move to a specific proposal, or abandon the idea(s). Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mschmidt at ripe.net Wed Oct 19 10:05:12 2016 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 19 Oct 2016 10:05:12 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) Message-ID: Dear colleagues, The draft documents for version 3.0 of the policy proposal 2016-03, "Locking Down the Final /8 Policy" have now been published, along with an impact analysis conducted by the RIPE NCC. The goal of this proposal is to ban transfers of allocations made under the final /8 policy. Also the proposal specifies what resources must be added to the RIPE NCC IPv4 available pool. Some of the differences from version 2.0 include: - Clarification that changes to holdership of address space as a result of company mergers or acquisitions are not affected by proposed transfer restriction - Legacy space handed over to the RIPE NCC will be added to the IPv4 available pool You can find the full proposal and the impact analysis at: https://www.ripe.net/participate/policies/proposals/2016-03 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2016-03/draft We want to draw your attention to two changes, which we hope it will make your proposal evaluation easier. - Policy proposals now contain a diff tool that allows easy comparison of different proposal versions ? simply click on the ?View Changes? symbol right beside the list of proposal versions. - The RIPE NCC impact analysis only mentions areas where the proposal is actually expected to have an impact. For example, if the analysis makes no comment about financial or legal impact, it means that no such impact is expected. We encourage you to read the draft document and send any comments to before 17 November 2016. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From niculae at plesa.ro Wed Oct 19 10:33:52 2016 From: niculae at plesa.ro (Plesa Niculae) Date: Wed, 19 Oct 2016 11:33:52 +0300 Subject: [address-policy-wg] niculae@plesa.ro Message-ID: <59335D21-9461-4786-8488-9381A3C77C05@plesa.ro> niculae at plesa.ro From aleksbulgakov at gmail.com Wed Oct 19 10:33:54 2016 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Wed, 19 Oct 2016 11:33:54 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: Hi. It is obviously the 99? of members want to withdraw this proposal in any versions, but the NCC strongly moves it forward. May be the NCC has own reasons to do it, but why it doesn't notice evident things. 19 ??? 2016 ?. 11:05 ???????????? "Marco Schmidt" ???????: > Dear colleagues, > > The draft documents for version 3.0 of the policy proposal 2016-03, > "Locking Down the Final /8 Policy" have now been published, along with an > impact analysis conducted by the RIPE NCC. > > The goal of this proposal is to ban transfers of allocations made under > the final /8 policy. Also the proposal specifies what resources must be > added to the RIPE NCC IPv4 available pool. > > Some of the differences from version 2.0 include: > > - Clarification that changes to holdership of address space as a result > of company mergers or acquisitions are not affected by proposed transfer > restriction > - Legacy space handed over to the RIPE NCC will be added to the IPv4 > available pool > > You can find the full proposal and the impact analysis at: > https://www.ripe.net/participate/policies/proposals/2016-03 > > And the draft documents at: > https://www.ripe.net/participate/policies/proposals/2016-03/draft > > We want to draw your attention to two changes, which we hope it will make > your proposal evaluation easier. > > - Policy proposals now contain a diff tool that allows easy comparison > of different proposal versions ? simply click on the ?View Changes? symbol > right beside the list of proposal versions. > - The RIPE NCC impact analysis only mentions areas where the proposal > is actually expected to have an impact. For example, if the analysis makes > no comment about financial or legal impact, it means that no such impact is > expected. > > We encourage you to read the draft document and send any comments to < > address-policy-wg at ripe.net> before 17 November 2016. > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at karotte.org Wed Oct 19 10:43:11 2016 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Wed, 19 Oct 2016 10:43:11 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: <20161019084311.GA12497@danton.fire-world.de> * Aleksey Bulgakov [2016-10-19 10:36]: > Hi. > > It is obviously the 99? of members want to withdraw this proposal in any > versions, but the NCC strongly moves it forward. May be the NCC has own > reasons to do it, but why it doesn't notice evident things. Hi Aleksey, please read how the PDP works: https://www.ripe.net/publications/docs/ripe-642 and stop hinting at some conspiracy. That's bullshit. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 581 bytes Desc: Digital signature URL: From gert at space.net Wed Oct 19 11:14:56 2016 From: gert at space.net (Gert Doering) Date: Wed, 19 Oct 2016 11:14:56 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: <20161019091456.GV79185@Space.Net> Hi, On Wed, Oct 19, 2016 at 11:33:54AM +0300, Aleksey Bulgakov wrote: > It is obviously the 99??? of members want to withdraw this proposal in any > versions, but the NCC strongly moves it forward. May be the NCC has own > reasons to do it, but why it doesn't notice evident things. It would be so kind of you to actually *READ* the summary I wrote at the end of the discussion phase. Or try to understand how the PDP works. The NCC is not involved in the decision making whether or not a proposal moves forward - the decision a the end of the discussion phase (which is what is relevant here) is made by the proposer(!), in agreement with the WG chairs (Sander and me). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From lists at velder.li Wed Oct 19 11:19:23 2016 From: lists at velder.li (Patrick Velder) Date: Wed, 19 Oct 2016 11:19:23 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: <995c0516-5432-5dbe-d00c-91fbb098c0b9@velder.li> Hi I still disagree changing the status of already allocated resources. -1 from me. Regards Patrick On 19.10.2016 10:05, Marco Schmidt wrote: > Dear colleagues, > > The draft documents for version 3.0 of the policy proposal 2016-03, "Locking Down the Final /8 Policy" have now been published, along with an impact analysis conducted by the RIPE NCC. > > The goal of this proposal is to ban transfers of allocations made under the final /8 policy. Also the proposal specifies what resources must be added to the RIPE NCC IPv4 available pool. > > Some of the differences from version 2.0 include: > > - Clarification that changes to holdership of address space as a result of company mergers or acquisitions are not affected by proposed transfer restriction > - Legacy space handed over to the RIPE NCC will be added to the IPv4 available pool > > You can find the full proposal and the impact analysis at: > https://www.ripe.net/participate/policies/proposals/2016-03 > > And the draft documents at: > https://www.ripe.net/participate/policies/proposals/2016-03/draft > > We want to draw your attention to two changes, which we hope it will make your proposal evaluation easier. > > - Policy proposals now contain a diff tool that allows easy comparison of different proposal versions ? simply click on the ?View Changes? symbol right beside the list of proposal versions. > - The RIPE NCC impact analysis only mentions areas where the proposal is actually expected to have an impact. For example, if the analysis makes no comment about financial or legal impact, it means that no such impact is expected. > > We encourage you to read the draft document and send any comments to before 17 November 2016. > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > From d.baeza at tvt-datos.es Wed Oct 19 11:21:36 2016 From: d.baeza at tvt-datos.es (Daniel Baeza) Date: Wed, 19 Oct 2016 11:21:36 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> Hi All, -1 to this. I think the current policy that prevents tranfers for 24 months is enough. Regards, El 19/10/2016 a las 10:05, Marco Schmidt escribi?: > Dear colleagues, > > The draft documents for version 3.0 of the policy proposal 2016-03, "Locking Down the Final /8 Policy" have now been published, along with an impact analysis conducted by the RIPE NCC. > > The goal of this proposal is to ban transfers of allocations made under the final /8 policy. Also the proposal specifies what resources must be added to the RIPE NCC IPv4 available pool. > > Some of the differences from version 2.0 include: > > - Clarification that changes to holdership of address space as a result of company mergers or acquisitions are not affected by proposed transfer restriction > - Legacy space handed over to the RIPE NCC will be added to the IPv4 available pool > > You can find the full proposal and the impact analysis at: > https://www.ripe.net/participate/policies/proposals/2016-03 > > And the draft documents at: > https://www.ripe.net/participate/policies/proposals/2016-03/draft > > We want to draw your attention to two changes, which we hope it will make your proposal evaluation easier. > > - Policy proposals now contain a diff tool that allows easy comparison of different proposal versions ? simply click on the ?View Changes? symbol right beside the list of proposal versions. > - The RIPE NCC impact analysis only mentions areas where the proposal is actually expected to have an impact. For example, if the analysis makes no comment about financial or legal impact, it means that no such impact is expected. > > We encourage you to read the draft document and send any comments to before 17 November 2016. > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > From ripe-wgs at radu-adrian.feurdean.net Wed Oct 19 11:23:30 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Wed, 19 Oct 2016 11:23:30 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: <1476869010.1372943.760587825.13DB1FBE@webmail.messagingengine.com> On Wed, Oct 19, 2016, at 10:33, Aleksey Bulgakov wrote: > Hi. > > It is obviously the 99? of members want to withdraw this proposal in any > versions, but the NCC strongly moves it forward. May be the NCC has own > reasons to do it, but why it doesn't notice evident things. Except that members (RIPE NCC members), unless they voice their concerns here, on this list, don't have a word to say on policy development. As for myself, I still strongly oppose for too many reasons (it would take half of a working day to write all them down again). As a very quick and incomplete reminder: - "two levels membership" / differentiated services - "RIPE NCC as an investment fund" (or "former Gold distributor") - uncertainty for feasibility of business processes (what exactly is M&A today ? , what will it be tomorrow ?) - stubbornness on arguments/issues that still do not yet apply everywhere or that still have enough space for a middlegroud - .... - https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-August/011700.html - https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-June/011565.html - https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-June/011548.html No, I don't think any of my concerns has been addressed. And last but not least, differentiated treatment of the proposals (ideas in general), depending on who is the proposer and how does it fit within the ideas of the "establishment". From aleksbulgakov at gmail.com Wed Oct 19 11:26:53 2016 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Wed, 19 Oct 2016 12:26:53 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> Message-ID: Ok. If it is better to say I agree that 2015-01 with 24 month period restriction is enough. Also there is the next text about ALLOCATED FINAL: Assignments and sub-allocations cannot be kept when moving to another provider. This allocation is not transferable to another LIR. What does it mean? Transfers are inpossible, but when the allocations move to another provider this case and should be returned to the NCC? 2016-10-19 12:21 GMT+03:00 Daniel Baeza : > Hi All, > > -1 to this. > > I think the current policy that prevents tranfers for 24 months is enough. > > Regards, > > > El 19/10/2016 a las 10:05, Marco Schmidt escribi?: >> >> Dear colleagues, >> >> The draft documents for version 3.0 of the policy proposal 2016-03, >> "Locking Down the Final /8 Policy" have now been published, along with an >> impact analysis conducted by the RIPE NCC. >> >> The goal of this proposal is to ban transfers of allocations made under >> the final /8 policy. Also the proposal specifies what resources must be >> added to the RIPE NCC IPv4 available pool. >> >> Some of the differences from version 2.0 include: >> >> - Clarification that changes to holdership of address space as a result >> of company mergers or acquisitions are not affected by proposed transfer >> restriction >> - Legacy space handed over to the RIPE NCC will be added to the IPv4 >> available pool >> >> You can find the full proposal and the impact analysis at: >> https://www.ripe.net/participate/policies/proposals/2016-03 >> >> And the draft documents at: >> https://www.ripe.net/participate/policies/proposals/2016-03/draft >> >> We want to draw your attention to two changes, which we hope it will make >> your proposal evaluation easier. >> >> - Policy proposals now contain a diff tool that allows easy comparison >> of different proposal versions ? simply click on the ?View Changes? symbol >> right beside the list of proposal versions. >> - The RIPE NCC impact analysis only mentions areas where the proposal >> is actually expected to have an impact. For example, if the analysis makes >> no comment about financial or legal impact, it means that no such impact is >> expected. >> >> We encourage you to read the draft document and send any comments to >> before 17 November 2016. >> >> Regards, >> >> Marco Schmidt >> Policy Development Officer >> RIPE NCC >> >> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum >> > -- ---------- Best regards, Aleksey Bulgakov Tel.: +7 (985)635-54-44 From h.lu at anytimechinese.com Wed Oct 19 11:39:10 2016 From: h.lu at anytimechinese.com (Lu Heng) Date: Wed, 19 Oct 2016 11:39:10 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> Message-ID: I believe it is an permenent solution to an temporary problem. Think 5 years from now, after last /8 ran out, will we still care about it anymore? Don't fix something that will no longer exsit in a short time period. On 19 October 2016 at 11:26, Aleksey Bulgakov wrote: > Ok. If it is better to say I agree that 2015-01 with 24 month period > restriction is enough. > > Also there is the next text about ALLOCATED FINAL: Assignments and > sub-allocations cannot be kept when moving to another provider. This > allocation is not transferable to another LIR. > What does it mean? Transfers are inpossible, but when the allocations > move to another provider this case and should be returned to the NCC? > > 2016-10-19 12:21 GMT+03:00 Daniel Baeza : > > Hi All, > > > > -1 to this. > > > > I think the current policy that prevents tranfers for 24 months is > enough. > > > > Regards, > > > > > > El 19/10/2016 a las 10:05, Marco Schmidt escribi?: > >> > >> Dear colleagues, > >> > >> The draft documents for version 3.0 of the policy proposal 2016-03, > >> "Locking Down the Final /8 Policy" have now been published, along with > an > >> impact analysis conducted by the RIPE NCC. > >> > >> The goal of this proposal is to ban transfers of allocations made under > >> the final /8 policy. Also the proposal specifies what resources must be > >> added to the RIPE NCC IPv4 available pool. > >> > >> Some of the differences from version 2.0 include: > >> > >> - Clarification that changes to holdership of address space as a > result > >> of company mergers or acquisitions are not affected by proposed transfer > >> restriction > >> - Legacy space handed over to the RIPE NCC will be added to the IPv4 > >> available pool > >> > >> You can find the full proposal and the impact analysis at: > >> https://www.ripe.net/participate/policies/proposals/2016-03 > >> > >> And the draft documents at: > >> https://www.ripe.net/participate/policies/proposals/2016-03/draft > >> > >> We want to draw your attention to two changes, which we hope it will > make > >> your proposal evaluation easier. > >> > >> - Policy proposals now contain a diff tool that allows easy > comparison > >> of different proposal versions ? simply click on the ?View Changes? > symbol > >> right beside the list of proposal versions. > >> - The RIPE NCC impact analysis only mentions areas where the > proposal > >> is actually expected to have an impact. For example, if the analysis > makes > >> no comment about financial or legal impact, it means that no such > impact is > >> expected. > >> > >> We encourage you to read the draft document and send any comments to > >> before 17 November 2016. > >> > >> Regards, > >> > >> Marco Schmidt > >> Policy Development Officer > >> RIPE NCC > >> > >> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > >> > > > > > > -- > ---------- > Best regards, > Aleksey Bulgakov > Tel.: +7 (985)635-54-44 > > -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Wed Oct 19 11:48:28 2016 From: gert at space.net (Gert Doering) Date: Wed, 19 Oct 2016 11:48:28 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> Message-ID: <20161019094828.GW79185@Space.Net> Hi, On Wed, Oct 19, 2016 at 11:39:10AM +0200, Lu Heng wrote: > I believe it is an permenent solution to an temporary problem. > > Think 5 years from now, after last /8 ran out, will we still care about it > anymore? > > Don't fix something that will no longer exsit in a short time period. So I take this as "non-support" = "opposition"? I think it is fairly clear here, but it would be good if people can very explicitly state their position, as the to-be-expected large amount of e-mail makes summarization very tedious for the chairs otherwise. thanks, Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From richih.mailinglist at gmail.com Wed Oct 19 11:51:33 2016 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Wed, 19 Oct 2016 11:51:33 +0200 Subject: [address-policy-wg] [policy-announce] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <9f21a405-af43-9ca6-5ace-07802b2b9998@ripe.net> References: <9f21a405-af43-9ca6-5ace-07802b2b9998@ripe.net> Message-ID: Dear all, I support this proposal. I would once again urge that the default view in the PDP process should be diffs. While I could find diffs between proposal versions on the PDP site, there was no obvious way to diff current text against current proposal version. Richard From nick at foobar.org Wed Oct 19 11:53:12 2016 From: nick at foobar.org (Nick Hilliard) Date: Wed, 19 Oct 2016 10:53:12 +0100 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: <58074288.5000003@foobar.org> Marco Schmidt wrote: > We encourage you to read the draft document and send any comments to > before 17 November 2016. The purpose of the policy is to restrict the flow of /22 allocations from the RIPE remaining ipv4 pool. While I'm sympathetic to this idea, the policy is not going to fix the problem that it sets out to fix and will create a new set of problems which will be extremely difficult for the RIPE NCC to recover from. Consequently I do not support it, because: 1. the core problem won't be fixed: the outgoing flow of /22s will not be affected in any way because speculators will get allocations using shelf Companies which can be sold as-is, thereby bypassing any policy that the RIPE community might want to consider in this area. The only way to even begin to fix this would be to move back to a needs-based allocation policy. 2. unregistered transfers will become a problem and this may become intractable in the future. This directly goes against the core principals of the RIPE database which is to ensure accurate registration of address holder details. Also, asset divesting is not catered for in the policy. If a company / LIR splits up, there is no way to handle splitting of IPv4 address allocations in the policy. There is no clear way to fix this problem within the principals of the policy. As an aside note, the problem of ipv4 allocation speedup from the RIPE NCC has been exacerbated by the recent RIPE NCC GM resolution: "The General Meeting approves the ability of RIPE NCC members to create additional LIR accounts". The net effect of this is that there is now a divergence between intended RIPE policy and RIPE NCC implementation. This is probably not helpful in the long run. Nick From nick at foobar.org Wed Oct 19 11:54:04 2016 From: nick at foobar.org (Nick Hilliard) Date: Wed, 19 Oct 2016 10:54:04 +0100 Subject: [address-policy-wg] [policy-announce] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <9f21a405-af43-9ca6-5ace-07802b2b9998@ripe.net> Message-ID: <580742BC.8070300@foobar.org> Richard Hartmann wrote: > I would once again urge that the default view in the PDP process > should be diffs. While I could find diffs between proposal versions on > the PDP site, there was no obvious way to diff current text against > current proposal version. There were easy-to-follow diffs here: https://www.ripe.net/participate/policies/proposals/2016-03/draft Nick From office at ip-broker.uk Wed Oct 19 11:54:46 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Wed, 19 Oct 2016 12:54:46 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <1476869010.1372943.760587825.13DB1FBE@webmail.messagingengine.com> References: <1476869010.1372943.760587825.13DB1FBE@webmail.messagingengine.com> Message-ID: Totally agree with Radu. -1 for this policy from me too. Ciprian On Wednesday, October 19, 2016, Radu-Adrian FEURDEAN < ripe-wgs at radu-adrian.feurdean.net> wrote: > On Wed, Oct 19, 2016, at 10:33, Aleksey Bulgakov wrote: > > Hi. > > > > It is obviously the 99? of members want to withdraw this proposal in any > > versions, but the NCC strongly moves it forward. May be the NCC has own > > reasons to do it, but why it doesn't notice evident things. > > Except that members (RIPE NCC members), unless they voice their concerns > here, on this list, don't have a word to say on policy development. > > As for myself, I still strongly oppose for too many reasons (it would > take half of a working day to write all them down again). > As a very quick and incomplete reminder: > - "two levels membership" / differentiated services > - "RIPE NCC as an investment fund" (or "former Gold distributor") > - uncertainty for feasibility of business processes (what exactly is > M&A today ? , what will it be tomorrow ?) > - stubbornness on arguments/issues that still do not yet apply > everywhere or that still have enough space for a middlegroud > - .... > - > https://www.ripe.net/ripe/mail/archives/address-policy- > wg/2016-August/011700.html > - > https://www.ripe.net/ripe/mail/archives/address-policy- > wg/2016-June/011565.html > - > https://www.ripe.net/ripe/mail/archives/address-policy- > wg/2016-June/011548.html > No, I don't think any of my concerns has been addressed. > > And last but not least, differentiated treatment of the proposals (ideas > in general), depending on who is the proposer and how does it fit within > the ideas of the "establishment". > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From office at ip-broker.uk Wed Oct 19 11:57:24 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Wed, 19 Oct 2016 12:57:24 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: Message-ID: Hi, I've sent this only to Marco instead of replying to the list. Please see my comments below. Ciprian On Monday, October 17, 2016, Ciprian Nica wrote: > Hi, > > I think it would be useful to list on the statistics also the broker that > facilitated the transfer. That might be of interest to the community and I > think the NCC should revise the transfer agreement template in order to be > able to mention the broker and also to publish it's name on the transfer > statistics page. Also the broker should be allowed to communicate with RIPE > and pass information on behalf of the customers during the transfer process. > > There is also a cosmetic thing that I don't know if it needs be mentioned > in policy in order to be implemented. The netname of the allocation keeps > the original allocation date in it's name which can be confusing although > there's the new "created" attribute. > > For example, the subnet 128.0.52.0/24 was transferred on 14/10/2016 and > it was part of an allocation with netname EU-JM-20120914. The new > allocation has netname ES-SISTEC-20120914. > > If the date is no longer relevant in a netname then I think it should be > simply ES-SISTEC, otherwise it can be ES-SISTEC-20161014 > > Ciprian > > > On Tue, Sep 27, 2016 at 4:08 PM, Marco Schmidt > wrote: > >> Dear colleagues, >> >> The draft documents for version 4.0 of the policy proposal 2015-04, "RIPE >> Resource Transfer Policies" have now been published, along with an impact >> analysis conducted by the RIPE NCC. >> >> The goal of this proposal is to create a single document with all >> relevant information regarding the transfer of Internet number resources. >> >> Some of the differences from version 3.0 include: >> >> - Adding a reference in all related allocation and assignment policies to >> the new transfer policy document >> - Clarification in the policy text and policy summary regarding transfers >> due to a change in the organisation?s business (such as a merger or >> acquisition) >> >> You can find the full proposal and the impact analysis at: >> https://www.ripe.net/participate/policies/proposals/2015-04 >> >> And the draft documents at: >> https://www.ripe.net/participate/policies/proposals/2015-04/draft >> >> We encourage you to read the draft document and send any comments to < >> address-policy-wg at ripe.net >> > before 26 >> October 2016. >> >> Regards >> >> Marco Schmidt >> Policy Development Officer >> RIPE NCC >> >> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From niculae at plesa.ro Wed Oct 19 11:59:20 2016 From: niculae at plesa.ro (Plesa Niculae) Date: Wed, 19 Oct 2016 12:59:20 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) Message-ID: <7F2324C7-B6FE-46AD-84E3-15F0F34D4EA8@plesa.ro> Dear colleagues, Regarding the [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies): The supposed purpose of the policy was to organise more efficiently, in a single document, the rules regarding transfer of resources but it brings a restriction which has not been properly analysed and debated. In my opinion there are many cases when two ISPs would merge. Due to the restructuring after the merger it is likely that the IPs could be used more efficiently and the resulting company would have spare resources that could be transferred like one of the AS numbers and maybe some IPs. If both companies have received the IPs and AS numbers many years ago, why should they not be able to transfer the resulting unused resources after the merger ? There is no logical point in that. Maybe there would not result some unused IPs but at least there is a 100% certainty that one of the AS numbers would become useless. This policy would force the company to keep it for 24 months just because they did a merger ? In today?s market it's quite common that smaller ISPs get acquired by larger ones and the policy would impose some restrictions which makes no sense. I have more observations regarding other non-sense and incorrect terms of the proposed policy, but first I really want to see if Marco, together with the RIPE team, really want to discuss and make modifications according the general good and common sense or everybody wants to pass this policy, like most of them, with no real answers to the problems raised. We will pass this policy in fanfare sounds, without any modifications, like the most of the past ones, or we will look seriously at members observations and change the policy accordingly? Best Regards Niculae Plesa -------------- next part -------------- An HTML attachment was scrubbed... URL: From h.lu at anytimechinese.com Wed Oct 19 12:00:47 2016 From: h.lu at anytimechinese.com (Lu Heng) Date: Wed, 19 Oct 2016 12:00:47 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <20161019094828.GW79185@Space.Net> References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> Message-ID: Hi On 19 October 2016 at 11:48, Gert Doering wrote: > Hi, > > On Wed, Oct 19, 2016 at 11:39:10AM +0200, Lu Heng wrote: > > I believe it is an permenent solution to an temporary problem. > > > > Think 5 years from now, after last /8 ran out, will we still care about > it > > anymore? > > > > Don't fix something that will no longer exsit in a short time period. > > So I take this as "non-support" = "opposition"? > > I think it is fairly clear here, but it would be good if people can very > explicitly state their position, as the to-be-expected large amount of > e-mail makes summarization very tedious for the chairs otherwise. > > Community is consensus based, not vote based. What I have said is one of the concern that have to be addressd with an reasonable counter argument. Chair's job is not collecting vote but make sure all concerns have been addressed reasonablely. But again, I think this is personal so I will not continue this discussion future. Let's go back to the policy. > thanks, > > Gert Doering > -- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From office at ip-broker.uk Wed Oct 19 12:12:52 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Wed, 19 Oct 2016 13:12:52 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: Message-ID: In the published version at point "B. Impact of Policy on Registry and Addressing System" it just states "After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented." Is it possible that we would get details on that ? What data was analysed and how was this conclusion reached ? Ciprian On Tuesday, September 27, 2016, Marco Schmidt wrote: > Dear colleagues, > > The draft documents for version 4.0 of the policy proposal 2015-04, "RIPE > Resource Transfer Policies" have now been published, along with an impact > analysis conducted by the RIPE NCC. > > The goal of this proposal is to create a single document with all relevant > information regarding the transfer of Internet number resources. > > Some of the differences from version 3.0 include: > > - Adding a reference in all related allocation and assignment policies to > the new transfer policy document > - Clarification in the policy text and policy summary regarding transfers > due to a change in the organisation?s business (such as a merger or > acquisition) > > You can find the full proposal and the impact analysis at: > https://www.ripe.net/participate/policies/proposals/2015-04 > > And the draft documents at: > https://www.ripe.net/participate/policies/proposals/2015-04/draft > > We encourage you to read the draft document and send any comments to < > address-policy-wg at ripe.net > before 26 October 2016. > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Wed Oct 19 12:18:58 2016 From: gert at space.net (Gert Doering) Date: Wed, 19 Oct 2016 12:18:58 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> Message-ID: <20161019101857.GY79185@Space.Net> Hi, On Wed, Oct 19, 2016 at 12:00:47PM +0200, Lu Heng wrote: [..] > What I have said is one of the concern that have to be addressd with an > reasonable counter argument. Thanks for the clarification. > Chair's job is not collecting vote but make sure all concerns have been > addressed reasonablely. Thanks for telling me what my job is, I wouldn't have guessed otherwise. Just for the record: part of the WG Chair's job is to judge the "roughness" of consensus based on the amount of supporting and opposing voices - both the number, and the quality of arguments have to be weighted (and to some extent the person making a certain argument). And if I cannot be sure what to make out of a statement, then I can either ask for clarity, or just discard as "random noise". Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From ripe-wgs at radu-adrian.feurdean.net Wed Oct 19 12:28:47 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Wed, 19 Oct 2016 12:28:47 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: Message-ID: <1476872927.1385031.760673489.6C19D69E@webmail.messagingengine.com> Hi, While I do agree with most of the concerns you present there, I'm wondering if this is not an issue to be discussed in some other working group (??? services ??? database ???). They don't seem to be related to the policy itself, but to the way RIPE NCC implements it and reflects the changes in the database. Marco ? Chairs ? anybody else ? -- Radu-Adrian FEURDEAN On Wed, Oct 19, 2016, at 11:57, Ciprian Nica wrote: > > Hi, > > > > I think it would be useful to list on the statistics also the broker that > > facilitated the transfer. That might be of interest to the community and I > > think the NCC should revise the transfer agreement template in order to be > > able to mention the broker and also to publish it's name on the transfer > > statistics page. Also the broker should be allowed to communicate with RIPE > > and pass information on behalf of the customers during the transfer process. > > > > There is also a cosmetic thing that I don't know if it needs be mentioned > > in policy in order to be implemented. The netname of the allocation keeps > > the original allocation date in it's name which can be confusing although > > there's the new "created" attribute. > > > > For example, the subnet 128.0.52.0/24 was transferred on 14/10/2016 and > > it was part of an allocation with netname EU-JM-20120914. The new > > allocation has netname ES-SISTEC-20120914. > > > > If the date is no longer relevant in a netname then I think it should be > > simply ES-SISTEC, otherwise it can be ES-SISTEC-20161014 > > > > Ciprian > > > > > > On Tue, Sep 27, 2016 at 4:08 PM, Marco Schmidt > > wrote: > > > >> Dear colleagues, > >> > >> The draft documents for version 4.0 of the policy proposal 2015-04, "RIPE > >> Resource Transfer Policies" have now been published, along with an impact > >> analysis conducted by the RIPE NCC. > >> > >> The goal of this proposal is to create a single document with all > >> relevant information regarding the transfer of Internet number resources. > >> > >> Some of the differences from version 3.0 include: > >> > >> - Adding a reference in all related allocation and assignment policies to > >> the new transfer policy document > >> - Clarification in the policy text and policy summary regarding transfers > >> due to a change in the organisation?s business (such as a merger or > >> acquisition) > >> > >> You can find the full proposal and the impact analysis at: > >> https://www.ripe.net/participate/policies/proposals/2015-04 > >> > >> And the draft documents at: > >> https://www.ripe.net/participate/policies/proposals/2015-04/draft > >> > >> We encourage you to read the draft document and send any comments to < > >> address-policy-wg at ripe.net > >> > before 26 > >> October 2016. > >> > >> Regards > >> > >> Marco Schmidt > >> Policy Development Officer > >> RIPE NCC > >> > >> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > >> > >> > > From h.lu at anytimechinese.com Wed Oct 19 12:33:09 2016 From: h.lu at anytimechinese.com (Lu Heng) Date: Wed, 19 Oct 2016 12:33:09 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <20161019101857.GY79185@Space.Net> References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> Message-ID: Hi On 19 October 2016 at 12:18, Gert Doering wrote: > Hi, > > On Wed, Oct 19, 2016 at 12:00:47PM +0200, Lu Heng wrote: > [..] > > What I have said is one of the concern that have to be addressd with an > > reasonable counter argument. > > Thanks for the clarification. > > > Chair's job is not collecting vote but make sure all concerns have been > > addressed reasonablely. > > Thanks for telling me what my job is, I wouldn't have guessed otherwise. > > Just for the record: part of the WG Chair's job is to judge the "roughness" > of consensus based on the amount of supporting and opposing voices - both > the number, and the quality of arguments have to be weighted (and to some > extent the person making a certain argument). > > And if I cannot be sure what to make out of a statement, then I can either > ask for clarity, or just discard as "random noise". > Agian, voicing concern is not exact same thing as "opposition", I have a concern, if it can be addressed well with reasonable conter argument, I might support. It's the very defination of the process ?reaching consensus". But again, I think it is not about the policy in discussion, we should stop here. I agree with Nick just said, it does not fix the core problem: the large eonomical difference between RIPE NCC member fees and market price for IPv4 will permenent exsists, Ramco said puting a sticker "not for sale" to decrease its value, it might be true, but the gap in those two mgiht just be too big(and will be bigger in the future) to close. > Gert Doering > -- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From office at ip-broker.uk Wed Oct 19 12:33:56 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Wed, 19 Oct 2016 13:33:56 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <1476872927.1385031.760673489.6C19D69E@webmail.messagingengine.com> References: <1476872927.1385031.760673489.6C19D69E@webmail.messagingengine.com> Message-ID: The policy states how the statistics are presented, therefore I think this issue should be addressed by the policy. RIPE NCC implements the policies and if we, the RIPE community, want some things to be implemented in a certain way then the only way to "ask" it is through the policy, otherwise our voices have no value. Regarding the lack of details at point B., that is in my opinion an insult to the community, regardless of what the policy is about. We should not accept generic statements like that. If nobody bothered to really make an impact analysis then just say it. Ciprian On Wednesday, October 19, 2016, Radu-Adrian FEURDEAN < ripe-wgs at radu-adrian.feurdean.net> wrote: > Hi, > > While I do agree with most of the concerns you present there, I'm > wondering if this is not an issue to be discussed in some other working > group (??? services ??? database ???). They don't seem to be related to > the policy itself, but to the way RIPE NCC implements it and reflects > the changes in the database. > > Marco ? Chairs ? anybody else ? > > -- > Radu-Adrian FEURDEAN > > On Wed, Oct 19, 2016, at 11:57, Ciprian Nica wrote: > > > > Hi, > > > > > > I think it would be useful to list on the statistics also the broker > that > > > facilitated the transfer. That might be of interest to the community > and I > > > think the NCC should revise the transfer agreement template in order > to be > > > able to mention the broker and also to publish it's name on the > transfer > > > statistics page. Also the broker should be allowed to communicate with > RIPE > > > and pass information on behalf of the customers during the transfer > process. > > > > > > There is also a cosmetic thing that I don't know if it needs be > mentioned > > > in policy in order to be implemented. The netname of the allocation > keeps > > > the original allocation date in it's name which can be confusing > although > > > there's the new "created" attribute. > > > > > > For example, the subnet 128.0.52.0/24 was transferred on 14/10/2016 > and > > > it was part of an allocation with netname EU-JM-20120914. The new > > > allocation has netname ES-SISTEC-20120914. > > > > > > If the date is no longer relevant in a netname then I think it should > be > > > simply ES-SISTEC, otherwise it can be ES-SISTEC-20161014 > > > > > > Ciprian > > > > > > > > > On Tue, Sep 27, 2016 at 4:08 PM, Marco Schmidt > > > ');>> > wrote: > > > > > >> Dear colleagues, > > >> > > >> The draft documents for version 4.0 of the policy proposal 2015-04, > "RIPE > > >> Resource Transfer Policies" have now been published, along with an > impact > > >> analysis conducted by the RIPE NCC. > > >> > > >> The goal of this proposal is to create a single document with all > > >> relevant information regarding the transfer of Internet number > resources. > > >> > > >> Some of the differences from version 3.0 include: > > >> > > >> - Adding a reference in all related allocation and assignment > policies to > > >> the new transfer policy document > > >> - Clarification in the policy text and policy summary regarding > transfers > > >> due to a change in the organisation?s business (such as a merger or > > >> acquisition) > > >> > > >> You can find the full proposal and the impact analysis at: > > >> https://www.ripe.net/participate/policies/proposals/2015-04 > > >> > > >> And the draft documents at: > > >> https://www.ripe.net/participate/policies/proposals/2015-04/draft > > >> > > >> We encourage you to read the draft document and send any comments to < > > >> address-policy-wg at ripe.net > > >> ');>> before 26 > > >> October 2016. > > >> > > >> Regards > > >> > > >> Marco Schmidt > > >> Policy Development Officer > > >> RIPE NCC > > >> > > >> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > >> > > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richih.mailinglist at gmail.com Wed Oct 19 12:34:27 2016 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Wed, 19 Oct 2016 12:34:27 +0200 Subject: [address-policy-wg] [policy-announce] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <580742BC.8070300@foobar.org> References: <9f21a405-af43-9ca6-5ace-07802b2b9998@ripe.net> <580742BC.8070300@foobar.org> Message-ID: On Wed, Oct 19, 2016 at 11:54 AM, Nick Hilliard wrote: > https://www.ripe.net/participate/policies/proposals/2016-03/draft Thank you. It's not the case here, but it was the case in the past, that the actual diff and this curated overview differed. This is why I personally prefer autogenerated diffs and the well established workflows around code review. Credit where credit is due: The link above is correct down to every last full stop, newline, and whitespace. I checked. Richard From office at ip-broker.uk Wed Oct 19 12:36:16 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Wed, 19 Oct 2016 13:36:16 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <7F2324C7-B6FE-46AD-84E3-15F0F34D4EA8@plesa.ro> References: <7F2324C7-B6FE-46AD-84E3-15F0F34D4EA8@plesa.ro> Message-ID: I totally agree with the AS number situation. When I worked for RCS&RDS we acquired many companies and although we kept some AS numbers, it really makes no sense in putting a 24 months lock on them. Ciprian On Wednesday, October 19, 2016, Plesa Niculae wrote: > Dear colleagues, > > Regarding the [address-policy-wg] 2015-04 New Version and Impact Analysis > Published (RIPE Resource Transfer Policies): > > The supposed purpose of the policy was to organise more efficiently, in a > single document, the rules regarding transfer of resources but it brings a > restriction which has not been properly analysed and debated. In my opinion > there are many cases when two ISPs would merge. Due to the restructuring > after the merger it is likely that the IPs could be used more efficiently > and the resulting company would have spare resources that could be > transferred like one of the AS numbers and maybe some IPs. If both > companies have received the IPs and AS numbers many years ago, why should > they not be able to transfer the resulting unused resources after the > merger ? There is no logical point in that. Maybe there would not result > some unused IPs but at least there is a 100% certainty that one of the AS > numbers would become useless. This policy would force the company to keep > it for 24 months just because they did a merger ? In today?s market it's > quite common that smaller ISPs get acquired by larger ones and the policy > would impose some restrictions which makes no sense. > > I have more observations regarding other non-sense and incorrect terms of > the proposed policy, but first I really want to see if Marco, together with > the RIPE team, really want to discuss and make modifications according the > general good and common sense or everybody wants to pass this policy, like > most of them, with no real answers to the problems raised. We will pass > this policy in fanfare sounds, without any modifications, like the most of > the past ones, or we will look seriously at members observations and change > the policy accordingly? > > Best Regards > Niculae Plesa > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From office at ip-broker.uk Wed Oct 19 12:44:25 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Wed, 19 Oct 2016 13:44:25 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <20161019101857.GY79185@Space.Net> References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> Message-ID: > Just for the record: part of the WG Chair's job is to judge the "roughness" > of consensus based on the amount of supporting and opposing voices - both > the number, and the quality of arguments have to be weighted (and to some > extent the person making a certain argument). > I'm certainly not among the fans of Lu but seeing such a statement from the WG Chair is unbelieveble. Really ? Do you ever judge a statement based on who is making it and not objectively ? In my opinion there is no space for any such extent and yes your job should be to represent an impartial and objective arbitration. Otherwise, I get the impression you are many times too subjective and try to enforce your personal opinions on others. If you can not be impartial and objective it would be only honourable from you to step down, join us in the debates and let someone else do the job. But as I've noticed (and nobody cared) you're one of the hoarders of last /8 so I really don't expect you to do that. Ciprian -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Wed Oct 19 13:11:12 2016 From: gert at space.net (Gert Doering) Date: Wed, 19 Oct 2016 13:11:12 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> Message-ID: <20161019111112.GA79185@Space.Net> Hi, On Wed, Oct 19, 2016 at 01:44:25PM +0300, Ciprian Nica wrote: > > Just for the record: part of the WG Chair's job is to judge the "roughness" > > of consensus based on the amount of supporting and opposing voices - both > > the number, and the quality of arguments have to be weighted (and to some > > extent the person making a certain argument). > > I'm certainly not among the fans of Lu but seeing such a statement from the > WG Chair is unbelieveble. Really ? Do you ever judge a statement based on > who is making it and not objectively ? If we introduce a policy that will stop abusive behaviour by a certain minority of the community, *or course* those minority will cry out very loudly that they will oppose the proposal. It would be very surprising to see otherwise. Is it relevant that they are not overly happy with us trying to stop their abusive behaviour? Not very much so. Of course this requires some community agreement on what "abusive" means, so it's very rarely as clear-cut as this. I am not *ignoring* people that turn out to be abusive, violating RIPE DB T&C, or are otherwise being an annoyance - but when the discussion is less than clear cut, arguments that are brought forward in a sensible, well considered and *understandable* way are weighted stronger than yelling... Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From noc at ntx.ru Wed Oct 19 13:23:03 2016 From: noc at ntx.ru (NTX NOC) Date: Wed, 19 Oct 2016 14:23:03 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <7F2324C7-B6FE-46AD-84E3-15F0F34D4EA8@plesa.ro> Message-ID: <4302f6ba-b28b-130e-6695-a78f92398f42@ntx.ru> Agree with AS numbers. There should not be any limit. Yuri On 19.10.2016 13:36, Ciprian Nica wrote: > I totally agree with the AS number situation. When I worked for RCS&RDS > we acquired many companies and although we kept some AS numbers, it > really makes no sense in putting a 24 months lock on them. > > Ciprian > > On Wednesday, October 19, 2016, Plesa Niculae > wrote: > > Dear colleagues, > > Regarding the [address-policy-wg] 2015-04 New Version and Impact > Analysis Published (RIPE Resource Transfer Policies): > > The supposed purpose of the policy was to organise more efficiently, > in a single document, the rules regarding transfer of resources but > it brings a restriction which has not been properly analysed and > debated. In my opinion there are many cases when two ISPs would > merge. Due to the restructuring after the merger it is likely that > the IPs could be used more efficiently and the resulting company > would have spare resources that could be transferred like one of the > AS numbers and maybe some IPs. If both companies have received the > IPs and AS numbers many years ago, why should they not be able to > transfer the resulting unused resources after the merger ? There is > no logical point in that. Maybe there would not result some unused > IPs but at least there is a 100% certainty that one of the AS > numbers would become useless. This policy would force the company to > keep it for 24 months just because they did a merger ? In today?s > market it's quite common that smaller ISPs get acquired by larger > ones and the policy would impose some restrictions which makes no sense. > > I have more observations regarding other non-sense and incorrect > terms of the proposed policy, but first I really want to see if > Marco, together with the RIPE team, really want to discuss and make > modifications according the general good and common sense or > everybody wants to pass this policy, like most of them, with no real > answers to the problems raised. We will pass this policy in fanfare > sounds, without any modifications, like the most of the past ones, > or we will look seriously at members observations and change the > policy accordingly? > > Best Regards > Niculae Plesa > > > From marius.cristea at ipv4trade.eu Wed Oct 19 13:16:30 2016 From: marius.cristea at ipv4trade.eu (Marius Cristea) Date: Wed, 19 Oct 2016 14:16:30 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) Message-ID: Dear colleagues, Over the last years RIPE NCC has imposed a "rule" that when the last IPs are transferred the transferring LIR has to pay the full annual membership fee (even if the LIR was not a member of RIPE for that entire year). I think that if this is something everybody agrees with, it should be inserted into the policy text to make this very clear. But if not, then maybe it would be useful to add a text which would simply say that RIPE NCC should relate exclusively on this policy when processing transfer requests and is not mandated by the RIPE community in imposing any kind of abusive taxes. I also have a problem with the 24 months period of keeping the IPv4 addresses after merging 2 companies. It's exactly our case, we want to buy and merge with a telecom company and we will no longer need all their IPv4 addresses since we have more than enough by merging both companies resources. We want to transfer a part of the IP addresses to other Company that really need them. Why to wait 24 months? Best Regards, Marius Cristea From Flavio.Palumbo at wind.it Wed Oct 19 13:26:39 2016 From: Flavio.Palumbo at wind.it (Palumbo Flavio) Date: Wed, 19 Oct 2016 11:26:39 +0000 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <4302f6ba-b28b-130e-6695-a78f92398f42@ntx.ru> References: <7F2324C7-B6FE-46AD-84E3-15F0F34D4EA8@plesa.ro> , <4302f6ba-b28b-130e-6695-a78f92398f42@ntx.ru> Message-ID: <590C1B96-04DE-45A8-A709-0848FC32B8C2@wind.it> Totally Agree with Niculae > Il giorno 19 ott 2016, alle ore 13:23, NTX NOC ha scritto: > > Agree with AS numbers. There should not be any limit. > > Yuri > > >> On 19.10.2016 13:36, Ciprian Nica wrote: >> I totally agree with the AS number situation. When I worked for RCS&RDS >> we acquired many companies and although we kept some AS numbers, it >> really makes no sense in putting a 24 months lock on them. >> >> Ciprian >> >> On Wednesday, October 19, 2016, Plesa Niculae > > wrote: >> >> Dear colleagues, >> >> Regarding the [address-policy-wg] 2015-04 New Version and Impact >> Analysis Published (RIPE Resource Transfer Policies): >> >> The supposed purpose of the policy was to organise more efficiently, >> in a single document, the rules regarding transfer of resources but >> it brings a restriction which has not been properly analysed and >> debated. In my opinion there are many cases when two ISPs would >> merge. Due to the restructuring after the merger it is likely that >> the IPs could be used more efficiently and the resulting company >> would have spare resources that could be transferred like one of the >> AS numbers and maybe some IPs. If both companies have received the >> IPs and AS numbers many years ago, why should they not be able to >> transfer the resulting unused resources after the merger ? There is >> no logical point in that. Maybe there would not result some unused >> IPs but at least there is a 100% certainty that one of the AS >> numbers would become useless. This policy would force the company to >> keep it for 24 months just because they did a merger ? In today?s >> market it's quite common that smaller ISPs get acquired by larger >> ones and the policy would impose some restrictions which makes no sense. >> >> I have more observations regarding other non-sense and incorrect >> terms of the proposed policy, but first I really want to see if >> Marco, together with the RIPE team, really want to discuss and make >> modifications according the general good and common sense or >> everybody wants to pass this policy, like most of them, with no real >> answers to the problems raised. We will pass this policy in fanfare >> sounds, without any modifications, like the most of the past ones, >> or we will look seriously at members observations and change the >> policy accordingly? >> >> Best Regards >> Niculae Plesa >> >> >> > > > > Check Point Le informazioni contenute in questo messaggio di posta elettronica e in ogni eventuale documento allegato sono riservate, potrebbero essere coperte dal segreto professionale e possono essere utilizzate esclusivamente dal destinatario sopra indicato. Ogni divulgazione o copia di questo messaggio o dei suoi eventuali allegati non autorizzata, cosi' come ogni uso o divulgazione delle informazioni negli stessi contenute, sono da considerarsi come vietate e potrebbero costituire violazione delle normative ivi applicabili. Se ricevete questo messaggio per errore Vi preghiamo di volerci avvertire immediatamente tramite posta elettronica o telefonicamente e di cancellare il presente messaggio e ogni documento ad esso allegato dal Vostro sistema. Vi informiamo che svolgiamo ogni attivita' finalizzata a proteggere la nostra rete da virus e non ci assumiamo alcuna responsabilita' in ordine a possibili virus che possano essere trasferiti con la presente mail. Grazie. ***************** The information contained in this e-mail and in any file transmitted with it is confidential and may be privileged for the sole use of the designated addressee. Any unauthorized dissemination or copying of this e-mail or its attachments, and any use or disclosure of any information contained in them, is strictly prohibited and may be illegal. If you are not the designated addressee, please notify the sender immediately by e-mail or by telephone and delete this e-mail and any file transmitted with it from your system. We make every effort to keep our network free from viruses and take no responsibility for any computer virus which might be transferred by way of this e-mail. Thank you. From office at ip-broker.uk Wed Oct 19 13:34:40 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Wed, 19 Oct 2016 14:34:40 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <20161019111112.GA79185@Space.Net> References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> Message-ID: I think this discussion should not be about the right of the majority or about ignoring the minority. That is nazi thinking. We should discuss and appreciate ideas to their value. But my problem at this point is not with an idea being right or wrong but with the fact that you are not a fair arbitrer. As a WG Chair my opinion is that you should not take sides. Also NCC should not express opinions but implement policies fairly. It's a simple question from a member of the community to one of the WG Chairs: did you abuse the last /8 or not ? Do you consider yourself a neutral arbitrer or not ? Do you consider yourself the one that should be judging others ? Or is it your "job" to shut the voices that are not according to your interests ? What I have expressed are my opinions as objectives as I can. I really don't discriminate and there are many people which I don't like and I can support their ideas, as well as there are many people which I admire and which I can heavily oppose when it's the case. That's what we all shoud do. But you are not one of us, you are the Chair so we have different expectations. Maybe we shouldn't but then what is really your "job" over here ? Ciprian On Wednesday, October 19, 2016, Gert Doering wrote: > Hi, > > On Wed, Oct 19, 2016 at 01:44:25PM +0300, Ciprian Nica wrote > > > Just for the record: part of the WG Chair's job is to judge the > "roughness" > > > of consensus based on the amount of supporting and opposing voices - > both > > > the number, and the quality of arguments have to be weighted (and to > some > > > extent the person making a certain argument). > > > > I'm certainly not among the fans of Lu but seeing such a statement from > the > > WG Chair is unbelieveble. Really ? Do you ever judge a statement based on > > who is making it and not objectively ? > > If we introduce a policy that will stop abusive behaviour by a certain > minority of the community, *or course* those minority will cry out very > loudly that they will oppose the proposal. It would be very surprising > to see otherwise. > > Is it relevant that they are not overly happy with us trying to stop their > abusive behaviour? Not very much so. > > Of course this requires some community agreement on what "abusive" means, > so it's very rarely as clear-cut as this. > > > I am not *ignoring* people that turn out to be abusive, violating > RIPE DB T&C, or are otherwise being an annoyance - but when the discussion > is less than clear cut, arguments that are brought forward in a sensible, > well considered and *understandable* way are weighted stronger than > yelling... > > Gert Doering > -- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ian.Dickinson at sky.uk Wed Oct 19 13:38:22 2016 From: Ian.Dickinson at sky.uk (Dickinson, Ian) Date: Wed, 19 Oct 2016 11:38:22 +0000 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> Message-ID: <9B3BFE0A18160E40BAF1950414D10FAE6170E571@WPMBX010.bskyb.com> Please be civil Ciprian. This just reads like the standard tactic of throwing mud and hoping it sticks. Ian From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Ciprian Nica Sent: 19 October 2016 12:35 To: Gert Doering Cc: RIPE Address Policy WG List Subject: Re: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) I think this discussion should not be about the right of the majority or about ignoring the minority. That is nazi thinking. We should discuss and appreciate ideas to their value. But my problem at this point is not with an idea being right or wrong but with the fact that you are not a fair arbitrer. As a WG Chair my opinion is that you should not take sides. Also NCC should not express opinions but implement policies fairly. It's a simple question from a member of the community to one of the WG Chairs: did you abuse the last /8 or not ? Do you consider yourself a neutral arbitrer or not ? Do you consider yourself the one that should be judging others ? Or is it your "job" to shut the voices that are not according to your interests ? What I have expressed are my opinions as objectives as I can. I really don't discriminate and there are many people which I don't like and I can support their ideas, as well as there are many people which I admire and which I can heavily oppose when it's the case. That's what we all shoud do. But you are not one of us, you are the Chair so we have different expectations. Maybe we shouldn't but then what is really your "job" over here ? Ciprian On Wednesday, October 19, 2016, Gert Doering > wrote: Hi, On Wed, Oct 19, 2016 at 01:44:25PM +0300, Ciprian Nica wrote > > Just for the record: part of the WG Chair's job is to judge the "roughness" > > of consensus based on the amount of supporting and opposing voices - both > > the number, and the quality of arguments have to be weighted (and to some > > extent the person making a certain argument). > > I'm certainly not among the fans of Lu but seeing such a statement from the > WG Chair is unbelieveble. Really ? Do you ever judge a statement based on > who is making it and not objectively ? If we introduce a policy that will stop abusive behaviour by a certain minority of the community, *or course* those minority will cry out very loudly that they will oppose the proposal. It would be very surprising to see otherwise. Is it relevant that they are not overly happy with us trying to stop their abusive behaviour? Not very much so. Of course this requires some community agreement on what "abusive" means, so it's very rarely as clear-cut as this. I am not *ignoring* people that turn out to be abusive, violating RIPE DB T&C, or are otherwise being an annoyance - but when the discussion is less than clear cut, arguments that are brought forward in a sensible, well considered and *understandable* way are weighted stronger than yelling... Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at karotte.org Wed Oct 19 13:54:44 2016 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Wed, 19 Oct 2016 13:54:44 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> Message-ID: <20161019115444.GA24129@danton.fire-world.de> * Ciprian Nica [2016-10-19 13:36]: > I think this discussion should not be about the right of the majority or > about ignoring the minority. That is nazi thinking. We should discuss and > appreciate ideas to their value. [..] > What I have expressed are my opinions as objectives as I can. I really > don't discriminate and there are many people which I don't like and I can Yeah I can see how objective you are. But this is good. I can make a blacklist of broker companies just by reading this mailinglist. Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 581 bytes Desc: Digital signature URL: From gert at space.net Wed Oct 19 13:59:06 2016 From: gert at space.net (Gert Doering) Date: Wed, 19 Oct 2016 13:59:06 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> Message-ID: <20161019115906.GB79185@Space.Net> Hi, On Wed, Oct 19, 2016 at 02:34:40PM +0300, Ciprian Nica wrote: > It's a simple question from a member of the community to one of the WG > Chairs: did you abuse the last /8 or not ? Do you consider yourself a > neutral arbitrer or not ? Do you consider yourself the one that should be > judging others ? Or is it your "job" to shut the voices that are not > according to your interests ? Since you insist on riding that horse, I can no longer ignore it - so you'll have your answer. On record. Yes, one of the LIRs that I represent in RIPE member issues (de.space) is holding two /22s out of 185/8. The second /22 came into this LIR together with two /19s, some equipment, an extra employee, and a number of customers when we acquired a smaller regional ISP in 2014. As per community policy, this is well within letter and *spirit* of the policy - the LIR acquired was not "set up to get a /22 and be bought" (it existed for some 15 years), it was providing ISP services, and there were reasons that do not need to be disclosed that the owners wanted to sell it, which had nothing to do with IP addresses. The acquisition went through the regular M&A process with the RIPE NCC, and all documents were properly scrutinized (and I can tell stories how much detail the NCC will check, and how much paperwork is involved). Does the number of IP addresses one of the LIRs I can represent hold have any relevance on my serving as WG chair? No. Am I neutral regarding address policy? Well, I do my best. Sometimes this is not easy, as I do have strong concerns for the well-being of the Internet globally and in the RIPE region - but this is why there is two chairs here: Sander will double-check every decision made, and everything is public anyway. Summaries are written for a reason, and decisions are based *on posts on the list*, so it does not really matter how neutral I am, as everything is public, and you can double-check the conclusions (and possible call up the arbitration procedure). So, yes, I consider myself still suitable as a WG chair for the address policy WG. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From Ian.Dickinson at sky.uk Wed Oct 19 14:05:33 2016 From: Ian.Dickinson at sky.uk (Dickinson, Ian) Date: Wed, 19 Oct 2016 12:05:33 +0000 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <58074288.5000003@foobar.org> References: <58074288.5000003@foobar.org> Message-ID: <9B3BFE0A18160E40BAF1950414D10FAE6170E5A2@WPMBX010.bskyb.com> Nick sums up my opinion admirably. Whilst I have some sympathy with the aim, I do not believe it will achieve it, and there will be some unwarranted side-effects. -1 Do not support as is Ian -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Nick Hilliard Sent: 19 October 2016 10:53 To: Marco Schmidt Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) Marco Schmidt wrote: > We encourage you to read the draft document and send any comments to > before 17 November 2016. The purpose of the policy is to restrict the flow of /22 allocations from the RIPE remaining ipv4 pool. While I'm sympathetic to this idea, the policy is not going to fix the problem that it sets out to fix and will create a new set of problems which will be extremely difficult for the RIPE NCC to recover from. Consequently I do not support it, because: 1. the core problem won't be fixed: the outgoing flow of /22s will not be affected in any way because speculators will get allocations using shelf Companies which can be sold as-is, thereby bypassing any policy that the RIPE community might want to consider in this area. The only way to even begin to fix this would be to move back to a needs-based allocation policy. 2. unregistered transfers will become a problem and this may become intractable in the future. This directly goes against the core principals of the RIPE database which is to ensure accurate registration of address holder details. Also, asset divesting is not catered for in the policy. If a company / LIR splits up, there is no way to handle splitting of IPv4 address allocations in the policy. There is no clear way to fix this problem within the principals of the policy. As an aside note, the problem of ipv4 allocation speedup from the RIPE NCC has been exacerbated by the recent RIPE NCC GM resolution: "The General Meeting approves the ability of RIPE NCC members to create additional LIR accounts". The net effect of this is that there is now a divergence between intended RIPE policy and RIPE NCC implementation. This is probably not helpful in the long run. Nick Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. From tore at fud.no Wed Oct 19 14:08:09 2016 From: tore at fud.no (Tore Anderson) Date: Wed, 19 Oct 2016 14:08:09 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <20161019115906.GB79185@Space.Net> References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> Message-ID: <20161019140809.5214e093@envy.e1.y.home> * Gert Doering > I consider myself still suitable as a WG chair for the address policy > WG. +1 Tore From noc at ntx.ru Wed Oct 19 14:14:44 2016 From: noc at ntx.ru (NTX NOC) Date: Wed, 19 Oct 2016 15:14:44 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <995c0516-5432-5dbe-d00c-91fbb098c0b9@velder.li> References: <995c0516-5432-5dbe-d00c-91fbb098c0b9@velder.li> Message-ID: <3c06b607-f7ef-3812-8fc9-72c4100b295d@ntx.ru> Greetings! Also -1. I think the current policy that prevents transfers for 24 months is more then enough. There no need to change anything and make live more complex, hard and worse. We already have problems with merges when ripe start to request registry updates and that makes merges between international companies impossible in real. For last 1-2 years while we discuss limitations for new LIRs there was too much talks that all will crash if we don't accept new polices. But you can see by LIR registration stats that those changes doesn't affect stats at all. LIRs can get IPs. RIPE has more then enough IPs. Let's better work on IPv6. People don't need any locking and new statuses in inetnum-s. Yuri. On 19.10.2016 12:19, Patrick Velder wrote: > Hi > > I still disagree changing the status of already allocated resources. > > -1 from me. > > Regards > Patrick > > > On 19.10.2016 10:05, Marco Schmidt wrote: >> Dear colleagues, >> >> The draft documents for version 3.0 of the policy proposal 2016-03, >> "Locking Down the Final /8 Policy" have now been published, along with >> an impact analysis conducted by the RIPE NCC. >> >> The goal of this proposal is to ban transfers of allocations made >> under the final /8 policy. Also the proposal specifies what resources >> must be added to the RIPE NCC IPv4 available pool. >> >> Some of the differences from version 2.0 include: >> >> - Clarification that changes to holdership of address space as a >> result of company mergers or acquisitions are not affected by proposed >> transfer restriction >> - Legacy space handed over to the RIPE NCC will be added to the >> IPv4 available pool >> >> You can find the full proposal and the impact analysis at: >> https://www.ripe.net/participate/policies/proposals/2016-03 >> >> And the draft documents at: >> https://www.ripe.net/participate/policies/proposals/2016-03/draft >> >> We want to draw your attention to two changes, which we hope it will >> make your proposal evaluation easier. >> >> - Policy proposals now contain a diff tool that allows easy >> comparison of different proposal versions ? simply click on the ?View >> Changes? symbol right beside the list of proposal versions. >> - The RIPE NCC impact analysis only mentions areas where the >> proposal is actually expected to have an impact. For example, if the >> analysis makes no comment about financial or legal impact, it means >> that no such impact is expected. >> >> We encourage you to read the draft document and send any comments to >> before 17 November 2016. >> >> Regards, >> >> Marco Schmidt >> Policy Development Officer >> RIPE NCC >> >> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum >> > > From sebastian at karotte.org Wed Oct 19 14:18:47 2016 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Wed, 19 Oct 2016 14:18:47 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <20161019115906.GB79185@Space.Net> References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> Message-ID: <20161019121847.GB24129@danton.fire-world.de> * Gert Doering [2016-10-19 14:03]: > So, yes, I consider myself still suitable as a WG chair for the address > policy WG. Support. And thank you for doing a job that grows more and more thankless by the day. Nothing else to add except that I will mark the day when we run out of the last pool or (preferably) IPv6 takes over. I think some kind of celebration and/or group therapy will be in order. Best Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 581 bytes Desc: Digital signature URL: From jim at rfc1035.com Wed Oct 19 14:19:11 2016 From: jim at rfc1035.com (Jim Reid) Date: Wed, 19 Oct 2016 13:19:11 +0100 Subject: [address-policy-wg] unacceptable conduct and ad-hominem attacks In-Reply-To: References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> Message-ID: <3CD975BB-4F83-49D7-8292-8789588020BE@rfc1035.com> > On 19 Oct 2016, at 12:34, Ciprian Nica wrote: > > But my problem at this point is not with an idea being right or wrong but with the fact that you are not a fair arbitrer. In your (utterly flawed) opinion. I?m fairly sure the overwhelming majority of the people of this list have absolute confidence in the integrity of the WG?s co-chairs. If you think you can do better, feel free to stand the next time the appointment process runs. > As a WG Chair my opinion is that you should not take sides. There is no evidence whatsoever to support your claim that Gert (or Sander) are ?taking sides?. > It's a simple question from a member of the community to one of the WG Chairs: did you abuse the last /8 or not ? Do you consider yourself a neutral arbitrer or not ? Do you consider yourself the one that should be judging others ? Here?s a simple rhetorical question for you. Do you think making unjustified ad-hominem attacks and insults like the above will encourage support for your position on this policy proposal? Your behaviour here is unacceptable and way, way, way out of line. > Or is it your "job" to shut the voices that are not according to your interests ? No. That?s *my* job. :-) Until you apologise and learn how to conduct yourself properly on this list, Ciprian SHUT UP. From jim at rfc1035.com Wed Oct 19 14:21:01 2016 From: jim at rfc1035.com (Jim Reid) Date: Wed, 19 Oct 2016 13:21:01 +0100 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <20161019121847.GB24129@danton.fire-world.de> References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> <20161019121847.GB24129@danton.fire-world.de> Message-ID: <145A04C7-D524-4F10-BB26-30F24183715B@rfc1035.com> > On 19 Oct 2016, at 13:18, Sebastian Wiesinger wrote: > >> So, yes, I consider myself still suitable as a WG chair for the address >> policy WG. > > Support. And thank you for doing a job that grows more and more > thankless by the day. +100. I?m stunned beyond disbelief that Gert?s (or Sander?s) credentials could even questioned. From wolfgang.tremmel at de-cix.net Wed Oct 19 14:27:47 2016 From: wolfgang.tremmel at de-cix.net (Wolfgang Tremmel) Date: Wed, 19 Oct 2016 12:27:47 +0000 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <20161019115906.GB79185@Space.Net> References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> Message-ID: <6EB6E59B-FDCC-4990-9602-F7088836DC69@de-cix.net> > On 19 Oct 2016, at 13:59, Gert Doering wrote: > > So, yes, I consider myself still suitable as a WG chair for the address > policy WG. +1 I know Gert now for 15+ years and never doubted his integrity. And thanks for still doing the job - I imagine in 20+ years we all will wonder why anybody ever cared about the distribution of IPv4 addresses as everybody is happily using IPv6 best regards Wolfgang -- Wolfgang Tremmel Phone +49 69 1730902 0 | Fax +49 69 4056 2716 | wolfgang.tremmel at de-cix.net Geschaeftsfuehrer Harald A. Summa | Registergericht AG K?ln HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net From hank at efes.iucc.ac.il Wed Oct 19 14:47:53 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 19 Oct 2016 15:47:53 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <20161019115906.GB79185@Space.Net> References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> Message-ID: On 19/10/2016 14:59, Gert Doering wrote: > So, yes, I consider myself still suitable as a WG chair for the address > policy WG. As do I. -Hank > > Gert Doering > -- APWG chair From office at ip-broker.uk Wed Oct 19 14:51:12 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Wed, 19 Oct 2016 15:51:12 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <20161019115906.GB79185@Space.Net> References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> Message-ID: As I have mentioned before, getting a /22 only to sell it after a couple weeks shows that it was only requested in order to make some money and not for a real need. It's a small glitch that many took advantage of. Also the merger & acquisition policy at that time suited your interests very well but that's neither important. What raises a question is the fact that you say you treat opinions based on the person that issues that opinion and not just the idea and that you induce the idea that a minority's voice should be ignored because it's obvious a minority would just oppose the majority. These are the problems that need to be dealt with. I will never support discrimination based on appartenance to a minority or personal feelings based on previous experience. Yes, start praising people if that's the purpose of this list. Hitler was also a very praised man. Let's stop with the personal feelings between us and discuss the ideas which are the important ones. I will not bring into discussion the "petty crime" that you did by taking advantage of the policies and putting aside a /22 from the last /8. It was wrong of me to mention it and it really is not important at all. Ciprian On Wed, Oct 19, 2016 at 2:59 PM, Gert Doering wrote: > Hi, > > On Wed, Oct 19, 2016 at 02:34:40PM +0300, Ciprian Nica wrote: > > It's a simple question from a member of the community to one of the WG > > Chairs: did you abuse the last /8 or not ? Do you consider yourself a > > neutral arbitrer or not ? Do you consider yourself the one that should be > > judging others ? Or is it your "job" to shut the voices that are not > > according to your interests ? > > Since you insist on riding that horse, I can no longer ignore it - so > you'll have your answer. On record. > > Yes, one of the LIRs that I represent in RIPE member issues (de.space) > is holding two /22s out of 185/8. The second /22 came into this LIR > together with two /19s, some equipment, an extra employee, and a number > of customers when we acquired a smaller regional ISP in 2014. > > As per community policy, this is well within letter and *spirit* of the > policy - the LIR acquired was not "set up to get a /22 and be bought" > (it existed for some 15 years), it was providing ISP services, and > there were reasons that do not need to be disclosed that the owners wanted > to sell it, which had nothing to do with IP addresses. The acquisition > went through the regular M&A process with the RIPE NCC, and all documents > were properly scrutinized (and I can tell stories how much detail the > NCC will check, and how much paperwork is involved). > > > Does the number of IP addresses one of the LIRs I can represent hold > have any relevance on my serving as WG chair? No. > > > Am I neutral regarding address policy? Well, I do my best. > > Sometimes this is not easy, as I do have strong concerns for the well-being > of the Internet globally and in the RIPE region - but this is why there > is two chairs here: Sander will double-check every decision made, and > everything is public anyway. Summaries are written for a reason, and > decisions are based *on posts on the list*, so it does not really matter > how neutral I am, as everything is public, and you can double-check the > conclusions (and possible call up the arbitration procedure). > > > So, yes, I consider myself still suitable as a WG chair for the address > policy WG. > > Gert Doering > -- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From office at ip-broker.uk Wed Oct 19 14:58:38 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Wed, 19 Oct 2016 15:58:38 +0300 Subject: [address-policy-wg] unacceptable conduct and ad-hominem attacks In-Reply-To: References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <3CD975BB-4F83-49D7-8292-8789588020BE@rfc1035.com> Message-ID: On Wed, Oct 19, 2016 at 3:19 PM, Jim Reid wrote: > > > On 19 Oct 2016, at 12:34, Ciprian Nica wrote: > > > > But my problem at this point is not with an idea being right or wrong > but with the fact that you are not a fair arbitrer. > > In your (utterly flawed) opinion. > > I respect everyone's opinion and especially yours. > I?m fairly sure the overwhelming majority of the people of this list have > absolute confidence in the integrity of the WG?s co-chairs. If you think > you can do better, feel free to stand the next time the appointment process > runs. > > I never care about the majority and I don't think that should be a standard. Time has proven that sometimes majorities are wrong. > > As a WG Chair my opinion is that you should not take sides. > > There is no evidence whatsoever to support your claim that Gert (or > Sander) are ?taking sides?. > Supporting an idea and ignoring someone based on personal feelings means taking sides. > > It's a simple question from a member of the community to one of the WG > Chairs: did you abuse the last /8 or not ? Do you consider yourself a > neutral arbitrer or not ? Do you consider yourself the one that should be > judging others ? > > Here?s a simple rhetorical question for you. Do you think making > unjustified ad-hominem attacks and insults like the above will encourage > support for your position on this policy proposal? > > Your behaviour here is unacceptable and way, way, way out of line. > > With power comes responsibility. And yes, we should question our "leaders" all the time. This is not something wrong, it's helpful for keeping the balance. > > Or is it your "job" to shut the voices that are not according to your > interests ? > > No. That?s *my* job. :-) > > Until you apologise and learn how to conduct yourself properly on this > list, Ciprian SHUT UP. Unsubscribe, shut up, go away... Next time you'll send me to a concentration camp ? No I WILL NOT SHUT UP ! I will always express my opinion even if I'm the only one in the world supporting it. A great romanian said that the best definition of democracy is "I will fight till my last drop of blood so you will have the right to disagree with me". I know many don't like it and prefer to solve matters by putting the fist into minority's mouth. Who'll be next in line to be "killed" tomorrow ? Ciprian -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhe at nosc.ja.net Wed Oct 19 14:59:03 2016 From: rhe at nosc.ja.net (Rob Evans) Date: Wed, 19 Oct 2016 13:59:03 +0100 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> Message-ID: <20161019125903.GA31428@Robs-MacBook-2.local> > Yes, start praising people if that's the purpose of this list. Hitler was > also a very praised man. Godwin! Rob From phessler at theapt.org Wed Oct 19 14:59:25 2016 From: phessler at theapt.org (Peter Hessler) Date: Wed, 19 Oct 2016 14:59:25 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> Message-ID: <20161019125925.GG27221@gir.theapt.org> Ciprian You have invoked Nazis and Hitler in two different emails to this list. This is incredibly offensive, for so many reasons. You need to calm down, and think very serious thoughts about your behaviour on this list. Nobody, and certainly NOT Gert or anyone else on a mailing list deserves to be treated that way. -peter From max at rfc2324.org Wed Oct 19 14:59:27 2016 From: max at rfc2324.org (Maximilian Wilhelm) Date: Wed, 19 Oct 2016 14:59:27 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> Message-ID: <20161019125927.GQ25148@principal.rfc2324.org> Anno domini 2016 Ciprian Nica scripsit: [...] > Yes, start praising people if that's the purpose of this list. Hitler was > also a very praised man. https://en.wikipedia.org/wiki/Godwin%27s_law Best Max From rogerj at gmail.com Wed Oct 19 15:01:48 2016 From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=) Date: Wed, 19 Oct 2016 15:01:48 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <145A04C7-D524-4F10-BB26-30F24183715B@rfc1035.com> References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> <20161019121847.GB24129@danton.fire-world.de> <145A04C7-D524-4F10-BB26-30F24183715B@rfc1035.com> Message-ID: On Wed, Oct 19, 2016 at 2:21 PM, Jim Reid wrote: >> On 19 Oct 2016, at 13:18, Sebastian Wiesinger wrote: >>> On Wed, Oct 19, 2016 at 1:59 PM, Gert Doering wrote: ... >>> So, yes, I consider myself still suitable as a WG chair for the address >>> policy WG. >> >> Support. And thank you for doing a job that grows more and more >> thankless by the day. > > +100. I?m stunned beyond disbelief that Gert?s (or Sander?s) credentials could even questioned. Guess it's a last resort when they see that they are running out of arguments? And amazing that some people have turned to "personal" attacks here rather than discussing the policy at hand. Either way - well handled Gert, you got my full support. Regarding the policy at hand, even considering Nick Hillard's argument it's hard to not support this policy. It at least try to solve a almost impossible problem to solve, better to do some than nothing? So a clear support from me. And our MAIN problem is the few players that really really hard try to game the system, they should be banned somehow but that's hard. I guess we need the board of RIPE NCC to once in a while step up and block things when they see clear abuse. -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From office at ip-broker.uk Wed Oct 19 15:10:59 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Wed, 19 Oct 2016 16:10:59 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> <20161019121847.GB24129@danton.fire-world.de> <145A04C7-D524-4F10-BB26-30F24183715B@rfc1035.com> Message-ID: > I guess we need the board of RIPE NCC to once in a while step up and > block things when > they see clear abuse. > Here is the fact: % Version 1 of object "185.54.120.0 - 185.54.123.255" % This version was a UPDATE operation on 2014-04-17 16:59 % You can use "--list-versions" to get a list of versions for an object. inetnum: 185.54.120.0 - 185.54.123.255 netname: DE-TRANSNET-20140417 descr: TRANSNET Internet Services GmbH country: DE org: ORG-TA16-RIPE % Version 2 of object "185.54.120.0 - 185.54.123.255" % This version was a UPDATE operation on 2014-07-30 15:41 % You can use "--list-versions" to get a list of versions for an object. inetnum: 185.54.120.0 - 185.54.123.255 netname: DE-SPACE-20140417 descr: SpaceNet AG country: DE 13 days after getting a /22 it was merged to Gert's LIR while he has a /22 which was never announced in the internet. Getting a /22 without ever announcing it for over 2 years plus getting a /22 just to transfer it after a couple weeks, that's a fact. I have detailed it as you keep insisting. I'm not making any wild accusations. These are the facts. So Gert did 2 actions which are against the spirit of this community. Praise him as much as you want for it but don't shut me for bringing this out. Support his anti-minority and personal feelings attitude if that's the kind of chair you like but who gives you the right not to allow me to express my opinion ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From erey at ernw.de Wed Oct 19 15:18:51 2016 From: erey at ernw.de (Enno Rey) Date: Wed, 19 Oct 2016 15:18:51 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> <20161019121847.GB24129@danton.fire-world.de> <145A04C7-D524-4F10-BB26-30F24183715B@rfc1035.com> Message-ID: <20161019131851.GC88790@ernw.de> Ciprian, a simple inquiry with the search engine of your choice would have revealed there was a M&A process involved in the transaction below. Making false accusations is probably even worse then ad hominem attacks. Feel free to reply to me off-list or approach me in Madrid in case you intend to reply to this. That way you're only wasting my time. thanks Enno On Wed, Oct 19, 2016 at 04:10:59PM +0300, Ciprian Nica wrote: > > I guess we need the board of RIPE NCC to once in a while step up and > > block things when > > they see clear abuse. > > > > Here is the fact: > > % Version 1 of object "185.54.120.0 - 185.54.123.255" > > % This version was a UPDATE operation on 2014-04-17 16:59 > > % You can use "--list-versions" to get a list of versions for an object. > > > inetnum: 185.54.120.0 - 185.54.123.255 > > netname: DE-TRANSNET-20140417 > > descr: TRANSNET Internet Services GmbH > > country: DE > > org: ORG-TA16-RIPE > > > % Version 2 of object "185.54.120.0 - 185.54.123.255" > > % This version was a UPDATE operation on 2014-07-30 15:41 > > % You can use "--list-versions" to get a list of versions for an object. > > > inetnum: 185.54.120.0 - 185.54.123.255 > > netname: DE-SPACE-20140417 > > descr: SpaceNet AG > > country: DE > > > 13 days after getting a /22 it was merged to Gert's LIR while he has a /22 > which was never announced in the internet. > > Getting a /22 without ever announcing it for over 2 years plus getting a > /22 just to transfer it after a couple weeks, that's a fact. > > I have detailed it as you keep insisting. I'm not making any wild > accusations. These are the facts. > > So Gert did 2 actions which are against the spirit of this community. > Praise him as much as you want for it but don't shut me for bringing this > out. > > Support his anti-minority and personal feelings attitude if that's the kind > of chair you like but who gives you the right not to allow me to express my > opinion ? -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From frettled at gmail.com Wed Oct 19 15:22:44 2016 From: frettled at gmail.com (Jan Ingvoldstad) Date: Wed, 19 Oct 2016 15:22:44 +0200 Subject: [address-policy-wg] unacceptable conduct and ad-hominem attacks In-Reply-To: References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <3CD975BB-4F83-49D7-8292-8789588020BE@rfc1035.com> Message-ID: On Wed, Oct 19, 2016 at 2:58 PM, Ciprian Nica wrote: > > > Unsubscribe, shut up, go away... Next time you'll send me to a > concentration camp ? No I WILL NOT SHUT UP ! I will always express my > opinion even if I'm the only one in the world supporting it. A great > romanian said that the best definition of democracy is "I will fight till > my last drop of blood so you will have the right to disagree with me". > > Your democratic right is to express your opinions without persecution from governmental authorities (with certain limitations). However, this is not a democracy. Additionally, you do not have the right to force your invective on others. We are not obliged to listen or read what you write, and as a mailing list member, you are obliged to at least a minimum of civility and courtesy to other members of the same list, be they WG chairs, or regular members. Calling them nazis and implicating that reacting to your behaviour is to send you to a concentration camp is far, far out of line, and shows that you're too disconnected from reality to listen to or respect, sorry. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerald at ax.tc Wed Oct 19 15:26:27 2016 From: gerald at ax.tc (Gerald K.) Date: Wed, 19 Oct 2016 15:26:27 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <20161019115906.GB79185@Space.Net> References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> Message-ID: I'am totally fine with Gert as WG chair. He represent the initial attitude of the RIPE NCC ("serving" the community) much more then the (few?) others on this list which provoke with their new commercial business plans based only on the one fact that IPv4 will run out and therefore could be considered as an valuable asset to make $$$ from IP addresses directly without any technical need. Yes this it capitalism. But I do not have to like it in every case. And I do not like it in this case. -- Gerald (AS20783) From frettled at gmail.com Wed Oct 19 15:28:05 2016 From: frettled at gmail.com (Jan Ingvoldstad) Date: Wed, 19 Oct 2016 15:28:05 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> <20161019121847.GB24129@danton.fire-world.de> <145A04C7-D524-4F10-BB26-30F24183715B@rfc1035.com> Message-ID: On Wed, Oct 19, 2016 at 3:01 PM, Roger J?rgensen wrote: > > Guess it's a last resort when they see that they are running out of > arguments? And amazing that > some people have turned to "personal" attacks here rather than > discussing the policy at hand. > > > Either way - well handled Gert, you got my full support. > I agree completely, thanks for voicing it that way. Regarding the policy at hand, even considering Nick Hillard's argument > it's hard to not support > this policy. It at least try to solve a almost impossible problem to > solve, better to do some > than nothing? So a clear support from me. > I support the proposal. The current text appears sufficiently improved to address the concerns raised, as I see it. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From office at ip-broker.uk Wed Oct 19 15:28:25 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Wed, 19 Oct 2016 16:28:25 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <20161019131851.GC88790@ernw.de> References: <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> <20161019121847.GB24129@danton.fire-world.de> <145A04C7-D524-4F10-BB26-30F24183715B@rfc1035.com> <20161019131851.GC88790@ernw.de> Message-ID: No, you are the one wasting my time and if anyone else has something to tell to me I'll be available in Madrid starting tomorrow. Please first read carefully and try to understand what I wrote. I never said Gert did something that was against any policy. Probably he never did such things. But he clearly took advantage of the merger & acquisition procedure and now he tries to close it through the policy 2015-04. Isn't this hypocrisy ? But let's not mix the discussions. My main concern is that two policies which are not properly discussed and approved by the community, which seem far from having a consensus (as far as I can see) will most likely be seen by the chair as perfect solutions that need to be implemented right away and he will say that there is consensus even if it isn't. I would remind you that it was another policy when Gert stepped down and admitted that he wouldn't consider himself objective enough and let Sanders take the decision. If he can't be objective enough from time to time, then ... just praise him, what else would you do ? Ciprian On Wed, Oct 19, 2016 at 4:18 PM, Enno Rey wrote: > Ciprian, > > a simple inquiry with the search engine of your choice would have revealed > there was a M&A process involved in the transaction below. > Making false accusations is probably even worse then ad hominem attacks. > > Feel free to reply to me off-list or approach me in Madrid in case you > intend to reply to this. That way you're only wasting my time. > > thanks > > Enno > > > > On Wed, Oct 19, 2016 at 04:10:59PM +0300, Ciprian Nica wrote: > > > I guess we need the board of RIPE NCC to once in a while step up and > > > block things when > > > they see clear abuse. > > > > > > > Here is the fact: > > > > % Version 1 of object "185.54.120.0 - 185.54.123.255" > > > > % This version was a UPDATE operation on 2014-04-17 16:59 > > > > % You can use "--list-versions" to get a list of versions for an object. > > > > > > inetnum: 185.54.120.0 - 185.54.123.255 > > > > netname: DE-TRANSNET-20140417 > > > > descr: TRANSNET Internet Services GmbH > > > > country: DE > > > > org: ORG-TA16-RIPE > > > > > > % Version 2 of object "185.54.120.0 - 185.54.123.255" > > > > % This version was a UPDATE operation on 2014-07-30 15:41 > > > > % You can use "--list-versions" to get a list of versions for an object. > > > > > > inetnum: 185.54.120.0 - 185.54.123.255 > > > > netname: DE-SPACE-20140417 > > > > descr: SpaceNet AG > > > > country: DE > > > > > > 13 days after getting a /22 it was merged to Gert's LIR while he has a > /22 > > which was never announced in the internet. > > > > Getting a /22 without ever announcing it for over 2 years plus getting a > > /22 just to transfer it after a couple weeks, that's a fact. > > > > I have detailed it as you keep insisting. I'm not making any wild > > accusations. These are the facts. > > > > So Gert did 2 actions which are against the spirit of this community. > > Praise him as much as you want for it but don't shut me for bringing this > > out. > > > > Support his anti-minority and personal feelings attitude if that's the > kind > > of chair you like but who gives you the right not to allow me to express > my > > opinion ? > > -- > Enno Rey > > ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de > Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 > > Handelsregister Mannheim: HRB 337135 > Geschaeftsfuehrer: Enno Rey > > ======================================================= > Blog: www.insinuator.net || Conference: www.troopers.de > Twitter: @Enno_Insinuator > ======================================================= > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From listas at cutre.net Wed Oct 19 15:31:59 2016 From: listas at cutre.net (listas at cutre.net) Date: Wed, 19 Oct 2016 15:31:59 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <6EB6E59B-FDCC-4990-9602-F7088836DC69@de-cix.net> References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> <6EB6E59B-FDCC-4990-9602-F7088836DC69@de-cix.net> Message-ID: <20478D23-D837-4093-8DD5-C17FD537CEC9@cutre.net> +1 > El 19/10/2016, a las 14:27, Wolfgang Tremmel escribi?: > > >> On 19 Oct 2016, at 13:59, Gert Doering wrote: >> >> So, yes, I consider myself still suitable as a WG chair for the address >> policy WG. > > +1 > > I know Gert now for 15+ years and never doubted his integrity. > > And thanks for still doing the job - I imagine in 20+ years we all will wonder why anybody ever cared about the distribution of IPv4 addresses as everybody is happily using IPv6 > > best regards > Wolfgang > > -- > Wolfgang Tremmel > > Phone +49 69 1730902 0 | Fax +49 69 4056 2716 | wolfgang.tremmel at de-cix.net > Geschaeftsfuehrer Harald A. Summa | Registergericht AG K?ln HRB 51135 > DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net > > > > > From rogerj at gmail.com Wed Oct 19 15:32:34 2016 From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=) Date: Wed, 19 Oct 2016 15:32:34 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> <20161019121847.GB24129@danton.fire-world.de> <145A04C7-D524-4F10-BB26-30F24183715B@rfc1035.com> Message-ID: Ciprian Nica, If you have a problem with someone, or claim someone is abusing something take it up with RIPE NCC. NOT THIS LIST! Can you please for now just shut up with your noise? Chair/RIPE NCC/whoever, can someone consider if there is reason to actual give Ciprian a warning and possible forced unsub? On Wed, Oct 19, 2016 at 3:10 PM, Ciprian Nica wrote: > >> >> I guess we need the board of RIPE NCC to once in a while step up and >> block things when >> they see clear abuse. > > > Here is the fact: > > % Version 1 of object "185.54.120.0 - 185.54.123.255" > > % This version was a UPDATE operation on 2014-04-17 16:59 > > % You can use "--list-versions" to get a list of versions for an object. > > > inetnum: 185.54.120.0 - 185.54.123.255 > > netname: DE-TRANSNET-20140417 > > descr: TRANSNET Internet Services GmbH > > country: DE > > org: ORG-TA16-RIPE > > > % Version 2 of object "185.54.120.0 - 185.54.123.255" > > % This version was a UPDATE operation on 2014-07-30 15:41 > > % You can use "--list-versions" to get a list of versions for an object. > > > inetnum: 185.54.120.0 - 185.54.123.255 > > netname: DE-SPACE-20140417 > > descr: SpaceNet AG > > country: DE > > > > 13 days after getting a /22 it was merged to Gert's LIR while he has a /22 > which was never announced in the internet. > > Getting a /22 without ever announcing it for over 2 years plus getting a /22 > just to transfer it after a couple weeks, that's a fact. > > I have detailed it as you keep insisting. I'm not making any wild > accusations. These are the facts. > > So Gert did 2 actions which are against the spirit of this community. Praise > him as much as you want for it but don't shut me for bringing this out. > > Support his anti-minority and personal feelings attitude if that's the kind > of chair you like but who gives you the right not to allow me to express my > opinion ? > > > -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From office at ip-broker.uk Wed Oct 19 15:33:20 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Wed, 19 Oct 2016 16:33:20 +0300 Subject: [address-policy-wg] unacceptable conduct and ad-hominem attacks In-Reply-To: References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <3CD975BB-4F83-49D7-8292-8789588020BE@rfc1035.com> Message-ID: Maybe this is not a democracy but I hope most of us try to be as democratic as possible. I was not addressing the person. I like Gert, I like Jim and many other people. I really admire most of them. But this doesn't mean that I should just shut up when I disagree with some ideas. And yes, probably my comparison is far from the reality but I do hope people can understand metaphors. You judging me is not less bad than me judging someone else except that, I reapeat, I'm just addressing the facts and actions and not the people. As an exception I brought up how Gert bend the policy for his personal benefit and now tries to impose policies which would have not allowed him to do what he did. But as I insisted, let's no longer discuss this subject. I do think what he did was wrong but it's not for me to judge him so I won't. On Wed, Oct 19, 2016 at 4:22 PM, Jan Ingvoldstad wrote: > On Wed, Oct 19, 2016 at 2:58 PM, Ciprian Nica wrote: >> >> >> Unsubscribe, shut up, go away... Next time you'll send me to a >> concentration camp ? No I WILL NOT SHUT UP ! I will always express my >> opinion even if I'm the only one in the world supporting it. A great >> romanian said that the best definition of democracy is "I will fight till >> my last drop of blood so you will have the right to disagree with me". >> >> > Your democratic right is to express your opinions without persecution from > governmental authorities (with certain limitations). > > However, this is not a democracy. > > Additionally, you do not have the right to force your invective on others. > We are not obliged to listen or read what you write, and as a mailing list > member, you are obliged to at least a minimum of civility and courtesy to > other members of the same list, be they WG chairs, or regular members. > > Calling them nazis and implicating that reacting to your behaviour is to > send you to a concentration camp is far, far out of line, and shows that > you're too disconnected from reality to listen to or respect, sorry. > -- > Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erey at ernw.de Wed Oct 19 15:37:42 2016 From: erey at ernw.de (Enno Rey) Date: Wed, 19 Oct 2016 15:37:42 +0200 Subject: [address-policy-wg] unacceptable conduct and ad-hominem attacks In-Reply-To: References: <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <3CD975BB-4F83-49D7-8292-8789588020BE@rfc1035.com> Message-ID: <20161019133742.GJ88790@ernw.de> Man, not much IP brokerage business to take care of on your desk today? Maybe call some customers? They're probably waiting for that. #justanidea #lifecanbespentinproductivewaystoo cheers Enno On Wed, Oct 19, 2016 at 04:33:20PM +0300, Ciprian Nica wrote: > Maybe this is not a democracy but I hope most of us try to be as democratic > as possible. I was not addressing the person. I like Gert, I like Jim and > many other people. I really admire most of them. But this doesn't mean that > I should just shut up when I disagree with some ideas. And yes, probably > my comparison is far from the reality but I do hope people can understand > metaphors. > > You judging me is not less bad than me judging someone else except that, I > reapeat, I'm just addressing the facts and actions and not the people. As > an exception I brought up how Gert bend the policy for his personal benefit > and now tries to impose policies which would have not allowed him to do > what he did. But as I insisted, let's no longer discuss this subject. I do > think what he did was wrong but it's not for me to judge him so I won't. > > > On Wed, Oct 19, 2016 at 4:22 PM, Jan Ingvoldstad wrote: > > > On Wed, Oct 19, 2016 at 2:58 PM, Ciprian Nica wrote: > >> > >> > >> Unsubscribe, shut up, go away... Next time you'll send me to a > >> concentration camp ? No I WILL NOT SHUT UP ! I will always express my > >> opinion even if I'm the only one in the world supporting it. A great > >> romanian said that the best definition of democracy is "I will fight till > >> my last drop of blood so you will have the right to disagree with me". > >> > >> > > Your democratic right is to express your opinions without persecution from > > governmental authorities (with certain limitations). > > > > However, this is not a democracy. > > > > Additionally, you do not have the right to force your invective on others. > > We are not obliged to listen or read what you write, and as a mailing list > > member, you are obliged to at least a minimum of civility and courtesy to > > other members of the same list, be they WG chairs, or regular members. > > > > Calling them nazis and implicating that reacting to your behaviour is to > > send you to a concentration camp is far, far out of line, and shows that > > you're too disconnected from reality to listen to or respect, sorry. > > -- > > Jan > > -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From office at ip-broker.uk Wed Oct 19 15:37:40 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Wed, 19 Oct 2016 16:37:40 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> <20161019121847.GB24129@danton.fire-world.de> <145A04C7-D524-4F10-BB26-30F24183715B@rfc1035.com> Message-ID: The usual reply when somebody says something here is "shut up" and "unsubscribe" ? Really ? I think I could talk more freely in Kremlin than here. Yes, the noise is what Gert did 2 years ago. Let's get over it and discuss what is really important. Please express your support for the two important ideas which are "let's ignore the minority because that's what minority does, it's simply against the majority" and "let's ignore people we don't like". Maybe we can set up some criteria for that ? Send your "+1" for the two ideas if you support them. There's no need for praising Gert anymore. I got the idea, he's one of the beloved sons of RIPE community. Ciprian On Wed, Oct 19, 2016 at 4:32 PM, Roger J?rgensen wrote: > Ciprian Nica, > > If you have a problem with someone, or claim someone is abusing something > take it up with RIPE NCC. NOT THIS LIST! > > Can you please for now just shut up with your noise? > > > > > Chair/RIPE NCC/whoever, > > can someone consider if there is reason to actual give Ciprian a warning > and > possible forced unsub? > > > > On Wed, Oct 19, 2016 at 3:10 PM, Ciprian Nica wrote: > > > >> > >> I guess we need the board of RIPE NCC to once in a while step up and > >> block things when > >> they see clear abuse. > > > > > > Here is the fact: > > > > % Version 1 of object "185.54.120.0 - 185.54.123.255" > > > > % This version was a UPDATE operation on 2014-04-17 16:59 > > > > % You can use "--list-versions" to get a list of versions for an object. > > > > > > inetnum: 185.54.120.0 - 185.54.123.255 > > > > netname: DE-TRANSNET-20140417 > > > > descr: TRANSNET Internet Services GmbH > > > > country: DE > > > > org: ORG-TA16-RIPE > > > > > > % Version 2 of object "185.54.120.0 - 185.54.123.255" > > > > % This version was a UPDATE operation on 2014-07-30 15:41 > > > > % You can use "--list-versions" to get a list of versions for an object. > > > > > > inetnum: 185.54.120.0 - 185.54.123.255 > > > > netname: DE-SPACE-20140417 > > > > descr: SpaceNet AG > > > > country: DE > > > > > > > > 13 days after getting a /22 it was merged to Gert's LIR while he has a > /22 > > which was never announced in the internet. > > > > Getting a /22 without ever announcing it for over 2 years plus getting a > /22 > > just to transfer it after a couple weeks, that's a fact. > > > > I have detailed it as you keep insisting. I'm not making any wild > > accusations. These are the facts. > > > > So Gert did 2 actions which are against the spirit of this community. > Praise > > him as much as you want for it but don't shut me for bringing this out. > > > > Support his anti-minority and personal feelings attitude if that's the > kind > > of chair you like but who gives you the right not to allow me to express > my > > opinion ? > > > > > > > > > > -- > > Roger Jorgensen | ROJO9-RIPE > rogerj at gmail.com | - IPv6 is The Key! > http://www.jorgensen.no | roger at jorgensen.no > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Wed Oct 19 15:45:18 2016 From: sander at steffann.nl (Sander Steffann) Date: Wed, 19 Oct 2016 15:45:18 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: Message-ID: <105CF2EB-9854-4FDD-85D2-4F746A626D5A@steffann.nl> Hello Marius, > Over the last years RIPE NCC has imposed a "rule" that when the last IPs are transferred the transferring LIR has to pay the full annual membership fee (even if the LIR was not a member of RIPE for that entire year). I think that if this is something everybody agrees with, it should be inserted into the policy text to make this very clear. But if not, then maybe it would be useful to add a text which would simply say that RIPE NCC should relate exclusively on this policy when processing transfer requests and is not mandated by the RIPE community in imposing any kind of abusive taxes. I'm sorry, but RIPE NCC membership related issues are off-topic for this working group. That includes calling the RIPE NCC membership fee structure "abusive taxes". > I also have a problem with the 24 months period of keeping the IPv4 addresses after merging 2 companies. It's exactly our case, we want to buy and merge with a telecom company and we will no longer need all their IPv4 addresses since we have more than enough by merging both companies resources. We want to transfer a part of the IP addresses to other Company that really need them. Why to wait 24 months? Because the community decided that addresses can only be transferred is the intention is to actually use them, and to prevent companies from buying and selling address space just to make a profit. Your choices are to sell the resources before merging so they can be used by someone else who needs them, or keep them and use them yourself. First acquiring them only to immediately sell them again is explicitly not allowed by RIPE policy. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From office at ip-broker.uk Wed Oct 19 15:46:06 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Wed, 19 Oct 2016 16:46:06 +0300 Subject: [address-policy-wg] unacceptable conduct and ad-hominem attacks In-Reply-To: <20161019133742.GJ88790@ernw.de> References: <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <3CD975BB-4F83-49D7-8292-8789588020BE@rfc1035.com> <20161019133742.GJ88790@ernw.de> Message-ID: "Man", If you have something against me, address it personally. You have my e-mail, you know where to find me for the next 10 days. Why do you think it's important for everybody to know that you hate me ? Ciprian On Wed, Oct 19, 2016 at 4:37 PM, Enno Rey wrote: > Man, > > not much IP brokerage business to take care of on your desk today? > Maybe call some customers? They're probably waiting for that. > > #justanidea > #lifecanbespentinproductivewaystoo > > cheers > > Enno > > > On Wed, Oct 19, 2016 at 04:33:20PM +0300, Ciprian Nica wrote: > > Maybe this is not a democracy but I hope most of us try to be as > democratic > > as possible. I was not addressing the person. I like Gert, I like Jim and > > many other people. I really admire most of them. But this doesn't mean > that > > I should just shut up when I disagree with some ideas. And yes, probably > > my comparison is far from the reality but I do hope people can understand > > metaphors. > > > > You judging me is not less bad than me judging someone else except that, > I > > reapeat, I'm just addressing the facts and actions and not the people. As > > an exception I brought up how Gert bend the policy for his personal > benefit > > and now tries to impose policies which would have not allowed him to do > > what he did. But as I insisted, let's no longer discuss this subject. I > do > > think what he did was wrong but it's not for me to judge him so I won't. > > > > > > On Wed, Oct 19, 2016 at 4:22 PM, Jan Ingvoldstad > wrote: > > > > > On Wed, Oct 19, 2016 at 2:58 PM, Ciprian Nica > wrote: > > >> > > >> > > >> Unsubscribe, shut up, go away... Next time you'll send me to a > > >> concentration camp ? No I WILL NOT SHUT UP ! I will always express my > > >> opinion even if I'm the only one in the world supporting it. A great > > >> romanian said that the best definition of democracy is "I will fight > till > > >> my last drop of blood so you will have the right to disagree with me". > > >> > > >> > > > Your democratic right is to express your opinions without persecution > from > > > governmental authorities (with certain limitations). > > > > > > However, this is not a democracy. > > > > > > Additionally, you do not have the right to force your invective on > others. > > > We are not obliged to listen or read what you write, and as a mailing > list > > > member, you are obliged to at least a minimum of civility and courtesy > to > > > other members of the same list, be they WG chairs, or regular members. > > > > > > Calling them nazis and implicating that reacting to your behaviour is > to > > > send you to a concentration camp is far, far out of line, and shows > that > > > you're too disconnected from reality to listen to or respect, sorry. > > > -- > > > Jan > > > > > -- > Enno Rey > > ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de > Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 > > Handelsregister Mannheim: HRB 337135 > Geschaeftsfuehrer: Enno Rey > > ======================================================= > Blog: www.insinuator.net || Conference: www.troopers.de > Twitter: @Enno_Insinuator > ======================================================= > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Wed Oct 19 15:55:53 2016 From: gert at space.net (Gert Doering) Date: Wed, 19 Oct 2016 15:55:53 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> <20161019121847.GB24129@danton.fire-world.de> <145A04C7-D524-4F10-BB26-30F24183715B@rfc1035.com> <20161019131851.GC88790@ernw.de> Message-ID: <20161019135553.GC79185@Space.Net> Hi, On Wed, Oct 19, 2016 at 04:28:25PM +0300, Ciprian Nica wrote: > I never said Gert did something that was against any policy. Probably he > never did such things. But he clearly took advantage of the merger & > acquisition procedure and now he tries to close it through the policy > 2015-04. Isn't this hypocrisy ? OK, *this* is something that needs an answer - which is unfortunate, because I wanted to let this thread die silently. I am not the proposer of 2015-04, so I certainly do not "try to do anything through the policy 2015-04". Erik Bais is. I'm not sure if I have commented on the merits of 2015-04 before - I might have, in discussions about the merits of having a single transfer policy document vs. lots of fragments in other policy documents, but certainly not on the aspect of "after a M&A, transfers of acquired space is no longer possible for 24 months". If you try to actually understand what this document says: "The proposal extends the 24-month transfer restriction to resources that have been transferred due to changes to an organisation?s business structure (such as a merger or acquisition). It is important to note that this restriction only prevents policy transfers ? resources subject to this restriction may still be transferred due to further mergers or acquisitions within the 24-month period." this in no way interacts with "company A buys company B, including their resources" - if in effect, it would deny company A from selling off B's resources afterward - which is not what we do, or intend to do. In case you're confusing 2015-04 (in your text) with 2016-03 (in the subject), it should be pointed out that 2016-03 very explicitely states: "5.5 Transfers of Allocations ... 4. Point 3 of this article does not apply to any change of holdership of address space as a result of company mergers or acquisitions" The very first version of 2016-03 would have required holders of multiple /22s, no matter how they came to hold them, to return all but one - but that was changed, not by *my* doing, but because the community made it very clear that that was not wanted. So, whatever point you are trying to make - I'm not the proposer of any of these proposals - AND neither of them disallows merges & acquisitions of LIRs with /22s > But let's not mix the discussions. My main concern is that two policies > which are not properly discussed and approved by the community, which seem > far from having a consensus (as far as I can see) will most likely be seen > by the chair as perfect solutions that need to be implemented right away > and he will say that there is consensus even if it isn't. Now that's an interesting point, and shows you've totally read and understood my summary on the discussion phase of 2016-03 v2.0 :-) (especially the bits about "proposer's decision" and "more support needed in review phase"). ... and the bits about "If you disagree with my interpretation..." that are at the end of every declaration of consensus - and have indeed prompted corrections in the past. > I would remind you that it was another policy when Gert stepped down and > admitted that he wouldn't consider himself objective enough and let Sanders > take the decision. If he can't be objective enough from time to time, then > ... just praise him, what else would you do ? There are cases where I clearly *want* to take a side - and then I say so, and put down the chair duties for these. So - can we stick to the merits or not of the proposal in the Subject: line now (which happens to be 2016-03)? If not, please change the Subject: to something that makes it clear that this is personal, and not related to the specific policies at hand. Dear WG participants: please see that we can let this thread re-focus. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From sander at steffann.nl Wed Oct 19 16:00:48 2016 From: sander at steffann.nl (Sander Steffann) Date: Wed, 19 Oct 2016 16:00:48 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <20161019125925.GG27221@gir.theapt.org> References: <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> <20161019125925.GG27221@gir.theapt.org> Message-ID: <95494087-1E2D-485E-B83A-098DE13D37C9@steffann.nl> Hi, > Op 19 okt. 2016, om 14:59 heeft Peter Hessler het volgende geschreven: > > Ciprian > > You have invoked Nazis and Hitler in two different emails to this list. > > This is incredibly offensive, for so many reasons. Ok, this is indeed going too far. Time for an official warning from the chairs. Ciprian: your language and analogies are unacceptable on this mailing list (well, any mailing list as far as I'm concerned, but I only chair this one). As Peter said: > You need to calm down, and think very serious thoughts about your behaviour on this list. On the positive side: I didn't know about Godwin's Law, so I learned something today :) Thank you, Sander RIPE APWG co-chair -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From office at ip-broker.uk Wed Oct 19 16:10:15 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Wed, 19 Oct 2016 17:10:15 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <20161019135553.GC79185@Space.Net> References: <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> <20161019121847.GB24129@danton.fire-world.de> <145A04C7-D524-4F10-BB26-30F24183715B@rfc1035.com> <20161019131851.GC88790@ernw.de> <20161019135553.GC79185@Space.Net> Message-ID: Hi, I was refering to 2015-04 and I was wrong to accuse you of hypocrisy. I understand now that you don't support the policy change which would "ban" regular transfer after mergers. I like the policies as they are and 2015-04 would be great if it would only compact the policies and not bring important changes. Ciprian On Wednesday, October 19, 2016, Gert Doering wrote: > Hi, > > On Wed, Oct 19, 2016 at 04:28:25PM +0300, Ciprian Nica wrote: > > I never said Gert did something that was against any policy. Probably he > > never did such things. But he clearly took advantage of the merger & > > acquisition procedure and now he tries to close it through the policy > > 2015-04. Isn't this hypocrisy ? > > OK, *this* is something that needs an answer - which is unfortunate, > because > I wanted to let this thread die silently. > > I am not the proposer of 2015-04, so I certainly do not "try to do anything > through the policy 2015-04". Erik Bais is. > > I'm not sure if I have commented on the merits of 2015-04 before - I might > have, in discussions about the merits of having a single transfer policy > document vs. lots of fragments in other policy documents, but certainly > not on the aspect of "after a M&A, transfers of acquired space is no > longer possible for 24 months". > > If you try to actually understand what this document says: > > "The proposal extends the 24-month transfer restriction to resources > that have been transferred due to changes to an organisation?s > business structure (such as a merger or acquisition). It is important > to note that this restriction only prevents policy transfers ? > resources subject to this restriction may still be transferred due > to further mergers or acquisitions within the 24-month period." > > this in no way interacts with "company A buys company B, including their > resources" - if in effect, it would deny company A from selling off B's > resources afterward - which is not what we do, or intend to do. > > > In case you're confusing 2015-04 (in your text) with 2016-03 (in the > subject), it should be pointed out that 2016-03 very explicitely states: > > "5.5 Transfers of Allocations > ... > 4. Point 3 of this article does not apply to any change of holdership > of address space as a result of company mergers or acquisitions" > > The very first version of 2016-03 would have required holders of multiple > /22s, no matter how they came to hold them, to return all but one - but > that was changed, not by *my* doing, but because the community made it > very clear that that was not wanted. > > > So, whatever point you are trying to make > > - I'm not the proposer of any of these proposals > - AND neither of them disallows merges & acquisitions of LIRs with /22s > > > > But let's not mix the discussions. My main concern is that two policies > > which are not properly discussed and approved by the community, which > seem > > far from having a consensus (as far as I can see) will most likely be > seen > > by the chair as perfect solutions that need to be implemented right away > > and he will say that there is consensus even if it isn't. > > Now that's an interesting point, and shows you've totally read and > understood > my summary on the discussion phase of 2016-03 v2.0 :-) (especially the > bits > about "proposer's decision" and "more support needed in review phase"). > > ... and the bits about "If you disagree with my interpretation..." that are > at the end of every declaration of consensus - and have indeed prompted > corrections in the past. > > > > I would remind you that it was another policy when Gert stepped down and > > admitted that he wouldn't consider himself objective enough and let > Sanders > > take the decision. If he can't be objective enough from time to time, > then > > ... just praise him, what else would you do ? > > There are cases where I clearly *want* to take a side - and then I say so, > and put down the chair duties for these. > > > So - can we stick to the merits or not of the proposal in the Subject: > line now (which happens to be 2016-03)? If not, please change the > Subject: to something that makes it clear that this is personal, and not > related to the specific policies at hand. > > Dear WG participants: please see that we can let this thread re-focus. > > Gert Doering > -- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From office at ip-broker.uk Wed Oct 19 16:14:38 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Wed, 19 Oct 2016 17:14:38 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <95494087-1E2D-485E-B83A-098DE13D37C9@steffann.nl> References: <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> <20161019125925.GG27221@gir.theapt.org> <95494087-1E2D-485E-B83A-098DE13D37C9@steffann.nl> Message-ID: I accept the warning and I also found about Godwin today. Matbe I should have made a more appropriate comparison. I appologize to Gert, once again. Please take some action against poeple which attack me personally just because they don't like what I say. Or maybe my colour, sexual orientation or whatever it is that they would not like about me. Ciprian On Wednesday, October 19, 2016, Sander Steffann wrote: > Hi, > > > Op 19 okt. 2016, om 14:59 heeft Peter Hessler > het volgende geschreven: > > > > Ciprian > > > > You have invoked Nazis and Hitler in two different emails to this list. > > > > This is incredibly offensive, for so many reasons. > > Ok, this is indeed going too far. Time for an official warning from the > chairs. > > Ciprian: your language and analogies are unacceptable on this mailing list > (well, any mailing list as far as I'm concerned, but I only chair this > one). As Peter said: > > > You need to calm down, and think very serious thoughts about your > behaviour on this list. > > On the positive side: I didn't know about Godwin's Law, so I learned > something today :) > > Thank you, > Sander > RIPE APWG co-chair > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Wed Oct 19 16:19:53 2016 From: gert at space.net (Gert Doering) Date: Wed, 19 Oct 2016 16:19:53 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> <20161019125925.GG27221@gir.theapt.org> <95494087-1E2D-485E-B83A-098DE13D37C9@steffann.nl> Message-ID: <20161019141953.GG79185@Space.Net> Hi, On Wed, Oct 19, 2016 at 05:14:38PM +0300, Ciprian Nica wrote: > I appologize to Gert, once again. Thanks, apology accepted. So - can we please return to discussing policy, based on the current version of the proposals(!), now? :-) Gert Doering -- list member, no hats -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From gert at space.net Wed Oct 19 16:25:24 2016 From: gert at space.net (Gert Doering) Date: Wed, 19 Oct 2016 16:25:24 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <20161019115906.GB79185@Space.Net> <20161019121847.GB24129@danton.fire-world.de> <145A04C7-D524-4F10-BB26-30F24183715B@rfc1035.com> <20161019131851.GC88790@ernw.de> <20161019135553.GC79185@Space.Net> Message-ID: <20161019142524.GH79185@Space.Net> Hi, On Wed, Oct 19, 2016 at 05:10:15PM +0300, Ciprian Nica wrote: > I was refering to 2015-04 and I was wrong to accuse you of hypocrisy. I > understand now that you don't support the policy change which would "ban" > regular transfer after mergers. To clarify: I neither actively support (= push) nor oppose this change. It's Erik Bais' proposal. gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From apwg at c4inet.net Wed Oct 19 16:36:18 2016 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Wed, 19 Oct 2016 15:36:18 +0100 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: <20161019143618.GI93886@cilantro.c4inet.net> I still oppose this proposal. Rationale: 1) It creates yet another class of address space when the goal should be to have only one class. 2) It is potentially harmful to the interests of both the RIPE community and the RIPE NCC by forcing the establishment of an IPv4 "black market", something that the "last /8" policy was *specifically* supposed to prevent. This has direct implications for the quality of registry records, particularly with regard to who *actually* controls a resource. 3) The impact on IPv4 resource consumption is determined by the NCC Impact statement to be "small". This small reduction comes at the price of increased bureaucracy and cost for the businesses that make up the membership. 4) The proposal establishes, as the overriding goal of IP(v4) policy, the conservation of IPv4 resources. This should not be the case, the overriding goal should instead be a transition to IPv6 as quickly as possible. (Re-arranging the deck chairs will not prevent the ship from sinking) rgds, Sascha Luck From alex at vpsville.ru Wed Oct 19 19:03:43 2016 From: alex at vpsville.ru (Alexey Galaev) Date: Wed, 19 Oct 2016 21:03:43 +0400 (MSK) Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <20161019143618.GI93886@cilantro.c4inet.net> References: <20161019143618.GI93886@cilantro.c4inet.net> Message-ID: <1950631511.11693.1476896623316.JavaMail.zimbra@vpsville.ru> Agree with Sascha. -1 for this policy from me. BR, Alexey Galaev +7 985 3608004, http://vpsville.ru ----- ???????? ????????? ----- ??: "Sascha Luck [ml]" ????: address-policy-wg at ripe.net ????????????: ?????, 19 ??????? 2016 ? 17:36:18 ????: Re: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) I still oppose this proposal. Rationale: 1) It creates yet another class of address space when the goal should be to have only one class. 2) It is potentially harmful to the interests of both the RIPE community and the RIPE NCC by forcing the establishment of an IPv4 "black market", something that the "last /8" policy was *specifically* supposed to prevent. This has direct implications for the quality of registry records, particularly with regard to who *actually* controls a resource. 3) The impact on IPv4 resource consumption is determined by the NCC Impact statement to be "small". This small reduction comes at the price of increased bureaucracy and cost for the businesses that make up the membership. 4) The proposal establishes, as the overriding goal of IP(v4) policy, the conservation of IPv4 resources. This should not be the case, the overriding goal should instead be a transition to IPv6 as quickly as possible. (Re-arranging the deck chairs will not prevent the ship from sinking) rgds, Sascha Luck From niculae at plesa.ro Wed Oct 19 19:06:14 2016 From: niculae at plesa.ro (Plesa Niculae) Date: Wed, 19 Oct 2016 20:06:14 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) Message-ID: <1B4AD592-FCAB-4854-8BD0-B0E348596296@plesa.ro> Dear all, I saw a lot of members and/or staff friends supporting one another in judging Ciprian metaphors, hyperbolas and comparisons and no one answering to the FACTS presented by him, and to the real life experienced problems that he raised. Everybody was disgusted when hearing about Hitler, Nazi or Camps and nobody has noticed that Ciprian only answers to disgusting words addressed to him, like: SHUT-UP! Somebody said to Aleksey this morning that he speaks bullshit and nobody complain about that language! So it became obvious for me that friends from/of OUR organisation stick together in shutting down everybody else with another opinion, fighting back on the figures of speech, not on the essence of the problems. I almost feel obliged to take a stand and to warn everybody that what happens with cross firing Ciprian for no other real reason than his colourful way of speaking is I N C O R R E C T ! I feel also obliged to thank very much to the ones not blinded by the fury attacks of the policy change initiators on the ones with different opinions than theirs and only focused on the real matters that Aleksey, Ciprian, Patrick, Daniel, Radu-Adrian, Lu and others raised up. I have to say that I am totally agree with the real and important problems of the policy raised by Ciprian and other members. I am against changing the existing policy. By attacking Ciprian you will not solve the problems of the policy and by ignoring the fact that the wg chairs have businesses in which they use the current policy in transferring IPs and after that they want to modify the policy as soon as possible and with insufficient debates and insufficient quorum raises a HUGE question mark. Best Regards, Niculae Plesa -------------- next part -------------- An HTML attachment was scrubbed... URL: From office at ip-broker.uk Wed Oct 19 19:10:18 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Wed, 19 Oct 2016 20:10:18 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <1476872927.1385031.760673489.6C19D69E@webmail.messagingengine.com> Message-ID: Regarding this policy I think it clearly states in the beginning: "The goal of this proposal is to create a single document with all relevant information regarding the transfer of Internet number resources." I congratulate Erik for it and I think it is very useful to have a single document that would address all situations. But we have to make it clear. Is 2015-04's purpose just to better organise information or to change policies ? If you would have just done what the goal express I think it would have been the first policy that would not get only consensus but unanimity. But when you slip in some changes, then it's a different thing. I agree that many things are not very clear and that there are things that can be improved. This however should be debated properly and maybe it should be done one step at a time through other policy proposals. To resume, if you would change the policy text to stick to it's goal you'd have my +100 (as I see it's getting more popular these days than the classical +1) :) But since this text brings changes I can only give a -1 for not sticking to the goal and for bringing changes that should be treated more careful, not just let's do it quickly however we can and we'll figure out on the way. Why not make good, permanent changes which are expected by many of the community. Ciprian On Wed, Oct 19, 2016 at 1:33 PM, Ciprian Nica wrote: > The policy states how the statistics are presented, therefore I think this > issue should be addressed by the policy. > > RIPE NCC implements the policies and if we, the RIPE community, want some > things to be implemented in a certain way then the only way to "ask" it is > through the policy, otherwise our voices have no value. > > Regarding the lack of details at point B., that is in my opinion an insult > to the community, regardless of what the policy is about. We should not > accept generic statements like that. If nobody bothered to really make an > impact analysis then just say it. > > Ciprian > > > On Wednesday, October 19, 2016, Radu-Adrian FEURDEAN < > ripe-wgs at radu-adrian.feurdean.net> wrote: > >> Hi, >> >> While I do agree with most of the concerns you present there, I'm >> wondering if this is not an issue to be discussed in some other working >> group (??? services ??? database ???). They don't seem to be related to >> the policy itself, but to the way RIPE NCC implements it and reflects >> the changes in the database. >> >> Marco ? Chairs ? anybody else ? >> >> -- >> Radu-Adrian FEURDEAN >> >> On Wed, Oct 19, 2016, at 11:57, Ciprian Nica wrote: >> >> > > Hi, >> > > >> > > I think it would be useful to list on the statistics also the broker >> that >> > > facilitated the transfer. That might be of interest to the community >> and I >> > > think the NCC should revise the transfer agreement template in order >> to be >> > > able to mention the broker and also to publish it's name on the >> transfer >> > > statistics page. Also the broker should be allowed to communicate >> with RIPE >> > > and pass information on behalf of the customers during the transfer >> process. >> > > >> > > There is also a cosmetic thing that I don't know if it needs be >> mentioned >> > > in policy in order to be implemented. The netname of the allocation >> keeps >> > > the original allocation date in it's name which can be confusing >> although >> > > there's the new "created" attribute. >> > > >> > > For example, the subnet 128.0.52.0/24 was transferred on 14/10/2016 >> and >> > > it was part of an allocation with netname EU-JM-20120914. The new >> > > allocation has netname ES-SISTEC-20120914. >> > > >> > > If the date is no longer relevant in a netname then I think it should >> be >> > > simply ES-SISTEC, otherwise it can be ES-SISTEC-20161014 >> > > >> > > Ciprian >> > > >> > > >> > > On Tue, Sep 27, 2016 at 4:08 PM, Marco Schmidt > > > > wrote: >> > > >> > >> Dear colleagues, >> > >> >> > >> The draft documents for version 4.0 of the policy proposal 2015-04, >> "RIPE >> > >> Resource Transfer Policies" have now been published, along with an >> impact >> > >> analysis conducted by the RIPE NCC. >> > >> >> > >> The goal of this proposal is to create a single document with all >> > >> relevant information regarding the transfer of Internet number >> resources. >> > >> >> > >> Some of the differences from version 3.0 include: >> > >> >> > >> - Adding a reference in all related allocation and assignment >> policies to >> > >> the new transfer policy document >> > >> - Clarification in the policy text and policy summary regarding >> transfers >> > >> due to a change in the organisation?s business (such as a merger or >> > >> acquisition) >> > >> >> > >> You can find the full proposal and the impact analysis at: >> > >> https://www.ripe.net/participate/policies/proposals/2015-04 >> > >> >> > >> And the draft documents at: >> > >> https://www.ripe.net/participate/policies/proposals/2015-04/draft >> > >> >> > >> We encourage you to read the draft document and send any comments to >> < >> > >> address-policy-wg at ripe.net >> > >> > >> before 26 >> > >> October 2016. >> > >> >> > >> Regards >> > >> >> > >> Marco Schmidt >> > >> Policy Development Officer >> > >> RIPE NCC >> > >> >> > >> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum >> > >> >> > >> >> > > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marius.cristea at ipv4trade.eu Wed Oct 19 19:23:18 2016 From: marius.cristea at ipv4trade.eu (marius.cristea at ipv4trade.eu) Date: Wed, 19 Oct 2016 20:23:18 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <105CF2EB-9854-4FDD-85D2-4F746A626D5A@steffann.nl> References: <105CF2EB-9854-4FDD-85D2-4F746A626D5A@steffann.nl> Message-ID: <204be962de2c4ea8a44922c0df8c0c3a@ipv4trade.eu> Hi Sandler, Thank you for the explanations, but I believe you haven't really addressed the issues I mentioned. The first issue is ABOUT Transfer Policies, to pay the annual membership fee after you TRANSFER ALL YOUR RESOURCES and maybe even close your Company, is about Transfer Policies. Your second answer is very subjective, have you ever buy and merge Companies? I've done that a couple of times, you never sell the company's (you merge) resources before the merge, because that company doesn't belong to you before the merge and is not you to decide regarding selling anything of that Company resources, either that is IP or fiber optic cable. Is NOT AT ALL what you mention:"First acquiring them only to immediately sell them again is explicitly not allowed by RIPE policy". What this have to do with the situation I mention ??? Please refer to the situation I mention, not on other matters that have nothing to do with it. Marius On 2016-10-19 16:45, Sander Steffann wrote: > Hello Marius, > >> Over the last years RIPE NCC has imposed a "rule" that when the last >> IPs are transferred the transferring LIR has to pay the full annual >> membership fee (even if the LIR was not a member of RIPE for that >> entire year). I think that if this is something everybody agrees with, >> it should be inserted into the policy text to make this very clear. >> But if not, then maybe it would be useful to add a text which would >> simply say that RIPE NCC should relate exclusively on this policy when >> processing transfer requests and is not mandated by the RIPE community >> in imposing any kind of abusive taxes. Is NOT AT ALL what you >> mention:"First acquiring them only to immediately sell them again is >> explicitly not allowed by RIPE policy". What this have to do with the >> situation I mention ??? > > I'm sorry, but RIPE NCC membership related issues are off-topic for > this working group. That includes calling the RIPE NCC membership fee > structure "abusive taxes". > >> I also have a problem with the 24 months period of keeping the IPv4 >> addresses after merging 2 companies. It's exactly our case, we want to >> buy and merge with a telecom company and we will no longer need all >> their IPv4 addresses since we have more than enough by merging both >> companies resources. We want to transfer a part of the IP addresses to >> other Company that really need them. Why to wait 24 months? > > Because the community decided that addresses can only be transferred > is the intention is to actually use them, and to prevent companies > from buying and selling address space just to make a profit. Your > choices are to sell the resources before merging so they can be used > by someone else who needs them, or keep them and use them yourself. > First acquiring them only to immediately sell them again is explicitly > not allowed by RIPE policy. > > Cheers, > Sander From pk at DENIC.DE Wed Oct 19 19:27:49 2016 From: pk at DENIC.DE (Peter Koch) Date: Wed, 19 Oct 2016 19:27:49 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: <20161019172749.GS11843@x28.adm.denic.de> On Wed, Oct 19, 2016 at 10:05:12AM +0200, Marco Schmidt wrote: > We want to draw your attention to two changes, which we hope it will make your proposal evaluation easier. > > - Policy proposals now contain a diff tool that allows easy comparison of different proposal versions ??? simply click on the ???View Changes??? symbol right beside the list of proposal versions. > - The RIPE NCC impact analysis only mentions areas where the proposal is actually expected to have an impact. For example, if the analysis makes no comment about financial or legal impact, it means that no such impact is expected. thanks, it helped. > We encourage you to read the draft document and send any comments to before 17 November 2016. While I am not convinced that the proposal will achieve its goals "in the long run", I do not see significant harm and one could argue that there's no "long run" for v4 anyway. Take this as "can live with" in the spirit of rough consensus. However, the proposal text could benefit from another copy edit and there is an interesting discovery in the impact assessment. Looking at 5.3: Any address space that is not covered by other policies or marked to be returned to IANA, will be covered by the rules in section 5.1. This includes address space that is: o Returned to the RIPE NCC, o Allocated to the RIPE NCC from the IANA recovered pool as defined in the RIPE Policy "Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA" o Given to the RIPE NCC by legacy holders the impact assessment says: [...] > IXP IPv4 assignments are the only resource type that currently has a special return policy defined. Section 6.1 of "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" states that "IP space returned by IXPs will be added to the reserved pool maintained for IXP use." Accordingly, any such returned IXP assignments are not added to the RIPE NCC's general available IPv4 pool. The path to ripe-649 was inspired by having single document covering v4 policies, therefore no other document with "other policies" exists and thus the only exception to the applicability of 5.1 is in 6.1, which hardly qualifies as "other policies", leading to a confusing result. Also, the clause "not covered by other policies or marked to be returned to IANA" is kind of a hard read. A reference describing the return mark might be helpful as would the decoupling of the "or" clause. Other details include the use of transfer vs re-allocation or re-assigment, but I can take this to the author. [from the impact assessmant] > Returned IPv4 addresses from LIRs and End Users and addresses received from IANA's recovered pool are currently added to the RIPE NCC's available IPv4 pool. If this proposal is accepted, legacy resources that have been handed over to the RIPE NCC will also be added to the available pool. Currently, the RIPE NCC holds a total of ten /24 IPv4 legacy resources. With apologies for lack of research; under what policy was this space "accepted" and not marked for return to IANA? -Peter From sander at steffann.nl Wed Oct 19 21:04:26 2016 From: sander at steffann.nl (Sander Steffann) Date: Wed, 19 Oct 2016 21:04:26 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <204be962de2c4ea8a44922c0df8c0c3a@ipv4trade.eu> References: <105CF2EB-9854-4FDD-85D2-4F746A626D5A@steffann.nl> <204be962de2c4ea8a44922c0df8c0c3a@ipv4trade.eu> Message-ID: <51ECAFC9-CBF3-4F83-BE57-3A48FC42F683@steffann.nl> Hello Marius, > Thank you for the explanations, but I believe you haven't really addressed the issues I mentioned. > The first issue is ABOUT Transfer Policies, to pay the annual membership fee after you TRANSFER ALL YOUR RESOURCES and maybe even close your Company, is about Transfer Policies. No, that is about your contractual agreement with the RIPE NCC. > Your second answer is very subjective, have you ever buy and merge Companies? I've done that a couple of times, you never sell the company's (you merge) resources before the merge, because that company doesn't belong to you before the merge and is not you to decide regarding selling anything of that Company resources, either that is IP or fiber optic cable. Is NOT AT ALL what you mention:"First acquiring them only to immediately sell them again is explicitly not allowed by RIPE policy". What this have to do with the situation I mention ??? Please refer to the situation I mention, not on other matters that have nothing to do with it. This is exactly the situation you mention: you buy a company, acquiring all their assets. One of those assets is an IPv4 allocation from RIPE NCC. To prevent speculation with IPv4 resources it is not allowed to sell those resources within 24 months of acquiring them. So in your case: buy the company, keep it running as a separate company/LIR for a little while, sort out where you want to transfer the resources you don't need, then merge the companies/LIRs. So, no problem. Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rgori at wirem.net Wed Oct 19 22:19:58 2016 From: rgori at wirem.net (Riccardo Gori) Date: Wed, 19 Oct 2016 22:19:58 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: I oppose this policy. I just acquired a new downstreamer customer that asked me to provide ip transit and space while he is investing in infrastructure. Once he will be ready he will setup its own LIR and get his /22 (if in time to..) He is moving to me from another provider 'cause the old provider said him he will never sell the assigned space to him. I said I will never sell him the space too, but I can sub-allocate part of my space now and so he can use it to grow his network ipv4/ipv6. I said him that when he will be ready with his own LIR i can give him the space he is annoucing/using if he simply is able to give me back same amount of space once obtained/bought it in the future. That is the agreement and the whole setup is already described in RIPE database and we are just waiting to get connected to start IP transit. Am I doing something wrong? 2016-03 wants to forbid this perfect legitimate business? Plase explain why I should go to my customer tomorrow and say that what we are doing will not be possibile? You know what? I'll lose the contract. My LIR will be unappetible to him even if only reading today the apwg. So I should let him go to another LIR maybe. Please I want to underline what this customer is paying to his old provider and tomorrow to me is only the transit. The old provider is providing him the space for free and I am doing the same with only more the agreement to give him the space once he will have an LIR. I don't want to be divantaged so I oppose this policy. kind regards Riccardo Il 19/10/2016 10:05, Marco Schmidt ha scritto: > Dear colleagues, > > The draft documents for version 3.0 of the policy proposal 2016-03, "Locking Down the Final /8 Policy" have now been published, along with an impact analysis conducted by the RIPE NCC. > > The goal of this proposal is to ban transfers of allocations made under the final /8 policy. Also the proposal specifies what resources must be added to the RIPE NCC IPv4 available pool. > > Some of the differences from version 2.0 include: > > - Clarification that changes to holdership of address space as a result of company mergers or acquisitions are not affected by proposed transfer restriction > - Legacy space handed over to the RIPE NCC will be added to the IPv4 available pool > > You can find the full proposal and the impact analysis at: > https://www.ripe.net/participate/policies/proposals/2016-03 > > And the draft documents at: > https://www.ripe.net/participate/policies/proposals/2016-03/draft > > We want to draw your attention to two changes, which we hope it will make your proposal evaluation easier. > > - Policy proposals now contain a diff tool that allows easy comparison of different proposal versions ? simply click on the ?View Changes? symbol right beside the list of proposal versions. > - The RIPE NCC impact analysis only mentions areas where the proposal is actually expected to have an impact. For example, if the analysis makes no comment about financial or legal impact, it means that no such impact is expected. > > We encourage you to read the draft document and send any comments to before 17 November 2016. > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From rgori at wirem.net Wed Oct 19 22:40:33 2016 From: rgori at wirem.net (Riccardo Gori) Date: Wed, 19 Oct 2016 22:40:33 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <58074288.5000003@foobar.org> References: <58074288.5000003@foobar.org> Message-ID: I think these observations are more than reasonable thank you Nick regards Riccardo Il 19/10/2016 11:53, Nick Hilliard ha scritto: > Marco Schmidt wrote: >> We encourage you to read the draft document and send any comments to >> before 17 November 2016. > The purpose of the policy is to restrict the flow of /22 allocations > from the RIPE remaining ipv4 pool. While I'm sympathetic to this idea, > the policy is not going to fix the problem that it sets out to fix and > will create a new set of problems which will be extremely difficult for > the RIPE NCC to recover from. Consequently I do not support it, because: > > 1. the core problem won't be fixed: the outgoing flow of /22s will not > be affected in any way because speculators will get allocations using > shelf Companies which can be sold as-is, thereby bypassing any policy > that the RIPE community might want to consider in this area. The only > way to even begin to fix this would be to move back to a needs-based > allocation policy. > > 2. unregistered transfers will become a problem and this may become > intractable in the future. This directly goes against the core > principals of the RIPE database which is to ensure accurate registration > of address holder details. > > Also, asset divesting is not catered for in the policy. If a company / > LIR splits up, there is no way to handle splitting of IPv4 address > allocations in the policy. There is no clear way to fix this problem > within the principals of the policy. > > As an aside note, the problem of ipv4 allocation speedup from the RIPE > NCC has been exacerbated by the recent RIPE NCC GM resolution: "The > General Meeting approves the ability of RIPE NCC members to create > additional LIR accounts". The net effect of this is that there is now a > divergence between intended RIPE policy and RIPE NCC implementation. > This is probably not helpful in the long run. > > Nick > -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From rgori at wirem.net Wed Oct 19 22:45:27 2016 From: rgori at wirem.net (Riccardo Gori) Date: Wed, 19 Oct 2016 22:45:27 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> Message-ID: Hi Lu, Il 19/10/2016 12:33, Lu Heng ha scritto: > Hi > > On 19 October 2016 at 12:18, Gert Doering > wrote: > > Hi, > > On Wed, Oct 19, 2016 at 12:00:47PM +0200, Lu Heng wrote: > [..] > > What I have said is one of the concern that have to be addressd with an > > reasonable counter argument. > > Thanks for the clarification. > > > Chair's job is not collecting vote but make sure all concerns > have been > > addressed reasonablely. > > Thanks for telling me what my job is, I wouldn't have guessed > otherwise. > > Just for the record: part of the WG Chair's job is to judge the > "roughness" > of consensus based on the amount of supporting and opposing voices > - both > the number, and the quality of arguments have to be weighted (and > to some > extent the person making a certain argument). > > And if I cannot be sure what to make out of a statement, then I > can either > ask for clarity, or just discard as "random noise". > > > Agian, voicing concern is not exact same thing as "opposition", I have > a concern, if it can be addressed well with reasonable conter > argument, I might support. > > It's the very defination of the process ?reaching consensus". > > But again, I think it is not about the policy in discussion, we should > stop here. > > I agree with Nick just said, it does not fix the core problem: the > large eonomical difference between > RIPE NCC member fees and market price for IPv4 will permenent exsists, > Ramco said puting a sticker > "not for sale" to decrease its value, it might be true, but the gap in > those two mgiht just be too big(and will be bigger in the future) to > close. Very nice example. I agree. > > > > > Gert Doering > -- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. > Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 > USt-IdNr.: DE813185279 > > > > > -- > -- > Kind regards. > Lu > -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From hank at efes.iucc.ac.il Thu Oct 20 06:54:40 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 20 Oct 2016 07:54:40 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> <20161019121847.GB24129@danton.fire-world.de> <145A04C7-D524-4F10-BB26-30F24183715B@rfc1035.com> Message-ID: On 19/10/2016 16:37, Ciprian Nica wrote: Gert, Whatever proposal(s) Ciprian supports considers my vote as a "-1". -Hank > The usual reply when somebody says something here is "shut up" and > "unsubscribe" ? Really ? I think I could talk more freely in Kremlin > than here. > > Yes, the noise is what Gert did 2 years ago. Let's get over it and > discuss what is really important. > > Please express your support for the two important ideas which are > "let's ignore the minority because that's what minority does, it's > simply against the majority" and "let's ignore people we don't like". > Maybe we can set up some criteria for that ? Send your "+1" for the > two ideas if you support them. There's no need for praising Gert > anymore. I got the idea, he's one of the beloved sons of RIPE community. > > Ciprian > > > > > On Wed, Oct 19, 2016 at 4:32 PM, Roger J?rgensen > wrote: > > Ciprian Nica, > > If you have a problem with someone, or claim someone is abusing > something > take it up with RIPE NCC. NOT THIS LIST! > > Can you please for now just shut up with your noise? > > > > > Chair/RIPE NCC/whoever, > > can someone consider if there is reason to actual give Ciprian a > warning and > possible forced unsub? > > > > On Wed, Oct 19, 2016 at 3:10 PM, Ciprian Nica > wrote: > > > >> > >> I guess we need the board of RIPE NCC to once in a while step > up and > >> block things when > >> they see clear abuse. > > > > > > Here is the fact: > > > > % Version 1 of object "185.54.120.0 - 185.54.123.255" > > > > % This version was a UPDATE operation on 2014-04-17 16:59 > > > > % You can use "--list-versions" to get a list of versions for an > object. > > > > > > inetnum: 185.54.120.0 - 185.54.123.255 > > > > netname: DE-TRANSNET-20140417 > > > > descr: TRANSNET Internet Services GmbH > > > > country: DE > > > > org: ORG-TA16-RIPE > > > > > > % Version 2 of object "185.54.120.0 - 185.54.123.255" > > > > % This version was a UPDATE operation on 2014-07-30 15:41 > > > > % You can use "--list-versions" to get a list of versions for an > object. > > > > > > inetnum: 185.54.120.0 - 185.54.123.255 > > > > netname: DE-SPACE-20140417 > > > > descr: SpaceNet AG > > > > country: DE > > > > > > > > 13 days after getting a /22 it was merged to Gert's LIR while he > has a /22 > > which was never announced in the internet. > > > > Getting a /22 without ever announcing it for over 2 years plus > getting a /22 > > just to transfer it after a couple weeks, that's a fact. > > > > I have detailed it as you keep insisting. I'm not making any wild > > accusations. These are the facts. > > > > So Gert did 2 actions which are against the spirit of this > community. Praise > > him as much as you want for it but don't shut me for bringing > this out. > > > > Support his anti-minority and personal feelings attitude if > that's the kind > > of chair you like but who gives you the right not to allow me to > express my > > opinion ? > > > > > > > > > > -- > > Roger Jorgensen | ROJO9-RIPE > rogerj at gmail.com | - IPv6 is > The Key! > http://www.jorgensen.no | roger at jorgensen.no > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mozafary at greenweb.ir Thu Oct 20 07:01:12 2016 From: mozafary at greenweb.ir (Mozafary Mohammad) Date: Thu, 20 Oct 2016 08:31:12 +0330 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <58074288.5000003@foobar.org> References: <58074288.5000003@foobar.org> Message-ID: Hello As Nick said, unregistered transfer will become problem on updating "RIPE Database" and as you know the database is main reason of RIRs mission. Also IP is IP and it's now important it's on last /8 or not.All IPs owner should have same right to transfer/re-allocation. On 10/19/2016 1:23 PM, Nick Hilliard wrote: > Marco Schmidt wrote: >> We encourage you to read the draft document and send any comments to >> before 17 November 2016. > The purpose of the policy is to restrict the flow of /22 allocations > from the RIPE remaining ipv4 pool. While I'm sympathetic to this idea, > the policy is not going to fix the problem that it sets out to fix and > will create a new set of problems which will be extremely difficult for > the RIPE NCC to recover from. Consequently I do not support it, because: > > 1. the core problem won't be fixed: the outgoing flow of /22s will not > be affected in any way because speculators will get allocations using > shelf Companies which can be sold as-is, thereby bypassing any policy > that the RIPE community might want to consider in this area. The only > way to even begin to fix this would be to move back to a needs-based > allocation policy. > > 2. unregistered transfers will become a problem and this may become > intractable in the future. This directly goes against the core > principals of the RIPE database which is to ensure accurate registration > of address holder details. > > Also, asset divesting is not catered for in the policy. If a company / > LIR splits up, there is no way to handle splitting of IPv4 address > allocations in the policy. There is no clear way to fix this problem > within the principals of the policy. > > As an aside note, the problem of ipv4 allocation speedup from the RIPE > NCC has been exacerbated by the recent RIPE NCC GM resolution: "The > General Meeting approves the ability of RIPE NCC members to create > additional LIR accounts". The net effect of this is that there is now a > divergence between intended RIPE policy and RIPE NCC implementation. > This is probably not helpful in the long run. > > Nick > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mozafary at greenweb.ir Thu Oct 20 07:17:20 2016 From: mozafary at greenweb.ir (Mozafary Mohammad) Date: Thu, 20 Oct 2016 08:47:20 +0330 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <1B4AD592-FCAB-4854-8BD0-B0E348596296@plesa.ro> References: <1B4AD592-FCAB-4854-8BD0-B0E348596296@plesa.ro> Message-ID: <5c2bcaae-7a6d-9c66-4aae-751caeb3901d@greenweb.ir> Your last line is most likely section of your email. On 10/19/2016 8:36 PM, Plesa Niculae wrote: > Dear all, > I saw a lot of members and/or staff friends supporting one another in > judging Ciprian metaphors, hyperbolas and comparisons and no one > answering to the *FACTS* presented by him, and to the *real life > experienced problems* that he raised. > Everybody was disgusted when hearing about Hitler, Nazi or Camps and > nobody has noticed that Ciprian *only answers* to disgusting words > addressed to him, like: *SHUT-UP!* Somebody said to Aleksey this > morning that he speaks bullshit and nobody complain about that language! > So it became obvious for me that friends from/of OUR organisation > stick together in shutting down everybody else with another opinion, > fighting back on the figures of speech, not on the essence of the > problems. > I almost feel obliged to take a stand and to warn everybody that what > happens with cross firing Ciprian for no other real reason than his > colourful way of speaking is *I N C O R R E C T *! I feel also obliged > to thank very much to the ones not blinded by the fury attacks of the > policy change initiators on the ones with different opinions than > theirs and only focused on the real matters that Aleksey, Ciprian, > Patrick, Daniel, Radu-Adrian, Lu and others raised up. > I have to say that I am totally agree with the real and important > problems of the policy raised by Ciprian and other members. I am > against changing the existing policy. By attacking Ciprian you will > not solve the problems of the policy and by ignoring the fact that the > wg chairs have businesses in which they use the current policy in > transferring IPs and after that they want to modify the policy as soon > as possible and with insufficient debates and insufficient quorum > raises a HUGE question mark. > Best Regards, > Niculae Plesa > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Thu Oct 20 07:20:50 2016 From: randy at psg.com (Randy Bush) Date: Thu, 20 Oct 2016 14:20:50 +0900 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> <20161019121847.GB24129@danton.fire-world.de> <145A04C7-D524-4F10-BB26-30F24183715B@rfc1035.com> Message-ID: > Whatever proposal(s) Ciprian supports considers my vote as a "-1". could we please return to civility? From listas at cutre.net Thu Oct 20 08:42:42 2016 From: listas at cutre.net (listas at cutre.net) Date: Thu, 20 Oct 2016 08:42:42 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> <20161019121847.GB24129@danton.fire-world.de> <145A04C7-D524-4F10-BB26-30F24183715B@rfc1035.com> Message-ID: I think the problem in the end is how we consider what is an public IP prefix. In my city (Madrid, Spain, if you have curiosity, welcome to the city hosting RIPE 73), we have taxis. A license to have a taxi is assigned for life and when the owner retires, he can sell it for whatever he wants and the market is able to pay. Of course the number of licenses is limited. We have also a electric car sharing system (car2go) that allow you to rent a car and pay for its usage. When the usage finish, the user return the car, no money returned, can't "sell" it because is not the owner. Of course the number of cars is limited. Those are two views on how to manage scarce resources. For some people public IP allocation should follow the first method. More "capitalist" it can be said, for others, the second, more "social", is the best. I'm of the second group. For me the IPs is something that is lend to me to do my work and not to trade them. Some time ago (before the last /8) I worked with a company that in one moment didn't need anymore their IPs (mother company delegated a range) so advised by me they returned them to RIPE and closed the LIR. That's how I see it. Note: my mail is educated and don't address nobody personally. Please keep the conversation at the same level. Demonstrate you're respected engineers and not hooligans. Enviado desde mi iPhone From hank at efes.iucc.ac.il Thu Oct 20 09:22:49 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 20 Oct 2016 10:22:49 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: Message-ID: <759fa1dc-2f4a-4dcc-b5eb-38f4cd34c835@email.android.com> An HTML attachment was scrubbed... URL: From saeed at ipm.ir Thu Oct 20 09:31:02 2016 From: saeed at ipm.ir (Saeed Khademi) Date: Thu, 20 Oct 2016 11:01:02 +0330 Subject: [address-policy-wg] 2016-03 New Version and Impact AnalysisPublished (Locking Down the Final /8 Policy) In-Reply-To: References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> <20161019121847.GB24129@danton.fire-world.de> <145A04C7-D524-4F10-BB26-30F24183715B@rfc1035.com> Message-ID: <32D103D75FBB40FE93F051773B567A22@Saeed> >> I'm of the second group. For me the IPs is something that is lend to me >> to do my work and not to trade them. This is the main idea behind the public IP addresses, according to IANA. I've mentioned this before in a discussion regarding another policy. PUBLIC IP addresses have given to us to use not to trade. We haven't paid for getting them, and we are not the owner. Kind Regards, Saeed. -----Original Message----- From: listas at cutre.net Sent: Thursday, October 20, 2016 10:12 AM To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2016-03 New Version and Impact AnalysisPublished (Locking Down the Final /8 Policy) I think the problem in the end is how we consider what is an public IP prefix. In my city (Madrid, Spain, if you have curiosity, welcome to the city hosting RIPE 73), we have taxis. A license to have a taxi is assigned for life and when the owner retires, he can sell it for whatever he wants and the market is able to pay. Of course the number of licenses is limited. We have also a electric car sharing system (car2go) that allow you to rent a car and pay for its usage. When the usage finish, the user return the car, no money returned, can't "sell" it because is not the owner. Of course the number of cars is limited. Those are two views on how to manage scarce resources. For some people public IP allocation should follow the first method. More "capitalist" it can be said, for others, the second, more "social", is the best. I'm of the second group. For me the IPs is something that is lend to me to do my work and not to trade them. Some time ago (before the last /8) I worked with a company that in one moment didn't need anymore their IPs (mother company delegated a range) so advised by me they returned them to RIPE and closed the LIR. That's how I see it. Note: my mail is educated and don't address nobody personally. Please keep the conversation at the same level. Demonstrate you're respected engineers and not hooligans. Enviado desde mi iPhone From randy at psg.com Thu Oct 20 09:53:06 2016 From: randy at psg.com (Randy Bush) Date: Thu, 20 Oct 2016 16:53:06 +0900 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <759fa1dc-2f4a-4dcc-b5eb-38f4cd34c835@email.android.com> References: <759fa1dc-2f4a-4dcc-b5eb-38f4cd34c835@email.android.com> Message-ID: > I will vote the opposite of whatever IP brokers vote.Their view is > strictly commercial whereas I am not part of that subgroup. i understand your position. but my problems are up a couple of layers. we have based our community's financial viability on recruiting a lot of new members. while having new blood is a good balance to us old fossils, the culture relied too much on unspoken common perceptions, practices, and goals. we are not good at articulating them and making them accessible to the new blood. so we write more and more complex policy documents, have lots of votes, ... [0]. and the world is changing, becoming more commercial, less academic and public service oriented. and some of us do not do as well with change as we might; a well-known trait of the, sad to say, majority gender. we need to get over it. i do not think we can, or maybe not even should want to, roll things back to the rosier (or so we fondly think) past. but we can try to move forward with some courtesy and civility and an effort to see everyone's viewpoint, especially of those with whom we think we disagree. and we can try to explain our positions and expectations a bit more clearly in order to compensate for the lack of documentation (that is not a plea for more policy documents or paperwork). randy -- 0 - this ongoing wg chair voting thing is such a great example. we had a small problem and the cure is a monster. hence my 'pigasus' (you have to google it; i was there) comment. From randy at psg.com Thu Oct 20 09:56:29 2016 From: randy at psg.com (Randy Bush) Date: Thu, 20 Oct 2016 16:56:29 +0900 Subject: [address-policy-wg] 2016-03 New Version and Impact AnalysisPublished (Locking Down the Final /8 Policy) In-Reply-To: <32D103D75FBB40FE93F051773B567A22@Saeed> References: <42a7c938-a01e-1566-e123-a2b764052af8@tvt-datos.es> <20161019094828.GW79185@Space.Net> <20161019101857.GY79185@Space.Net> <20161019111112.GA79185@Space.Net> <20161019115906.GB79185@Space.Net> <20161019121847.GB24129@danton.fire-world.de> <145A04C7-D524-4F10-BB26-30F24183715B@rfc1035.com> <32D103D75FBB40FE93F051773B567A22@Saeed> Message-ID: > PUBLIC IP addresses have given to us to use not to trade. We haven't > paid for getting them, and we are not the owner. today, they are not given to us; we pay to rent them. yes, we are renting integers. From saeed at ipm.ir Thu Oct 20 10:38:55 2016 From: saeed at ipm.ir (Saeed Khademi) Date: Thu, 20 Oct 2016 12:08:55 +0330 Subject: [address-policy-wg] 2016-03 New Version and Impact AnalysisPublished (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: >> today, they are not given to us; we pay to rent them. yes, we are renting integers. That is because of a wrong policy which allows trading them. If there is a wrong doing, and it is being practiced by many, it doesn't mean it is correct. When some organizations are selling their IP addresses, it means that they don't need these addresses for their internal use. Which means the reasons they introduced to NCC to justify their need, either do not exist any more or were fake in the first place. Whatever the reason, those blocks have to be returned to NCC pool. Kind Regards, Saeed. -----Original Message----- From: Randy Bush Sent: Thursday, October 20, 2016 11:26 AM To: Saeed Khademi Cc: listas at cutre.net ; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2016-03 New Version and Impact AnalysisPublished (Locking Down the Final /8 Policy) > PUBLIC IP addresses have given to us to use not to trade. We haven't > paid for getting them, and we are not the owner. today, they are not given to us; we pay to rent them. yes, we are renting integers. From gert at space.net Thu Oct 20 10:47:17 2016 From: gert at space.net (Gert Doering) Date: Thu, 20 Oct 2016 10:47:17 +0200 Subject: [address-policy-wg] transfers and renting of Integers in general (was: 2016-03) In-Reply-To: References: Message-ID: <20161020084717.GL79185@Space.Net> Hi On Thu, Oct 20, 2016 at 12:08:55PM +0330, Saeed Khademi wrote: > >> today, they are not given to us; we pay to rent them. yes, we are > renting integers. > > That is because of a wrong policy which allows trading them. > If there is a wrong doing, and it is being practiced by many, > it doesn't mean it is correct. > > When some organizations are selling their IP addresses, it means that > they don't need these addresses for their internal use. Which means > the reasons they introduced to NCC to justify their need, either do not > exist any more > or were fake in the first place. > Whatever the reason, those blocks have to be returned to NCC pool. While I understand your frustration, please change the Subject: line when the discussion strays from the proposal being discussed. One day, it might be necessary to fundamentally revisit the policies regarding address transfer in general, but 2016-03 is not the proposal doing this. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From office at ip-broker.uk Thu Oct 20 11:57:05 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Thu, 20 Oct 2016 12:57:05 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <759fa1dc-2f4a-4dcc-b5eb-38f4cd34c835@email.android.com> References: <759fa1dc-2f4a-4dcc-b5eb-38f4cd34c835@email.android.com> Message-ID: Hi, Over the years I saw many "haters" which are against this business. I didn't invent it and the real money goes to the ones that got the resources for "free" and then seek to make a fortune out of it. There were people in the first years telling me that this business is illegal. Well, I guess this is something that all pioneers have to deal with. If I would moderate the list I would remove people that make such affirmations. I do hope that every sane person over here can accept criticism. I lived under the communist time and I know how it is when a leader says something wrong but he believes is right and a bunch of penguins just sit in the room and applause. Let's get to reason and sanity (hopefull we all can do that). For the moment we have to discuss the current policies and then come up with some better ones as many people complain about the current situation. So we have to discuss a policy that is suppose to organize things but it inserts important changes and a policy which is against the interest of most of the voices around here. In my opinion they need to get dropped and we need to take one issue at a time and figure out how to fix it. Again, I'm like any of you and definitely not against any single person. Obviously there are people which I like and people which I dislike. But let's be civil and discuss ideas not people as nobody is perfect but we have enough capable brains among us to produce good ideas that would benefit every honest member of the community. Let's stop focusing on policies "against" and try to do things that move things forward in a positive way. Everybody can figure out what their goal are but (maybe it's unfortunate) our society is mostly driven and blinded by profit. That's how is it and we can't ignore it. IPv6 makes companies rich, probably more than IPv4 does. People seeking "world peace" are a great asset to our world but I'm afraid that won't happen during our lifetime. Enjoy Madrid, have fun, and try to treat life in a bit more positive way. Hate will never bring anything postive, not even to the hater. Ciprian On Thursday, October 20, 2016, Hank Nussbacher wrote: > I'll rephrase: > I will vote the opposite of whatever IP brokers vote. Their view is > strictly commercial whereas I am not part of that subgroup. > > Better? > > Hank > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Thu Oct 20 12:01:29 2016 From: randy at psg.com (Randy Bush) Date: Thu, 20 Oct 2016 19:01:29 +0900 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <759fa1dc-2f4a-4dcc-b5eb-38f4cd34c835@email.android.com> Message-ID: > If I would moderate the list I would remove people let's not > I lived under the communist time and I know how it is when a leader > says something wrong but he believes is right and a bunch of penguins > just sit in the room and applause. i assure you that this is not just from communist times. are you seeing what is going on in britain, the states, ...? could you please set an example and pick one small issue in this document and discuss its pros and cons? randy From richih.mailinglist at gmail.com Thu Oct 20 12:07:53 2016 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Thu, 20 Oct 2016 12:07:53 +0200 Subject: [address-policy-wg] [policy-announce] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <9f21a405-af43-9ca6-5ace-07802b2b9998@ripe.net> Message-ID: On Wed, Oct 19, 2016 at 11:51 AM, Richard Hartmann wrote: > I support this proposal. To qualify my +1, while I do get the argument that this will not entirely stop hogging and speculation, it's at least a step in the right direction. Even considering Ricardo's emails, I don't see a hard argument against this proposal as it's easily possible to set up the downstream LIR earlier if they anticipate the need, anyway. To me, the pros outweigh the possible cons, and it's an overall improvement. Richard From office at ip-broker.uk Thu Oct 20 12:24:12 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Thu, 20 Oct 2016 13:24:12 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <759fa1dc-2f4a-4dcc-b5eb-38f4cd34c835@email.android.com> Message-ID: On Thursday, October 20, 2016, Randy Bush wrote: > > If I would moderate the list I would remove people > > let's not > > Ok, I can be a hater too sometimes but I don't like it. > I lived under the communist time and I know how it is when a leader > > says something wrong but he believes is right and a bunch of penguins > > just sit in the room and applause. > > i assure you that this is not just from communist times. are you seeing > what is going on in britain, the states, ...? > > Yes, bullshit (I was told this is an acceptable word here) happens all over the world and we are bringing it here as well. > could you please set an example and pick one small issue in this > document and discuss its pros and cons? > I oppose both policies. For 2015-04 it's obvious, a policy that is supposed to arrange my hair nicer would make me bold. You either do a cosmetic reorganisation or important changes which should never be added just like that, as some changes are minor and shouldn't be discussed (but in a different policy) As for 2016-03 I think we should set our goals right. Isn't everybody saying that IPv4 is dead for over 4 years already ? Isn't everybody saying that the only way forward is to IPv6 and exhausting RIPE's available pool sooner would help people move to IPv6 ? Let's discuss a single fact which should guide us towards properly improving policies. What do you people want ? To kill IPv4 or to make it more desirable, more valuable ? Let's first agree on this and after that we can set our foot in the right direction. Ciprian -------------- next part -------------- An HTML attachment was scrubbed... URL: From noc at netskin.com Thu Oct 20 12:26:21 2016 From: noc at netskin.com (Netskin NOC) Date: Thu, 20 Oct 2016 12:26:21 +0200 Subject: [address-policy-wg] [policy-announce] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <9f21a405-af43-9ca6-5ace-07802b2b9998@ripe.net> Message-ID: <15b186e3-62c9-66db-c86e-6be52c27b66a@netskin.com> -1 for the proposal If anything, better implement a policy which forces the (big players) to return their (huge amounts) of unused space, as briefly discussed a year ago: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2015-October/010768.html https://www.ripe.net/ripe/mail/archives/address-policy-wg/2015-October/010752.html Just start by grabbing all ips currently listed on the marketplace and shut it down ;-) BTW: How much money was and is invested in building and maintaining the marketplace? Corin On 20.10.2016 12:07, Richard Hartmann wrote: > On Wed, Oct 19, 2016 at 11:51 AM, Richard Hartmann > wrote: > >> I support this proposal. > > To qualify my +1, while I do get the argument that this will not > entirely stop hogging and speculation, it's at least a step in the > right direction. > > Even considering Ricardo's emails, I don't see a hard argument against > this proposal as it's easily possible to set up the downstream LIR > earlier if they anticipate the need, anyway. > > > To me, the pros outweigh the possible cons, and it's an overall improvement. > > > Richard > From gert at space.net Thu Oct 20 12:29:10 2016 From: gert at space.net (Gert Doering) Date: Thu, 20 Oct 2016 12:29:10 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <759fa1dc-2f4a-4dcc-b5eb-38f4cd34c835@email.android.com> Message-ID: <20161020102910.GO79185@Space.Net> Hi, On Thu, Oct 20, 2016 at 01:24:12PM +0300, Ciprian Nica wrote: > I oppose both policies. > > For 2015-04 it's obvious, a policy that is supposed to arrange my hair > nicer would make me bold. You either do a cosmetic reorganisation or > important changes which should never be added just like that, as some > changes are minor and shouldn't be discussed (but in a different policy) > > As for 2016-03 I think we should set our goals right. Isn't everybody > saying that IPv4 is dead for over 4 years already ? Isn't everybody saying > that the only way forward is to IPv6 and exhausting RIPE's available pool > sooner would help people move to IPv6 ? Please do NOT mix comments to different policies into an e-mail that has a Subject: that says "2016-03". This makes it MUCH harder for the chairs to go back to the mail archives later on and see who said what regarding a specific proposal - and then, if I cannot remember "oh, there was a comment about 2015-04 in a 2016-03 thread", you're going to complain that I have ignored your comment. Right? Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From gert at space.net Thu Oct 20 12:30:23 2016 From: gert at space.net (Gert Doering) Date: Thu, 20 Oct 2016 12:30:23 +0200 Subject: [address-policy-wg] [policy-announce] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <15b186e3-62c9-66db-c86e-6be52c27b66a@netskin.com> References: <9f21a405-af43-9ca6-5ace-07802b2b9998@ripe.net> <15b186e3-62c9-66db-c86e-6be52c27b66a@netskin.com> Message-ID: <20161020103023.GP79185@Space.Net> Hi, On Thu, Oct 20, 2016 at 12:26:21PM +0200, Netskin NOC wrote: > If anything, better implement a policy which forces the (big players) to return their (huge amounts) of unused space, as > briefly discussed a year ago: This is a separate discussion, and should not be done under the Subject: of 2016-03. Folks, I understand that e-mail is hard. But give it a try. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From noc at netskin.com Thu Oct 20 12:38:55 2016 From: noc at netskin.com (Netskin NOC) Date: Thu, 20 Oct 2016 12:38:55 +0200 Subject: [address-policy-wg] [policy-announce] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <20161020103023.GP79185@Space.Net> References: <9f21a405-af43-9ca6-5ace-07802b2b9998@ripe.net> <15b186e3-62c9-66db-c86e-6be52c27b66a@netskin.com> <20161020103023.GP79185@Space.Net> Message-ID: <6383440c-9c4c-b89d-8ff1-e7db73fa9384@netskin.com> On 20.10.2016 12:30, Gert Doering wrote: > This is a separate discussion, and should not be done under the Subject: > of 2016-03. > > Folks, I understand that e-mail is hard. But give it a try. I know and thus didn't start a discussion about the topic, I just suggested it...probably by reviving the old thread I mentioned. Cheers Corin From phessler at theapt.org Thu Oct 20 12:45:34 2016 From: phessler at theapt.org (Peter Hessler) Date: Thu, 20 Oct 2016 12:45:34 +0200 Subject: [address-policy-wg] seperate subject, because people can't follow directions In-Reply-To: <6383440c-9c4c-b89d-8ff1-e7db73fa9384@netskin.com> References: <9f21a405-af43-9ca6-5ace-07802b2b9998@ripe.net> <15b186e3-62c9-66db-c86e-6be52c27b66a@netskin.com> <20161020103023.GP79185@Space.Net> <6383440c-9c4c-b89d-8ff1-e7db73fa9384@netskin.com> Message-ID: <20161020104534.GI27221@gir.theapt.org> On 2016 Oct 20 (Thu) at 12:38:55 +0200 (+0200), Netskin NOC wrote: :On 20.10.2016 12:30, Gert Doering wrote: :>This is a separate discussion, and should not be done under the Subject: :>of 2016-03. :> :>Folks, I understand that e-mail is hard. But give it a try. : :I know and thus didn't start a discussion about the topic, I just suggested :it...probably by reviving the old thread I mentioned. : THEN CHANGE THE SUBJECT! This isn't rocket science, or even science at all. -- When Marriage is Outlawed, Only Outlaws will have Inlaws. From sander at steffann.nl Thu Oct 20 13:37:52 2016 From: sander at steffann.nl (Sander Steffann) Date: Thu, 20 Oct 2016 13:37:52 +0200 Subject: [address-policy-wg] ALLOCATED PI / UNSPECIFIED next action Message-ID: <33985AE5-1467-48DE-8FDB-90EFF92ADA62@steffann.nl> Hello working group, The discussion on how the RIPE NCC should deal with ALLOCATED PI / ALLOCATED UNSPECIFIED has died down a couple of weeks ago. We therefore think that it is time to draw conclusions. A total of 16 people and the working group chairs participated in the discussion following Ingrid?s proposal on how to handle the situation of PI assignments within ALLOCATED PI / UNSPECIFIED. Five people (Sergey Myasoedov, Radu-Adrian FEURDEAN, Nick Hilliard, Leo Vegoda and Hank Nussbacher) created side-threads without expressing an explicit opinion on the proposal. The remaining 11 people were: ? Patrick Velder ? Larisa Yurkina ? Randy Bush ? Enno Rey ? Herve Clement ? Stefan Schiele ? Markus Weber ? Carlos Friacas ? Leo Vegoda ? Andre Chapuis ? Daniel Stolpe ? Oliver Bartels Four participants stated that they represent organisations holding such allocations (Larisa, Markus, Andre and Daniel). Three people indicate that they are related to PI assignments within such allocations (Enno, Stefan and Oliver). Five people stated their clear support for the proposal (Enno, Stefan, Oliver, Patrick and Herve), mainly to increase clarity for PI assignment user and to support correct registration. While there was no explicit opposition, Larisa and Andre stated that it would create extra workload for their organisations while they don?t really see the gains of such change. Larisa suggested to introduce alternative RIPE database statuses instead. The other participants had mixed opinions: Markus understands the advantages for PI assignment users, but was concerned about the extra workload for his organisation. He suggested to somehow lock PI?s within the allocations and force the PI holders to sign contracts, but recognized that this idea might be not practicable. Daniel could life with the change from ASSIGNED PI to ASSIGNED PA but agreed with Larisa and Andre that there is actually no issue to be fixed. Randy supported the aim of correct registration but also stated his concerns about the routing table and that some PI holders might not be happy to pay a fee for the sponsoring LIR. Carlos also stated his concerns for the routing table. Conclusion: Five people supported the proposed approach, four people saw some advantages but also were concerned about side effects, while two people didn?t see the need to take action. There were three opposing arguments: - big workload compared to the gain - increase of the routing table - PI holders might not like to pay a fee for the sponsorship The first opposing argument can be considered as addressed as three PI users confirmed that a clarification of that issue would be very important to them. And the RIPE NCC can support the LIRs, for example making bulk updates on route and domain objects. The second opposing argument, could be considered that this is not directly related to the fixing of the registration. Already now all but one of the allocations in question contain more specific route advertisements. Also in the extem case that all ASSIGNED PI within the allocations would be carved out, we would talk few thousand new entries in regards to 628K total routing entries (normal growth of the routing table is around 2K per week). The third opposing argument was addressed by Gert, stating that PI holders appreciate to pay a small fee to be sure that their resources are correctly registered. Based on all of this I feel we have a strong enough mandate for the RIPE NCC to move forward, but some concerns about the amount of work involved. I therefore would like to ask the RIPE NCC on behalf of this working group to move forward with their plan, but to extend the proposed deadline of the end of January 2017 by a few months (the end of Q1 2017) to give LIRs a little bit more time if needed. Cheers, Sander APWG co-chair -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From stolpe at resilans.se Thu Oct 20 15:16:59 2016 From: stolpe at resilans.se (Daniel Stolpe) Date: Thu, 20 Oct 2016 15:16:59 +0200 (CEST) Subject: [address-policy-wg] ALLOCATED PI / UNSPECIFIED next action In-Reply-To: <33985AE5-1467-48DE-8FDB-90EFF92ADA62@steffann.nl> References: <33985AE5-1467-48DE-8FDB-90EFF92ADA62@steffann.nl> Message-ID: Thanks for the update and summary Sander! I have been thinking a bit both during this particular case and in general about something from another working group. Job introduced the concept of "numbered work items" with several phases and where the first phase reads like (quote): phase 1: problem definition In this phase as group we'll work on formulating an exact problem definition: text goes back and forth in the working group, example cases of the problem are provided. In a 2 or 3 weeks timeframe the chairs declare consensus on the problem statement of NWI. phase 1 output: clearly defined problem statement, or a conclusion we cannot agree upon a problem statement definition. If the latter is true, the NWI cannot proceed to phase 2. (end quote). Maybe it is only me but I have had the feeling sometimes that we are not completely sure what problem we are trying to solve, and that we can sometimes start with proposing a solution before the problem is well defined or agreed on. I think I am correct that the problem in the particualar case is unclear (unspecified or pi that is maybe not really pi) and/or incorrect (pi that is really pa) data and according to that I agree with Sanders summary below. Cheers, Daniel On Thu, 20 Oct 2016, Sander Steffann wrote: > Hello working group, > > The discussion on how the RIPE NCC should deal with ALLOCATED PI / ALLOCATED UNSPECIFIED has died down a couple of weeks ago. We therefore think that it is time to draw conclusions. > > A total of 16 people and the working group chairs participated in the discussion following Ingrid?s proposal on how to handle the situation of PI assignments within ALLOCATED PI / UNSPECIFIED. Five people (Sergey Myasoedov, Radu-Adrian FEURDEAN, Nick Hilliard, Leo Vegoda and Hank Nussbacher) created side-threads without expressing an explicit opinion on the proposal. > > The remaining 11 people were: > ? Patrick Velder > ? Larisa Yurkina > ? Randy Bush > ? Enno Rey > ? Herve Clement > ? Stefan Schiele > ? Markus Weber > ? Carlos Friacas > ? Leo Vegoda > ? Andre Chapuis > ? Daniel Stolpe > ? Oliver Bartels > > Four participants stated that they represent organisations holding such allocations (Larisa, Markus, Andre and Daniel). > Three people indicate that they are related to PI assignments within such allocations (Enno, Stefan and Oliver). > > Five people stated their clear support for the proposal (Enno, Stefan, Oliver, Patrick and Herve), mainly to increase clarity for PI assignment user and to support correct registration. > > While there was no explicit opposition, Larisa and Andre stated that it would create extra workload for their organisations while they don?t really see the gains of such change. Larisa suggested to introduce alternative RIPE database statuses instead. > > The other participants had mixed opinions: > Markus understands the advantages for PI assignment users, but was concerned about the extra workload for his organisation. He suggested to somehow lock PI?s within the allocations and force the PI holders to sign contracts, but recognized that this idea might be not practicable. > Daniel could life with the change from ASSIGNED PI to ASSIGNED PA but agreed with Larisa and Andre that there is actually no issue to be fixed. > Randy supported the aim of correct registration but also stated his concerns about the routing table and that some PI holders might not be happy to pay a fee for the sponsoring LIR. > Carlos also stated his concerns for the routing table. > > Conclusion: > Five people supported the proposed approach, four people saw some advantages but also were concerned about side effects, while two people didn?t see the need to take action. > > There were three opposing arguments: > - big workload compared to the gain > - increase of the routing table > - PI holders might not like to pay a fee for the sponsorship > > The first opposing argument can be considered as addressed as three PI users confirmed that a clarification of that issue would be very important to them. And the RIPE NCC can support the LIRs, for example making bulk updates on route and domain objects. > > The second opposing argument, could be considered that this is not directly related to the fixing of the registration. Already now all but one of the allocations in question contain more specific route advertisements. Also in the extem case that all ASSIGNED PI within the allocations would be carved out, we would talk few thousand new entries in regards to 628K total routing entries (normal growth of the routing table is around 2K per week). > > The third opposing argument was addressed by Gert, stating that PI holders appreciate to pay a small fee to be sure that their resources are correctly registered. > > Based on all of this I feel we have a strong enough mandate for the RIPE NCC to move forward, but some concerns about the amount of work involved. I therefore would like to ask the RIPE NCC on behalf of this working group to move forward with their plan, but to extend the proposed deadline of the end of January 2017 by a few months (the end of Q1 2017) to give LIRs a little bit more time if needed. > > Cheers, > Sander > APWG co-chair _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm From office at ip-broker.uk Thu Oct 20 15:39:56 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Thu, 20 Oct 2016 16:39:56 +0300 Subject: [address-policy-wg] ALLOCATED PI / UNSPECIFIED next action In-Reply-To: References: <33985AE5-1467-48DE-8FDB-90EFF92ADA62@steffann.nl> Message-ID: I agree with Daniel. A well defined problem is half of the solution. In this particular case the problem arises because the main question is who makes the money, the LIR or the end user. In the past there have been PAs used as PIs so technically I think the "allocated" part should be the one that's more important, therefore I would support the replacement of allocated pi & unspecified to allocated pa. If you ignore the greed then changing the status would not make any difference. Ripe has a relation with the LIR and the LIR with the customer. Changing PI to PA will not affect the workability of the IPs nor the relations that are already in place. Changing them to regular pi assignments would break the link between lir and customer and give the enduser a possibility to make money, nothing more. Ciprian On Thursday, October 20, 2016, Daniel Stolpe wrote: > > Thanks for the update and summary Sander! > > I have been thinking a bit both during this particular case and in general > about something from another working group. Job introduced the concept of > "numbered work items" with several phases and where the first phase reads > like (quote): > > phase 1: problem definition > In this phase as group we'll work on formulating an exact problem > definition: text goes back and forth in the working group, example > cases of the problem are provided. In a 2 or 3 weeks timeframe the > chairs declare consensus on the problem statement of NWI. > > phase 1 output: clearly defined problem statement, or a conclusion > we cannot agree upon a problem statement definition. If the latter > is true, the NWI cannot proceed to phase 2. > > (end quote). > > Maybe it is only me but I have had the feeling sometimes that we are not > completely sure what problem we are trying to solve, and that we can > sometimes start with proposing a solution before the problem is well > defined or agreed on. > > I think I am correct that the problem in the particualar case is unclear > (unspecified or pi that is maybe not really pi) and/or incorrect (pi that > is really pa) data and according to that I agree with Sanders summary below. > > Cheers, > Daniel > > On Thu, 20 Oct 2016, Sander Steffann wrote: > > Hello working group, >> >> The discussion on how the RIPE NCC should deal with ALLOCATED PI / >> ALLOCATED UNSPECIFIED has died down a couple of weeks ago. We therefore >> think that it is time to draw conclusions. >> >> A total of 16 people and the working group chairs participated in the >> discussion following Ingrid?s proposal on how to handle the situation of PI >> assignments within ALLOCATED PI / UNSPECIFIED. Five people (Sergey >> Myasoedov, Radu-Adrian FEURDEAN, Nick Hilliard, Leo Vegoda and Hank >> Nussbacher) created side-threads without expressing an explicit opinion on >> the proposal. >> >> The remaining 11 people were: >> ? Patrick Velder >> ? Larisa Yurkina >> ? Randy Bush >> ? Enno Rey >> ? Herve Clement >> ? Stefan Schiele >> ? Markus Weber >> ? Carlos Friacas >> ? Leo Vegoda >> ? Andre Chapuis >> ? Daniel Stolpe >> ? Oliver Bartels >> >> Four participants stated that they represent organisations holding such >> allocations (Larisa, Markus, Andre and Daniel). >> Three people indicate that they are related to PI assignments within such >> allocations (Enno, Stefan and Oliver). >> >> Five people stated their clear support for the proposal (Enno, Stefan, >> Oliver, Patrick and Herve), mainly to increase clarity for PI assignment >> user and to support correct registration. >> >> While there was no explicit opposition, Larisa and Andre stated that it >> would create extra workload for their organisations while they don?t really >> see the gains of such change. Larisa suggested to introduce alternative >> RIPE database statuses instead. >> >> The other participants had mixed opinions: >> Markus understands the advantages for PI assignment users, but was >> concerned about the extra workload for his organisation. He suggested to >> somehow lock PI?s within the allocations and force the PI holders to sign >> contracts, but recognized that this idea might be not practicable. >> Daniel could life with the change from ASSIGNED PI to ASSIGNED PA but >> agreed with Larisa and Andre that there is actually no issue to be fixed. >> Randy supported the aim of correct registration but also stated his >> concerns about the routing table and that some PI holders might not be >> happy to pay a fee for the sponsoring LIR. >> Carlos also stated his concerns for the routing table. >> >> Conclusion: >> Five people supported the proposed approach, four people saw some >> advantages but also were concerned about side effects, while two people >> didn?t see the need to take action. >> >> There were three opposing arguments: >> - big workload compared to the gain >> - increase of the routing table >> - PI holders might not like to pay a fee for the sponsorship >> >> The first opposing argument can be considered as addressed as three PI >> users confirmed that a clarification of that issue would be very important >> to them. And the RIPE NCC can support the LIRs, for example making bulk >> updates on route and domain objects. >> >> The second opposing argument, could be considered that this is not >> directly related to the fixing of the registration. Already now all but one >> of the allocations in question contain more specific route advertisements. >> Also in the extem case that all ASSIGNED PI within the allocations would be >> carved out, we would talk few thousand new entries in regards to 628K total >> routing entries (normal growth of the routing table is around 2K per week). >> >> The third opposing argument was addressed by Gert, stating that PI >> holders appreciate to pay a small fee to be sure that their resources are >> correctly registered. >> >> Based on all of this I feel we have a strong enough mandate for the RIPE >> NCC to move forward, but some concerns about the amount of work involved. I >> therefore would like to ask the RIPE NCC on behalf of this working group to >> move forward with their plan, but to extend the proposed deadline of the >> end of January 2017 by a few months (the end of Q1 2017) to give LIRs a >> little bit more time if needed. >> >> Cheers, >> Sander >> APWG co-chair >> > > ____________________________________________________________ > _____________________ > Daniel Stolpe Tel: 08 - 688 11 81 > stolpe at resilans.se > Resilans AB Fax: 08 - 55 00 21 63 > http://www.resilans.se/ > Box 45 094 > 556741-1193 > 104 30 Stockholm > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewh at ripe.net Thu Oct 20 16:41:41 2016 From: andrewh at ripe.net (Andrew de la Haye) Date: Thu, 20 Oct 2016 16:41:41 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) Message-ID: Dear Peter, > [from the impact assessmant] > > Returned IPv4 addresses from LIRs and End Users and addresses received > from IANA's recovered pool are currently added to the RIPE NCC's > available IPv4 pool. >If this proposal is accepted, legacy resources > that have been handed over to the RIPE NCC will also be added to the > available pool. Currently, the RIPE NCC >holds a total of ten /24 IPv4 > legacy resources. > > With apologies for lack of research; under what policy was this space > "accepted" > and not marked for return to IANA? There is no policy to give us guidance on what to do with received legacy space. However, the RIPE NCC has previously taken the initiative and returned address space to IANA on two separate occasions: 22 May 2012 https://www.ripe.net/publications/news/announcements/ripe-ncc-returns-legacy-address-space-to-iana 22 April 2014 https://www.ripe.net/publications/news/announcements/legacy-ipv4-address-space-returned-to-iana More recently, we have kept this address space separate and have not added it to our available pool. Kind regards Andrew de la Haye Chief Operations Officer RIPE NCC From elvis at velea.eu Thu Oct 20 17:44:45 2016 From: elvis at velea.eu (Elvis Daniel Velea) Date: Thu, 20 Oct 2016 18:44:45 +0300 Subject: [address-policy-wg] Fwd: Re: Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <48d42760-80dc-2e37-a436-e5ff46de00a3@velea.eu> References: <48d42760-80dc-2e37-a436-e5ff46de00a3@velea.eu> Message-ID: <0a5fc271-fdd3-650d-2d19-f49e7970bb18@velea.eu> Dear Sander, list, below is an e-mail sent on 8/29 which did not make it to the list. Dear RIPE NCC admins - please check and help me understand why the message forwarded below did not make it to the mailing list as the google mail server ( that is used to host my @velea.eu private e-mail address) shows it as delivered (in the Sent folder) and I did receive the (BCC'ed copy). - please note, I am hiding the IP address and the from host in the headers below with '*x*'. If you need these details, please send me a message privately and I will share the IP address and even the name of my workstation. Sander, please take this message into account as well. I hope/think that the message below could make a difference. I am sorry for reacting so late, I did not know that my message did not make it to the list until I saw Sander's message with the summary. Regards, Elvis -------- Forwarded Message -------- Return-Path: Received: from *x* ([*x.x.x.x*]) by smtp.googlemail.com with ESMTPSA id i80sm14433191wmf.11.2016.08.29.10.09.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Aug 2016 10:09:38 -0700 (PDT) Reply-To: elvis at velea.eu Subject: Re: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED References: <0a0dcd8a-a685-ed25-6837-0d807c370c21 at velder.li> <57A31AAE.6060305 at ripn.net> <20160804113710.GJ79185 at Space.Net> <20160804121033.GK79185 at Space.Net> To: address-policy-wg at ripe.net From: Elvis Daniel Velea Message-ID: <48d42760-80dc-2e37-a436-e5ff46de00a3 at velea.eu> Date: Mon, 29 Aug 2016 20:09:37 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi everyone, On 8/5/16 4:41 PM, Ingrid Wijte wrote: > Dear colleagues, > > >>>> Also, it might lead to deaggs (Markus' case) where a /14 that was >>>> originally "in one LIR" would be "3x /16, plus some smaller fragments >>>> in the LIR" and "lots of /24 PI managed by the NCC" now - so the /14 >>>> won't get a ROA, and he'll have to announce more-specifics. >>> lemme see if i get this. to have the owner registration correct, some >>> address space will have to be broken up and owned by multiple IRs, thus >>> fragmenting routing? i like correct registration, but the commons has >>> become pretty polluted. > > The main issue that we (the WG and the RIPE NCC) are trying to resolve > is the lack of clarity around the status and rights of these > assignments. It?s not necessarily the case that the End User > registration is incorrect. In many cases LIRs have put a lot of effort > into keeping this information up to date. I believe that since these were PI assignments - the holdership/ownership/call-it-whatever of the IP addresses stays with the company to which this IP block was registered - the PI holder. If the holder of the PI assignment agrees with the change of the block from ASSIGNED PI to PA, that will mean they are giving up on their right to hold/transfer the PI block. I think the main issue here is: who owns the rights of these IP addresses? If it's the LIR (because it was an allocation) - then they could kick the end-user out at any time. If it's the end-user - well, they should sign maintenance agreements as every PI holder and get those PIs under the same rules as everyone else's. I know of at least a few cases where the end-users have requested a PI assignment and have received one. However, some of them have received the PI assignments (approved by the RIPE NCC) from an ALLOCATED PI block while others have received them directly from the RIPE NCC. In both cases, the only one communicating with the RIPE NCC was the LIR. The end-users had no idea of the difference between the two PI blocks. That is why I believe that the NCC should talk to every PI holder from those PI/unspecified allocations and see if they - the end-users - the holders of the IP addresses - want to have the PI sponsored by an LIR (and therefore sign a maintenance agreement) or if they may want the IP block to be transferred to the LIR holding the large allocation (and transformed into ASSIGNED PA). The first step - talking to the allocation holder (the LIR) - is logical. However, if you only talk to the LIR you will only see one side of the story. It should be, I believe, the end-user that should decide whether they give up on their right to those IPs which now have become assets and are worth money. Therefore, I think that the RIPE NCC should talk to every single company holding a PI assignment from an ALLOCATED PI/UNSPECIFIED block and give them the option to give up on the maintenance of the IPs (and the right to transfer/sell) and transform them into ASSIGNED PA, or become a PI user - like all the others in the world - and sign a maintenance agreement with a LIR (and have the ?50/year associated cost). regards, elvis -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Thu Oct 20 18:33:12 2016 From: sander at steffann.nl (Sander Steffann) Date: Thu, 20 Oct 2016 18:33:12 +0200 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <0a5fc271-fdd3-650d-2d19-f49e7970bb18@velea.eu> References: <48d42760-80dc-2e37-a436-e5ff46de00a3@velea.eu> <0a5fc271-fdd3-650d-2d19-f49e7970bb18@velea.eu> Message-ID: <10AF06F1-F8B4-4BFF-B3E2-1B2DA8C09EA4@steffann.nl> Hello Elvis, > Therefore, I think that the RIPE NCC should talk to every single company > holding a PI assignment from an ALLOCATED PI/UNSPECIFIED block and give > them the option to give up on the maintenance of the IPs (and the right > to transfer/sell) and transform them into ASSIGNED PA, or become a PI > user - like all the others in the world - and sign a maintenance > agreement with a LIR (and have the ?50/year associated cost). The message Ingrid sent on the 4th of August already stated: "The WG agreed that, where the LIR can document a mutual agreement that they administer the address space, a conversion from PI to PA should take place. In all other cases, assignments with the status ASSIGNED PI should be treated as being assigned by the RIPE NCC." So no need to talk to each and every resource holder. The responsibility is with the LIR to show documentation, and the default is to convert the assignment to normal PI. And that is as far as we need to go here. The rest are implementation details and should be left to the RIPE NCC. Let's not micro-manage who exactly they should talk to. So to summarise: I think what you want is already part of what the RIPE NCC proposed, modulo implementation details. So the previous message holds: RIPE NCC, please move ahead. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From elvis at velea.eu Thu Oct 20 18:47:19 2016 From: elvis at velea.eu (Elvis Daniel Velea) Date: Thu, 20 Oct 2016 19:47:19 +0300 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <10AF06F1-F8B4-4BFF-B3E2-1B2DA8C09EA4@steffann.nl> References: <48d42760-80dc-2e37-a436-e5ff46de00a3@velea.eu> <0a5fc271-fdd3-650d-2d19-f49e7970bb18@velea.eu> <10AF06F1-F8B4-4BFF-B3E2-1B2DA8C09EA4@steffann.nl> Message-ID: Hi Sander, I think I should've carefully looked at Ingrid's e-mail, maybe through some glasses :) Indeed, the message from Ingrid stated exactly what I was asking for. I am still hoping to receive a message (it can be in private) from one of the the NCC's ops to see if we can find out why my initial message did not make it to the list. Apologies for all the noise, at least this is not 'popcorn style' like yesterday's :) Regards, Elvis On 10/20/16 7:33 PM, Sander Steffann wrote: > Hello Elvis, > >> Therefore, I think that the RIPE NCC should talk to every single company >> holding a PI assignment from an ALLOCATED PI/UNSPECIFIED block and give >> them the option to give up on the maintenance of the IPs (and the right >> to transfer/sell) and transform them into ASSIGNED PA, or become a PI >> user - like all the others in the world - and sign a maintenance >> agreement with a LIR (and have the ?50/year associated cost). > The message Ingrid sent on the 4th of August already stated: "The WG agreed that, where the LIR can document a mutual agreement that they administer the address space, a conversion from PI to PA should take place. In all other cases, assignments with the status ASSIGNED PI should be treated as being assigned by the RIPE NCC." > > So no need to talk to each and every resource holder. The responsibility is with the LIR to show documentation, and the default is to convert the assignment to normal PI. And that is as far as we need to go here. The rest are implementation details and should be left to the RIPE NCC. Let's not micro-manage who exactly they should talk to. > > So to summarise: I think what you want is already part of what the RIPE NCC proposed, modulo implementation details. So the previous message holds: RIPE NCC, please move ahead. > > Cheers, > Sander > From stefan at softtech.nl Thu Oct 20 21:44:19 2016 From: stefan at softtech.nl (Stefan van Westering) Date: Thu, 20 Oct 2016 19:44:19 +0000 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <20161020102910.GO79185@Space.Net> References: <759fa1dc-2f4a-4dcc-b5eb-38f4cd34c835@email.android.com> , <20161020102910.GO79185@Space.Net> Message-ID: <755E092F-722A-4645-932A-79833376C9F8@softtech.nl> Hi, I do not know if this is the right place. If not please direct me to the proper location to "vote" for this proposal. I support this proposal and thus: I say +1 for the proposal. With kind regards, Stefan van Westering SoftTech Automatisering B.V. Op 20 okt. 2016 om 12:29 heeft Gert Doering > het volgende geschreven: Hi, On Thu, Oct 20, 2016 at 01:24:12PM +0300, Ciprian Nica wrote: I oppose both policies. For 2015-04 it's obvious, a policy that is supposed to arrange my hair nicer would make me bold. You either do a cosmetic reorganisation or important changes which should never be added just like that, as some changes are minor and shouldn't be discussed (but in a different policy) As for 2016-03 I think we should set our goals right. Isn't everybody saying that IPv4 is dead for over 4 years already ? Isn't everybody saying that the only way forward is to IPv6 and exhausting RIPE's available pool sooner would help people move to IPv6 ? Please do NOT mix comments to different policies into an e-mail that has a Subject: that says "2016-03". This makes it MUCH harder for the chairs to go back to the mail archives later on and see who said what regarding a specific proposal - and then, if I cannot remember "oh, there was a comment about 2015-04 in a 2016-03 thread", you're going to complain that I have ignored your comment. Right? Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stecenkoserj at gmail.com Thu Oct 20 22:07:02 2016 From: stecenkoserj at gmail.com (Sergey Stecenko) Date: Thu, 20 Oct 2016 23:07:02 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <755E092F-722A-4645-932A-79833376C9F8@softtech.nl> References: <759fa1dc-2f4a-4dcc-b5eb-38f4cd34c835@email.android.com> <20161020102910.GO79185@Space.Net> <755E092F-722A-4645-932A-79833376C9F8@softtech.nl> Message-ID: Hi. If I am not wrong, the main idea of the NCC is to switch to IPv6 networks. But it strongly tries to stretch this process. This proposal will create more problems than benefit. If you remember the NCC already restricted multi LIR accounts and then asked members to vote to cancel it. Moreover there is already 24 month restriction for transfers. It is enough. So I opposite this proposal. --- Rgds, Serj 2016-10-20 22:44 GMT+03:00 Stefan van Westering : > Hi, > > I do not know if this is the right place. If not please direct me to the > proper location to "vote" for this proposal. > > I support this proposal and thus: > I say +1 for the proposal. > > With kind regards, > > > > Stefan van Westering > > > > SoftTech Automatisering B.V. > > > Op 20 okt. 2016 om 12:29 heeft Gert Doering het volgende > geschreven: > > Hi, > > On Thu, Oct 20, 2016 at 01:24:12PM +0300, Ciprian Nica wrote: > > I oppose both policies. > > > For 2015-04 it's obvious, a policy that is supposed to arrange my hair > > nicer would make me bold. You either do a cosmetic reorganisation or > > important changes which should never be added just like that, as some > > changes are minor and shouldn't be discussed (but in a different policy) > > > As for 2016-03 I think we should set our goals right. Isn't everybody > > saying that IPv4 is dead for over 4 years already ? Isn't everybody saying > > that the only way forward is to IPv6 and exhausting RIPE's available pool > > sooner would help people move to IPv6 ? > > > Please do NOT mix comments to different policies into an e-mail that > has a Subject: that says "2016-03". > > This makes it MUCH harder for the chairs to go back to the mail archives > later on and see who said what regarding a specific proposal - and then, > if I cannot remember "oh, there was a comment about 2015-04 in a 2016-03 > thread", you're going to complain that I have ignored your comment. Right? > > Gert Doering > -- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From sander at steffann.nl Thu Oct 20 22:10:43 2016 From: sander at steffann.nl (Sander Steffann) Date: Thu, 20 Oct 2016 22:10:43 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <759fa1dc-2f4a-4dcc-b5eb-38f4cd34c835@email.android.com> <20161020102910.GO79185@Space.Net> <755E092F-722A-4645-932A-79833376C9F8@softtech.nl> Message-ID: <78DBB12B-D8C1-480A-8A92-7AEB4F225083@steffann.nl> Hello Sergey, > If I am not wrong, the main idea of the NCC is to switch to IPv6 > networks. But it strongly tries to stretch this process. You seem to misunderstand how this works. It is the community that sets these policies, not the NCC. The RIPE NCC implements what the internet community (us) wants it to do. The NCC definitely isn't stretching the process of getting IPv6 deployed, quite the opposite. > So I opposite this proposal. Noted. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From stefan at softtech.nl Thu Oct 20 22:37:40 2016 From: stefan at softtech.nl (Stefan van Westering) Date: Thu, 20 Oct 2016 20:37:40 +0000 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <51ECAFC9-CBF3-4F83-BE57-3A48FC42F683@steffann.nl> References: <105CF2EB-9854-4FDD-85D2-4F746A626D5A@steffann.nl> <204be962de2c4ea8a44922c0df8c0c3a@ipv4trade.eu>, <51ECAFC9-CBF3-4F83-BE57-3A48FC42F683@steffann.nl> Message-ID: Hi, Just like the other proposal (2016-03) i support this proposal and thus: I say +1 for this proposal. Again if this is not the right place or need extra motivation to be noted, let me know. With kind regards, Stefan van Westering SoftTech Automatisering B.V. Op 19 okt. 2016 om 21:04 heeft Sander Steffann > het volgende geschreven: Hello Marius, Thank you for the explanations, but I believe you haven't really addressed the issues I mentioned. The first issue is ABOUT Transfer Policies, to pay the annual membership fee after you TRANSFER ALL YOUR RESOURCES and maybe even close your Company, is about Transfer Policies. No, that is about your contractual agreement with the RIPE NCC. Your second answer is very subjective, have you ever buy and merge Companies? I've done that a couple of times, you never sell the company's (you merge) resources before the merge, because that company doesn't belong to you before the merge and is not you to decide regarding selling anything of that Company resources, either that is IP or fiber optic cable. Is NOT AT ALL what you mention:"First acquiring them only to immediately sell them again is explicitly not allowed by RIPE policy". What this have to do with the situation I mention ??? Please refer to the situation I mention, not on other matters that have nothing to do with it. This is exactly the situation you mention: you buy a company, acquiring all their assets. One of those assets is an IPv4 allocation from RIPE NCC. To prevent speculation with IPv4 resources it is not allowed to sell those resources within 24 months of acquiring them. So in your case: buy the company, keep it running as a separate company/LIR for a little while, sort out where you want to transfer the resources you don't need, then merge the companies/LIRs. So, no problem. Sander -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfriacas at fccn.pt Thu Oct 20 23:30:21 2016 From: cfriacas at fccn.pt (Carlos Friacas) Date: Thu, 20 Oct 2016 22:30:21 +0100 (WEST) Subject: [address-policy-wg] ALLOCATED PI / UNSPECIFIED next action In-Reply-To: References: <33985AE5-1467-48DE-8FDB-90EFF92ADA62@steffann.nl> Message-ID: Hi, On Thu, 20 Oct 2016, Ciprian Nica wrote: > I agree with Daniel. A well defined problem is half of the solution. +1. > In this particular case the problem arises because the main question is who makes?the money, the LIR or the end user. And when noone is really "making money", but is just using the number resources as they were originally distributed...??? > In the past there have been PAs used as PIs Yes. But that doesn't qualify as "a mess" or "swamp"? > so technically I think the "allocated" part should be the one that's > more important, therefore I would support the replacement of allocated > pi & unspecified to allocated pa. Why would you want to change status of something that belongs/is in use by other organizations? With or without agreement from the end user (and LIR)? > If you ignore the greed then changing the status would not make any > difference.? Maybe we need to revisit how this "issue" was created in the first place... (and when). > Ripe has a relation with the LIR and the LIR with the customer. 1st part is true. 2nd part i really wish it was true... this (ALLOCATED PI/UNSPECIFIED blocks) is not LEGACY space, but there are some tricky details too... :-( > Changing PI to PA will not affect the workability of the IPs nor the > relations that are already in place. Yes they can be..... and this can probably be observed from the routing info. Example: LIR manages /16, everything is PI, so every /24 is already "globally routable". Once that /16 automagically becomes PA, anyone in the world can happilly reject any /24 from the /16. This is even harder if end users are not using the same upstream and/or don't even have any relationship with the LIR -- can happen, does happen because this goes wayyyyyy back. Please keep in mind this still comes from the 20th century... ;-) > Changing them to regular pi assignments would break the link between > lir and customer and give the enduser a possibility to make money, > nothing more. ??? Afaik, they are already PI. The link is (probably) mostly broken, and, imho that's the core of the "monster" we have to deal with ;-) Cheers, Carlos > Ciprian > > On Thursday, October 20, 2016, Daniel Stolpe wrote: > > Thanks for the update and summary Sander! > > I have been thinking a bit both during this particular case and in general about something from another working group. Job introduced the concept of > "numbered work items" with several phases and where the first phase reads like (quote): > > phase 1: problem definition > ? ? In this phase as group we'll work on formulating an exact problem > ? ? definition: text goes back and forth in the working group, example > ? ? cases of the problem are provided. In a 2 or 3 weeks timeframe the > ? ? chairs declare consensus on the problem statement of NWI. > > ? ? phase 1 output: clearly defined problem statement, or a conclusion > ? ? we cannot agree upon a problem statement definition. If the latter > ? ? is true, the NWI cannot proceed to phase 2. > > (end quote). > > Maybe it is only me but I have had the feeling sometimes that we are not completely sure what problem we are trying to solve, and that we can sometimes > start with proposing a solution before the problem is well defined or agreed on. > > I think I am correct that the problem in the particualar case is unclear (unspecified or pi that is maybe not really pi) and/or incorrect (pi that is > really pa) data and according to that I agree with Sanders summary below. > > Cheers, > Daniel > > On Thu, 20 Oct 2016, Sander Steffann wrote: > > Hello working group, > > The discussion on how the RIPE NCC should deal with ALLOCATED PI / ALLOCATED UNSPECIFIED has died down a couple of weeks ago. We therefore > think that it is time to draw conclusions. > > A total of 16 people and the working group chairs participated in the discussion following Ingrid?s proposal on how to handle the situation > of PI assignments within ALLOCATED PI / UNSPECIFIED. Five people (Sergey Myasoedov, Radu-Adrian FEURDEAN, Nick Hilliard, Leo Vegoda and Hank > Nussbacher) created side-threads without expressing an explicit opinion on the proposal. > > The remaining 11 people were: > ?? ? Patrick Velder > ?? ? Larisa Yurkina > ?? ? Randy Bush > ?? ? Enno Rey > ?? ? Herve Clement > ?? ? Stefan Schiele > ?? ? Markus Weber > ?? ? Carlos Friacas > ?? ? Leo Vegoda > ?? ? Andre Chapuis > ?? ? Daniel Stolpe > ?? ? Oliver Bartels > > Four participants stated that they represent organisations holding such allocations (Larisa, Markus, Andre and Daniel). > Three people indicate that they are related to PI assignments within such allocations (Enno, Stefan and Oliver). > > Five people stated their clear support for the proposal (Enno, Stefan, Oliver, Patrick and Herve), mainly to increase clarity for PI > assignment user and to support correct registration. > > While there was no explicit opposition, Larisa and Andre stated that it would create extra workload for their organisations while they don?t > really see the gains of such change. Larisa suggested to introduce alternative RIPE database statuses instead. > > The other participants had mixed opinions: > Markus understands the advantages for PI assignment users, but was concerned about the extra workload for his organisation. He suggested to > somehow lock PI?s within the allocations and force the PI holders to sign contracts, but recognized that this idea might be not practicable. > Daniel could life with the change from ASSIGNED PI to ASSIGNED PA but agreed with Larisa and Andre that there is actually no issue to be > fixed. > Randy supported the aim of correct registration but also stated his concerns about the routing table and that some PI holders might not be > happy to pay a fee for the sponsoring LIR. > Carlos also stated his concerns for the routing table. > > Conclusion: > Five people supported the proposed approach, four people saw some advantages but also were concerned about side effects, while two people > didn?t see the need to take action. > > There were three opposing arguments: > - big workload compared to the gain > - increase of the routing table > - PI holders might not like to pay a fee for the sponsorship > > The first opposing argument can be considered as addressed as three PI users confirmed that a clarification of that issue would be very > important to them. And the RIPE NCC can support the LIRs, for example making bulk updates on route and domain objects. > > The second opposing argument, could be considered that this is not directly related to the fixing of the registration. Already now all but > one of the allocations in question contain more specific route advertisements. Also in the extem case that all ASSIGNED PI within the > allocations would be carved out, we would talk few thousand new entries in regards to 628K total routing entries (normal growth of the > routing table is around 2K per week). > > The third opposing argument was addressed by Gert, stating that PI holders appreciate to pay a small fee to be sure that their resources are > correctly registered. > > Based on all of this I feel we have a strong enough mandate for the RIPE NCC to move forward, but some concerns about the amount of work > involved. I therefore would like to ask the RIPE NCC on behalf of this working group to move forward with their plan, but to extend the > proposed deadline of the end of January 2017 by a few months (the end of Q1 2017) to give LIRs a little bit more time if needed. > > Cheers, > Sander > APWG co-chair > > > _________________________________________________________________________________ > Daniel Stolpe? ? ? ? ? ?Tel:? 08 - 688 11 81? ? ? ? ? ? ? ? ? ?stolpe at resilans.se > Resilans AB? ? ? ? ? ? ?Fax:? 08 - 55 00 21 63? ? ? ? ? ? http://www.resilans.se/ > Box 45 094? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 556741-1193 > 104 30 Stockholm > > > > From cfriacas at fccn.pt Thu Oct 20 23:33:23 2016 From: cfriacas at fccn.pt (Carlos Friacas) Date: Thu, 20 Oct 2016 22:33:23 +0100 (WEST) Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: Andrew, Well done! (others might disagree) ps: Maybe someone needs to kickstart a new policy proposal about this. Regards, Carlos Fria?as On Thu, 20 Oct 2016, Andrew de la Haye wrote: > Dear Peter, > >> [from the impact assessmant] >> >> Returned IPv4 addresses from LIRs and End Users and addresses received >> from IANA's recovered pool are currently added to the RIPE NCC's available >> IPv4 pool. >If this proposal is accepted, legacy resources that have been >> handed over to the RIPE NCC will also be added to the available pool. >> Currently, the RIPE NCC >holds a total of ten /24 IPv4 legacy resources. >> >> With apologies for lack of research; under what policy was this space >> "accepted" >> and not marked for return to IANA? > > There is no policy to give us guidance on what to do with received legacy > space. However, the RIPE NCC has previously taken the initiative and returned > address space to IANA on two separate occasions: > > 22 May 2012 > https://www.ripe.net/publications/news/announcements/ripe-ncc-returns-legacy-address-space-to-iana > > 22 April 2014 > https://www.ripe.net/publications/news/announcements/legacy-ipv4-address-space-returned-to-iana > > More recently, we have kept this address space separate and have not added it > to our available pool. > > Kind regards > > Andrew de la Haye > Chief Operations Officer > RIPE NCC > From mschmidt at ripe.net Fri Oct 21 10:15:52 2016 From: mschmidt at ripe.net (Marco Schmidt) Date: Fri, 21 Oct 2016 10:15:52 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) Message-ID: Dear colleagues, A new RIPE Policy proposal 2016-04, "IPv6 PI Sub-assignment Clarification" is now available for discussion. The goal of this proposal is to define sub-assignments in IPv6 PI assignments as subnets of /64 and shorter. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-04 We encourage you to review this proposal and send your comments to before 21 November 2016. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From david at sargasso.net Fri Oct 21 10:32:24 2016 From: david at sargasso.net (David Croft) Date: Fri, 21 Oct 2016 10:32:24 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: References: Message-ID: Strong support in principle. We have been denied IPv6 temporary assignments due to the NCC's interpretation that a single DHCP lease on wifi is a "subassignment" to another entity, which was clearly not the intention. I note that the "New policy text" does not specify the replacement text for the "Contractual Requirements" Regards, David On 21 October 2016 at 10:15, Marco Schmidt wrote: > Dear colleagues, > > A new RIPE Policy proposal 2016-04, "IPv6 PI Sub-assignment Clarification" > is now available for discussion. > > The goal of this proposal is to define sub-assignments in IPv6 PI assignments as subnets of /64 and shorter. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2016-04 > > We encourage you to review this proposal and send your comments to > before 21 November 2016. > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > -- David Croft For support enquiries please always contact support at sargasso.net and not any named individual. UK: 0845 034 5020 USA: 212-400-1694 Sargasso Networks Ltd. Registered in England and Wales No. 06404839. Registered Office: 46a Albert Road North, Reigate, Surrey, RH2 9EL http://www.sargasso.net/ From office at ip-broker.uk Fri Oct 21 10:43:03 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Fri, 21 Oct 2016 11:43:03 +0300 Subject: [address-policy-wg] ALLOCATED PI / UNSPECIFIED next action In-Reply-To: References: <33985AE5-1467-48DE-8FDB-90EFF92ADA62@steffann.nl> Message-ID: Dear Carlos, What I was trying to say is that if we try not to complicate things then we can say there were IPs given to LIRs which they would distribute to the end-users and those IPs should remain under LIR's control and there were IPs given to end users through LIRs. The status of the IPs is just a text. Everything has to be based on contracts between RIR -> LIR and LIR -> user. It is not important what the status was, the IPs were and are used exactly the same way. And you are wrong, having a PA assignment doesn't restrict you at all. Everybody accepts /24 announcements no matter their status and it's no longer the case with RIPE's recommended longest prefix. That was changed to /24 long time ago. So today if someone has a /24 assigned PA from an LIR, he can announce it through whatever ISPs he wants and doens't need to have anything to do with the LIR except from the agreement through which he got the IPs from the LIR. As for the PI assignments that were made from PI allocations, the purpose was indeed to make a distinctions between multihomed users and those who used only the LIR as their upstream provider, it was supposed to help with the aggregation but it was never respected. Always there have been PA assignments used exactly the same way as PI assignments and, even though I had objections at the time, NCC said that's perfectly ok. Now, if the PI assignment holder doesn't have a contract with the LIR, then what are we talking about, he should return the IPs immediately. If he has an agreement, they can continue happily with that agreement even if the status would change from PI to PA. >From my point of view it's a simple solution to a not very complicated problem. But as I mentioned it's always about the money. I have no interest in this, I don't have any PI blocks (either allocated or assigned) and I support the logic behind the process. I would consider it an abuse if NCC would interfere between an LIR and it's customer and I don't think that we, the RIPE community, should support something like that. By adopting a policy which would probably break some contracts could result in some legal complaints. And why are we doing this ? Just for a few silvers ? Ciprian On Fri, Oct 21, 2016 at 12:30 AM, Carlos Friacas wrote: > > Hi, > > On Thu, 20 Oct 2016, Ciprian Nica wrote: > > I agree with Daniel. A well defined problem is half of the solution. >> > > +1. > > In this particular case the problem arises because the main question is >> who makes the money, the LIR or the end user. >> > > And when noone is really "making money", but is just using the number > resources as they were originally distributed...??? > > > In the past there have been PAs used as PIs >> > > Yes. But that doesn't qualify as "a mess" or "swamp"? > > > so technically I think the "allocated" part should be the one that's more >> important, therefore I would support the replacement of allocated pi & >> unspecified to allocated pa. >> > > Why would you want to change status of something that belongs/is in use by > other organizations? > With or without agreement from the end user (and LIR)? > > > If you ignore the greed then changing the status would not make any >> difference. >> > > Maybe we need to revisit how this "issue" was created in the first > place... (and when). > > > Ripe has a relation with the LIR and the LIR with the customer. >> > > 1st part is true. 2nd part i really wish it was true... this (ALLOCATED > PI/UNSPECIFIED blocks) is not LEGACY space, but there are some tricky > details too... :-( > > > Changing PI to PA will not affect the workability of the IPs nor the >> relations that are already in place. >> > > Yes they can be..... and this can probably be observed from the routing > info. > > Example: LIR manages /16, everything is PI, so every /24 is already > "globally routable". Once that /16 automagically becomes PA, anyone in the > world can happilly reject any /24 from the /16. This is even harder if end > users are not using the same upstream and/or don't even have any > relationship with the LIR -- can happen, does happen because this goes > wayyyyyy back. > > Please keep in mind this still comes from the 20th century... ;-) > > > Changing them to regular pi assignments would break the link between lir >> and customer and give the enduser a possibility to make money, nothing more. >> > > ??? > Afaik, they are already PI. The link is (probably) mostly broken, and, > imho that's the core of the "monster" we have to deal with ;-) > > > Cheers, > Carlos > > > > Ciprian >> >> On Thursday, October 20, 2016, Daniel Stolpe wrote: >> >> Thanks for the update and summary Sander! >> >> I have been thinking a bit both during this particular case and in >> general about something from another working group. Job introduced the >> concept of >> "numbered work items" with several phases and where the first phase >> reads like (quote): >> >> phase 1: problem definition >> In this phase as group we'll work on formulating an exact >> problem >> definition: text goes back and forth in the working group, >> example >> cases of the problem are provided. In a 2 or 3 weeks timeframe >> the >> chairs declare consensus on the problem statement of NWI. >> >> phase 1 output: clearly defined problem statement, or a >> conclusion >> we cannot agree upon a problem statement definition. If the >> latter >> is true, the NWI cannot proceed to phase 2. >> >> (end quote). >> >> Maybe it is only me but I have had the feeling sometimes that we >> are not completely sure what problem we are trying to solve, and that we >> can sometimes >> start with proposing a solution before the problem is well defined >> or agreed on. >> >> I think I am correct that the problem in the particualar case is >> unclear (unspecified or pi that is maybe not really pi) and/or incorrect >> (pi that is >> really pa) data and according to that I agree with Sanders summary >> below. >> >> Cheers, >> Daniel >> >> On Thu, 20 Oct 2016, Sander Steffann wrote: >> >> Hello working group, >> >> The discussion on how the RIPE NCC should deal with ALLOCATED >> PI / ALLOCATED UNSPECIFIED has died down a couple of weeks ago. We therefore >> think that it is time to draw conclusions. >> >> A total of 16 people and the working group chairs >> participated in the discussion following Ingrid?s proposal on how to handle >> the situation >> of PI assignments within ALLOCATED PI / UNSPECIFIED. Five >> people (Sergey Myasoedov, Radu-Adrian FEURDEAN, Nick Hilliard, Leo Vegoda >> and Hank >> Nussbacher) created side-threads without expressing an >> explicit opinion on the proposal. >> >> The remaining 11 people were: >> ? Patrick Velder >> ? Larisa Yurkina >> ? Randy Bush >> ? Enno Rey >> ? Herve Clement >> ? Stefan Schiele >> ? Markus Weber >> ? Carlos Friacas >> ? Leo Vegoda >> ? Andre Chapuis >> ? Daniel Stolpe >> ? Oliver Bartels >> >> Four participants stated that they represent organisations >> holding such allocations (Larisa, Markus, Andre and Daniel). >> Three people indicate that they are related to PI assignments >> within such allocations (Enno, Stefan and Oliver). >> >> Five people stated their clear support for the proposal >> (Enno, Stefan, Oliver, Patrick and Herve), mainly to increase clarity for PI >> assignment user and to support correct registration. >> >> While there was no explicit opposition, Larisa and Andre >> stated that it would create extra workload for their organisations while >> they don?t >> really see the gains of such change. Larisa suggested to >> introduce alternative RIPE database statuses instead. >> >> The other participants had mixed opinions: >> Markus understands the advantages for PI assignment users, >> but was concerned about the extra workload for his organisation. He >> suggested to >> somehow lock PI?s within the allocations and force the PI >> holders to sign contracts, but recognized that this idea might be not >> practicable. >> Daniel could life with the change from ASSIGNED PI to >> ASSIGNED PA but agreed with Larisa and Andre that there is actually no >> issue to be >> fixed. >> Randy supported the aim of correct registration but also >> stated his concerns about the routing table and that some PI holders might >> not be >> happy to pay a fee for the sponsoring LIR. >> Carlos also stated his concerns for the routing table. >> >> Conclusion: >> Five people supported the proposed approach, four people saw >> some advantages but also were concerned about side effects, while two people >> didn?t see the need to take action. >> >> There were three opposing arguments: >> - big workload compared to the gain >> - increase of the routing table >> - PI holders might not like to pay a fee for the sponsorship >> >> The first opposing argument can be considered as addressed as >> three PI users confirmed that a clarification of that issue would be very >> important to them. And the RIPE NCC can support the LIRs, for >> example making bulk updates on route and domain objects. >> >> The second opposing argument, could be considered that this >> is not directly related to the fixing of the registration. Already now all >> but >> one of the allocations in question contain more specific >> route advertisements. Also in the extem case that all ASSIGNED PI within the >> allocations would be carved out, we would talk few thousand >> new entries in regards to 628K total routing entries (normal growth of the >> routing table is around 2K per week). >> >> The third opposing argument was addressed by Gert, stating >> that PI holders appreciate to pay a small fee to be sure that their >> resources are >> correctly registered. >> >> Based on all of this I feel we have a strong enough mandate >> for the RIPE NCC to move forward, but some concerns about the amount of work >> involved. I therefore would like to ask the RIPE NCC on >> behalf of this working group to move forward with their plan, but to extend >> the >> proposed deadline of the end of January 2017 by a few months >> (the end of Q1 2017) to give LIRs a little bit more time if needed. >> >> Cheers, >> Sander >> APWG co-chair >> >> >> ____________________________________________________________ >> _____________________ >> Daniel Stolpe Tel: 08 - 688 11 81 >> stolpe at resilans.se >> Resilans AB Fax: 08 - 55 00 21 63 >> http://www.resilans.se/ >> Box 45 094 >> 556741-1193 >> 104 30 Stockholm >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From office at ip-broker.uk Fri Oct 21 10:49:51 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Fri, 21 Oct 2016 11:49:51 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <105CF2EB-9854-4FDD-85D2-4F746A626D5A@steffann.nl> <204be962de2c4ea8a44922c0df8c0c3a@ipv4trade.eu> <51ECAFC9-CBF3-4F83-BE57-3A48FC42F683@steffann.nl> Message-ID: Hi, Since there were many discussions and yes, I've made the mistake to write in a different topic about the 2015-04, I want to state clearly that I oppose this policy. Again, if it would do what it's goal is, then it would be perfect. But it doesn't. It brings up important changes which are commented by people with no experience in mergers and acquisitions. While working for RCS&RDS I have seen many takovers and acquisitions and I know how the process goes. It's not always easy and definitely complicated. Why do we need to put more stones in front of the wagon ? An acquisition is not just signing a transfer agreement. For regular transfers it's ok to have a 24 months hold period, but asimilating a regular transfer with a company acquisition is wrong. Buying a company needs to be documented with official, state issued, documents. That is if I prove that I legally acquired a company, why would you think that it's something fishy and the purpose was to hide a simple transfer of IPs ? The two are nowhere near to be compared. The acquisition process takes time and money which represents already enough reasons not to mask a transfer this way. Ciprian On Thu, Oct 20, 2016 at 11:37 PM, Stefan van Westering wrote: > Hi, > > Just like the other proposal (2016-03) i support this proposal and thus: > I say +1 for this proposal. > > Again if this is not the right place or need extra motivation to be noted, > let me know. > > *With kind regards,* > > > > *Stefan van Westering* > > > > *SoftTech Automatisering B.V.* > > > > Op 19 okt. 2016 om 21:04 heeft Sander Steffann het > volgende geschreven: > > Hello Marius, > > Thank you for the explanations, but I believe you haven't really addressed > the issues I mentioned. > > The first issue is ABOUT Transfer Policies, to pay the annual membership > fee after you TRANSFER ALL YOUR RESOURCES and maybe even close your > Company, is about Transfer Policies. > > > No, that is about your contractual agreement with the RIPE NCC. > > Your second answer is very subjective, have you ever buy and merge > Companies? I've done that a couple of times, you never sell the company's > (you merge) resources before the merge, because that company doesn't belong > to you before the merge and is not you to decide regarding selling anything > of that Company resources, either that is IP or fiber optic cable. Is NOT > AT ALL what you mention:"First acquiring them only to immediately sell them > again is explicitly not allowed by RIPE policy". What this have to do with > the situation I mention ??? Please refer to the situation I mention, not on > other matters that have nothing to do with it. > > > This is exactly the situation you mention: you buy a company, acquiring > all their assets. One of those assets is an IPv4 allocation from RIPE NCC. > To prevent speculation with IPv4 resources it is not allowed to sell those > resources within 24 months of acquiring them. > > So in your case: buy the company, keep it running as a separate > company/LIR for a little while, sort out where you want to transfer the > resources you don't need, then merge the companies/LIRs. > > So, no problem. > Sander > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From he at uninett.no Fri Oct 21 11:43:08 2016 From: he at uninett.no (Havard Eidnes) Date: Fri, 21 Oct 2016 11:43:08 +0200 (CEST) Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <51ECAFC9-CBF3-4F83-BE57-3A48FC42F683@steffann.nl> Message-ID: <20161021.114308.1325955746172376290.he@uninett.no> > Since there were many discussions and yes, I've made the mistake to write > in a different topic about the 2015-04, I want to state clearly that I > oppose this policy. > > Again, if it would do what it's goal is, then it would be perfect. But it > doesn't. It brings up important changes which are commented by people with > no experience in mergers and acquisitions. > > While working for RCS&RDS I have seen many takovers and acquisitions and I > know how the process goes. It's not always easy and definitely complicated. This basically says "I know this process, you don't, I won't tell you the details, instead trust me!" I would say that I would completely understand if this doesn't carry any weight with the majority of the participants here, and is probably unlikely to sway opinion in your favour. > Why do we need to put more stones in front of the wagon? An acquisition is > not just signing a transfer agreement. For regular transfers it's ok to > have a 24 months hold period, but asimilating a regular transfer with a > company acquisition is wrong. Buying a company needs to be documented with > official, state issued, documents. That is if I prove that I legally > acquired a company, why would you think that it's something fishy and the > purpose was to hide a simple transfer of IPs? The two are nowhere near to > be compared. The acquisition process takes time and money which represents > already enough reasons not to mask a transfer this way. My guess: because there is a widespread perception (right or wrong) that the mergers and aquisitions procedure has been abused (in the past?) to violate the intention of the "last /8" policy. The ease with which companies can be formed in some jurisdictions does not provide what's seen as a sufficient push-back against abusing this avenue of forming companies solely for the purpose of getting a /22 out of the last /8 with the (not so well hidden) intention of simply merging this company with another once the resource has been issued, and then transferring the resource out of the merged company. Regards, - H?vard From office at ip-broker.uk Fri Oct 21 11:53:52 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Fri, 21 Oct 2016 12:53:52 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <20161021.114308.1325955746172376290.he@uninett.no> References: <51ECAFC9-CBF3-4F83-BE57-3A48FC42F683@steffann.nl> <20161021.114308.1325955746172376290.he@uninett.no> Message-ID: What you say could be expressed (again it's a metaphor) like this: Someone (probably) has noticed abuse from some people in the past. Let's throw everybody in jail and this way we'll make sure there is no abuse. I would go with the let's do a better job in identifying abuse and not allowing it to happen. As for the takeovers, it's not that I wouldn't get into details. My previous employer has acuired probably over 100 other companies. Every case was particular and some took years to integrate. You can not sell the IPs before integrating their network. In all the situations, even when we know there was an agreement for acquisition of company X, it wasn't absorbed overnight. The process is complex and involves approvals from various authorities, integration of the network, migration of customers and in the end you can draw the line and mark as unused the as number, IPs, computers, etc. Ciprian On Friday, October 21, 2016, Havard Eidnes wrote: > > Since there were many discussions and yes, I've made the mistake to write > > in a different topic about the 2015-04, I want to state clearly that I > > oppose this policy. > > > > Again, if it would do what it's goal is, then it would be perfect. But it > > doesn't. It brings up important changes which are commented by people > with > > no experience in mergers and acquisitions. > > > > While working for RCS&RDS I have seen many takovers and acquisitions and > I > > know how the process goes. It's not always easy and definitely > complicated. > > This basically says "I know this process, you don't, I won't tell > you the details, instead trust me!" > > I would say that I would completely understand if this doesn't > carry any weight with the majority of the participants here, and > is probably unlikely to sway opinion in your favour. > > > Why do we need to put more stones in front of the wagon? An acquisition > is > > not just signing a transfer agreement. For regular transfers it's ok to > > have a 24 months hold period, but asimilating a regular transfer with a > > company acquisition is wrong. Buying a company needs to be documented > with > > official, state issued, documents. That is if I prove that I legally > > acquired a company, why would you think that it's something fishy and the > > purpose was to hide a simple transfer of IPs? The two are nowhere near > to > > be compared. The acquisition process takes time and money which > represents > > already enough reasons not to mask a transfer this way. > > My guess: because there is a widespread perception (right or wrong) > that the mergers and aquisitions procedure has been abused (in the > past?) to violate the intention of the "last /8" policy. The ease > with which companies can be formed in some jurisdictions does not > provide what's seen as a sufficient push-back against abusing this > avenue of forming companies solely for the purpose of getting a /22 > out of the last /8 with the (not so well hidden) intention of simply > merging this company with another once the resource has been issued, > and then transferring the resource out of the merged company. > > Regards, > > - H?vard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Fri Oct 21 12:32:58 2016 From: sander at steffann.nl (Sander Steffann) Date: Fri, 21 Oct 2016 12:32:58 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <51ECAFC9-CBF3-4F83-BE57-3A48FC42F683@steffann.nl> <20161021.114308.1325955746172376290.he@uninett.no> Message-ID: Hi Ciprian, > As for the takeovers, it's not that I wouldn't get into details. My previous employer has acuired probably over 100 other companies. Every case was particular and some took years to integrate. You can not sell the IPs before integrating their network. So then what is the problem with the 24 month holding period? It sounds like it works exactly as designed: you can't sell addresses immediately, but there is no problem selling then after a multi-year integration project. Cheers, Sander From he at uninett.no Fri Oct 21 12:45:01 2016 From: he at uninett.no (Havard Eidnes) Date: Fri, 21 Oct 2016 12:45:01 +0200 (CEST) Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <20161021.114308.1325955746172376290.he@uninett.no> Message-ID: <20161021.124501.1230279093156300597.he@uninett.no> > What you say could be expressed (again it's a metaphor) like this: If you're interested in swaying the opinion in your favour you would do well by avoiding arguing by using metaphors or colurful paraphrasing, and instead argue the individual items you apparently so very much disagree with. > As for the takeovers, it's not that I wouldn't get into details. My > previous employer has acuired probably over 100 other companies. Every case > was particular and some took years to integrate. You can not sell the IPs > before integrating their network. > > In all the situations, even when we know there was an agreement for > acquisition of company X, it wasn't absorbed overnight. The process is > complex and involves approvals from various authorities, integration of the > network, migration of customers and in the end you can draw the line and > mark as unused the as number, IPs, computers, etc. You conveniently side-stepped answering the case I described. Note that I wrote "*solely* for the purpose of of getting a /22...". In that case there would be no customers to move or networks to merge. I would say it is incumbent upon you to justify that we should keep this loophole as wide as a truck in the policy. The 24-month holding period puts a damper on this avenue of abuse against the intention of the last /8 policy, and would put a little bit more longevity into the availability of the resources under that policy. It may be that this diminishes your company's prospects of near-future income, to which I would say that basing your buisness on the abuse of something which is perceived as a common resource is perhaps not worthy of so much sympathy? Regards, - H?vard From max at rfc2324.org Fri Oct 21 12:55:27 2016 From: max at rfc2324.org (Maximilian Wilhelm) Date: Fri, 21 Oct 2016 12:55:27 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: References: Message-ID: <20161021105527.GS25148@principal.rfc2324.org> Anno domini 2016 David Croft scripsit: > Strong support in principle. We have been denied IPv6 temporary > assignments due to the NCC's interpretation that a single DHCP lease > on wifi is a "subassignment" to another entity, which was clearly not > the intention. Thanks for the support. > I note that the "New policy text" does not specify the replacement > text for the "Contractual Requirements" That doesn't seem neccessary as the point in question - the definiton of a sub-assignment - is specified in the new version of ripe-655. What are you missing? Best Max -- <@Placebox> Gibts eigentlich IRGENDWAS im IT-Bereich, was nicht a priori komplett schei?e ist? <@Zugschlus> all software sucks From apwg at c4inet.net Fri Oct 21 12:57:07 2016 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Fri, 21 Oct 2016 11:57:07 +0100 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <20161021.124501.1230279093156300597.he@uninett.no> References: <20161021.114308.1325955746172376290.he@uninett.no> <20161021.124501.1230279093156300597.he@uninett.no> Message-ID: <20161021105707.GJ93886@cilantro.c4inet.net> You would do well to take some lessons in debate culture yourself. You're -not even too veiledly- accusing another member of abuse, something we have heard altogether too much of lately. As for 2015-04, I oppose it as it tries yet again to bring M&A under policy regulation (s. 2.2) which the community has no business doing. Further, I am fundamentally opposed to the tactic of including the unpalatable with the desirable. I would support 2015-04 if it restricted itself to collating transfer policy in one document without imposing further restrictions. rgds, Sascha Luck On Fri, Oct 21, 2016 at 12:45:01PM +0200, Havard Eidnes wrote: >> What you say could be expressed (again it's a metaphor) like >> this: > >If you're interested in swaying the opinion in your favour you >would do well by avoiding arguing by using metaphors or colurful >paraphrasing, and instead argue the individual items you >apparently so very much disagree with. > >> As for the takeovers, it's not that I wouldn't get into >> details. My previous employer has acuired probably over 100 >> other companies. Every case was particular and some took years >> to integrate. You can not sell the IPs before integrating >> their network. >> >> In all the situations, even when we know there was an >> agreement for acquisition of company X, it wasn't absorbed >> overnight. The process is complex and involves approvals from >> various authorities, integration of the network, migration of >> customers and in the end you can draw the line and mark as >> unused the as number, IPs, computers, etc. > >You conveniently side-stepped answering the case I described. >Note that I wrote "*solely* for the purpose of of getting a >/22...". In that case there would be no customers to move or >networks to merge. I would say it is incumbent upon you to >justify that we should keep this loophole as wide as a truck in >the policy. > >The 24-month holding period puts a damper on this avenue of >abuse against the intention of the last /8 policy, and would put >a little bit more longevity into the availability of the >resources under that policy. It may be that this diminishes >your company's prospects of near-future income, to which I would >say that basing your buisness on the abuse of something which is >perceived as a common resource is perhaps not worthy of so much >sympathy? > >Regards, > >- H?vard > From he at uninett.no Fri Oct 21 13:17:32 2016 From: he at uninett.no (Havard Eidnes) Date: Fri, 21 Oct 2016 13:17:32 +0200 (CEST) Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <20161021105707.GJ93886@cilantro.c4inet.net> References: <20161021.124501.1230279093156300597.he@uninett.no> <20161021105707.GJ93886@cilantro.c4inet.net> Message-ID: <20161021.131732.1966246577534839196.he@uninett.no> > You would do well to take some lessons in debate culture > yourself. You're -not even too veiledly- accusing another member > of abuse, something we have heard altogether too much of lately. In my humble opinion I did not. I admit that I may have cut it close, though. However, it is really difficult making an argument in this discussion without mentioning the case of abuse against the intention of the last /8 policy. I think it's a pretty well established fact that the M&A loophole has been used to ... perform actions with resources in the last /8 which are counter to the intention of the last /8 policy. For brevity I label this as "abuse" or as "abuse against the intention of the last /8 policy". It should also be pretty obvious that the various IP brokers have a business self-interest in maintaining the restriction-free M&A loophole, perhaps even though they only gain business as facilitators of the transfers resulting from the actions described. > As for 2015-04, I oppose it as it tries yet again to bring M&A > under policy regulation (s. 2.2) which the community has no > business doing. Please educate me why the community has no business doing this. I would have thought that was well within scope for the address policy. Best regards, - H?vard From apwg at c4inet.net Fri Oct 21 13:42:48 2016 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Fri, 21 Oct 2016 12:42:48 +0100 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <20161021.131732.1966246577534839196.he@uninett.no> References: <20161021.124501.1230279093156300597.he@uninett.no> <20161021105707.GJ93886@cilantro.c4inet.net> <20161021.131732.1966246577534839196.he@uninett.no> Message-ID: <20161021114248.GK93886@cilantro.c4inet.net> On Fri, Oct 21, 2016 at 01:17:32PM +0200, Havard Eidnes wrote: >> As for 2015-04, I oppose it as it tries yet again to bring M&A >> under policy regulation (s. 2.2) which the community has no >> business doing. > >Please educate me why the community has no business doing this. >I would have thought that was well within scope for the address >policy. In market-based economies, M&As -including the disposal of assets- are a matter for the parties involved and, occasionally, a state regulator, which the NCC is NOT. It is unthinkable in such a society that business decisions are subject to the whim of random people on a mailing list. The RIPE NCC recognises that and puts M&A firmly outside policy. Where it should remain unless the desire is that every transfer application or M&A notification start with filing suit against the NCC. rgds, Sascha Luck From office at ip-broker.uk Fri Oct 21 14:01:00 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Fri, 21 Oct 2016 15:01:00 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <20161021.124501.1230279093156300597.he@uninett.no> References: <20161021.114308.1325955746172376290.he@uninett.no> <20161021.124501.1230279093156300597.he@uninett.no> Message-ID: On Friday, October 21, 2016, Havard Eidnes wrote: > > What you say could be expressed (again it's a metaphor) like this: > > If you're interested in swaying the opinion in your favour you > would do well by avoiding arguing by using metaphors or colurful > paraphrasing, and instead argue the individual items you > apparently so very much disagree with. > > I express my ideas the way I think and I don't give lessons to anyone. > > As for the takeovers, it's not that I wouldn't get into details. My > > previous employer has acuired probably over 100 other companies. Every > case > > was particular and some took years to integrate. You can not sell the IPs > > before integrating their network. > > > > In all the situations, even when we know there was an agreement for > > acquisition of company X, it wasn't absorbed overnight. The process is > > complex and involves approvals from various authorities, integration of > the > > network, migration of customers and in the end you can draw the line and > > mark as unused the as number, IPs, computers, etc. > > You conveniently side-stepped answering the case I described. Note > that I wrote "*solely* for the purpose of of getting a /22...". In > that case there would be no customers to move or networks to merge. I > would say it is incumbent upon you to justify that we should keep this > loophole as wide as a truck in the policy. > > The 24-month holding period puts a damper on this avenue of abuse > against the intention of the last /8 policy, and would put a little > bit more longevity into the availability of the resources under that > policy. It may be that this diminishes your company's prospects of > near-future income, to which I would say that basing your buisness on > the abuse of something which is perceived as a common resource is > perhaps not worthy of so much sympathy? > > Again, unfunded personal attacks. Why do you have to analyze the person and not the idea. Who gives you the right to accuse make such allegations and what is the purpose of this ? Have I taken advantage of a loophole ? Just let everyone know about it, like I did in regard to one of the chairs, don't throw accusations just because you don't agree with me. > Regards, > > - H?vard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From office at ip-broker.uk Fri Oct 21 14:03:48 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Fri, 21 Oct 2016 15:03:48 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <20161021105707.GJ93886@cilantro.c4inet.net> References: <20161021.114308.1325955746172376290.he@uninett.no> <20161021.124501.1230279093156300597.he@uninett.no> <20161021105707.GJ93886@cilantro.c4inet.net> Message-ID: Agree with Sascha. As with the Allocated PI, in this situation RIPE community would like to impose some policies which are against the most common business practices. It is not efficient as it can at any time be attacked in any civilized justice system. Can anyone bring out some data on the "huge" abuse that took/takes place ? Let's not stop a supposedly abuse by adopting abusive policies. Ciprian On Friday, October 21, 2016, Sascha Luck [ml] wrote: > You would do well to take some lessons in debate culture > yourself. You're -not even too veiledly- accusing another member > of abuse, something we have heard altogether too much of lately. > > As for 2015-04, I oppose it as it tries yet again to bring M&A > under policy regulation (s. 2.2) which the community has no > business doing. Further, I am fundamentally opposed to the tactic > of including the unpalatable with the desirable. I would support > 2015-04 if it restricted itself to collating transfer policy in > one document without imposing further restrictions. > > rgds, > Sascha Luck > > On Fri, Oct 21, 2016 at 12:45:01PM +0200, Havard Eidnes wrote: > >> What you say could be expressed (again it's a metaphor) like >>> this: >>> >> >> If you're interested in swaying the opinion in your favour you >> would do well by avoiding arguing by using metaphors or colurful >> paraphrasing, and instead argue the individual items you >> apparently so very much disagree with. >> >> As for the takeovers, it's not that I wouldn't get into >>> details. My previous employer has acuired probably over 100 >>> other companies. Every case was particular and some took years >>> to integrate. You can not sell the IPs before integrating >>> their network. >>> >>> In all the situations, even when we know there was an >>> agreement for acquisition of company X, it wasn't absorbed >>> overnight. The process is complex and involves approvals from >>> various authorities, integration of the network, migration of >>> customers and in the end you can draw the line and mark as >>> unused the as number, IPs, computers, etc. >>> >> >> You conveniently side-stepped answering the case I described. >> Note that I wrote "*solely* for the purpose of of getting a >> /22...". In that case there would be no customers to move or >> networks to merge. I would say it is incumbent upon you to >> justify that we should keep this loophole as wide as a truck in >> the policy. >> >> The 24-month holding period puts a damper on this avenue of >> abuse against the intention of the last /8 policy, and would put >> a little bit more longevity into the availability of the >> resources under that policy. It may be that this diminishes >> your company's prospects of near-future income, to which I would >> say that basing your buisness on the abuse of something which is >> perceived as a common resource is perhaps not worthy of so much >> sympathy? >> >> Regards, >> >> - H?vard >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From office at ip-broker.uk Fri Oct 21 14:11:41 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Fri, 21 Oct 2016 15:11:41 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <51ECAFC9-CBF3-4F83-BE57-3A48FC42F683@steffann.nl> <20161021.114308.1325955746172376290.he@uninett.no> Message-ID: Hi Sander, I hoped you would understand the idea and not hang on details. Yes, an integration process can take days, weeks, months or years. There are cases when placing a 24 months hold would make no difference but in most cases I think (based on the experience with previous acquisitions at my previous employer) it would affect the business. Can you agree with me that in most of the cases at least the AS number will become unuseful and that would be probably a lot sooner than the 24 months ? Getting back to the fundaments, I will never support any policy that says "it's better to put everybody in jail even if some are innocent instead of letting everybody free even some might be criminals". This is wrong and should be debated properly. The policy's goal has nothing to do with bringing changes to the rules. NCC says the changes do not have a notable impact. Then don't make the changes ! Ciprian On Friday, October 21, 2016, Sander Steffann wrote: > Hi Ciprian, > > > As for the takeovers, it's not that I wouldn't get into details. My > previous employer has acuired probably over 100 other companies. Every case > was particular and some took years to integrate. You can not sell the IPs > before integrating their network. > > So then what is the problem with the 24 month holding period? It sounds > like it works exactly as designed: you can't sell addresses immediately, > but there is no problem selling then after a multi-year integration project. > > Cheers, > Sander > -------------- next part -------------- An HTML attachment was scrubbed... URL: From office at ip-broker.uk Fri Oct 21 14:15:51 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Fri, 21 Oct 2016 15:15:51 +0300 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: References: Message-ID: +1 from me on this I think that at ripe72 someone gave an example with a situation where this would be a problem and the policy would solve it. That's what we need. Clearly identify a real problem and propose a policy to fix it. Great job ! Ciprian On Friday, October 21, 2016, Marco Schmidt wrote: > Dear colleagues, > > A new RIPE Policy proposal 2016-04, "IPv6 PI Sub-assignment Clarification" > is now available for discussion. > > The goal of this proposal is to define sub-assignments in IPv6 PI > assignments as subnets of /64 and shorter. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2016-04 > > We encourage you to review this proposal and send your comments to > > before 21 November 2016. > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From he at uninett.no Fri Oct 21 14:16:59 2016 From: he at uninett.no (Havard Eidnes) Date: Fri, 21 Oct 2016 14:16:59 +0200 (CEST) Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <20161021.124501.1230279093156300597.he@uninett.no> Message-ID: <20161021.141659.1850689056661724328.he@uninett.no> >> You conveniently side-stepped answering the case I described. Note >> that I wrote "*solely* for the purpose of of getting a /22...". In >> that case there would be no customers to move or networks to merge. I >> would say it is incumbent upon you to justify that we should keep this >> loophole as wide as a truck in the policy. >> >> The 24-month holding period puts a damper on this avenue of abuse >> against the intention of the last /8 policy, and would put a little >> bit more longevity into the availability of the resources under that >> policy. It may be that this diminishes your company's prospects of >> near-future income, to which I would say that basing your buisness on >> the abuse of something which is perceived as a common resource is >> perhaps not worthy of so much sympathy? > > Again, unfounded personal attacks. Please read that again. I said "It may be..." (last paragraph above). > Why do you have to analyze the person and not the idea. The idea I beleive is section 2.2 in the 2015-04 proposal. I beleive I have argued for its presence, by describing the abuse against the last /8 policy we'd otherwise be widely open to. > Who gives you the right to accuse make such allegations and > what is the purpose of this? Have I taken advantage of a > loophole? I beleive that if you read what I wrote earlier more carefully, you would come to the conclusion that I have not made such a claim. However, you're strongly defending the continued presence of a loophole in the policy as wide as a truck, permitting behaviour such as described earlier. I'd say it falls upon you to justify why we should let status quo continue, where the stated intention of the last /8 policy is widely open for ... circumvention. Regards, - H?vard From office at ip-broker.uk Fri Oct 21 14:24:20 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Fri, 21 Oct 2016 15:24:20 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <20161021.141659.1850689056661724328.he@uninett.no> References: <20161021.124501.1230279093156300597.he@uninett.no> <20161021.141659.1850689056661724328.he@uninett.no> Message-ID: On Friday, October 21, 2016, Havard Eidnes wrote: > >> You conveniently side-stepped answering the case I described. Note > >> that I wrote "*solely* for the purpose of of getting a /22...". In > >> that case there would be no customers to move or networks to merge. I > >> would say it is incumbent upon you to justify that we should keep this > >> loophole as wide as a truck in the policy. > >> > >> The 24-month holding period puts a damper on this avenue of abuse > >> against the intention of the last /8 policy, and would put a little > >> bit more longevity into the availability of the resources under that > >> policy. It may be that this diminishes your company's prospects of > >> near-future income, to which I would say that basing your buisness on > >> the abuse of something which is perceived as a common resource is > >> perhaps not worthy of so much sympathy? > > > > Again, unfounded personal attacks. > > Please read that again. > > I said "It may be..." (last paragraph above). > > That means inducing ideas and it's an accusation. > > Why do you have to analyze the person and not the idea. > > The idea I beleive is section 2.2 in the 2015-04 proposal. > I beleive I have argued for its presence, by describing the abuse > against the last /8 policy we'd otherwise be widely open to. > > > Who gives you the right to accuse make such allegations and > > what is the purpose of this? Have I taken advantage of a > > loophole? > > I beleive that if you read what I wrote earlier more carefully, > you would come to the conclusion that I have not made such a > claim. > > However, you're strongly defending the continued presence of a > loophole in the policy as wide as a truck, permitting behaviour > such as described earlier. I'd say it falls upon you to justify > why we should let status quo continue, where the stated intention > of the last /8 policy is widely open for ... circumvention. > > You made remarks specifically to me and my company. I have explained why I don't support this policy. If you notice a problem and want to fix it the process is to make a proposal and we debate it. But using a policy that is intended to do something and "fix" something else doesn't seem at least appropriate. And if I don't like Hillary it doesn't mean I support Trump. It's not always black and white, therefore please don't reach conclusions regarding me and my company only based on my opinions. I'm sure that I'm not always right but I'm sure that I express exactly what I think all the time. Ciprian -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Fri Oct 21 14:31:58 2016 From: sander at steffann.nl (Sander Steffann) Date: Fri, 21 Oct 2016 14:31:58 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <51ECAFC9-CBF3-4F83-BE57-3A48FC42F683@steffann.nl> <20161021.114308.1325955746172376290.he@uninett.no> Message-ID: <6A7D915F-59C0-44BA-B78D-A4695D01BF54@steffann.nl> Hi, > I hoped you would understand the idea and not hang on details. Policy development is all about details. > Yes, an integration process can take days, weeks, months or years. There are cases when placing a 24 months hold would make no difference but in most cases I think (based on the experience with previous acquisitions at my previous employer) it would affect the business. Ok. > Can you agree with me that in most of the cases at least the AS number will become unuseful and that would be probably a lot sooner than the 24 months ? What would be the point in selling AS numbers? Just return it to the NCC. > Getting back to the fundaments, I will never support any policy that says "it's better to put everybody in jail even if some are innocent instead of letting everybody free even some might be criminals". This is wrong and should be debated properly. Again, these kind of extreme analogies are out of place here. Debate is indeed what we need, but based on facts and accurate details. > The policy's goal has nothing to do with bringing changes to the rules. Huh? First, all policy proposals are about changing the rules. Second, don't make assumptions about what the authors goals are, stick to the facts. > NCC says the changes do not have a notable impact. Then don't make the changes ! Stop extrapolating what others write to support your own arguments. The proposal doesn't have a notable impact besides the impact it's designed to have. Cheers, Sander From office at ip-broker.uk Fri Oct 21 15:35:32 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Fri, 21 Oct 2016 16:35:32 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <6A7D915F-59C0-44BA-B78D-A4695D01BF54@steffann.nl> References: <51ECAFC9-CBF3-4F83-BE57-3A48FC42F683@steffann.nl> <20161021.114308.1325955746172376290.he@uninett.no> <6A7D915F-59C0-44BA-B78D-A4695D01BF54@steffann.nl> Message-ID: > What would be the point in selling AS numbers? Just return it to the NCC. > > What is the point in selling IPs. Just return them to the NCC. It's the same with AS numbers. There is a market for them too. > > Getting back to the fundaments, I will never support any policy that > says "it's better to put everybody in jail even if some are innocent > instead of letting everybody free even some might be criminals". This is > wrong and should be debated properly. > > Again, these kind of extreme analogies are out of place here. Debate is > indeed what we need, but based on facts and accurate details. I'm trying to bring out the fundaments behind the ideas. Even if the situations are different the is the same principle behind and it's a wrong one. > > The policy's goal has nothing to do with bringing changes to the rules. > > Huh? First, all policy proposals are about changing the rules. Second, > don't make assumptions about what the authors goals are, stick to the facts. I'm reading the policy text, not assuming anything. This one particulary had a different scope (as it states). It was supposed to be just a "cosmetic" change. > > NCC says the changes do not have a notable impact. Then don't make the > changes ! > > Stop extrapolating what others write to support your own arguments. The > proposal doesn't have a notable impact besides the impact it's designed to > have. > Again, anyone can read the first lines in the proposal. The goal is a cosmetic one. At the impact section B, NCC says there is no significant impact on registry and addressing system. The only impact expressed by NCC is on their operations which would have some (important) work to do as well as on the legal side. From your wording I would understand that actually there is an impact but it is hidden ? NCC didn't mention it so either it's not important or it's hidden. Which would it be ? What I propose is for the author to stick to the proposal's goal which would then get "unanimous" acceptance and start a new policy for the supposed loophole that would properly address it, considering all the situations. Address one thing at a time, this way the good ideas can pass quickly while the controversed ones will be properly debated. Ciprian -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis at velea.eu Fri Oct 21 15:36:15 2016 From: elvis at velea.eu (Elvis Daniel Velea) Date: Fri, 21 Oct 2016 16:36:15 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: <82106c30-78e8-d72c-9bac-4c25cbba2437@velea.eu> Hi, On 10/19/16 11:05 AM, Marco Schmidt wrote: > The goal of this proposal is to ban transfers of allocations made under the final /8 policy. Also the proposal specifies what resources must be added to the RIPE NCC IPv4 available pool. I do not agree with this policy proposal and believe it will not fix anything, instead - it will harm the registry. > Some of the differences from version 2.0 include: > > - Clarification that changes to holdership of address space as a result of company mergers or acquisitions are not affected by proposed transfer restriction this fixes only a tiny bit of the problem. > - Legacy space handed over to the RIPE NCC will be added to the IPv4 available pool this has nothing to do with the policy proposal. I feel it's just some candy offered to sweeten the proposal itself. This was the short version of my response. Those reading this e-mail during working hours, you can go back to work ;) those that still have some popcorn left, feel free to read further. Below are the 6 most important reasons why I believe this policy proposal should not become policy: 1. This policy proposal will create two types of members. a. the members that have received resources before 2012 + the members that can afford to 'buy' IP addresses allocated until recently (-2y from the date this policy proposal would be implemented) b. the members that have only received resources after September 2012 and can not afford to buy IP IP addresses at the market prices (but they can buy an unlimited number of these from the RIPE NCC at ~?4,5 (?3,4/1st year + ?1,4/2nd year - redistribution of profit) The first type of member would be allowed to participate in an IP transfer market that was (until the implementation of this policy proposal, if ever) accessible to everyone and anyone with resources received from the RIPE NCC or an other member. The second type of member will not be allowed to participate in this IP transfer market unless they buy first from an other member. Some members have already been able to transfer their /22 received from the last /8. With the implementation of this policy proposal (if ever) I feel that we as a community will discriminate between those that have received their last /22 (and want/need, for various reasons to transfer it) 2 or more years before implementation and those that have received less than 2 years before the implementation (or any time after). I know some of you do not like analogies. But I would compare this with 2 people buying their cars. The first can buy the car and sell it 2 years later, only because the purchase happened even just a few days before the car industry decides that cars can no longer be sold further. So, those that have bought their car and used it for 1.5 years will have to return it (for free) to the car manufacturer while others could have sold it because they were quick in the purchase process and bought it earlier. So, I think that once this policy proposal would be implemented (if ever) it would discriminate the second type of member as they will not be allowed to participate in a well established IP transfer market with the IP addresses received from the RIPE NCC (and only with the IP addresses they need to buy from the market first). 2. This policy proposal will create yet an other color of IP addresses. I believe and hope that in the near future we will start talking about the removal of colors and not about addition of more colors. Numbers are just numbers. There is no difference between a number received in 1990, one received after 1992 or one that has status PI or PA. Now, we want to add a color for numbers received after 2012... My router does not know any difference between these numbers and nobody really cares. Do you think that PI holders care that they are not supposed to sub-assign that space to other customers ? Do you think the RIPE NCC has any say or can really verify who (and most importantly - how someone) is using any of these numbers? The community decided to remove most of the barriers when 2013-03, 2014-02, 2014-05 were approved and implemented. These policy proposals removed all the 'old' requirements and cleaned up the IPv4 policy so much that anyone can now do whatever they want with their IPv4 space (not that they could have not done it in the past, but they would have to lie to the RIPE NCC if they would have ever needed an additional allocation). This policy proposal tends to take us back to previous way of thinking, an old one - I think. So, just adding more colors and barriers will only complicate things. And I've always liked policies and procedures that are clear and simple. As simple as possible. 3. This policy proposal will drive some IPv4 transfers underground. We already know and have seen it in previous presentations that where the RIR system tries to impose some limitations, the real world invents something to circumvent those limitations. Currently, with very large allocations, the invention is called a 'futures contract'. While the RIPE NCC policies will say that ALLOCATED FINAL can not be transferred between LIRs (if this policy proposal will ever make it into policy), most LIRs will find ways to circumvent the policy (as they have always done it). They will create contracts that will stay underground and will be covered by NDAs, they will use loopholes in the M&A process, they will do whatever they need to in order to (sell/buy) the resources they needed. We've seen that some of the people that participated in the previous discussion of this policy proposal said they will never do such a thing, they will never buy a /22 that says ALLOCATED FINAL. Would you change your mind if your business depended on it? If there was no other way to receive an IP block that you desperately need ? If you have a very important customer that would leave if you can not assign a few more IP addresses? I bet anyone that has a commercial business will think twice and examine again and again where is that border between profit and loss and whether respecting the RIPE Policies to the very last letter really matter that much that they would rather have a loss. 4. This policy proposal will drive the free IPv4 pool to run-out even faster. What will the LIRs do if they won't be able to find affordable IPv4 in the market any longer? If these /22s that were allocated from the last /8 are no longer available in the transfer market? Well, they will either buy more expensive (pre-2012) IP addresses or go to the RIPE NCC and receive a /22 for less than ?5/IP. The board announced publicly that anyone can open multiple LIRs if they need more IPs. Approving this policy proposal will only remove some 'assets' from the free market and the supply will shrink, therefore driving prices up for whatever is pre-2012 and pushing more members to get the IPs they need from the RIPE NCC by means of setting up multiple LIRs. 5. This policy proposal will affect the registry (in a bad way) As said in #3, some transfers will be driven underground. We do not see many of those in the RIPE Region at this moment because there is no limitation on who can transfer and when (except for the two years anti-flip bit). If this proposal ever becomes policy, the transfers of the /22s will still happen. If the two parties can not convince the RIPE NCC of their 'M&A' and can not get the IPs changed in the RIPE Database from a name to an other, they will keep on using them with the wrong name. This will affect the quality of the registry and we will have a registry with two colors. The bleached IPs will be the ones pre-2012 and the rest will have various colours of grey. 6. Artificial explosion of number members The implementation of the members' vote (on the board decision of blocking the registration of multiple LIRs on the same company name) requires those that need a second /22 to keep it in a second LIR for at least 2 years before this second /22 can be transferred to their first LIR. The second LIR can then, after the transfer, be closed. So the price per IP, has been set to a minimum 2 years membership + sign-up fee - redistribution. It may actually require the company opening multiple LIRs to keep all of these open if they want to hold on to their IP addresses. It is not very clear what will happen when these companies will want to consolidate all the LIRs they have into one. If they will be forced to return the /22 they got on their second LIR, then they will be forced to keep this second LIR open. If that's the case, the number of LIRs will explode and will not shrink every time a second LIR ages 2 years and can transfer the /22 to the first. I am unsure whether Remco, as a private citizen but more, as a Board member has given this enough thought. I believe that this policy proposal will make the RIPE NCC more and more unstable with difficulties in making financial plans on the long run. I worry that these companies that will be forced to keep multiple LIRs open just to hold on to their /22s may take the Board or the NCC to court because they are not allowed (after 2 years) to consolidate their membership into one registry. I am unsure what a court would say when they are told that Remco has multiple hats and his proposal is not made with a Board hat. To most of the world (and I've talked to quite a few people about it), this policy proposal seems to come from the RIPE NCC Board. To many people that I talk to, this policy proposal is seen as a double standard from the NCC Board. On one hand, the Board decided to advise the members to vote to allow companies to open multiple LIRs. On the other hand, one of the Board Members (even if as a private citizen) makes a policy proposal that forces those to pay a la longue for each /22 they received. There may be other reasons why I do not like this proposal. The ones mentioned above are the most important ones. Regards, Elvis From office at ip-broker.uk Fri Oct 21 15:45:21 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Fri, 21 Oct 2016 16:45:21 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <82106c30-78e8-d72c-9bac-4c25cbba2437@velea.eu> References: <82106c30-78e8-d72c-9bac-4c25cbba2437@velea.eu> Message-ID: I didn't have any popcorn but a few nachos were helpful to read the full e-mail. Very good and detailed explanations. +100 from me to Elvis which can also be read as -100 for the policy. For those of you who pretend working, it's friday so you can't trick anyone ;). You'd better read Elvis's mail entirely. Have a nice weekend, Ciprian On Fri, Oct 21, 2016 at 4:36 PM, Elvis Daniel Velea wrote: > Hi, > > On 10/19/16 11:05 AM, Marco Schmidt wrote: > >> The goal of this proposal is to ban transfers of allocations made under >> the final /8 policy. Also the proposal specifies what resources must be >> added to the RIPE NCC IPv4 available pool. >> > I do not agree with this policy proposal and believe it will not fix > anything, instead - it will harm the registry. > >> Some of the differences from version 2.0 include: >> >> - Clarification that changes to holdership of address space as a >> result of company mergers or acquisitions are not affected by proposed >> transfer restriction >> > this fixes only a tiny bit of the problem. > >> - Legacy space handed over to the RIPE NCC will be added to the IPv4 >> available pool >> > this has nothing to do with the policy proposal. I feel it's just some > candy offered to sweeten the proposal itself. > > This was the short version of my response. Those reading this e-mail > during working hours, you can go back to work ;) those that still have some > popcorn left, feel free to read further. > > Below are the 6 most important reasons why I believe this policy proposal > should not become policy: > > 1. This policy proposal will create two types of members. > > a. the members that have received resources before 2012 + the members that > can afford to 'buy' IP addresses allocated until recently (-2y from the > date this policy proposal would be implemented) > b. the members that have only received resources after September 2012 and > can not afford to buy IP IP addresses at the market prices (but they can > buy an unlimited number of these from the RIPE NCC at ~?4,5 (?3,4/1st year > + ?1,4/2nd year - redistribution of profit) > > The first type of member would be allowed to participate in an IP transfer > market that was (until the implementation of this policy proposal, if ever) > accessible to everyone and anyone with resources received from the RIPE NCC > or an other member. > The second type of member will not be allowed to participate in this IP > transfer market unless they buy first from an other member. > > Some members have already been able to transfer their /22 received from > the last /8. With the implementation of this policy proposal (if ever) I > feel that we as a community will discriminate between those that have > received their last /22 (and want/need, for various reasons to transfer it) > 2 or more years before implementation and those that have received less > than 2 years before the implementation (or any time after). > > I know some of you do not like analogies. But I would compare this with 2 > people buying their cars. The first can buy the car and sell it 2 years > later, only because the purchase happened even just a few days before the > car industry decides that cars can no longer be sold further. So, those > that have bought their car and used it for 1.5 years will have to return it > (for free) to the car manufacturer while others could have sold it because > they were quick in the purchase process and bought it earlier. > > So, I think that once this policy proposal would be implemented (if ever) > it would discriminate the second type of member as they will not be allowed > to participate in a well established IP transfer market with the IP > addresses received from the RIPE NCC (and only with the IP addresses they > need to buy from the market first). > > > 2. This policy proposal will create yet an other color of IP addresses. > > I believe and hope that in the near future we will start talking about the > removal of colors and not about addition of more colors. Numbers are just > numbers. There is no difference between a number received in 1990, one > received after 1992 or one that has status PI or PA. Now, we want to add a > color for numbers received after 2012... > > My router does not know any difference between these numbers and nobody > really cares. Do you think that PI holders care that they are not supposed > to sub-assign that space to other customers ? Do you think the RIPE NCC has > any say or can really verify who (and most importantly - how someone) is > using any of these numbers? > The community decided to remove most of the barriers when 2013-03, > 2014-02, 2014-05 were approved and implemented. These policy proposals > removed all the 'old' requirements and cleaned up the IPv4 policy so much > that anyone can now do whatever they want with their IPv4 space (not that > they could have not done it in the past, but they would have to lie to the > RIPE NCC if they would have ever needed an additional allocation). This > policy proposal tends to take us back to previous way of thinking, an old > one - I think. > > So, just adding more colors and barriers will only complicate things. And > I've always liked policies and procedures that are clear and simple. As > simple as possible. > > > 3. This policy proposal will drive some IPv4 transfers underground. > > We already know and have seen it in previous presentations that where the > RIR system tries to impose some limitations, the real world invents > something to circumvent those limitations. Currently, with very large > allocations, the invention is called a 'futures contract'. > > While the RIPE NCC policies will say that ALLOCATED FINAL can not be > transferred between LIRs (if this policy proposal will ever make it into > policy), most LIRs will find ways to circumvent the policy (as they have > always done it). They will create contracts that will stay underground and > will be covered by NDAs, they will use loopholes in the M&A process, they > will do whatever they need to in order to (sell/buy) the resources they > needed. > > We've seen that some of the people that participated in the previous > discussion of this policy proposal said they will never do such a thing, > they will never buy a /22 that says ALLOCATED FINAL. Would you change your > mind if your business depended on it? If there was no other way to receive > an IP block that you desperately need ? If you have a very important > customer that would leave if you can not assign a few more IP addresses? > I bet anyone that has a commercial business will think twice and examine > again and again where is that border between profit and loss and whether > respecting the RIPE Policies to the very last letter really matter that > much that they would rather have a loss. > > > 4. This policy proposal will drive the free IPv4 pool to run-out even > faster. > > What will the LIRs do if they won't be able to find affordable IPv4 in the > market any longer? If these /22s that were allocated from the last /8 are > no longer available in the transfer market? Well, they will either buy more > expensive (pre-2012) IP addresses or go to the RIPE NCC and receive a /22 > for less than ?5/IP. > The board announced publicly that anyone can open multiple LIRs if they > need more IPs. > > Approving this policy proposal will only remove some 'assets' from the > free market and the supply will shrink, therefore driving prices up for > whatever is pre-2012 and pushing more members to get the IPs they need from > the RIPE NCC by means of setting up multiple LIRs. > > > 5. This policy proposal will affect the registry (in a bad way) > > As said in #3, some transfers will be driven underground. We do not see > many of those in the RIPE Region at this moment because there is no > limitation on who can transfer and when (except for the two years anti-flip > bit). > If this proposal ever becomes policy, the transfers of the /22s will still > happen. If the two parties can not convince the RIPE NCC of their 'M&A' and > can not get the IPs changed in the RIPE Database from a name to an other, > they will keep on using them with the wrong name. > > This will affect the quality of the registry and we will have a registry > with two colors. The bleached IPs will be the ones pre-2012 and the rest > will have various colours of grey. > > 6. Artificial explosion of number members > > The implementation of the members' vote (on the board decision of blocking > the registration of multiple LIRs on the same company name) requires those > that need a second /22 to keep it in a second LIR for at least 2 years > before this second /22 can be transferred to their first LIR. The second > LIR can then, after the transfer, be closed. So the price per IP, has been > set to a minimum 2 years membership + sign-up fee - redistribution. > > It may actually require the company opening multiple LIRs to keep all of > these open if they want to hold on to their IP addresses. It is not very > clear what will happen when these companies will want to consolidate all > the LIRs they have into one. If they will be forced to return the /22 they > got on their second LIR, then they will be forced to keep this second LIR > open. > > If that's the case, the number of LIRs will explode and will not shrink > every time a second LIR ages 2 years and can transfer the /22 to the first. > I am unsure whether Remco, as a private citizen but more, as a Board member > has given this enough thought. I believe that this policy proposal will > make the RIPE NCC more and more unstable with difficulties in making > financial plans on the long run. > > I worry that these companies that will be forced to keep multiple LIRs > open just to hold on to their /22s may take the Board or the NCC to court > because they are not allowed (after 2 years) to consolidate their > membership into one registry. I am unsure what a court would say when they > are told that Remco has multiple hats and his proposal is not made with a > Board hat. To most of the world (and I've talked to quite a few people > about it), this policy proposal seems to come from the RIPE NCC Board. > To many people that I talk to, this policy proposal is seen as a double > standard from the NCC Board. On one hand, the Board decided to advise the > members to vote to allow companies to open multiple LIRs. On the other > hand, one of the Board Members (even if as a private citizen) makes a > policy proposal that forces those to pay a la longue for each /22 they > received. > > > There may be other reasons why I do not like this proposal. The ones > mentioned above are the most important ones. > > Regards, > Elvis > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Fri Oct 21 15:51:08 2016 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 21 Oct 2016 15:51:08 +0200 (CEST) Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <82106c30-78e8-d72c-9bac-4c25cbba2437@velea.eu> References: <82106c30-78e8-d72c-9bac-4c25cbba2437@velea.eu> Message-ID: On Fri, 21 Oct 2016, Elvis Daniel Velea wrote: > a. the members that have received resources before 2012 + the members that > can afford to 'buy' IP addresses allocated until recently (-2y from the date > this policy proposal would be implemented) > b. the members that have only received resources after September 2012 and can > not afford to buy IP IP addresses at the market prices (but they can buy an > unlimited number of these from the RIPE NCC at ~?4,5 (?3,4/1st year + > ?1,4/2nd year - redistribution of profit) Correct. These post-2012 members would have ZERO IPv4 addresses from RIPE NCC if it wasn't for the Last /8 policy, we would have completely exhausted in 2012 without this policy. So they were only able to get addresses at all because these addresses were saved to be used under different policy, thus under restrictions. I was one of the proponents of this. I have subsequently changed my mind and I am now of the opinion that we should not have any /8 policy at all, and just hand out the rest of the IPv4 space to current LIRs and let the market handle the rest. It's obvious from the discussions here that most people do not appreciate the intention behind the last-/8 policy, and our attempts to try to help new entrants into the market has failed. So let's just get it over with and exhaust all the rest of RIPE NCC free addresses immediately by some scheme to divvy up whatever free resources are left to the members and after that, let all restrictions go. If we're actually exhausted then some people might get on with deploying IPv6, I hear some people not deploying because they see that RIPE isn't completely exhausted yet. -- Mikael Abrahamsson email: swmike at swm.pp.se From sander at steffann.nl Fri Oct 21 16:35:05 2016 From: sander at steffann.nl (Sander Steffann) Date: Fri, 21 Oct 2016 16:35:05 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <20161021114248.GK93886@cilantro.c4inet.net> References: <20161021.124501.1230279093156300597.he@uninett.no> <20161021105707.GJ93886@cilantro.c4inet.net> <20161021.131732.1966246577534839196.he@uninett.no> <20161021114248.GK93886@cilantro.c4inet.net> Message-ID: <4E805786-2E86-4C73-AE09-3D2F2ED812DB@steffann.nl> Hi Sasha, > In market-based economies, M&As -including the disposal of > assets- are a matter for the parties involved and, occasionally, a state regulator, which the NCC is NOT. > It is unthinkable in such a society that business decisions are > subject to the whim of random people on a mailing list. The > RIPE NCC recognises that and puts M&A firmly outside policy. I think we need to look at the differences between regulating M&A, which is indeed far outside the scope of this working group, and defining policy about what can be done with resources after someone acquires them (M&A or otherwise) which is definitely in scope. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sander at steffann.nl Fri Oct 21 16:45:41 2016 From: sander at steffann.nl (Sander Steffann) Date: Fri, 21 Oct 2016 16:45:41 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <82106c30-78e8-d72c-9bac-4c25cbba2437@velea.eu> Message-ID: Hi Mikael, > These post-2012 members would have ZERO IPv4 addresses from RIPE NCC if it wasn't for the Last /8 policy, we would have completely exhausted in 2012 without this policy. > > So they were only able to get addresses at all because these addresses were saved to be used under different policy, thus under restrictions. > > I was one of the proponents of this. I have subsequently changed my mind and I am now of the opinion that we should not have any /8 policy at all, and just hand out the rest of the IPv4 space to current LIRs and let the market handle the rest. It's obvious from the discussions here that most people do not appreciate the intention behind the last-/8 policy, and our attempts to try to help new entrants into the market has failed. I share your sentiment. It's tempting to assume that all the new LIRs are ungrateful and don't appreciate what this community did for them before their companies even existed, and that we therefore failed. I still resist that temptation and hope that the silent majority is actually appreciative that we didn't leave them in the cold. > So let's just get it over with and exhaust all the rest of RIPE NCC free addresses immediately by some scheme to divvy up whatever free resources are left to the members and after that, let all restrictions go. > > If we're actually exhausted then some people might get on with deploying IPv6, I hear some people not deploying because they see that RIPE isn't completely exhausted yet. Yeah, I have heard that repeatedly over the last couple of years. I'm still explaining that the remaining IPv4 resources are a special-case so that newcomers get a small foothold in the IPv4 world as part of their NCC membership and not be left completely to the whims of the market. That there is a remaining pool doesn't mean it's business as usual, or that that pool should be used as a cheap source of an expensive resource for sale on the market. Some people seem to have trouble understanding that. It's indeed disappointing that not all current participants share the selfless principles of the ones that made the policies before them. But those principles and fair policies are what I'm still fighting for. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From office at ip-broker.uk Fri Oct 21 17:01:20 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Fri, 21 Oct 2016 18:01:20 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <4E805786-2E86-4C73-AE09-3D2F2ED812DB@steffann.nl> References: <20161021.124501.1230279093156300597.he@uninett.no> <20161021105707.GJ93886@cilantro.c4inet.net> <20161021.131732.1966246577534839196.he@uninett.no> <20161021114248.GK93886@cilantro.c4inet.net> <4E805786-2E86-4C73-AE09-3D2F2ED812DB@steffann.nl> Message-ID: On Fri, Oct 21, 2016 at 5:35 PM, Sander Steffann wrote: > Hi Sasha, > > > In market-based economies, M&As -including the disposal of > > assets- are a matter for the parties involved and, occasionally, a state > regulator, which the NCC is NOT. > > It is unthinkable in such a society that business decisions are > > subject to the whim of random people on a mailing list. The > > RIPE NCC recognises that and puts M&A firmly outside policy. > > I think we need to look at the differences between regulating M&A, which > is indeed far outside the scope of this working group, and defining policy > about what can be done with resources after someone acquires them (M&A or > otherwise) which is definitely in scope. > > It is also beyond the scope of this policy regulating what can be done with resources and we're still discussing it. Let's stick to the policy's scope and start a new one with proper debates over this issue. Ciprian -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Fri Oct 21 17:05:54 2016 From: sander at steffann.nl (Sander Steffann) Date: Fri, 21 Oct 2016 17:05:54 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <20161021.124501.1230279093156300597.he@uninett.no> <20161021105707.GJ93886@cilantro.c4inet.net> <20161021.131732.1966246577534839196.he@uninett.no> <20161021114248.GK93886@cilantro.c4inet.net> <4E805786-2E86-4C73-AE09-3D2F2ED812DB@steffann.nl> Message-ID: <4BB2CEF2-B934-412C-AFBF-D75EC6812AF4@steffann.nl> Hello Ciprian, > It is also beyond the scope of this policy regulating what can be done with resources and we're still discussing it. Let's stick to the policy's scope and start a new one with proper debates over this issue. Please leave it to the chairs to determine what is in scope for being discussed and what is not. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From office at ip-broker.uk Fri Oct 21 17:11:06 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Fri, 21 Oct 2016 18:11:06 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <4BB2CEF2-B934-412C-AFBF-D75EC6812AF4@steffann.nl> References: <20161021.124501.1230279093156300597.he@uninett.no> <20161021105707.GJ93886@cilantro.c4inet.net> <20161021.131732.1966246577534839196.he@uninett.no> <20161021114248.GK93886@cilantro.c4inet.net> <4E805786-2E86-4C73-AE09-3D2F2ED812DB@steffann.nl> <4BB2CEF2-B934-412C-AFBF-D75EC6812AF4@steffann.nl> Message-ID: On Fri, Oct 21, 2016 at 6:05 PM, Sander Steffann wrote: > Hello Ciprian, > > > It is also beyond the scope of this policy regulating what can be done > with resources and we're still discussing it. Let's stick to the policy's > scope and start a new one with proper debates over this issue. > > Please leave it to the chairs to determine what is in scope for being > discussed and what is not. > > So it doesn't matter what the policy says it's scope is, it only matters what the chair decides we can discuss or not. Nice "democracy" we have ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgori at wirem.net Fri Oct 21 17:15:47 2016 From: rgori at wirem.net (Riccardo Gori) Date: Fri, 21 Oct 2016 17:15:47 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <82106c30-78e8-d72c-9bac-4c25cbba2437@velea.eu> Message-ID: <1bf27c66-b07d-952f-2696-cb8723699435@wirem.net> Hi Mikael, Hi Sander, Il 21/10/2016 16:45, Sander Steffann ha scritto: > Hi Mikael, > >> These post-2012 members would have ZERO IPv4 addresses from RIPE NCC if it wasn't for the Last /8 policy, we would have completely exhausted in 2012 without this policy. >> >> So they were only able to get addresses at all because these addresses were saved to be used under different policy, thus under restrictions. >> >> I was one of the proponents of this. I have subsequently changed my mind and I am now of the opinion that we should not have any /8 policy at all, and just hand out the rest of the IPv4 space to current LIRs and let the market handle the rest. It's obvious from the discussions here that most people do not appreciate the intention behind the last-/8 policy, and our attempts to try to help new entrants into the market has failed. > I share your sentiment. It's tempting to assume that all the new LIRs are ungrateful and don't appreciate what this community did for them before their companies even existed, and that we therefore failed. I still resist that temptation and hope that the silent majority is actually appreciative that we didn't leave them in the cold. You can find my thankfulness for this in the email archived in apwg >> So let's just get it over with and exhaust all the rest of RIPE NCC free addresses immediately by some scheme to divvy up whatever free resources are left to the members and after that, let all restrictions go. >> >> If we're actually exhausted then some people might get on with deploying IPv6, I hear some people not deploying because they see that RIPE isn't completely exhausted yet. > Yeah, I have heard that repeatedly over the last couple of years. I'm still explaining that the remaining IPv4 resources are a special-case so that newcomers get a small foothold in the IPv4 world as part of their NCC membership and not be left completely to the whims of the market. That there is a remaining pool doesn't mean it's business as usual, or that that pool should be used as a cheap source of an expensive resource for sale on the market. Some people seem to have trouble understanding that. > > It's indeed disappointing that not all current participants share the selfless principles of the ones that made the policies before them. But those principles and fair policies are what I'm still fighting for. I think you are missing that LIRs before 09/2012 are sitting on unused space. Not me, not us LIR after 09/2012. We just need space now to grow our new businesses. Who wants to sell space to who? > > Cheers, > Sander > cheers Riccardo -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- From sander at steffann.nl Fri Oct 21 17:48:16 2016 From: sander at steffann.nl (Sander Steffann) Date: Fri, 21 Oct 2016 17:48:16 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <20161021.124501.1230279093156300597.he@uninett.no> <20161021105707.GJ93886@cilantro.c4inet.net> <20161021.131732.1966246577534839196.he@uninett.no> <20161021114248.GK93886@cilantro.c4inet.net> <4E805786-2E86-4C73-AE09-3D2F2ED812DB@steffann.nl> <4BB2CEF2-B934-412C-AFBF-D75EC6812AF4@steffann.nl> Message-ID: > So it doesn't matter what the policy says it's scope is, it only matters what the chair decides we can discuss or not. Nice "democracy" we have ... Even in parliament you need a chairperson to keep the discussion on topic and to prevent people from hijacking it. Cheers, Sander From office at ip-broker.uk Fri Oct 21 17:59:33 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Fri, 21 Oct 2016 18:59:33 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <20161021.124501.1230279093156300597.he@uninett.no> <20161021105707.GJ93886@cilantro.c4inet.net> <20161021.131732.1966246577534839196.he@uninett.no> <20161021114248.GK93886@cilantro.c4inet.net> <4E805786-2E86-4C73-AE09-3D2F2ED812DB@steffann.nl> <4BB2CEF2-B934-412C-AFBF-D75EC6812AF4@steffann.nl> Message-ID: On Fri, Oct 21, 2016 at 6:48 PM, Sander Steffann wrote: > > > So it doesn't matter what the policy says it's scope is, it only matters > what the chair decides we can discuss or not. Nice "democracy" we have ... > > Even in parliament you need a chairperson to keep the discussion on topic > and to prevent people from hijacking it. > And hopefully that's what they do. Anyone who has read the policy can see what it's goal is and that what I've said is just to stick to that goal. If that's hijacking then you can call me Don Quijote. Ciprian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ian.Dickinson at sky.uk Fri Oct 21 18:00:39 2016 From: Ian.Dickinson at sky.uk (Dickinson, Ian) Date: Fri, 21 Oct 2016 16:00:39 +0000 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: References: Message-ID: <9B3BFE0A18160E40BAF1950414D10FAE6170F0B2@WPMBX010.bskyb.com> I support this proposal, as it solves the issue in a lightweight and appropriate fashion. Ian -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Marco Schmidt Sent: 21 October 2016 09:16 To: address-policy-wg at ripe.net Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) Dear colleagues, A new RIPE Policy proposal 2016-04, "IPv6 PI Sub-assignment Clarification" is now available for discussion. The goal of this proposal is to define sub-assignments in IPv6 PI assignments as subnets of /64 and shorter. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-04 We encourage you to review this proposal and send your comments to before 21 November 2016. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. From david at sargasso.net Fri Oct 21 18:08:48 2016 From: david at sargasso.net (David Croft) Date: Fri, 21 Oct 2016 18:08:48 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: <20161021105527.GS25148@principal.rfc2324.org> References: <20161021105527.GS25148@principal.rfc2324.org> Message-ID: On 21 October 2016 at 12:55, Maximilian Wilhelm wrote: > Anno domini 2016 David Croft scripsit: >> I note that the "New policy text" does not specify the replacement >> text for the "Contractual Requirements" > > That doesn't seem neccessary as the point in question - the definiton > of a sub-assignment - is specified in the new version of ripe-655. > > What are you missing? It appears in the "Current policy text" section, which implied that it was going to be changed in the "New policy text" section, but I guess it's just there for context then. David -- David Croft For support enquiries please always contact support at sargasso.net and not any named individual. UK: 0845 034 5020 USA: 212-400-1694 Sargasso Networks Ltd. Registered in England and Wales No. 06404839. Registered Office: 46a Albert Road North, Reigate, Surrey, RH2 9EL http://www.sargasso.net/ From apwg at c4inet.net Fri Oct 21 18:11:49 2016 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Fri, 21 Oct 2016 17:11:49 +0100 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: References: Message-ID: <20161021161149.GL93886@cilantro.c4inet.net> On Fri, Oct 21, 2016 at 10:15:52AM +0200, Marco Schmidt wrote: >The goal of this proposal is to define sub-assignments in IPv6 PI assignments as subnets of /64 and shorter. For some reason, the rules for end-user infrastructure are stricter than they were for ipv4. This proposal solves the issue and I therefore support it. rgds, Sascha Luck From max at rfc2324.org Fri Oct 21 18:19:50 2016 From: max at rfc2324.org (Maximilian Wilhelm) Date: Fri, 21 Oct 2016 18:19:50 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: References: <20161021105527.GS25148@principal.rfc2324.org> Message-ID: <20161021161950.GU25148@principal.rfc2324.org> Anno domini 2016 David Croft scripsit: > On 21 October 2016 at 12:55, Maximilian Wilhelm wrote: > > Anno domini 2016 David Croft scripsit: > >> I note that the "New policy text" does not specify the replacement > >> text for the "Contractual Requirements" > > > > That doesn't seem neccessary as the point in question - the definiton > > of a sub-assignment - is specified in the new version of ripe-655. > > > > What are you missing? > > It appears in the "Current policy text" section, which implied that it > was going to be changed in the "New policy text" section, but I guess > it's just there for context then. Yes, indeed. I quoted that part as it is relavant context for the change and holds the point in questions. Best Max -- "Wer nicht mehr liebt und nicht mehr irrt, der lasse sich begraben." -- Johann Wolfgang von Goethe From sander at steffann.nl Fri Oct 21 20:00:54 2016 From: sander at steffann.nl (Sander Steffann) Date: Fri, 21 Oct 2016 20:00:54 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <1bf27c66-b07d-952f-2696-cb8723699435@wirem.net> References: <82106c30-78e8-d72c-9bac-4c25cbba2437@velea.eu> <1bf27c66-b07d-952f-2696-cb8723699435@wirem.net> Message-ID: Hi, > I think you are missing that LIRs before 09/2012 are sitting on unused space. Not me, not us LIR after 09/2012. > We just need space now to grow our new businesses. Who wants to sell space to who? If new businesses depend on getting IPv4 addresses to grow then they're on a losing strategy from the start... It's hard, but we've know for many years that that's the way it is. Cheers, Sander From wusel+ml at uu.org Fri Oct 21 21:44:52 2016 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Fri, 21 Oct 2016 21:44:52 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: References: Message-ID: <29c2bb20-24c9-82ee-d94c-04150b1be6d5@uu.org> Hello, am 21.10.2016 um 10:32 schrieb David Croft: > Strong support in principle. We have been denied IPv6 temporary > assignments due to the NCC's interpretation that a single DHCP lease > on wifi is a "subassignment" to another entity, which was clearly not > the intention. I'm new to this, so please bear with my simple-mindedness here, but to me it looks like ?the NCC's interpretation that a single DHCP lease on wifi is a "subassignment" to another entity? iswhat should be addressed, instead of special-caseing something intoan already complex policy document. Reading through ripe-655 multiple times, I can't find a basisfor counting an temporal, RA/DHCP-based, lease of PI space by an organisation holding Provider Independent Resources as a sub- assignment of a/128 prefix. Quoting the relevant definitions of ripe-655: ---8<--- 2.6. Assign To ?assign? means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties. [?] 7. IPv6 Provider Independent (PI) Assignments To qualify for IPv6 PI address space, an organisation must meet therequirements of the policies described in the RIPE NCC document entitled ?Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region?. The RIPE NCC will assign the prefix directly to the End User organisationsupon a request properly submitted to the RIPE NCC, either directly orthrough a sponsoring LIR. [?] Assignments will be made from a separate 'designated block' to facilitate filtering practices. The PI assignment cannot be further assigned to other organisations. --->8--- An ?assignment? therefore is something that ? to prevent the word ?assign? here ? dedicates an address space to someone for a specifc purpose and this act needs to be registered (see 5, and esp. 5.5) in an RIR database. But PI assignments cannot be assigned further, as clearly stated. Operating a WiFi network for employees, relatives, event-visitors or even the general public (i. e. open WiFi, no WPA2) as an End User of Provider Independent Resources does not constitute an ?assignment?, neither in terms of ripe-655 nor in real life. As far as I understand the process, this WG suggests the policies which the NCC implements? So, unless there was a previous call from this WG to the NCC to interpret things as it is reportedly done ? which, from the comment, wasn't the case? ?, why not just vote on a statement that NCC's interpretation is outside of the scope or intention of ripe-655? I mean, it's not the policy that's at fault here; there exists an _interpretation_, used by the RIPE NCC during evaluation of PI space requests, which at least to me is not even remotely covered by ripe-655. Don't mess with what's not broken, fix what is broken ;) Regards, -kai (End User since 1992) -- Kai Siering Schal?ckstra?e 107, 33332 G?tersloh eMail: wusel at uu.org ISN: 98735*1796 ? Phone: +49 172 8635608 ---------------------------------------------------------------------- "Getdate firmly believes that years after 1999 do not exist; getdate will have to be killed by the year 2000." -- From the "Bugs" section of cnews-020592/libc/getdate.3 From richih.mailinglist at gmail.com Fri Oct 21 22:25:57 2016 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 21 Oct 2016 22:25:57 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: <20161021105527.GS25148@principal.rfc2324.org> References: <20161021105527.GS25148@principal.rfc2324.org> Message-ID: +1 Richard Sent by mobile; excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgori at wirem.net Sat Oct 22 06:26:40 2016 From: rgori at wirem.net (Riccardo Gori) Date: Sat, 22 Oct 2016 06:26:40 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: References: Message-ID: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> Hi list, I support this proposal. It's seems logical and needed modify. Simple and easy clarification to avoid misunderstading in interpretation. Well done thank you Max. I realized that I was proposing sort of this to one of my customers just before summer season 2016 for beach side public wifi. Project postponed to summer season 2017 for technical reasons. I would copy the "Contractual requirements" under "New Policy Text" since like this seems to be part of the modify. regards Riccardo Il 21/10/2016 10:15, Marco Schmidt ha scritto: > Dear colleagues, > > A new RIPE Policy proposal 2016-04, "IPv6 PI Sub-assignment Clarification" > is now available for discussion. > > The goal of this proposal is to define sub-assignments in IPv6 PI assignments as subnets of /64 and shorter. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2016-04 > > We encourage you to review this proposal and send your comments to > before 21 November 2016. > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > -- Riccardo Gori From rogerj at gmail.com Sat Oct 22 07:47:45 2016 From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=) Date: Sat, 22 Oct 2016 07:47:45 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <20161021114248.GK93886@cilantro.c4inet.net> References: <20161021.124501.1230279093156300597.he@uninett.no> <20161021105707.GJ93886@cilantro.c4inet.net> <20161021.131732.1966246577534839196.he@uninett.no> <20161021114248.GK93886@cilantro.c4inet.net> Message-ID: On Oct 21, 2016 13:42, "Sascha Luck [ml]" wrote: > > On Fri, Oct 21, 2016 at 01:17:32PM +0200, Havard Eidnes wrote: >>> >>> As for 2015-04, I oppose it as it tries yet again to bring M&A >>> under policy regulation (s. 2.2) which the community has no >>> business doing. >> >> >> Please educate me why the community has no business doing this. >> I would have thought that was well within scope for the address >> policy. > > > In market-based economies, M&As -including the disposal of > assets- are a matter for the parties involved and, occasionally, a state regulator, which the NCC is NOT. > It is unthinkable in such a society that business decisions are > subject to the whim of random people on a mailing list. The > RIPE NCC recognises that and puts M&A firmly outside policy. > Where it should remain unless the desire is that every transfer > application or M&A notification start with filing suit against > the NCC. I think our main problem here is that people think of IP space handed out by RIRs to be an asset just as a datacenter building or a router. It is not, it is a right to use a resources given a few limitation (ncc member ship is one). However pre RIR IP space might be considered an assets as I see it. --- Roger J --- > rgds, > Sascha Luck > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ww at hubs.net.uk Sat Oct 22 11:17:02 2016 From: ww at hubs.net.uk (William Waites) Date: Sat, 22 Oct 2016 09:17:02 +0000 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> References: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> Message-ID: <8660okg2up.fsf@naartjie.uucp> > A new RIPE Policy proposal 2016-04, "IPv6 PI Sub-assignment Clarification" > is now available for discussion. I support this proposal as well. The current interpretation of the policy seems pathological to be honest. It could be supposed that given the Freifunk precedent, a local government (for example) would not be able to get a PI assignment because they provide complimentary Wifi in their lobby. I find it hard to believe that the original policy could have been intended to be read like this and indeed am a little surprised that the NCC has taken such an interpretation. So there is clearly a bug in the policy and this patch appears to fix it. Best wishes, -w -- William Waites Network Engineer HUBS AS60241 From richih.mailinglist at gmail.com Sat Oct 22 12:10:48 2016 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Sat, 22 Oct 2016 12:10:48 +0200 Subject: [address-policy-wg] Thank you to the chairs Message-ID: Dear chairs, as it's all too easy to forget the amount of work that some people dedicate to keeping their particular corners of the Internet sane and cleant, I just wanted to take this opportunity to thank you for your work. Thank you. Enjoy your wooly-headed selfs next week, Richard From max at rfc2324.org Sat Oct 22 12:39:49 2016 From: max at rfc2324.org (Maximilian Wilhelm) Date: Sat, 22 Oct 2016 12:39:49 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: <29c2bb20-24c9-82ee-d94c-04150b1be6d5@uu.org> References: <29c2bb20-24c9-82ee-d94c-04150b1be6d5@uu.org> Message-ID: <20161022103949.GW25148@principal.rfc2324.org> Anno domini 2016 Kai 'wusel' Siering scripsit: Hi Kai, > am 21.10.2016 um 10:32 schrieb David Croft: > > Strong support in principle. We have been denied IPv6 temporary > > assignments due to the NCC's interpretation that a single DHCP lease > > on wifi is a "subassignment" to another entity, which was clearly not > > the intention. > I'm new to this, so please bear with my simple-mindedness here, > but to me it looks like ?the NCC's interpretation that a single > DHCP lease on wifi is a "subassignment" to another entity? iswhat > should be addressed, instead of special-caseing something intoan > already complex policy document. > Reading through ripe-655 multiple times, I can't find a basisfor > counting an temporal, RA/DHCP-based, lease of PI space by an > organisation holding Provider Independent Resources as a sub- > assignment of a/128 prefix. [...] > An ?assignment? therefore is something that ? to prevent the word > ?assign? here ? dedicates an address space to someone for a specifc > purpose and this act needs to be registered (see 5, and esp. 5.5) > in an RIR database. But PI assignments cannot be assigned further, > as clearly stated. > > Operating a WiFi network for employees, relatives, event-visitors or > even the general public (i. e. open WiFi, no WPA2) as an End User > of Provider Independent Resources does not constitute an > ?assignment?, neither in terms of ripe-655 nor in real life. > > As far as I understand the process, this WG suggests the policies > which the NCC implements? So, unless there was a previous call from > this WG to the NCC to interpret things as it is reportedly done ? > which, from the comment, wasn't the case? ?, why not just vote on > a statement that NCC's interpretation is outside of the scope or > intention of ripe-655? There is no such thing as a "vote on a statement hat NCC's interpretation is outside of the scope". See below. > I mean, it's not the policy that's at fault here; there exists > an _interpretation_, used by the RIPE NCC during evaluation of PI > space requests, which at least to me is not even remotely covered > by ripe-655. Don't mess with what's not broken, fix what is broken ;) As previously discussed via IRC the means of the community to "tell the RIPE NCC how to interpret things and do it's job" are the RIPE policies, such as ripe-655. Obviously the current policy is "broken" - to use your wording - as there have been multiple interpretations within the NCC. The proposed policy change tries to close this room for interpretation by defining "an interpretaton" for the point in question following the Policy Development Process. See https://www.ripe.net/participate/policies for details about this. Best Max From ebais at a2b-internet.com Sat Oct 22 13:07:45 2016 From: ebais at a2b-internet.com (Erik Bais - A2B Internet) Date: Sat, 22 Oct 2016 13:07:45 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: <8660okg2up.fsf@naartjie.uucp> References: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> <8660okg2up.fsf@naartjie.uucp> Message-ID: <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> Although I see the intent of the policy, the question that I have is : If a PI space holder is offering free wifi .. they are offering an access service for other to be used in their building or realm ... that qualifies as their infrastructure ... The users of the service, are not making any claims that they require a specific (set of) number assigned ... the user isn't moving into a contractual ( subscription ) agreement for it .. if we are under the current policy disallowing people using the usage of wifi, it would be similar to disallowing people coffee from the network connected coffee machine.. or not allowing guests walking through a hall with CTV camera's with PI IPv6... especially if they can see what the camera's are capturing on a screen ... /brrrr. ;-) An assignment by policy, is setting aside a dedicated set of number(s) to be used by a party. The current PI IPv6 policy does not allow further sub-assignments to third parties. And using the IP space isn't the same as getting an (sub-) assignment from that prefix.. Going into that kind of thinking would be similar to not allowing external voice calls to IPv6 PI assigned phones, because some third party should be able to make use of it.. This discussion is different if we are actually (commercially) hosting services on a (semi)permanent basis on the PI assigned space... like if a third party is actually offering webservice hosting or voip services over that WIFI .. But if the wifi is for regular public wifi access, to allow guests that roam in a public environment on an ad-hoc basis ... it falls perfectly under the current policy imho. That this might be open for interpertation, doesn't directly mean that the current policy is flawed. I know from working with the NCC, that some of the IPRA's haven't been around since this particular policy was discussed and some might have different views .. So it is good that these particular corner cases are re-discussed from time to time imho.. And I would also like to ask the NCC before we try to implement this into a change, how the NCC would see this and how the IPRA's are instructed currently on this, on how to evaluate this. ( before the formal IA further in the PDP ) Regards, Erik Bais > Op 22 okt. 2016 om 11:17 heeft William Waites het volgende geschreven: > > >> A new RIPE Policy proposal 2016-04, "IPv6 PI Sub-assignment Clarification" >> is now available for discussion. > > I support this proposal as well. The current interpretation of the > policy seems pathological to be honest. It could be supposed that given > the Freifunk precedent, a local government (for example) would not be > able to get a PI assignment because they provide complimentary Wifi in > their lobby. I find it hard to believe that the original policy could > have been intended to be read like this and indeed am a little surprised > that the NCC has taken such an interpretation. So there is clearly a bug > in the policy and this patch appears to fix it. > > Best wishes, > -w > > -- > William Waites > Network Engineer > HUBS AS60241 > From jordi.palet at consulintel.es Sat Oct 22 13:39:29 2016 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 22 Oct 2016 13:39:29 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> References: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> <8660okg2up.fsf@naartjie.uucp> <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> Message-ID: Fully agree. Using addresses to provide temporary Internet connectivity to ?visiting? users should not be considered as an assignment, and in fact looking into my notes, when I presented the IPv6 PI policy proposal, I?d this clearly pictured in my mind. So I don?t think we need this change. The Assignment definition mentions Internet infrastructure: 2.6. Assign To ?assign? means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties. In my opinion devices visiting a hot spot AREN?T Internet infrastructure. So if there is a need for clarification, it is not just for the PI policy, but a more global scope in the section 2.6, o even a new section depicting what is ?Internet infrastructure?. For example, the CPE of a customer it is infrastructure, but not the devices behind it. Let?s put it in another way. If the hot spot allows a router to ?connect? to the hot spot and get assigned a /64, then this router is allowing ?other? devices to connect, so in this case it is network infrastructure. Saludos, Jordi -----Mensaje original----- De: address-policy-wg en nombre de Erik Bais - A2B Internet Responder a: Fecha: s?bado, 22 de octubre de 2016, 13:07 Para: William Waites CC: Asunto: Re: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) Although I see the intent of the policy, the question that I have is : If a PI space holder is offering free wifi .. they are offering an access service for other to be used in their building or realm ... that qualifies as their infrastructure ... The users of the service, are not making any claims that they require a specific (set of) number assigned ... the user isn't moving into a contractual ( subscription ) agreement for it .. if we are under the current policy disallowing people using the usage of wifi, it would be similar to disallowing people coffee from the network connected coffee machine.. or not allowing guests walking through a hall with CTV camera's with PI IPv6... especially if they can see what the camera's are capturing on a screen ... /brrrr. ;-) An assignment by policy, is setting aside a dedicated set of number(s) to be used by a party. The current PI IPv6 policy does not allow further sub-assignments to third parties. And using the IP space isn't the same as getting an (sub-) assignment from that prefix.. Going into that kind of thinking would be similar to not allowing external voice calls to IPv6 PI assigned phones, because some third party should be able to make use of it.. This discussion is different if we are actually (commercially) hosting services on a (semi)permanent basis on the PI assigned space... like if a third party is actually offering webservice hosting or voip services over that WIFI .. But if the wifi is for regular public wifi access, to allow guests that roam in a public environment on an ad-hoc basis ... it falls perfectly under the current policy imho. That this might be open for interpertation, doesn't directly mean that the current policy is flawed. I know from working with the NCC, that some of the IPRA's haven't been around since this particular policy was discussed and some might have different views .. So it is good that these particular corner cases are re-discussed from time to time imho.. And I would also like to ask the NCC before we try to implement this into a change, how the NCC would see this and how the IPRA's are instructed currently on this, on how to evaluate this. ( before the formal IA further in the PDP ) Regards, Erik Bais > Op 22 okt. 2016 om 11:17 heeft William Waites het volgende geschreven: > > >> A new RIPE Policy proposal 2016-04, "IPv6 PI Sub-assignment Clarification" >> is now available for discussion. > > I support this proposal as well. The current interpretation of the > policy seems pathological to be honest. It could be supposed that given > the Freifunk precedent, a local government (for example) would not be > able to get a PI assignment because they provide complimentary Wifi in > their lobby. I find it hard to believe that the original policy could > have been intended to be read like this and indeed am a little surprised > that the NCC has taken such an interpretation. So there is clearly a bug > in the policy and this patch appears to fix it. > > Best wishes, > -w > > -- > William Waites > Network Engineer > HUBS AS60241 > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From sander at steffann.nl Sat Oct 22 16:28:45 2016 From: sander at steffann.nl (Sander Steffann) Date: Sat, 22 Oct 2016 16:28:45 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> References: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> <8660okg2up.fsf@naartjie.uucp> <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> Message-ID: Hi Erik, > Going into that kind of thinking would be similar to not allowing external voice calls to IPv6 PI assigned phones, because some third party should be able to make use of it.. > > This discussion is different if we are actually (commercially) hosting services on a (semi)permanent basis on the PI assigned space... like if a third party is actually offering webservice hosting or voip services over that WIFI .. And there is where it gets complicated :) A bit of history: The IPv4 policy had the text "IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. These addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure." This "loophole" made it possible for IPv4 service providers to connect users to their network without making a separate assignment. Originally the idea was that the interconnect wasn't an assignment but the address space routed over that interconnect was. Cases where a single 3rd party server was connected were also not considered assignments because of this rule. Then IPv4 NAT came along, and most residential ISPs started to not assign addresses to customers at all anymore: they only got the interconnect and were expected to NAT using the interconnect's address. That made it possible for ISPs to run their ISP completely on PI addresses. The IPv6 policy then closed the loophole for (IIRC) two reasons: - it was considered unfair that some ISPs used cheap PI addresses while others paid for running the NCC (this included hosters using PI space as well as access ISPs) - the fear that allowing interconnects on cheap PI space would encourage ISPs to force their users to use NAT on IPv6 This of course forced all ISPs to use PA space, but situations where the "ISP" vs "End user" boundary wasn't the classical one had problems. This was discussed on RIPE62 (https://ripe62.ripe.net/presentations/209-apwg.pdf starting at slide 9, it took me a lot of effort trying to find that one, I couldn't imagine it already being 5 years ago) and because of that an effort was started to stop distributing different "colours" of address space and unify PA and PI. Unfortunately that effort failed because it turned out to cause too many complications (see https://ripe67.ripe.net/presentations/215-20131016_-_PA:PI_Unification_IPv6_Address_Space.pdf), which is why we are at the current policy and interpretation as presented 5 years ago: > - No DSL > - No Cable > - VPN > - No co-location > - No virtual servers > - No SSL hosting > > No buts and no exceptions And that's where we are today, and what this policy proposal is trying to change. Cheers, Sander -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: page13image3088.png Type: image/png Size: 212 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From wusel+ml at uu.org Sat Oct 22 17:34:17 2016 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Sat, 22 Oct 2016 17:34:17 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: References: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> <8660okg2up.fsf@naartjie.uucp> <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> Message-ID: <743adb0c-2ce5-5071-800c-250f054c6582@uu.org> Hi there, am 22.10.2016 um 16:28 schrieb Sander Steffann: > This of course forced all ISPs to use PA space, but situations where the "ISP" vs "End user" boundary wasn't the classical one had problems. This was discussed on RIPE62 (https://ripe62.ripe.net/presentations/209-apwg.pdfstarting at slide 9, it took me a lot of effort trying to find that one, I couldn't imagine it already being 5 years ago) and because of that an effort was started to stop distributing different "colours" of address space and unify PA and PI. > > Unfortunately that effort failed because it turned out to cause too many complications (see https://ripe67.ripe.net/presentations/215-20131016_-_PA:PI_Unification_IPv6_Address_Space.pdf), which is why we are at the current policy and interpretation as presented 5 years ago: > >> - No DSL >> - No Cable >> - VPN >> - No co-location >> - No virtual servers >> - No SSL hosting >> >> No buts and no exceptions > > And that's where we are today, and what this policy proposal is trying to change. Sander, thanks for the historical context. It explains this statement from the proposal: ?Today, organisation networks usually include some kind of guest networks, (public) WIFI hotspots in their offices, PTP-VPN links to customers? sites, or anything similar where devices of non-members of the organisation would get assigned an IP out of the organisation?s prefix. Strictly following the current RIPE policy regarding eligibility for IPv6 PI space, organisations aren't allowed to be provided with PI space when this is the case.? But there's nothing about that in ripe-655:?To qualify for IPv6 PI address space, an organisation must meet the requirements of the policies described in the RIPE NCC document entitled ?Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region? [reference goes to ripe-637 as of this writing].? Thus, there seems to be a policy, and an interpretation of that policy, the later hidden in some slides? Now I do agree that the policy needs fixing, as it neither refers nor at least mentions these ?interpretations?. By policy's text, if you sign the Independent Assignment Request and Maintenance Agreement with a sponsoring LIR, you are qualified to receive IPv6 PI space, no? BUT: how would the simple addition of ?[w]ithin the context of these policies, a sub-assignment is an assignment of a length of /64 or shorter? will solve the issue that mentioning WiFi in the PI request leads to it's refusal? (Note that ?no WiFi? is not even present on above's list.) If above's ?interpretation? is still the current one, it misses WiFi, so that should not have led to refusal of PI assigments. If not, where is the current one and how does the APWG influence it ? and how does the general public, e. g. an End User looking for PI space to IPv6- number his or her gear once-and-for-all, learn about it? Regards, -kai -- Kai Siering Schal?ckstra?e 107, 33332 G?tersloh eMail: Kai.Siering at uu.org ISN: 98735*1796 ? Phone: +49 172 8635608 ---------------------------------------------------------------------- "Getdate firmly believes that years after 1999 do not exist; getdate will have to be killed by the year 2000." -- From the "Bugs" section of cnews-020592/libc/getdate.3 From sander at steffann.nl Sat Oct 22 18:39:00 2016 From: sander at steffann.nl (Sander Steffann) Date: Sat, 22 Oct 2016 18:39:00 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: <743adb0c-2ce5-5071-800c-250f054c6582@uu.org> References: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> <8660okg2up.fsf@naartjie.uucp> <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> <743adb0c-2ce5-5071-800c-250f054c6582@uu.org> Message-ID: <29784B88-3C9C-49E4-A1CC-2E1615F0FE9A@steffann.nl> Hello Kai, > Sander, thanks for the historical context. > > It explains this statement from the proposal: ?Today, organisation > networks usually include some kind of guest networks, (public) WIFI > hotspots in their offices, PTP-VPN links to customers? sites, or > anything similar where devices of non-members of the organisation > would get assigned an IP out of the organisation?s prefix. Strictly > following the current RIPE policy regarding eligibility for IPv6 PI > space, organisations aren't allowed to be provided with PI space when > this is the case.? > > But there's nothing about that in ripe-655:?To qualify for IPv6 PI > address space, an organisation must meet the requirements of the > policies described in the RIPE NCC document entitled ?Contractual > Requirements for Provider Independent Resources Holders in the RIPE > NCC Service Region? [reference goes to ripe-637 as of this writing].? > > Thus, there seems to be a policy, and an interpretation of that > policy, the later hidden in some slides? > > Now I do agree that the policy needs fixing, as it neither refers nor > at least mentions these ?interpretations?. By policy's text, if you > sign the Independent Assignment Request and Maintenance Agreement with > a sponsoring LIR, you are qualified to receive IPv6 PI space, no? Yes, but the RIPE NCC checks your intended usage to confirm that it doesn't conflict with the policy. > BUT: how would the simple addition of ?[w]ithin the context of these > policies, a sub-assignment is an assignment of a length of /64 or > shorter? will solve the issue that mentioning WiFi in the PI request > leads to it's refusal? (Note that ?no WiFi? is not even present on > above's list.) There are dozens (maybe hundreds) of ways in which to use address space. Those examples aren't meant to be exclusive. Now, the problem is that we never properly defined what a sub-assignment in this context is. Just based on the language, every case where I tell you to use an address is an assignment. If I were to give you a bit of paper that says "you can use 2001:db8::1" then that is an assignment. I just assigned 2001:db8::1 to you. (Yes, we could get into the discussion that SLAAC isn't technically an assignment in this context but stateful DHCPv6 is, but let's not go there). Basically, under the current policy, based on the English language, letting any 3rd party use your IPv6 PI address space is a violation of the policy. > If above's ?interpretation? is still the current one, it misses WiFi, > so that should not have led to refusal of PI assignments. If not, where > is the current one and how does the APWG influence it ? and how does > the general public, e. g. an End User looking for PI space to IPv6- > number his or her gear once-and-for-all, learn about it? That were some examples, not a complete list. There is no such list. And 3rd party usage of IPv6 PI addresses is currently not allowed. What this policy tries to define is what sub-assignment, and define it as a /64 or more. So letting 3rd parties connect to your WiFi (which will assign them a couple of addresses) is fine, as is letting someone host a server on your network. But you're not allowed to give them their own /64 or more. If you do that then (under the proposed policy text) you are sub-assigning, which isn't allowed. Basically, what is proposed is: assigning separate addresses is fine, whole subnets is not. One of the things I would like to see discussed here is whether the current text is doing what it is supposed to. Is putting a limit at /64 a good criterium? I could comments like "this encourages people to make non-/64 subnets" etc. On the other hand, say we would instead write in the policy that assigning subnets to 3rd parties isn't allowed no matter which size, would that make /127 point-to-point connections impossible? Speaking as a chair: this issue has been around for a long time, and it keeps coming up. Without us (this WG) giving extra guidance to the RIPE NCC their interpretation of what we mean by "sub-assignment" can only be based on the English language, where assignment without any further qualification/quantification means *any* assignment, even if it's just a single address. So I would like to properly define in policy what we as a working group would like to happen. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From scottleibrand at gmail.com Sat Oct 22 18:50:27 2016 From: scottleibrand at gmail.com (Scott Leibrand) Date: Sat, 22 Oct 2016 11:50:27 -0500 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: <29784B88-3C9C-49E4-A1CC-2E1615F0FE9A@steffann.nl> References: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> <8660okg2up.fsf@naartjie.uucp> <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> <743adb0c-2ce5-5071-800c-250f054c6582@uu.org> <29784B88-3C9C-49E4-A1CC-2E1615F0FE9A@steffann.nl> Message-ID: On Saturday, October 22, 2016, Sander Steffann wrote: > > Now, the problem is that we never properly defined what a sub-assignment > in this context is. Just based on the language, every case where I tell you > to use an address is an assignment. If I were to give you a bit of paper > that says "you can use 2001:db8::1" then that is an assignment. I just > assigned 2001:db8::1 to you. (Yes, we could get into the discussion that > SLAAC isn't technically an assignment in this context but stateful DHCPv6 > is, but let's not go there). Basically, under the current policy, based on > the English language, letting any 3rd party use your IPv6 PI address space > is a violation of the policy. > I agree this needs to be fixed. > What this policy tries to define is what sub-assignment, and define it as > a /64 or more. So letting 3rd parties connect to your WiFi (which will > assign them a couple of addresses) is fine, as is letting someone host a > server on your network. But you're not allowed to give them their own /64 > or more. If you do that then (under the proposed policy text) you are > sub-assigning, which isn't allowed. > > Basically, what is proposed is: assigning separate addresses is fine, > whole subnets is not. > I think this is the right approach. +1 for support. > One of the things I would like to see discussed here is whether the > current text is doing what it is supposed to. Is putting a limit at /64 a > good criterium? I could comments like "this encourages people to make > non-/64 subnets" etc. On the other hand, say we would instead write in the > policy that assigning subnets to 3rd parties isn't allowed no matter which > size, would that make /127 point-to-point connections impossible? > I would be fine with /64 as the criterion, with the intention to revise the policy at some point if people abuse the policy (and their customers) by assigning subnets longer/smaller than /64. I would also be fine with something like "any assignment shorter/larger than /126" to make sure PtP links aren't covered, but any usable assignment would be. That might also discourage use of /112s for PtP links, though, which I don't have any problem with. I think on balance, the /64 cutoff is a reasonable starting point that could be adjusted later if needed. > Speaking as a chair: this issue has been around for a long time, and it > keeps coming up. Without us (this WG) giving extra guidance to the RIPE NCC > their interpretation of what we mean by "sub-assignment" can only be based > on the English language, where assignment without any further > qualification/quantification means *any* assignment, even if it's just a > single address. So I would like to properly define in policy what we as a > working group would like to happen. +1 -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-wgs at radu-adrian.feurdean.net Sat Oct 22 22:33:31 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 22 Oct 2016 22:33:31 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <20161021114248.GK93886@cilantro.c4inet.net> References: <20161021.124501.1230279093156300597.he@uninett.no> <20161021105707.GJ93886@cilantro.c4inet.net> <20161021.131732.1966246577534839196.he@uninett.no> <20161021114248.GK93886@cilantro.c4inet.net> Message-ID: <1477168411.1086952.764187681.770B05F2@webmail.messagingengine.com> On Fri, Oct 21, 2016, at 13:42, Sascha Luck [ml] wrote: > RIPE NCC recognises that and puts M&A firmly outside policy. > Where it should remain unless the desire is that every transfer > application or M&A notification start with filing suit against > the NCC. On the other hand, since RIPE NCC *DOES* allow multiple LIRs per single legal entity, it would make some sense that the M&A procedure (the one outside the policy scope) is limited to only changing the name of the LIR. Of course that would mean that all movements of IP addresses between LIRs, even those related to mergers, acquisition, restructuring, consolidation, ..... would fall under transfer policy. Could someone detail what would be the problem in this case (except a limited amount of money of up to 4200 EUR). Unfortunately this is not where we are, and it doesn't look like it's where is going. As for RIPE NCC handling completely on its own the M&A process this is exactly what allowed abuse to happen in the first place (and will still do, even with 2015-01, 2015-04 and 2016-03). And how about a business split - this doesn't feel like handled by the M&A procedure. -- Radu-Adrian FEURDEAN From office at ip-broker.uk Sat Oct 22 22:38:52 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Sat, 22 Oct 2016 23:38:52 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <1477168411.1086952.764187681.770B05F2@webmail.messagingengine.com> References: <20161021.124501.1230279093156300597.he@uninett.no> <20161021105707.GJ93886@cilantro.c4inet.net> <20161021.131732.1966246577534839196.he@uninett.no> <20161021114248.GK93886@cilantro.c4inet.net> <1477168411.1086952.764187681.770B05F2@webmail.messagingengine.com> Message-ID: That's a good point, what would happen when a business splits ? I think there are many situations that need to be discussed and if we want to do something good we'd need to cover all situations. And yes, there is definitely the need for better policies in order for NCC to do exactly what the community wants and not leave room for interpretation. Ciprian On Sat, Oct 22, 2016 at 11:33 PM, Radu-Adrian FEURDEAN < ripe-wgs at radu-adrian.feurdean.net> wrote: > On Fri, Oct 21, 2016, at 13:42, Sascha Luck [ml] wrote: > > > RIPE NCC recognises that and puts M&A firmly outside policy. > > Where it should remain unless the desire is that every transfer > > application or M&A notification start with filing suit against > > the NCC. > > On the other hand, since RIPE NCC *DOES* allow multiple LIRs per single > legal entity, it would make some sense that the M&A procedure (the one > outside the policy scope) is limited to only changing the name of the > LIR. > Of course that would mean that all movements of IP addresses between > LIRs, even those related to mergers, acquisition, restructuring, > consolidation, ..... would fall under transfer policy. Could someone > detail what would be the problem in this case (except a limited amount > of money of up to 4200 EUR). > Unfortunately this is not where we are, and it doesn't look like it's > where is going. > > As for RIPE NCC handling completely on its own the M&A process this is > exactly what allowed abuse to happen in the first place (and will still > do, even with 2015-01, 2015-04 and 2016-03). And how about a business > split - this doesn't feel like handled by the M&A procedure. > > -- > Radu-Adrian FEURDEAN > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arash_mpc at parsun.com Sat Oct 22 22:42:45 2016 From: arash_mpc at parsun.com (Arash Naderpour) Date: Sun, 23 Oct 2016 07:42:45 +1100 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <82106c30-78e8-d72c-9bac-4c25cbba2437@velea.eu> <1bf27c66-b07d-952f-2696-cb8723699435@wirem.net> Message-ID: <008901d22ca4$e7edb660$b7c92320$@parsun.com> Hi, The ones that already have a grown business needs to be targeted to return their IP addresses and switch to IPv6 as soon as possible, They already had enough time, Not the ones that recently started. If old businesses depend on selling IPv4 address to new comers and now looking to put some more value on their old blocks, their strategy should not be supported by 2016-03. Hence Opposing 2016-03, -1. Regards, Arash -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Sander Steffann Sent: Saturday, 22 October 2016 5:01 AM To: Riccardo Gori Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) Hi, > I think you are missing that LIRs before 09/2012 are sitting on unused space. Not me, not us LIR after 09/2012. > We just need space now to grow our new businesses. Who wants to sell space to who? If new businesses depend on getting IPv4 addresses to grow then they're on a losing strategy from the start... It's hard, but we've know for many years that that's the way it is. Cheers, Sander From wusel+ml at uu.org Sat Oct 22 22:49:55 2016 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Sat, 22 Oct 2016 22:49:55 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: <29784B88-3C9C-49E4-A1CC-2E1615F0FE9A@steffann.nl> References: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> <8660okg2up.fsf@naartjie.uucp> <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> <743adb0c-2ce5-5071-800c-250f054c6582@uu.org> <29784B88-3C9C-49E4-A1CC-2E1615F0FE9A@steffann.nl> Message-ID: <17f978d5-224e-2cb7-fc0a-e4e9729d8630@uu.org> Hi Sander, > Yes, but the RIPE NCC checks your intended usage to confirm that it doesn't conflict with the policy. >> BUT: how would the simple addition of ?[w]ithin the context of these policies, a sub-assignment is an assignment of a length of /64 or shorter? will solve the issue that mentioning WiFi in the PI request leads to it's refusal? (Note that ?no WiFi? is not even present on above's list.) > There are dozens (maybe hundreds) of ways in which to use address space. Those examples aren't meant to be exclusive. Now, the problem is that we never properly defined what a sub-assignment in this context is. Just based on the language, every case where I tell you to use an address is an assignment. If I were to give you a bit of paper that says "you can use 2001:db8::1" then that is an assignment. I just assigned 2001:db8::1 to you. (Yes, we could get into the discussion that SLAAC isn't technically an assignment in this context but stateful DHCPv6 is, but let's not go there). Basically, under the current policy, based on the English language, letting any 3rd party use your IPv6 PI address space is a violation of the policy. I beg to differ, it's not about (interpretation of) English language. The policy defines, what ?to assign? means in the context of the policy. Article 2.6. states: ?To ?assign? means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties.? (Which, btw, means there's no difference between PA and PI here. Thus, End Users must not use DHCPv6 nor WiFi, with NCC'scurrent interpretation. Eeks.) The WiFi is part of my (internet-facing) infrastructure I operate. It needs address space to work as designed, so where do I take that from? My routers, switches and internal systems are numbered from my PI space; do I need non-PI space for my WiFi? (Another /48 for maybe 20 devices?) Anyway, I don't intend to nit-pick here; I would like to understand why things are as they obviously are, although there already are definitions for the terms used. Then, I'd like to get things fixed in a way that looking at the ?document [which] defines registry policies for the assignment and allocation of globally unique IPv6 addresses to Internet Service Providers (ISPs) and other organisations? (self-definition of ripe-655) it is clear what can be done with the address space requested and/or received and when the request can/will be denied. Currently, to me it's anything but clear from that document, as hidden rules exist that are neither documented nor mentioned. > And 3rd party usage of IPv6 PI addresses is currently not allowed. Well, if reading the policy that way, neither is it for non-PI space? > What this policy tries to define is what sub-assignment, and define it as a /64 or more. So letting 3rd parties connect to your WiFi (which will assign them a couple of addresses) is fine, as is letting someone host a server on your network. But you're not allowed to give them their own /64 or more. If you do that then (under the proposed policy text) you are sub-assigning, which isn't allowed. This is because ?assignment? isn't used as defined by the policy, imho. If the proposed change solves the issue that fellow Freifunkas can not get IPv6 PI space, well, +1. But as WiFi is mentioned nowhere, this looks like wishful thinking to me. Let's play it through: The policy change gets approved and implemented, and now a /64 of my IPv6 PI for my WiFi is ok. (And giving a /64 or less to my kids/neighbour/barber is as well?) But, I actually operate two WiFis, one for the general public and one for my family. Thus, I now use a /63 in total, but only a /64 each, for WiFi. Ok, not ok?Ok, as: ?Within the context of these policies, a sub-assignment is an assignment of a length of /64 or shorter.? (Actually, it would not be ok, as ?/64 or shorter? still prohibts use of /64 for e. g. WiFi. The proposal therefore should read ?/63 or shorter? or ?shorter than /64?, I think, or SLAAC is not an option anymore.) > Speaking as a chair: this issue has been around for a long time, and it keeps coming up. Without us (this WG) giving extra guidance to the RIPE NCC their interpretation of what we mean by "sub-assignment" can only be based on the English language, where assignment without any further qualification/quantification means *any* assignment, even if it's just a single address. So I would like to properly define in policy what we as a working group would like to happen. That sums up pretty well my issues with the proposed change (while I still see a clear definition of ?assignment? in the policy and wonder why only me understands it as that; is my understanding of the English really that flawed?). Regards, -kai P.S. I don't aim for IPv6 PI for the WiFi part of our Freifunk setup; I'm just tired of renumbering 10+ systems and 20+ tunnels on every change of the upstream used, thus I looked into getting IPv6 PI, which led me here. Renumbering really sucks and I'm currently looking into NPTv6 as the ultimate solution to that; especially, as IPv6 PI obviously comes with too many hidden strings attached. And if it's in place at the egdeanyway, NPTv6 for the WiFi part comes for free. NATs are good, it seems. -- Kai Siering Schal?ckstra?e 107, 33332 G?tersloh eMail: Kai.Siering at uu.org ISN: 98735*1796 ? Phone: +49 172 8635608 ---------------------------------------------------------------------- "Getdate firmly believes that years after 1999 do not exist; getdate will have to be killed by the year 2000." -- From the "Bugs" section of cnews-020592/libc/getdate.3 From sander at steffann.nl Sat Oct 22 23:21:12 2016 From: sander at steffann.nl (Sander Steffann) Date: Sat, 22 Oct 2016 23:21:12 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <008901d22ca4$e7edb660$b7c92320$@parsun.com> References: <82106c30-78e8-d72c-9bac-4c25cbba2437@velea.eu> <1bf27c66-b07d-952f-2696-cb8723699435@wirem.net> <008901d22ca4$e7edb660$b7c92320$@parsun.com> Message-ID: Hi Arash, > If old businesses depend on selling IPv4 address to new comers and now > looking to put some more value on their old blocks, their strategy should > not be supported by 2016-03. I'm sorry, but it's doing the opposite: it will make sure that the remaining pool is not drained by traders, keeping it available for longer for new companies that need them. If the "cheap" pool for newcomers runs out and address transfers become the *only* source for addresses, guess what will happen to the prices. Cheers, Sander From sander at steffann.nl Sat Oct 22 23:30:40 2016 From: sander at steffann.nl (Sander Steffann) Date: Sat, 22 Oct 2016 23:30:40 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: <17f978d5-224e-2cb7-fc0a-e4e9729d8630@uu.org> References: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> <8660okg2up.fsf@naartjie.uucp> <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> <743adb0c-2ce5-5071-800c-250f054c6582@uu.org> <29784B88-3C9C-49E4-A1CC-2E1615F0FE9A@steffann.nl> <17f978d5-224e-2cb7-fc0a-e4e9729d8630@uu.org> Message-ID: Hi, I'll answer the bits I can answer from the top of my head, I'll look into the rest later. > But as WiFi is mentioned nowhere, this looks like wishful thinking to me. Policy shouldn't mention specific technologies at all. Policy should be generic enough to allow for variations and future developments. > Let's play it through: The policy change gets approved and implemented, and now a /64 of my IPv6 PI for my WiFi is ok. (And giving a /64 or less to my kids/neighbour/barber is as well?) But, I actually operate two WiFis, one for the general public and one for my family. Thus, I now use a /63 in total, but only a /64 each, for WiFi. Ok, not ok?Ok, as: ?Within the context of these policies, a sub-assignment is an assignment of a length of /64 or shorter.? > > (Actually, it would not be ok, as ?/64 or shorter? still prohibts use of /64 for e. g. WiFi. The proposal therefore should read ?/63 or shorter? or ?shorter than /64?, I think, or SLAAC is not an option anymore.) You are misunderstanding. We're not talking about what you configure on your Wi-Fi, we're talking about what you delegate to third parties: the users of the Wi-Fi. Unless you assign a whole /64 to a single Wi-Fi user it's within the proposed policy. Cheers, Sander From arash_mpc at parsun.com Sun Oct 23 00:31:03 2016 From: arash_mpc at parsun.com (Arash Naderpour) Date: Sun, 23 Oct 2016 09:31:03 +1100 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <82106c30-78e8-d72c-9bac-4c25cbba2437@velea.eu> <1bf27c66-b07d-952f-2696-cb8723699435@wirem.net> <008901d22ca4$e7edb660$b7c92320$@parsun.com> Message-ID: <00b101d22cb3$fcd54890$f67fd9b0$@parsun.com> Hi Sander, I understand your point, but this already happened with other RIRs and they have no "cheap" pool to fulfil new requests, what happened them and to the prices in their region? Do we have many intra-RIR transfers from RIPE region to other RIRs today? Luckily we still have an /8 in RIPE (and thanks to the old community members for that), but 2016-03 cannot make that much change on draining rate. And I don't think that the pool is that much drained by traders. Yes there is a percentage drained by traders, but comparing to the actual users that's not that much to put this kind of restriction. (We also have enough other restrictions in place) Regards, Arash Naderpour -----Original Message----- From: Sander Steffann [mailto:sander at steffann.nl] Sent: Sunday, 23 October 2016 8:21 AM To: Arash Naderpour Cc: Riccardo Gori ; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) Hi Arash, > If old businesses depend on selling IPv4 address to new comers and now > looking to put some more value on their old blocks, their strategy > should not be supported by 2016-03. I'm sorry, but it's doing the opposite: it will make sure that the remaining pool is not drained by traders, keeping it available for longer for new companies that need them. If the "cheap" pool for newcomers runs out and address transfers become the *only* source for addresses, guess what will happen to the prices. Cheers, Sander From bogdan at rotariu.ro Sun Oct 23 00:59:10 2016 From: bogdan at rotariu.ro (Bogdan-Stefan Rotariu) Date: Sun, 23 Oct 2016 01:59:10 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <00b101d22cb3$fcd54890$f67fd9b0$@parsun.com> References: <82106c30-78e8-d72c-9bac-4c25cbba2437@velea.eu> <1bf27c66-b07d-952f-2696-cb8723699435@wirem.net> <008901d22ca4$e7edb660$b7c92320$@parsun.com> <00b101d22cb3$fcd54890$f67fd9b0$@parsun.com> Message-ID: <14530B95-0475-48B4-93EE-7C569689E412@rotariu.ro> > On 23 Oct 2016, at 01:31, Arash Naderpour wrote: > > Luckily we still have an /8 in RIPE (and thanks to the old community members > for that), but 2016-03 cannot make that much change on draining rate. And I > don't think that the pool is that much drained by traders. Yes there is a > percentage drained by traders, but comparing to the actual users that's not > that much to put this kind of restriction. (We also have enough other > restrictions in place) Yes, thanks to old members who didn?t care about the future of others and made this mess. Thanks to members like http://ipv4.stil.dk and many many more who requested huge amount of IP space without a real need, now selling them for profit. Thanks to traders like Elvis and Ciprian the problem evolved, but they just used an open door and following the rules. While some of you are techies in some ISP or even having your own business, working hard for you, family, employees, making money, some company/IP trader made a huge amount of money in a short amount of time ?selling? IP?s. You, old members, knew before ?90?s and ?00 that the IP Space will exhaust between 2005 and 2011, and you still permitted allocations with almost no real proof of needing from the requester/LIR. This policy will not slow traders, and I think it will really affect the new members that really needed the IP Spaces. A policy that tightens the allocation procedure with real verifications might be better. I do not support this policy -------------- next part -------------- An HTML attachment was scrubbed... URL: From wusel+ml at uu.org Sun Oct 23 01:07:54 2016 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Sun, 23 Oct 2016 01:07:54 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: References: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> <8660okg2up.fsf@naartjie.uucp> <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> <743adb0c-2ce5-5071-800c-250f054c6582@uu.org> <29784B88-3C9C-49E4-A1CC-2E1615F0FE9A@steffann.nl> <17f978d5-224e-2cb7-fc0a-e4e9729d8630@uu.org> Message-ID: <8ea98106-4e4e-9642-55f0-156d506358e5@uu.org> Moin, just a quick reply as well. Am 22.10.2016 um 23:30 schrieb Sander Steffann: > >> Let's play it through: The policy change gets approved and implemented, and now a /64 of my IPv6 PI for my WiFi is ok. (And giving a /64 or less to my kids/neighbour/barber is as well?) But, I actually operate two WiFis, one for the general public and one for my family. Thus, I now use a /63 in total, but only a /64 each, for WiFi. Ok, not ok?Ok, as: ?Within the context of these policies, a sub-assignment is an assignment of a length of /64 or shorter.? >> >> (Actually, it would not be ok, as ?/64 or shorter? still prohibts use of /64 for e. g. WiFi. The proposal therefore should read ?/63 or shorter? or ?shorter than /64?, I think, or SLAAC is not an option anymore.) > You are misunderstanding. We're not talking about what you configure on your Wi-Fi, we're talking about what you delegate to third parties: the users of the Wi-Fi. Unless you assign a whole /64 to a single Wi-Fi user it's within the proposed policy. Bear with me; I still cannot accept the conflicting-with-policy definition of ?delegate? or ?assign? in the context of RA or DHCPv6. Proposal states: ?As an example, some Freifunk Communities in Germany have been had their PI request declined because some 1-digit-number of subnets would have been used as IPv6 prefixes on public WIFIs. This usage of the IP space in the End User?s infrastructure has been interpreted as a sub-assignment of a /128 prefix. This would have been "assigned" to a user device of the public WIFI network as the device would get an IP address via SLAAC (or any other means for that matter).? So, since anything _above_ /64 (e. g. /65 to /128) would be whitewashed by the proposal, using a whole /48 PA or PI for /64s for WiFis would be ok, as long as each WiFi user only gets less than a /64 ?assigned?? Proposal states: ?Today, organisation networks usually include some kind of guest networks, (public) WIFI hotspots in their offices, PTP-VPN links to customers? sites, or anything similar where devices of non-members of the organisation would get assigned an IP out of the organisation?s prefix.? These days I configure P2P links as /64 (with ::1 and ::2 being the endpoints), because ... people actually tried to hit me with cluebats when I carried over IPv4-behaviour of /32 or /31 links into IPv6 (/127). So, even after this proposal, I am not allowed to use my IPv6 PA or PI space to build P2P-links outside my organisation, e. g. for peering, with a netmask of /64? But at least anything above /64 (read: /127) in PI would be ok, which currently isn't, neither for PA nor PI? Regards, -kai From sander at steffann.nl Sun Oct 23 02:06:37 2016 From: sander at steffann.nl (Sander Steffann) Date: Sun, 23 Oct 2016 02:06:37 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <14530B95-0475-48B4-93EE-7C569689E412@rotariu.ro> References: <82106c30-78e8-d72c-9bac-4c25cbba2437@velea.eu> <1bf27c66-b07d-952f-2696-cb8723699435@wirem.net> <008901d22ca4$e7edb660$b7c92320$@parsun.com> <00b101d22cb3$fcd54890$f67fd9b0$@parsun.com> <14530B95-0475-48B4-93EE-7C569689E412@rotariu.ro> Message-ID: <56BFD65E-1522-4A32-B935-7EA04DADCCDC@steffann.nl> Hi, > Yes, thanks to old members who didn?t care about the future of others and made this mess. Please read my previous post. > Thanks to members like http://ipv4.stil.dk and many many more who requested huge amount of IP space without a real need, now selling them for profit. > > Thanks to traders like Elvis and Ciprian the problem evolved, but they just used an open door and following the rules. No ad hominem attacks on this list > While some of you are techies in some ISP or even having your own business, working hard for you, family, employees, making money, some company/IP trader made a huge amount of money in a short amount of time ?selling? IP?s. > > You, old members, knew before ?90?s and ?00 that the IP Space will exhaust between 2005 and 2011, and you still permitted allocations with almost no real proof of needing from the requester/LIR. Those statements are false, please see the archives. > This policy will not slow traders, and I think it will really affect the new members that really needed the IP Spaces. How? If they need the addresses then a policy that says that they can't sell them won't have any effect on them. > A policy that tightens the allocation procedure with real verifications might be better. > > I do not support this policy Sorry, for participating in a consensus based discussion you need to come up with arguments and valid training that can be discussed. Your message only contains ad hominem attacks and wild and inaccurate statements and is therefore for useful for the policy development process. This working group is open to all for discussing policy development, but messages like this do not qualify as "discussing". Cheers, Sander -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Sun Oct 23 02:09:29 2016 From: sander at steffann.nl (Sander Steffann) Date: Sun, 23 Oct 2016 02:09:29 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <56BFD65E-1522-4A32-B935-7EA04DADCCDC@steffann.nl> References: <82106c30-78e8-d72c-9bac-4c25cbba2437@velea.eu> <1bf27c66-b07d-952f-2696-cb8723699435@wirem.net> <008901d22ca4$e7edb660$b7c92320$@parsun.com> <00b101d22cb3$fcd54890$f67fd9b0$@parsun.com> <14530B95-0475-48B4-93EE-7C569689E412@rotariu.ro> <56BFD65E-1522-4A32-B935-7EA04DADCCDC@steffann.nl> Message-ID: Sorry, bad auto correct: > [...] need to come up with arguments and valid training That should be "reasoning" > that can be discussed. Your message only contains ad hominem attacks and wild and inaccurate statements and is therefore for useful That should be "not useful" > for the policy development process. Sorry for the typos, Sander From sander at steffann.nl Sun Oct 23 02:12:54 2016 From: sander at steffann.nl (Sander Steffann) Date: Sun, 23 Oct 2016 02:12:54 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: References: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> <8660okg2up.fsf@naartjie.uucp> <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> <743adb0c-2ce5-5071-800c-250f054c6582@uu.org> <29784B88-3C9C-49E4-A1CC-2E1615F0FE9A@steffann.nl> <17f978d5-224e-2cb7-fc0a-e4e9729d8630@uu.org> Message-ID: <83B5FDA4-8E94-4815-BC96-45DDF17BEC93@steffann.nl> Hi Leo, > So prefix delegation is OK as long as the prefix is longer than a /64? Technically that's what the proposal is currently proposing. I'm curious about the opinions of working group members about that. Cheers, Sander From sander at steffann.nl Sun Oct 23 02:19:53 2016 From: sander at steffann.nl (Sander Steffann) Date: Sun, 23 Oct 2016 02:19:53 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: <8ea98106-4e4e-9642-55f0-156d506358e5@uu.org> References: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> <8660okg2up.fsf@naartjie.uucp> <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> <743adb0c-2ce5-5071-800c-250f054c6582@uu.org> <29784B88-3C9C-49E4-A1CC-2E1615F0FE9A@steffann.nl> <17f978d5-224e-2cb7-fc0a-e4e9729d8630@uu.org> <8ea98106-4e4e-9642-55f0-156d506358e5@uu.org> Message-ID: Hi Kai, > So, since anything _above_ /64 (e. g. /65 to /128) would be whitewashed by the proposal, using a whole /48 PA or PI for /64s for WiFis would be ok, as long as each WiFi user only gets less than a /64 ?assigned?? That's what the proposal currently says. > Proposal states: ?Today, organisation networks usually include some kind of guest networks, (public) WIFI hotspots in their offices, PTP-VPN links to customers? sites, or anything similar where devices of non-members of the organisation would get assigned an IP out of the organisation?s prefix.? > > These days I configure P2P links as /64 (with ::1 and ::2 being the endpoints), because ... people actually tried to hit me with cluebats when I carried over IPv4-behaviour of /32 or /31 links into IPv6 (/127). Actually, using a /127 for point to point links is pretty common. There is even an RFC about it (https://tools.ietf.org/html/rfc6164). I use it a lot, also I the training courses I give. I reserve the whole /64 in the numbering plan just in case, but on the link I usually configure ::a/127 and ::b/127. > So, even after this proposal, I am not allowed to use my IPv6 PA or PI space to build P2P-links outside my organisation, e. g. for peering, with a netmask of /64? But at least anything above /64 (read: /127) in PI would be ok, which currently isn't, neither for PA nor PI? Technically, yes. I still have to re-read the PA bit, because I'm not sure about that. I'll reply to that later. Cheers, Sander -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Sun Oct 23 02:27:35 2016 From: sander at steffann.nl (Sander Steffann) Date: Sun, 23 Oct 2016 02:27:35 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <00b101d22cb3$fcd54890$f67fd9b0$@parsun.com> References: <82106c30-78e8-d72c-9bac-4c25cbba2437@velea.eu> <1bf27c66-b07d-952f-2696-cb8723699435@wirem.net> <008901d22ca4$e7edb660$b7c92320$@parsun.com> <00b101d22cb3$fcd54890$f67fd9b0$@parsun.com> Message-ID: <1F3B1CB0-6C3F-4F1B-9572-F5E8CB5C12D0@steffann.nl> Hi Arash, > I understand your point, but this already happened with other RIRs and they > have no "cheap" pool to fulfil new requests, what happened them and to the > prices in their region? Do we have many intra-RIR transfers from RIPE region > to other RIRs today? Good question. I'm sure the NCC will include such numbers I their presentation next week. I'm curious about that as well. > Luckily we still have an /8 in RIPE (and thanks to the old community members > for that), but 2016-03 cannot make that much change on draining rate. And I > don't think that the pool is that much drained by traders. Yes there is a > percentage drained by traders, but comparing to the actual users that's not > that much to put this kind of restriction. (We also have enough other > restrictions in place) Thanks for setting a good example of how to discuss policy proposal effects in a civil way. I completely understand your reasoning, and this is useful feedback. Thank you! Sander (After all that has happened on this list recently I felt I had to encourage good discussions as well. I don't want to sound negative all the time :) From randy at psg.com Sun Oct 23 03:05:09 2016 From: randy at psg.com (Randy Bush) Date: Sun, 23 Oct 2016 10:05:09 +0900 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <14530B95-0475-48B4-93EE-7C569689E412@rotariu.ro> References: <82106c30-78e8-d72c-9bac-4c25cbba2437@velea.eu> <1bf27c66-b07d-952f-2696-cb8723699435@wirem.net> <008901d22ca4$e7edb660$b7c92320$@parsun.com> <00b101d22cb3$fcd54890$f67fd9b0$@parsun.com> <14530B95-0475-48B4-93EE-7C569689E412@rotariu.ro> Message-ID: > Yes, thanks to old members who didn?t care about the future of others > and made this mess. excuse! it is we old folk who made the last /8 policy in a, possibly mistaken, attempt to allow new folk to enter the game for as long as possible. can we keep the accusations out of this and focus on how to make the internet better? thanks. randy From tore at fud.no Sun Oct 23 10:06:13 2016 From: tore at fud.no (Tore Anderson) Date: Sun, 23 Oct 2016 10:06:13 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: <17f978d5-224e-2cb7-fc0a-e4e9729d8630@uu.org> References: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> <8660okg2up.fsf@naartjie.uucp> <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> <743adb0c-2ce5-5071-800c-250f054c6582@uu.org> <29784B88-3C9C-49E4-A1CC-2E1615F0FE9A@steffann.nl> <17f978d5-224e-2cb7-fc0a-e4e9729d8630@uu.org> Message-ID: <20161023100613.71c7a30e@envy.e1.y.home> Hi Kai, * Kai 'wusel' Siering > (Which, btw, means there's no difference between PA and PI here. > Thus, End Users must not use DHCPv6 nor WiFi, with NCC'scurrent > interpretation. Eeks.) > > [...] > > And 3rd party usage of IPv6 PI addresses is currently not allowed. > > Well, if reading the policy that way, neither is it for non-PI space? I think you're right. An assignment is an assignment. If the policy currently disallows using assignments (PI or PA) for things like wireless networks for guests, then I'd say that 2016-04 doesn't go far enough. Tore From jordi.palet at consulintel.es Sun Oct 23 10:11:50 2016 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 23 Oct 2016 10:11:50 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: <20161023100613.71c7a30e@envy.e1.y.home> References: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> <8660okg2up.fsf@naartjie.uucp> <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> <743adb0c-2ce5-5071-800c-250f054c6582@uu.org> <29784B88-3C9C-49E4-A1CC-2E1615F0FE9A@steffann.nl> <17f978d5-224e-2cb7-fc0a-e4e9729d8630@uu.org> <20161023100613.71c7a30e@envy.e1.y.home> Message-ID: <40C5C497-244B-4C25-B989-974E35F64FEC@consulintel.es> If I?ve a PI for my company ? and I offer WiFi for the laptops or phones of my employees, and their families and customers when they come to my office ? are those assignments? Clearly they are ?others?, not the same organization that got the PI. That?s why I think we need to consider that assignment is for infrastructure, not end devices, at least this seems to be my reading of the definition. Saludos, Jordi -----Mensaje original----- De: address-policy-wg en nombre de Tore Anderson Responder a: Fecha: domingo, 23 de octubre de 2016, 10:06 Para: Kai 'wusel' Siering CC: "address-policy-wg at ripe.net Working Group" Asunto: Re: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) Hi Kai, * Kai 'wusel' Siering > (Which, btw, means there's no difference between PA and PI here. > Thus, End Users must not use DHCPv6 nor WiFi, with NCC'scurrent > interpretation. Eeks.) > > [...] > > And 3rd party usage of IPv6 PI addresses is currently not allowed. > > Well, if reading the policy that way, neither is it for non-PI space? I think you're right. An assignment is an assignment. If the policy currently disallows using assignments (PI or PA) for things like wireless networks for guests, then I'd say that 2016-04 doesn't go far enough. Tore ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From leo at vegoda.org Sat Oct 22 23:45:56 2016 From: leo at vegoda.org (Leo Vegoda) Date: Sat, 22 Oct 2016 14:45:56 -0700 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: References: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> <8660okg2up.fsf@naartjie.uucp> <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> <743adb0c-2ce5-5071-800c-250f054c6582@uu.org> <29784B88-3C9C-49E4-A1CC-2E1615F0FE9A@steffann.nl> <17f978d5-224e-2cb7-fc0a-e4e9729d8630@uu.org> Message-ID: On 10/22/2016 02:30 PM, Sander Steffann wrote: [...] > You are misunderstanding. We're not talking about what you configure on your Wi-Fi, we're talking about what you delegate to third parties: the users of the Wi-Fi. Unless you assign a whole /64 to a single Wi-Fi user it's within the proposed policy. So prefix delegation is OK as long as the prefix is longer than a /64? Regards, Leo Vegoda From ebais at a2b-internet.com Sun Oct 23 11:48:31 2016 From: ebais at a2b-internet.com (Erik Bais - A2B Internet) Date: Sun, 23 Oct 2016 11:48:31 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: <40C5C497-244B-4C25-B989-974E35F64FEC@consulintel.es> References: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> <8660okg2up.fsf@naartjie.uucp> <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> <743adb0c-2ce5-5071-800c-250f054c6582@uu.org> <29784B88-3C9C-49E4-A1CC-2E1615F0FE9A@steffann.nl> <17f978d5-224e-2cb7-fc0a-e4e9729d8630@uu.org> <20161023100613.71c7a30e@envy.e1.y.home> <40C5C497-244B-4C25-B989-974E35F64FEC@consulintel.es> Message-ID: <14C3ECD4-414F-489A-AFB2-4124A27F0CF1@a2b-internet.com> This is also my interpertation... If you use DHCP of any kind on the network to randomly provide a number for a device to connect to the network on a temp lease, it isn't an assignment to the letter of the policy. That is also not how the intent of the policy was written. If you assign a number or subnet to a specific device and that is fixed in the configuration, so the next time you connect, you will get the same number/subnet, you can see that as an assignment. Especially if that is part of a contractual agreement / service / subscription. Most users/devices are looking for a single digit number, not a subnet for their connectivity need. The difference between the two is in the duration and the expectation. Most roaming wifi users won't be asking for a complete subnet or prefix on their laptop or hosting services / third party apps on a wifi link ... Most wifi users just want to avoid telco charges while listening to spotify, skype or watch youtube/twitch/netflix while in a waiting room .. or do some whatsapp while in a wiating room of their healthcare provider.. these are not permanent roamers lurkers to avoid RIPE charges or trying to scam their infra behind some public provided wifi connection. If the specific wifi/network implementation required to use a /64 or smaller per connecting device/user, for security reasons for instance, it would still be the same if those prefixes would be selected dynamically. If the situation is as stated above, the usage should be perfectly within the current policy. Regards, Erik Bais > Op 23 okt. 2016 om 10:11 heeft JORDI PALET MARTINEZ het volgende geschreven: > > If I?ve a PI for my company ? and I offer WiFi for the laptops or phones of my employees, and their families and customers when they come to my office ? are those assignments? Clearly they are ?others?, not the same organization that got the PI. > > That?s why I think we need to consider that assignment is for infrastructure, not end devices, at least this seems to be my reading of the definition. > > Saludos, > Jordi > > > -----Mensaje original----- > De: address-policy-wg en nombre de Tore Anderson > Responder a: > Fecha: domingo, 23 de octubre de 2016, 10:06 > Para: Kai 'wusel' Siering > CC: "address-policy-wg at ripe.net Working Group" > Asunto: Re: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) > > Hi Kai, > > * Kai 'wusel' Siering > >> (Which, btw, means there's no difference between PA and PI here. >> Thus, End Users must not use DHCPv6 nor WiFi, with NCC'scurrent >> interpretation. Eeks.) >> >> [...] > >>> And 3rd party usage of IPv6 PI addresses is currently not allowed. >> >> Well, if reading the policy that way, neither is it for non-PI space? > > I think you're right. An assignment is an assignment. > > If the policy currently disallows using assignments (PI or PA) for > things like wireless networks for guests, then I'd say that 2016-04 > doesn't go far enough. > > Tore > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > From apwg at c4inet.net Sun Oct 23 13:20:56 2016 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Sun, 23 Oct 2016 12:20:56 +0100 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <4E805786-2E86-4C73-AE09-3D2F2ED812DB@steffann.nl> References: <20161021.124501.1230279093156300597.he@uninett.no> <20161021105707.GJ93886@cilantro.c4inet.net> <20161021.131732.1966246577534839196.he@uninett.no> <20161021114248.GK93886@cilantro.c4inet.net> <4E805786-2E86-4C73-AE09-3D2F2ED812DB@steffann.nl> Message-ID: <20161023112056.GM93886@cilantro.c4inet.net> On Fri, Oct 21, 2016 at 04:35:05PM +0200, Sander Steffann wrote: >I think we need to look at the differences between regulating >M&A, which is indeed far outside the scope of this working >group, and defining policy about what can be done with resources >after someone acquires them (M&A or otherwise) which is >definitely in scope. Disposal of assets is part of, and sometimes the reason for, mergers and acquisitions. Trying to regulate this, especially when one isn't mandated to has made many's a lawyer rich. rgds, Sascha Luck From ripe-wgs at radu-adrian.feurdean.net Sun Oct 23 14:12:19 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sun, 23 Oct 2016 14:12:19 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: References: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> <8660okg2up.fsf@naartjie.uucp> <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> <743adb0c-2ce5-5071-800c-250f054c6582@uu.org> <29784B88-3C9C-49E4-A1CC-2E1615F0FE9A@steffann.nl> <17f978d5-224e-2cb7-fc0a-e4e9729d8630@uu.org> Message-ID: <1477224739.2191171.764541081.2E89E0A0@webmail.messagingengine.com> On Sat, Oct 22, 2016, at 23:30, Sander Steffann wrote: > > (Actually, it would not be ok, as ?/64 or shorter? still prohibts use of /64 for e. g. WiFi. The proposal therefore should read ?/63 or shorter? or ?shorter than /64?, I think, or SLAAC is not an option anymore.) > > You are misunderstanding. We're not talking about what you configure on > your Wi-Fi, we're talking about what you delegate to third parties: the > users of the Wi-Fi. Unless you assign a whole /64 to a single Wi-Fi user > it's within the proposed policy. ... and this is where technical implementation comes and messes things up.... If you are functioning in "subscriber management" mode, you equipment may impose you that each subscriber has its own subnet for interconnection (mine does) - obvious choice being a /64. But being in "subscriber management" mode may not be the case for somebody offering wifi on a non-commercial basis, but if it still is, you may always try to use "longer than /64" (??? /128 ???) subnet per device. I haven't tried to see if "longer than /64" works with my equipment, since for me it's a non problem (I do assignments from PAs). -- Radu-Adrian FEURDEAN From ebais at a2b-internet.com Sun Oct 23 14:27:35 2016 From: ebais at a2b-internet.com (Erik Bais) Date: Sun, 23 Oct 2016 14:27:35 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: Message-ID: <00d301d22d28$d9a02aa0$8ce07fe0$@a2b-internet.com> Hi Ciprian, > On Monday, October 17, 2016, Ciprian Nica wrote: > Hi, > I think it would be useful to list on the statistics also the broker that facilitated the transfer. When we made the parts that needed to be published in the transfer statistics, that have crossed my mind, but I failed to see what the benefit is for the community. I can understand from your point why you would ask this, but I'm not going to take this suggestion in this policy. The transfers are between offering and receiving parties.. the facilitators are not a part in this process, except in the financial agreements. Price is also not mentioned or what the BGP routing vendor is that is used for the new prefix.. On the topic of the netname : if you want the netname to be changed, you can open a ticket with the Hostmaster during the transfer to make that happen. No need to put that in policy. Regards, Erik Bais From ebais at a2b-internet.com Sun Oct 23 14:36:36 2016 From: ebais at a2b-internet.com (Erik Bais) Date: Sun, 23 Oct 2016 14:36:36 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <1476872927.1385031.760673489.6C19D69E@webmail.messagingengine.com> Message-ID: <00d401d22d2a$1a0a3a80$4e1eaf80$@a2b-internet.com> Hi Ciprian, The goal of the policy have been discussed on the list and in the RIPE meetings ? so trying to de-rail the process this late in the game, while you were present at the other meetings by saying that it isn?t clear ? it?s valid anymore.. Because as you may remember that was already addressed when it was brought up by Elvis 2 RIPE meetings ago .. and it was addressed at that point. Regards, Erik Bais Van: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Namens Ciprian Nica Verzonden: woensdag 19 oktober 2016 19:10 Aan: address-policy-wg at ripe.net Onderwerp: Re: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) Regarding this policy I think it clearly states in the beginning: "The goal of this proposal is to create a single document with all relevant information regarding the transfer of Internet number resources." I congratulate Erik for it and I think it is very useful to have a single document that would address all situations. But we have to make it clear. Is 2015-04's purpose just to better organise information or to change policies ? If you would have just done what the goal express I think it would have been the first policy that would not get only consensus but unanimity. But when you slip in some changes, then it's a different thing. I agree that many things are not very clear and that there are things that can be improved. This however should be debated properly and maybe it should be done one step at a time through other policy proposals. To resume, if you would change the policy text to stick to it's goal you'd have my +100 (as I see it's getting more popular these days than the classical +1) :) But since this text brings changes I can only give a -1 for not sticking to the goal and for bringing changes that should be treated more careful, not just let's do it quickly however we can and we'll figure out on the way. Why not make good, permanent changes which are expected by many of the community. Ciprian On Wed, Oct 19, 2016 at 1:33 PM, Ciprian Nica > wrote: The policy states how the statistics are presented, therefore I think this issue should be addressed by the policy. RIPE NCC implements the policies and if we, the RIPE community, want some things to be implemented in a certain way then the only way to "ask" it is through the policy, otherwise our voices have no value. Regarding the lack of details at point B., that is in my opinion an insult to the community, regardless of what the policy is about. We should not accept generic statements like that. If nobody bothered to really make an impact analysis then just say it. Ciprian On Wednesday, October 19, 2016, Radu-Adrian FEURDEAN > wrote: Hi, While I do agree with most of the concerns you present there, I'm wondering if this is not an issue to be discussed in some other working group (??? services ??? database ???). They don't seem to be related to the policy itself, but to the way RIPE NCC implements it and reflects the changes in the database. Marco ? Chairs ? anybody else ? -- Radu-Adrian FEURDEAN On Wed, Oct 19, 2016, at 11:57, Ciprian Nica wrote: > > Hi, > > > > I think it would be useful to list on the statistics also the broker that > > facilitated the transfer. That might be of interest to the community and I > > think the NCC should revise the transfer agreement template in order to be > > able to mention the broker and also to publish it's name on the transfer > > statistics page. Also the broker should be allowed to communicate with RIPE > > and pass information on behalf of the customers during the transfer process. > > > > There is also a cosmetic thing that I don't know if it needs be mentioned > > in policy in order to be implemented. The netname of the allocation keeps > > the original allocation date in it's name which can be confusing although > > there's the new "created" attribute. > > > > For example, the subnet 128.0.52.0/24 was transferred on 14/10/2016 and > > it was part of an allocation with netname EU-JM-20120914. The new > > allocation has netname ES-SISTEC-20120914. > > > > If the date is no longer relevant in a netname then I think it should be > > simply ES-SISTEC, otherwise it can be ES-SISTEC-20161014 > > > > Ciprian > > > > > > On Tue, Sep 27, 2016 at 4:08 PM, Marco Schmidt > > > wrote: > > > >> Dear colleagues, > >> > >> The draft documents for version 4.0 of the policy proposal 2015-04, "RIPE > >> Resource Transfer Policies" have now been published, along with an impact > >> analysis conducted by the RIPE NCC. > >> > >> The goal of this proposal is to create a single document with all > >> relevant information regarding the transfer of Internet number resources. > >> > >> Some of the differences from version 3.0 include: > >> > >> - Adding a reference in all related allocation and assignment policies to > >> the new transfer policy document > >> - Clarification in the policy text and policy summary regarding transfers > >> due to a change in the organisation?s business (such as a merger or > >> acquisition) > >> > >> You can find the full proposal and the impact analysis at: > >> https://www.ripe.net/participate/policies/proposals/2015-04 > >> > >> And the draft documents at: > >> https://www.ripe.net/participate/policies/proposals/2015-04/draft > >> > >> We encourage you to read the draft document and send any comments to < > >> address-policy-wg at ripe.net > >> > before 26 > >> October 2016. > >> > >> Regards > >> > >> Marco Schmidt > >> Policy Development Officer > >> RIPE NCC > >> > >> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Sun Oct 23 15:20:39 2016 From: sander at steffann.nl (Sander Steffann) Date: Sun, 23 Oct 2016 15:20:39 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: <1477224739.2191171.764541081.2E89E0A0@webmail.messagingengine.com> References: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> <8660okg2up.fsf@naartjie.uucp> <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> <743adb0c-2ce5-5071-800c-250f054c6582@uu.org> <29784B88-3C9C-49E4-A1CC-2E1615F0FE9A@steffann.nl> <17f978d5-224e-2cb7-fc0a-e4e9729d8630@uu.org> <1477224739.2191171.764541081.2E89E0A0@webmail.messagingengine.com> Message-ID: <2028F837-B020-4A07-9D07-14E0046DBB55@steffann.nl> Hi Radu-Adrian, > ... and this is where technical implementation comes and messes things > up.... > If you are functioning in "subscriber management" mode, you equipment > may impose you that each subscriber has its own subnet for > interconnection (mine does) - obvious choice being a /64. I think that that's perfectly in line with the current policy: if you have subscribers then you need to get PA addresses. The current policy proposal is not trying to change that. But using a /64 for an interconnect is not unreasonable in other circumstances such as VPN connections between two enterprises etc. Cheers, Sander From office at ip-broker.uk Sun Oct 23 16:39:43 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Sun, 23 Oct 2016 17:39:43 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <00d301d22d28$d9a02aa0$8ce07fe0$@a2b-internet.com> References: <00d301d22d28$d9a02aa0$8ce07fe0$@a2b-internet.com> Message-ID: Hi, On Sunday, October 23, 2016, Erik Bais wrote: > Hi Ciprian, > > > On Monday, October 17, 2016, Ciprian Nica > wrote: > > Hi, > > > I think it would be useful to list on the statistics also the broker > that facilitated the transfer. > > When we made the parts that needed to be published in the transfer > statistics, that have crossed my mind, but I failed to see what the benefit > is for the community. The benefit would be that the community can make an idea about whether a broker's info can be reliable or not. There are brokers that never brokered a transaction. > I can understand from your point why you would ask this, but I'm not going > to take this suggestion in this policy. > > I am also a member of this community, besides being your competitor and although you wouldn't like people to see that I've brokered the most transfers, it's quite possible you would broker more transfers than me in the future. We all do our jobs good and my proposal is not just for advertising, I really think people would like to see it. > The transfers are between offering and receiving parties.. the > facilitators are not a part in this process, except in the financial > agreements. > Price is also not mentioned or what the BGP routing vendor is that is used > for the new prefix.. > > I don't know about other brokers but I'm not getting my commission just for puttig 2 parties at the table. We are part of the process, we assist both seller and buyer and we follow every step of the transaction, although we're not allowed by NCC to communicate on behalf of our customers. > On the topic of the netname : if you want the netname to be changed, you > can open a ticket with the Hostmaster during the transfer to make that > happen. No need to put that in policy. > > > I think the idea would be to have this by default and not request it every time. I also think that at least the law enforcement agencies (from my past cooperation with them in the past) would benefit of this clarification. Ciprian -------------- next part -------------- An HTML attachment was scrubbed... URL: From office at ip-broker.uk Sun Oct 23 16:46:16 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Sun, 23 Oct 2016 17:46:16 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <00d401d22d2a$1a0a3a80$4e1eaf80$@a2b-internet.com> References: <1476872927.1385031.760673489.6C19D69E@webmail.messagingengine.com> <00d401d22d2a$1a0a3a80$4e1eaf80$@a2b-internet.com> Message-ID: Hi, On Sunday, October 23, 2016, Erik Bais wrote: > Hi Ciprian, > > > > The goal of the policy have been discussed on the list and in the RIPE > meetings ? so trying to de-rail the process this late in the game, while > you were present at the other meetings by saying that it isn?t clear ? it?s > valid anymore.. > > I'm not tring to derail anything. Why is it so late in the game ? The final proposal was recently published. This policy is relatively "old" and suffered many changes so it's no point in commenting the previous versions. I'm talking about the final, 4th version and it's the open discussion phase. Aren't we supposed to discuss it ? > > > > Because as you may remember that was already addressed when it was brought > up by Elvis 2 RIPE meetings ago .. and it was addressed at that point. > > > > Was that this version of the policy ? No and I think that if this was addressed a year ago you could have changes the policy to correctly express it's goals. Ciprian > Regards, > > Erik Bais > > > > *Van:* address-policy-wg [mailto:address-policy-wg-bounces at ripe.net > ] *Namens > *Ciprian Nica > *Verzonden:* woensdag 19 oktober 2016 19:10 > *Aan:* address-policy-wg at ripe.net > > *Onderwerp:* Re: [address-policy-wg] 2015-04 New Version and Impact > Analysis Published (RIPE Resource Transfer Policies) > > > > Regarding this policy I think it clearly states in the beginning: "The > goal of this proposal is to create a single document with all relevant > information regarding the transfer of Internet number resources." > > I congratulate Erik for it and I think it is very useful to have a single > document that would address all situations. But we have to make it clear. > Is 2015-04's purpose just to better organise information or to change > policies ? > > If you would have just done what the goal express I think it would have > been the first policy that would not get only consensus but unanimity. > > But when you slip in some changes, then it's a different thing. I agree > that many things are not very clear and that there are things that can be > improved. This however should be debated properly and maybe it should be > done one step at a time through other policy proposals. > > To resume, if you would change the policy text to stick to it's goal you'd > have my +100 (as I see it's getting more popular these days than the > classical +1) :) > > But since this text brings changes I can only give a -1 for not sticking > to the goal and for bringing changes that should be treated more careful, > not just let's do it quickly however we can and we'll figure out on the > way. Why not make good, permanent changes which are expected by many of the > community. > > Ciprian > > > > > > > > On Wed, Oct 19, 2016 at 1:33 PM, Ciprian Nica > wrote: > > The policy states how the statistics are presented, therefore I think this > issue should be addressed by the policy. > > > > RIPE NCC implements the policies and if we, the RIPE community, want some > things to be implemented in a certain way then the only way to "ask" it is > through the policy, otherwise our voices have no value. > > > > Regarding the lack of details at point B., that is in my opinion an insult > to the community, regardless of what the policy is about. We should not > accept generic statements like that. If nobody bothered to really make an > impact analysis then just say it. > > > > Ciprian > > > > On Wednesday, October 19, 2016, Radu-Adrian FEURDEAN < > ripe-wgs at radu-adrian.feurdean.net > > > wrote: > > Hi, > > While I do agree with most of the concerns you present there, I'm > wondering if this is not an issue to be discussed in some other working > group (??? services ??? database ???). They don't seem to be related to > the policy itself, but to the way RIPE NCC implements it and reflects > the changes in the database. > > Marco ? Chairs ? anybody else ? > > -- > Radu-Adrian FEURDEAN > > On Wed, Oct 19, 2016, at 11:57, Ciprian Nica wrote: > > > > Hi, > > > > > > I think it would be useful to list on the statistics also the broker > that > > > facilitated the transfer. That might be of interest to the community > and I > > > think the NCC should revise the transfer agreement template in order > to be > > > able to mention the broker and also to publish it's name on the > transfer > > > statistics page. Also the broker should be allowed to communicate with > RIPE > > > and pass information on behalf of the customers during the transfer > process. > > > > > > There is also a cosmetic thing that I don't know if it needs be > mentioned > > > in policy in order to be implemented. The netname of the allocation > keeps > > > the original allocation date in it's name which can be confusing > although > > > there's the new "created" attribute. > > > > > > For example, the subnet 128.0.52.0/24 was transferred on 14/10/2016 > and > > > it was part of an allocation with netname EU-JM-20120914. The new > > > allocation has netname ES-SISTEC-20120914. > > > > > > If the date is no longer relevant in a netname then I think it should > be > > > simply ES-SISTEC, otherwise it can be ES-SISTEC-20161014 > > > > > > Ciprian > > > > > > > > > On Tue, Sep 27, 2016 at 4:08 PM, Marco Schmidt > > > ');>> wrote: > > > > > >> Dear colleagues, > > >> > > >> The draft documents for version 4.0 of the policy proposal 2015-04, > "RIPE > > >> Resource Transfer Policies" have now been published, along with an > impact > > >> analysis conducted by the RIPE NCC. > > >> > > >> The goal of this proposal is to create a single document with all > > >> relevant information regarding the transfer of Internet number > resources. > > >> > > >> Some of the differences from version 3.0 include: > > >> > > >> - Adding a reference in all related allocation and assignment > policies to > > >> the new transfer policy document > > >> - Clarification in the policy text and policy summary regarding > transfers > > >> due to a change in the organisation?s business (such as a merger or > > >> acquisition) > > >> > > >> You can find the full proposal and the impact analysis at: > > >> https://www.ripe.net/participate/policies/proposals/2015-04 > > >> > > >> And the draft documents at: > > >> https://www.ripe.net/participate/policies/proposals/2015-04/draft > > >> > > >> We encourage you to read the draft document and send any comments to < > > >> address-policy-wg at ripe.net > > > >> ');>> before > 26 > > >> October 2016. > > >> > > >> Regards > > >> > > >> Marco Schmidt > > >> Policy Development Officer > > >> RIPE NCC > > >> > > >> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > >> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Sun Oct 23 17:09:56 2016 From: ebais at a2b-internet.com (Erik Bais) Date: Sun, 23 Oct 2016 17:09:56 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <00d301d22d28$d9a02aa0$8ce07fe0$@a2b-internet.com> Message-ID: <011901d22d3f$87e27300$97a75900$@a2b-internet.com> Hi, Feel free to adjust the policy in a new policy proposal, if you think it is vital for the future. As the author of this policy I?m not going to include it in this one. The transfer statistics isn?t a contest between brokers/facilitators or a place for advertising in my opinion. But don?t let my opinion on that keep you from writing your own policy proposal. Regards, Erik Bais Van: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Namens Ciprian Nica Verzonden: zondag 23 oktober 2016 16:40 Aan: Erik Bais CC: address-policy-wg at ripe.net Onderwerp: Re: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) Hi, On Sunday, October 23, 2016, Erik Bais > wrote: Hi Ciprian, > On Monday, October 17, 2016, Ciprian Nica > wrote: > Hi, > I think it would be useful to list on the statistics also the broker that facilitated the transfer. When we made the parts that needed to be published in the transfer statistics, that have crossed my mind, but I failed to see what the benefit is for the community. The benefit would be that the community can make an idea about whether a broker's info can be reliable or not. There are brokers that never brokered a transaction. I can understand from your point why you would ask this, but I'm not going to take this suggestion in this policy. I am also a member of this community, besides being your competitor and although you wouldn't like people to see that I've brokered the most transfers, it's quite possible you would broker more transfers than me in the future. We all do our jobs good and my proposal is not just for advertising, I really think people would like to see it. The transfers are between offering and receiving parties.. the facilitators are not a part in this process, except in the financial agreements. Price is also not mentioned or what the BGP routing vendor is that is used for the new prefix.. I don't know about other brokers but I'm not getting my commission just for puttig 2 parties at the table. We are part of the process, we assist both seller and buyer and we follow every step of the transaction, although we're not allowed by NCC to communicate on behalf of our customers. On the topic of the netname : if you want the netname to be changed, you can open a ticket with the Hostmaster during the transfer to make that happen. No need to put that in policy. I think the idea would be to have this by default and not request it every time. I also think that at least the law enforcement agencies (from my past cooperation with them in the past) would benefit of this clarification. Ciprian -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Sun Oct 23 18:06:03 2016 From: ebais at a2b-internet.com (Erik Bais) Date: Sun, 23 Oct 2016 18:06:03 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <20161021.124501.1230279093156300597.he@uninett.no> <20161021105707.GJ93886@cilantro.c4inet.net> <20161021.131732.1966246577534839196.he@uninett.no> <20161021114248.GK93886@cilantro.c4inet.net> <1477168411.1086952.764187681.770B05F2@webmail.messagingengine.com> Message-ID: <013301d22d47$5e8d6b60$1ba84220$@a2b-internet.com> I?ll entertain your question here, although the question isn?t in relation to the policy proposal, but more about how transfers work .. If a company splits? it is actually very simple ? you setup a second LIR .. ( Provided that we are talking about RIPE PA space.. ) ? And you transfer the space out that needs to go to the business that is split off, to the new LIR ? The new entity / LIR would also receive a free /22 IPv4 and have the right to a /29 IPv6 and request an AS number, if they like, in the process ? And also get 2 free access tickets to the next RIPE meeting ? and may send employees to a new LIR training. In case you are talking about RIPE PI space .. it is even easier .. You decide who the sponsoring LIR is going to be for the new entity.. ( the split off business.. ) Sign an End-User Agreement with the Sponsoring LIR of choice .. Initiate a transfer to split the original prefix into multiple smaller prefixes.. and divide them between the 2 companies.. Send a signed Transfer agreement document and a copy of the End-User Agreement to the RIPE NCC or upload it through the portal ? The new entity doesn?t have any additional rights to an extra /22 or other stuff or free tickets or trainings. Similar as with Legacy space .. only a Confirmation of Transfer to the RIPE NCC Service Region ( no RIPE NCC or Sponsoring LIR contract required even .. ) I?m not saying that there might be corner cases out there that one might bump into however I think that with all the different versions that we worked on, we addressed the ones that are common in normal business practices. The policy proposal doesn?t limit companies from doing M&A?s ? and if you would read point 2.2, it clearly points that out in the text.. The text states : > Scarce resources, which are understood as those resources that are allocated or assigned by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit ASNs), > cannot be transferred for 24 months from the date the resource was received by the resource holder. > This restriction also applies if the resource was received due to a change in the organisation?s business (such as a merger or acquisition). > This restriction does not prevent the resources from being transferred due to further mergers or acquisitions within the 24-month period. So it doesn't prevent future M&A's .. as that is not possible to restrict and not the intention ... The intention is to avoid speculation by hoarding and combining LIR's and transferring IP space out. Regards, Erik Bais --- Van: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Namens Ciprian Nica Verzonden: zaterdag 22 oktober 2016 22:39 Aan: Radu-Adrian FEURDEAN ripe-wgs at radu-adrian.feurdean.net CC: RIPE Address Policy WG List Onderwerp: Re: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) That's a good point, what would happen when a business splits ? I think there are many situations that need to be discussed and if we want to do something good we'd need to cover all situations. And yes, there is definitely the need for better policies in order for NCC to do exactly what the community wants and not leave room for interpretation. Ciprian On Sat, Oct 22, 2016 at 11:33 PM, Radu-Adrian FEURDEAN wrote: On Fri, Oct 21, 2016, at 13:42, Sascha Luck [ml] wrote: > RIPE NCC recognises that and puts M&A firmly outside policy. > Where it should remain unless the desire is that every transfer > application or M&A notification start with filing suit against > the NCC. On the other hand, since RIPE NCC *DOES* allow multiple LIRs per single legal entity, it would make some sense that the M&A procedure (the one outside the policy scope) is limited to only changing the name of the LIR. Of course that would mean that all movements of IP addresses between LIRs, even those related to mergers, acquisition, restructuring, consolidation, ..... would fall under transfer policy. Could someone detail what would be the problem in this case (except a limited amount of money of up to 4200 EUR). Unfortunately this is not where we are, and it doesn't look like it's where is going. As for RIPE NCC handling completely on its own the M&A process this is exactly what allowed abuse to happen in the first place (and will still do, even with 2015-01, 2015-04 and 2016-03). And how about a business split - this doesn't feel like handled by the M&A procedure. -- Radu-Adrian FEURDEAN From office at telefonip.org Sun Oct 23 16:48:39 2016 From: office at telefonip.org (Telefon Ip) Date: Sun, 23 Oct 2016 17:48:39 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <82106c30-78e8-d72c-9bac-4c25cbba2437@velea.eu> <1bf27c66-b07d-952f-2696-cb8723699435@wirem.net> <008901d22ca4$e7edb660$b7c92320$@parsun.com> Message-ID: On Saturday, October 22, 2016, Sander Steffann wrote: > Hi Arash, > > > If old businesses depend on selling IPv4 address to new comers and now > > looking to put some more value on their old blocks, their strategy should > > not be supported by 2016-03. > > I'm sorry, but it's doing the opposite: it will make sure that the > remaining pool is not drained by traders, keeping it available for longer > for new companies that need them. If the "cheap" pool for newcomers runs > out and address transfers become the *only* source for addresses, guess > what will happen to the prices. I've heared this story over and over. Let's protect the pool, let's not waste it and now, after 4 years the pool is almost the same size. Again, what is our purpose here ? Where is the imagined abuse ? Bring up some actual statistics not fake scary scenarios. Ciprian -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Sun Oct 23 19:23:46 2016 From: sander at steffann.nl (Sander Steffann) Date: Sun, 23 Oct 2016 19:23:46 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: <82106c30-78e8-d72c-9bac-4c25cbba2437@velea.eu> <1bf27c66-b07d-952f-2696-cb8723699435@wirem.net> <008901d22ca4$e7edb660$b7c92320$@parsun.com> Message-ID: <8D76781A-3623-405A-B9B6-175D3F5D6904@steffann.nl> Hi Ciprian, > I've heared this story over and over. Let's protect the pool, let's not waste it and now, after 4 years the pool is almost the same size. The only reason that the pool is the size it is is because we received some last scraps from IANA. The number of addresses coming from IANA are less and less each time, so that's not sustainable. Without that the pool would be more than half empty by now. > Again, what is our purpose here ? Where is the imagined abuse ? Bring up some actual statistics not fake scary scenarios. I have no purpose but to keep discussions on this list productive and honest. I'll leave the statistics to the working group session and the authors of the policy proposals. Cheers, Sander From niculae at plesa.ro Sun Oct 23 20:25:07 2016 From: niculae at plesa.ro (Plesa Niculae) Date: Sun, 23 Oct 2016 21:25:07 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <4196960C-1CDD-4A56-B55B-7EF99A8591F6@plesa.ro> References: <1B4AD592-FCAB-4854-8BD0-B0E348596296@plesa.ro> <4196960C-1CDD-4A56-B55B-7EF99A8591F6@plesa.ro> Message-ID: <17E37458-134C-44D0-B8BE-61FB34FAF6EA@plesa.ro> > On 20 Oct 2016, at 10:42, Plesa Niculae wrote: > > Hi Steffann, > > I strongly believe that we should have this conversation public. You switch it to private, for the reason I don?t understand, because we have nothing to hide and nobody to protect, I kindly ask you to make it public. > Why are you tell me that I make an attack? Attack on who? Attack or defend a member that was in the cross fire of chairs & friends? Please read all the messages and you will see that Ciprian was under attack, he was the one first receiving insults and fight back only after. > > My answers to your comments are as follows: > > - the facts are that Gert got IPs from the last /8 just 2 weeks before he did the merger and he also keeps a /22 out of the last /8 for over 2 years without being announced. This shows that he got the IPs even if he didn't actually need them. This is not against the policies but it?s at least immoral. > > - he compared actions not people and telling somebody to shut up is a severe offence. I saw some do not want to be democratic and civilised but I didn?t expect group leaders to support such an authoritarian attitude. > > - I understand how the policy works. I don?t understand when open for discussion means ?praise us and our ideas and shut up if you have anything to say against it as we don't care about your opinions"! > > I hope I was clear and straight with the explanations of my intervention. I have no other reasons than democracy, justice and common sense. I can?t look and do nothing when I saw somebody not treated correct because he had a different opinion than the leaders. > > Best Regards, > Niculae Plesa > > >> On 19 Oct 2016, at 22:27, Sander Steffann wrote: >> >> Hello Plesa, >> >> Replying off-list because I don't want to drag this out any further. >> >>> I saw a lot of members and/or staff friends supporting one another in judging Ciprian metaphors, hyperbolas and comparisons and no one answering to the FACTS presented by him, and to the real life experienced problems that he raised. >> >> What facts? That one of the working group chairs works at an ISP and has merged with another ISP? There was nothing to discuss there, and the baseless allegations made by Ciprian were not worth responding to. Gert kindly responded anyway, and there is nothing more to discuss. >> >>> Everybody was disgusted when hearing about Hitler, Nazi or Camps and nobody has noticed that Ciprian only answers to disgusting words addressed to him, like: SHUT-UP! Somebody said to Aleksey this morning that he speaks bullshit and nobody complain about that language! >> >> I'm sorry, but calling an argument bullshit vs using very offensive language like calling people Nazi's, comparing people to Hitler etc are in completely different leagues. Telling someone to shut up is not polite, but it's completely understandable after the abhorrent language used by Ciprian. >> >>> So it became obvious for me that friends from/of OUR organisation stick together in shutting down everybody else with another opinion, fighting back on the figures of speech, not on the essence of the problems. I almost feel obliged to take a stand and to warn everybody that what happens with cross firing Ciprian for no other real reason than his colourful way of speaking is I N C O R R E C T ! >> >> Comparing people to Hitler and Nazi's is more than colourful language and figures of speech. Ciprian apparently understood that, as he has publicly apologised. >> >> Now, let's discuss policy again, without hateful language, insults and allegations. >> >>> I feel also obliged to thank very much to the ones not blinded by the fury attacks of the policy change initiators on the ones with different opinions than theirs and only focused on the real matters that Aleksey, Ciprian, Patrick, Daniel, Radu-Adrian, Lu and others raised up. >> >> Don't worry, those voices have been heard. >> >>> I have to say that I am totally agree with the real and important problems of the policy raised by Ciprian and other members. I am against changing the existing policy. >> >> Noted. >> >>> By attacking Ciprian you will not solve the problems of the policy and by ignoring the fact that the wg chairs have businesses in which they use the current policy in transferring IPs and after that they want to modify the policy as soon as possible and with insufficient debates and insufficient quorum raises a HUGE question mark. >> >> It was Ciprian making the attacks. And now you apparently. This end right now. These baseless accusations against proposers and chairs are unacceptable. The company that Gert works for has merged with another company, nothing more. I personally have never sold or bought address space at all. This "business in transferring IPs" of the chairs exists only in your imagination. Stop these allegations. >> >> From your comments it is clear that you don't understand how policy development works in RIPE: >> >> - someone from the community makes a proposal >> - the working group chairs have no stake in the proposal >> - the RIPE Policy Development Process is how we handle such proposals >> - there are clearly defined discussion and review phases for debate >> - decision making is based on rough consensus, not "quorum" >> - there is a proper appeals procedure if you think the chairs have made a wrong decision >> >> And that's all. >> Sander >> > From gert at space.net Sun Oct 23 22:17:59 2016 From: gert at space.net (Gert Doering) Date: Sun, 23 Oct 2016 22:17:59 +0200 Subject: [address-policy-wg] even more off-topic stuff (was: 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <17E37458-134C-44D0-B8BE-61FB34FAF6EA@plesa.ro> References: <1B4AD592-FCAB-4854-8BD0-B0E348596296@plesa.ro> <4196960C-1CDD-4A56-B55B-7EF99A8591F6@plesa.ro> <17E37458-134C-44D0-B8BE-61FB34FAF6EA@plesa.ro> Message-ID: <20161023201759.GI79185@Space.Net> Hi, On Sun, Oct 23, 2016 at 09:25:07PM +0300, Plesa Niculae wrote: > > On 20 Oct 2016, at 10:42, Plesa Niculae wrote: > > > > I strongly believe that we should have this conversation public. You switch it to private, for the reason I don???t understand, because we have nothing to hide and nobody to protect, I kindly ask you to make it public. The sole purpose of the address-policy mailing list is to discuss *address policy*. The noise level on this list sometimes gets very high, so people that are interested in *policy making* (and not in personal attacks) complain to the chairs that we need to keep it more focused - and that's what Sander tried to: take the discussion offline, so your points are answered, but do not contribute to the noise level. Your mail has nothing to do whatsoever with the policy proposals currently under discussion, and so this was a very reasonable request. If you insist on sending stuff to the list that is not related to the policy proposals under discussion, *at least* be polite enough to those readers that are interested in discussions to change the Subject: so it's clear that your mails are not related to 2016-03. thanks, Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From office at telefonip.org Mon Oct 24 00:23:24 2016 From: office at telefonip.org (Telefon Ip) Date: Mon, 24 Oct 2016 01:23:24 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <8D76781A-3623-405A-B9B6-175D3F5D6904@steffann.nl> References: <82106c30-78e8-d72c-9bac-4c25cbba2437@velea.eu> <1bf27c66-b07d-952f-2696-cb8723699435@wirem.net> <008901d22ca4$e7edb660$b7c92320$@parsun.com> <8D76781A-3623-405A-B9B6-175D3F5D6904@steffann.nl> Message-ID: Hi, > > I've heared this story over and over. Let's protect the pool, let's not > waste it and now, after 4 years the pool is almost the same size. > > The only reason that the pool is the size it is is because we received > some last scraps from IANA. The number of addresses coming from IANA are > less and less each time, so that's not sustainable. Without that the pool > would be more than half empty by now. > > As I've said, I've heard this story with the same explanation over and over for already a few years. I don't think that this story is sustainable either. The truth is almost everybody predicted the pool would last for 5 years and it's about the same size after 4. The same story was repeated over and over that the last /8 is under attack and we must do everything to protect it while this was never really documented and there were no actual statistics to show a real problem. > > Again, what is our purpose here ? Where is the imagined abuse ? Bring up > some actual statistics not fake scary scenarios. > > I have no purpose but to keep discussions on this list productive and > honest. I'll leave the statistics to the working group session and the > authors of the policy proposals. > I like facts and figures and I definitely look forward to the wg session. Ciprian -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-wgs.cs at schiefner.de Mon Oct 24 09:29:56 2016 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Mon, 24 Oct 2016 09:29:56 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <00d301d22d28$d9a02aa0$8ce07fe0$@a2b-internet.com> Message-ID: <592cb8a0-ba57-3a78-363a-ce24b0d6e825@schiefner.de> Hi Ciprian - On 23.10.2016 16:39, Ciprian Nica wrote: > On Sunday, October 23, 2016, Erik Bais > wrote: > When we made the parts that needed to be published in the transfer > statistics, that have crossed my mind, but I failed to see what the > benefit is for the community. > > The benefit would be that the community can make an idea about whether a > broker's info can be reliable or not. There are brokers that never > brokered a transaction. from this point of view, I could call myself a mathematician, a knitter, a carpenter, a plumber and a rocket scientist at the same time. It's just that I haven't yet carried out either one of their usual tasks and activities. The reality is: a broker that hasn't brokered any deal yet, is most likely not (yet) a broker, but for the time being just a wannabe-broker at best. > I can understand from your point why you would ask this, but I'm not > going to take this suggestion in this policy. > > I am also a member of this community, besides being your competitor and > although you wouldn't like people to see that I've brokered the most > transfers, it's quite possible you would broker more transfers than me > in the future. We all do our jobs good and my proposal is not just > for advertising, I really think people would like to see it. I'd also love to get ad space for free from the RIPE NCC for my business, but won't and don't even want to. As such, e.g. real estate agents are not mentioned in the official land register either. I do see, however, your point that people may want to background check their IP broker of potential choice: for this purpose I'd like to suggest the formation of an IP Broker association that would define quality definitions, measurements and such - as e.g. the above mentioned real estate agents have already given numerous good examples for. But please do not overload the NCC's tray here - I do fully agree with Erik in this regard. Best, -C. From office at ip-broker.uk Mon Oct 24 10:08:43 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Mon, 24 Oct 2016 11:08:43 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <592cb8a0-ba57-3a78-363a-ce24b0d6e825@schiefner.de> References: <00d301d22d28$d9a02aa0$8ce07fe0$@a2b-internet.com> <592cb8a0-ba57-3a78-363a-ce24b0d6e825@schiefner.de> Message-ID: Hi, On Monday, October 24, 2016, Carsten Schiefner wrote: > Hi Ciprian - > > On 23.10.2016 16:39, Ciprian Nica wrote: > > On Sunday, October 23, 2016, Erik Bais > > >> wrote: > > When we made the parts that needed to be published in the transfer > > statistics, that have crossed my mind, but I failed to see what the > > benefit is for the community. > > > > The benefit would be that the community can make an idea about whether a > > broker's info can be reliable or not. There are brokers that never > > brokered a transaction. > > from this point of view, I could call myself a mathematician, a knitter, > a carpenter, a plumber and a rocket scientist at the same time. It's > just that I haven't yet carried out either one of their usual tasks and > activities. > > The reality is: a broker that hasn't brokered any deal yet, is most > likely not (yet) a broker, but for the time being just a wannabe-broker > at best. > > Agree, and there are many of them. > > I can understand from your point why you would ask this, but I'm not > > going to take this suggestion in this policy. > > > > I am also a member of this community, besides being your competitor and > > although you wouldn't like people to see that I've brokered the most > > transfers, it's quite possible you would broker more transfers than me > > in the future. We all do our jobs good and my proposal is not just > > for advertising, I really think people would like to see it. > > I'd also love to get ad space for free from the RIPE NCC for my > business, but won't and don't even want to. As such, e.g. real estate > agents are not mentioned in the official land register either. > > The free ad space is already there. There is a list of brokers on ripe website. > I do see, however, your point that people may want to background check > their IP broker of potential choice: for this purpose I'd like to > suggest the formation of an IP Broker association that would define > quality definitions, measurements and such - as e.g. the above mentioned > real estate agents have already given numerous good examples for. > > I don't think that would be easy to achieve but it's a good idea. > But please do not overload the NCC's tray here - I do fully agree with > Erik in this regard. > > There is, though, an important thing which I think the policy needs to address. The broker should be allowed to discuss with ripe on behalf of his customers. It has happened several times that we had customers who don't understand english very well and many times they would just ask us to write the reply and they would simply copy/paste it. It would help if ripe would allow us to directly pass on information and answer ripe's questions. Ciprian -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-wgs.cs at schiefner.de Mon Oct 24 10:39:31 2016 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Mon, 24 Oct 2016 10:39:31 +0200 Subject: [address-policy-wg] RIPE Resource Transfer Policies: List of IP Brokers In-Reply-To: References: <00d301d22d28$d9a02aa0$8ce07fe0$@a2b-internet.com> <592cb8a0-ba57-3a78-363a-ce24b0d6e825@schiefner.de> Message-ID: <454745a8-062b-f211-6156-c2ea907c3603@schiefner.de> Hi Ciprian - On 24.10.2016 10:08, Ciprian Nica wrote: > I'd also love to get ad space for free from the RIPE NCC for my > business, but won't and don't even want to. As such, e.g. real estate > agents are not mentioned in the official land register either. > > The free ad space is already there. There is a list of brokers on ripe > website. yepp, there indeed is one; at: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfers/brokers - still, that list itself is IMHO as neutral and impartial as possible. And it is clear how to get on this list. When the notion of "who did it" in the stats is not. Not likely at least. At least it is no necessary information for the documentation of a successful transfer, I firmly believe. Best, -C. From ripe-wgs.cs at schiefner.de Mon Oct 24 10:47:40 2016 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Mon, 24 Oct 2016 10:47:40 +0200 Subject: [address-policy-wg] RIPE Resource Transfer Policies: Power of Attorney In-Reply-To: References: <00d301d22d28$d9a02aa0$8ce07fe0$@a2b-internet.com> <592cb8a0-ba57-3a78-363a-ce24b0d6e825@schiefner.de> Message-ID: Hi Ciprian - On 24.10.2016 10:08, Ciprian Nica wrote: > There is, though, an important thing which I think the policy needs to > address. The broker should be allowed to discuss with ripe on behalf of > his customers. It has happened several times that we had customers who > don't understand english very well and many times they would just ask us > to write the reply and they would simply copy/paste it. It would help if > ripe would allow us to directly pass on information and answer ripe's > questions. I do see your point - but I guess, that would require some proper authorization of the broker by Power of Attorny or sth. similar from the buyer and/or seller. Feel free to come up with a separate proposal to get this into the policy. But I am afraid that this might be non-trivial as the NCC services region covers multiple jurisdiction. OTOH, I am sure that the NCC's Legal Dept. will assist you in formulating the requirements if you ask nicely. :-) Best, -C. From rgori at wirem.net Mon Oct 24 11:54:28 2016 From: rgori at wirem.net (Riccardo Gori) Date: Mon, 24 Oct 2016 11:54:28 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <013301d22d47$5e8d6b60$1ba84220$@a2b-internet.com> References: <20161021.124501.1230279093156300597.he@uninett.no> <20161021105707.GJ93886@cilantro.c4inet.net> <20161021.131732.1966246577534839196.he@uninett.no> <20161021114248.GK93886@cilantro.c4inet.net> <1477168411.1086952.764187681.770B05F2@webmail.messagingengine.com> <013301d22d47$5e8d6b60$1ba84220$@a2b-internet.com> Message-ID: <6e5847d9-9d7e-c2d6-a18c-03ac75ccd825@wirem.net> Hi Erik, Il 23/10/2016 18:06, Erik Bais ha scritto: > I?ll entertain your question here, although the question isn?t in relation to the policy proposal, but more about how transfers work .. > > If a company splits? it is actually very simple ? you setup a second LIR .. ( Provided that we are talking about RIPE PA space.. ) ? > > And you transfer the space out that needs to go to the business that is split off, to the new LIR ? > The new entity / LIR would also receive a free /22 IPv4 and have the right to a /29 IPv6 and request an AS number, if they like, in the process ? > > And also get 2 free access tickets to the next RIPE meeting ? and may send employees to a new LIR training. > > In case you are talking about RIPE PI space .. it is even easier .. > You decide who the sponsoring LIR is going to be for the new entity.. ( the split off business.. ) Sign an End-User Agreement with the Sponsoring LIR of choice .. > Initiate a transfer to split the original prefix into multiple smaller prefixes.. and divide them between the 2 companies.. > > Send a signed Transfer agreement document and a copy of the End-User Agreement to the RIPE NCC or upload it through the portal ? > The new entity doesn?t have any additional rights to an extra /22 or other stuff or free tickets or trainings. > > Similar as with Legacy space .. only a Confirmation of Transfer to the RIPE NCC Service Region ( no RIPE NCC or Sponsoring LIR contract required even .. ) > > I?m not saying that there might be corner cases out there that one might bump into however I think that with all the different versions that we worked on, we addressed the ones that are common in normal business practices. > > The policy proposal doesn?t limit companies from doing M&A?s ? and if you would read point 2.2, it clearly points that out in the text.. > > The text states : > >> Scarce resources, which are understood as those resources that are allocated or assigned by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit ASNs), >> cannot be transferred for 24 months from the date the resource was received by the resource holder. >> This restriction also applies if the resource was received due to a change in the organisation?s business (such as a merger or acquisition). >> This restriction does not prevent the resources from being transferred due to further mergers or acquisitions within the 24-month period. > So it doesn't prevent future M&A's .. as that is not possible to restrict and not the intention ... > The intention is to avoid speculation by hoarding and combining LIR's and transferring IP space out. I wanted to see this stated in the summary proposal as a goal. I confess this proposal see me almost neutral but what I don't like is that the summary proposal has as primary goal collect transfer policies in one document but we are mosltly discussing possibile abuses of M&A procedures. This policy technically forces business process to take place (this makes this policy similar to 2016-03) as example to keep an LIR opened while the company has been acquired. In my point of view is not a good idea to force business processes for reasons already expresses by others: future inconsistence of database, possible back market behind and so on.... Please consider me neutral today i have to think a little bit more about it and maybe need some chat with you. Said this, text of 2015-04 is wonderfully clean now and is very clear. Thank you for you work Erik. Now I need to go get the plane to get there ;-) see you in Madrid. regards Riccardo > > Regards, > Erik Bais > > --- > > > Van: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Namens Ciprian Nica > Verzonden: zaterdag 22 oktober 2016 22:39 > Aan: Radu-Adrian FEURDEAN ripe-wgs at radu-adrian.feurdean.net > CC: RIPE Address Policy WG List > Onderwerp: Re: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) > > That's a good point, what would happen when a business splits ? I think there are many situations that need to be discussed and if we want to do something good we'd need to cover all situations. And yes, there is definitely the need for better policies in order for NCC to do exactly what the community wants and not leave room for interpretation. > > Ciprian > > On Sat, Oct 22, 2016 at 11:33 PM, Radu-Adrian FEURDEAN wrote: > On Fri, Oct 21, 2016, at 13:42, Sascha Luck [ml] wrote: > >> RIPE NCC recognises that and puts M&A firmly outside policy. >> Where it should remain unless the desire is that every transfer >> application or M&A notification start with filing suit against >> the NCC. > On the other hand, since RIPE NCC *DOES* allow multiple LIRs per single > legal entity, it would make some sense that the M&A procedure (the one > outside the policy scope) is limited to only changing the name of the > LIR. > Of course that would mean that all movements of IP addresses between > LIRs, even those related to mergers, acquisition, restructuring, > consolidation, ..... would fall under transfer policy. Could someone > detail what would be the problem in this case (except a limited amount > of money of up to 4200 EUR). > Unfortunately this is not where we are, and it doesn't look like it's > where is going. > > As for RIPE NCC handling completely on its own the M&A process this is > exactly what allowed abuse to happen in the first place (and will still > do, even with 2015-01, 2015-04 and 2016-03). And how about a business > split - this doesn't feel like handled by the M&A procedure. > > -- > Radu-Adrian FEURDEAN > > > -- Ing. Riccardo Gori e-mail: rgori at wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logoWirem_4cm_conR.jpg Type: image/jpeg Size: 41774 bytes Desc: not available URL: From sander at steffann.nl Mon Oct 24 16:17:36 2016 From: sander at steffann.nl (Sander Steffann) Date: Mon, 24 Oct 2016 16:17:36 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <00d301d22d28$d9a02aa0$8ce07fe0$@a2b-internet.com> <592cb8a0-ba57-3a78-363a-ce24b0d6e825@schiefner.de> Message-ID: Hi Ciprian, > There is, though, an important thing which I think the policy needs to address. The broker should be allowed to discuss with ripe on behalf of his customers. It has happened several times that we had customers who don't understand english very well and many times they would just ask us to write the reply and they would simply copy/paste it. It would help if ripe would allow us to directly pass on information and answer ripe's questions. Your customer can add you as an official contact in the LIR Portal if necessary. That is the way LIRs can define who is permitted to speak on their behalf. I have done that in the past: got added as a contact, handled the case for them, and then was removed as a contact again. I can imagine that not all LIRs are comfortable doing that, but in that case the communication should go through the LIRs existing contacts anyway. As there are already existing authorisation mechanisms for who can speak on behalf of an LIR I don't see the need to create a new one specifically for brokers. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2084 bytes Desc: not available URL: From ripe-wgs.cs at schiefner.de Mon Oct 24 17:27:37 2016 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Mon, 24 Oct 2016 17:27:37 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <00d301d22d28$d9a02aa0$8ce07fe0$@a2b-internet.com> <592cb8a0-ba57-3a78-363a-ce24b0d6e825@schiefner.de> Message-ID: <430e2f12-af39-e2f8-fe04-59b3544c8938@schiefner.de> Hi Sander, On 24.10.2016 16:17, Sander Steffann wrote: > Your customer can add you as an official contact in the LIR Portal if > necessary. That is the way LIRs can define who is permitted to speak > on their behalf. I have done that in the past: got added as a > contact, handled the case for them, and then was removed as a contact > again. I can imagine that not all LIRs are comfortable doing that, > but in that case the communication should go through the LIRs > existing contacts anyway. > > As there are already existing authorisation mechanisms for who can > speak on behalf of an LIR I don't see the need to create a new one > specifically for brokers. excellent idea! Gets rid of all that PoA stuff immediately. At times, one just cannot see the wood for the all the trees... :-) Best, -C. From leo.vegoda at icann.org Mon Oct 24 18:34:16 2016 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 24 Oct 2016 16:34:16 +0000 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: <14530B95-0475-48B4-93EE-7C569689E412@rotariu.ro> References: <82106c30-78e8-d72c-9bac-4c25cbba2437@velea.eu> <1bf27c66-b07d-952f-2696-cb8723699435@wirem.net> <008901d22ca4$e7edb660$b7c92320$@parsun.com> <00b101d22cb3$fcd54890$f67fd9b0$@parsun.com> <14530B95-0475-48B4-93EE-7C569689E412@rotariu.ro> Message-ID: Bogdan-Stefan Rotariu wrote: [...] > You, old members, knew before ?90?s and ?00 that the IP Space will exhaust > between 2005 and 2011, and you still permitted allocations with almost no > real proof of needing from the requester/LIR. This is simply not true. Between 20115 and 2016 the number of people in Europe who use the Internet grew from 277 million to 499 million, according to the ITU's key ICT data report: https://www.itu.int/en/ITU-D/Statistics/Documents/statistics/2016/ITU_Key_2005-2016_ICT_data.xls (Excel) That massive growth in Internet usage strongly suggests that there was genuine need for the address allocations made by the RIPE NCC. Regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4968 bytes Desc: not available URL: From office at ip-broker.uk Mon Oct 24 19:17:31 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Mon, 24 Oct 2016 20:17:31 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <00d301d22d28$d9a02aa0$8ce07fe0$@a2b-internet.com> <592cb8a0-ba57-3a78-363a-ce24b0d6e825@schiefner.de> Message-ID: Hi, Actually there were cases where we did like that, being put as a contact for the LIR. I don't think this should be the solution as it doesn't seem adequate at least. There were also cases where we would have to "speak" on behalf of both parties so it would be awkward if not unprofessional to be a contact person for both sides. >From our experience the need is just to "translate" (figurative and not) the messages between NCC and LIRs. It is a situation we meet often and I think it should be addressed in a clear procedural way. I don't agree with using tricks. Ciprian On Monday, October 24, 2016, Sander Steffann wrote: > Hi Ciprian, > > > There is, though, an important thing which I think the policy needs to > address. The broker should be allowed to discuss with ripe on behalf of his > customers. It has happened several times that we had customers who don't > understand english very well and many times they would just ask us to write > the reply and they would simply copy/paste it. It would help if ripe would > allow us to directly pass on information and answer ripe's questions. > > Your customer can add you as an official contact in the LIR Portal if > necessary. That is the way LIRs can define who is permitted to speak on > their behalf. I have done that in the past: got added as a contact, handled > the case for them, and then was removed as a contact again. I can imagine > that not all LIRs are comfortable doing that, but in that case the > communication should go through the LIRs existing contacts anyway. > > As there are already existing authorisation mechanisms for who can speak > on behalf of an LIR I don't see the need to create a new one specifically > for brokers. > > Cheers, > Sander > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Mon Oct 24 19:22:05 2016 From: sander at steffann.nl (Sander Steffann) Date: Mon, 24 Oct 2016 19:22:05 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <00d301d22d28$d9a02aa0$8ce07fe0$@a2b-internet.com> <592cb8a0-ba57-3a78-363a-ce24b0d6e825@schiefner.de> Message-ID: Hi Ciprian, > Actually there were cases where we did like that, being put as a contact for the LIR. I don't think this should be the solution as it doesn't seem adequate at least. There were also cases where we would have to "speak" on behalf of both parties so it would be awkward if not unprofessional to be a contact person for both sides. This sentence does not parse. You have to speak on behalf of parties but you cannot be a contact person for them? That doesn't make sense. If you feel that is awkward or unprofessional to speak on behalf of both then don't. Get a separate broker that represents the other party. But in what you wrote above you contradict yourself. > From our experience the need is just to "translate" (figurative and not) the messages between NCC and LIRs. It is a situation we meet often and I think it should be addressed in a clear procedural way. I don't agree with using tricks. This is not a trick. If you can speak on behalf of an LIR then you are a contact and should be registered as such. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2084 bytes Desc: not available URL: From office at ip-broker.uk Mon Oct 24 19:30:16 2016 From: office at ip-broker.uk (Ciprian Nica) Date: Mon, 24 Oct 2016 20:30:16 +0300 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <00d301d22d28$d9a02aa0$8ce07fe0$@a2b-internet.com> <592cb8a0-ba57-3a78-363a-ce24b0d6e825@schiefner.de> Message-ID: I'll be short as I'm assisting an interesting presentation ;) What I meant is that it's not "right" to be a contact person for them since I'm not the one making decisions. I'm an interface and I should be able to represent, help, interact but I feel by not allowing this, we're going too far with the "contact person" trick (solution). Ciprian On Monday, October 24, 2016, Sander Steffann wrote: > Hi Ciprian, > > > Actually there were cases where we did like that, being put as a contact > for the LIR. I don't think this should be the solution as it doesn't seem > adequate at least. There were also cases where we would have to "speak" on > behalf of both parties so it would be awkward if not unprofessional to be a > contact person for both sides. > > This sentence does not parse. You have to speak on behalf of parties but > you cannot be a contact person for them? That doesn't make sense. If you > feel that is awkward or unprofessional to speak on behalf of both then > don't. Get a separate broker that represents the other party. But in what > you wrote above you contradict yourself. > > > From our experience the need is just to "translate" (figurative and not) > the messages between NCC and LIRs. It is a situation we meet often and I > think it should be addressed in a clear procedural way. I don't agree with > using tricks. > > This is not a trick. If you can speak on behalf of an LIR then you are a > contact and should be registered as such. > > Cheers, > Sander > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Mon Oct 24 19:37:26 2016 From: sander at steffann.nl (Sander Steffann) Date: Mon, 24 Oct 2016 19:37:26 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: <00d301d22d28$d9a02aa0$8ce07fe0$@a2b-internet.com> <592cb8a0-ba57-3a78-363a-ce24b0d6e825@schiefner.de> Message-ID: <6AE86027-9D6A-4F4F-B66E-EDE08F624FF3@steffann.nl> Hi, > I'll be short as I'm assisting an interesting presentation ;) > > What I meant is that it's not "right" to be a contact person for them since I'm not the one making decisions. I'm an interface and I should be able to represent, help, interact but I feel by not allowing this, we're going too far with the "contact person" trick (solution). Well, the NCC needs to know who is authoritative to speak for the customer. If it's you then you are a contact, if not then the NCC can not talk to you because you're not authoritative. In that case you will have to assist the LIR from the sideline. You can't have both at the same time. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2084 bytes Desc: not available URL: From mike at iptrading.com Mon Oct 24 19:45:13 2016 From: mike at iptrading.com (Mike Burns) Date: Mon, 24 Oct 2016 13:45:13 -0400 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <6AE86027-9D6A-4F4F-B66E-EDE08F624FF3@steffann.nl> References: <00d301d22d28$d9a02aa0$8ce07fe0$@a2b-internet.com> <592cb8a0-ba57-3a78-363a-ce24b0d6e825@schiefner.de> <6AE86027-9D6A-4F4F-B66E-EDE08F624FF3@steffann.nl> Message-ID: <005301d22e1e$5fcbbd10$1f633730$@iptrading.com> Hi, We have seen the "contact" method here at ARIN. In the past we were able to meet the needs of our clients with a Letter of Agency for ARIN. Not sure if that would fly anymore, though. What about a Letter of Agency at RIPE? Regards, Mike Burns -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Sander Steffann Sent: Monday, October 24, 2016 1:37 PM To: Ciprian Nica Cc: address-policy-wg at ripe.net Working Group Subject: Re: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) Hi, > I'll be short as I'm assisting an interesting presentation ;) > > What I meant is that it's not "right" to be a contact person for them since I'm not the one making decisions. I'm an interface and I should be able to represent, help, interact but I feel by not allowing this, we're going too far with the "contact person" trick (solution). Well, the NCC needs to know who is authoritative to speak for the customer. If it's you then you are a contact, if not then the NCC can not talk to you because you're not authoritative. In that case you will have to assist the LIR from the sideline. You can't have both at the same time. Cheers, Sander From leo.vegoda at icann.org Mon Oct 24 22:02:03 2016 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 24 Oct 2016 20:02:03 +0000 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: <83B5FDA4-8E94-4815-BC96-45DDF17BEC93@steffann.nl> References: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> <8660okg2up.fsf@naartjie.uucp> <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> <743adb0c-2ce5-5071-800c-250f054c6582@uu.org> <29784B88-3C9C-49E4-A1CC-2E1615F0FE9A@steffann.nl> <17f978d5-224e-2cb7-fc0a-e4e9729d8630@uu.org> <83B5FDA4-8E94-4815-BC96-45DDF17BEC93@steffann.nl> Message-ID: HI Sander, Sander Steffann wrote: [...] > > So prefix delegation is OK as long as the prefix is longer than a /64? > > Technically that's what the proposal is currently proposing. I'm curious > about the opinions of working group members about that. Taking no position on the proposal itself, I'd like to draw people's attention to RFC 7421 (Analysis of the 64-bit Boundary in IPv6 Addressing). Section 4.4 deals with Implementation and Deployment Issues and might be a helpful read when considering a proposal that might lead to significant pressure to deploy infrastructures designed to delegate prefixes longer than /64. Kind regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4968 bytes Desc: not available URL: From oliver at bartels.de Mon Oct 24 23:57:57 2016 From: oliver at bartels.de (Oliver Bartels F+E) Date: Mon, 24 Oct 2016 23:57:57 +0200 Subject: [address-policy-wg] ALLOCATED PI / UNSPECIFIED next action In-Reply-To: References: <33985AE5-1467-48DE-8FDB-90EFF92ADA62@steffann.nl> Message-ID: <7a5e1eaf-9513-c946-702e-c2d5d565f620@bartels.de> Am 20.10.2016 um 15:39 schrieb Ciprian Nica: > > In the past there have been PAs used as PIs so technically I think the > "allocated" part should be the one that's more important, therefore I would > support the replacement of allocated pi & unspecified to allocated pa. If > you ignore the greed then changing the status would not make any difference. > > Ripe has a relation with the LIR and the LIR with the customer. Changing PI > to PA will not affect the workability of the IPs nor the relations that are > already in place. Changing them to regular pi assignments would break the > link between lir and customer and give the enduser a possibility to make > money, nothing more. I strongly oppose against this. We are not living in a world where you can seize or just steal other people's ressources just to make your live easier. IP PI *is* a company ressource and quite often there are no relations, as well as with other legacy IPv4. Period. Oliver -- Oliver Bartels, M.Sc. (TUM) + oliver at bartels.de + Fon : +49-(0)89-856305-0 Oliver Bartels F+E + 80935 M?nchen, Germany + www.bartels.de + DE129558421 From max at rfc2324.org Tue Oct 25 09:21:15 2016 From: max at rfc2324.org (Maximilian Wilhelm) Date: Tue, 25 Oct 2016 09:21:15 +0200 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: References: <8660okg2up.fsf@naartjie.uucp> <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> <743adb0c-2ce5-5071-800c-250f054c6582@uu.org> <29784B88-3C9C-49E4-A1CC-2E1615F0FE9A@steffann.nl> <17f978d5-224e-2cb7-fc0a-e4e9729d8630@uu.org> <83B5FDA4-8E94-4815-BC96-45DDF17BEC93@steffann.nl> Message-ID: <20161025072115.GC25148@principal.rfc2324.org> Anno domini 2016 Leo Vegoda scripsit: Hi Leo, > > > So prefix delegation is OK as long as the prefix is longer than a /64? > > > > Technically that's what the proposal is currently proposing. I'm curious > > about the opinions of working group members about that. > Taking no position on the proposal itself, I'd like to draw people's > attention to RFC 7421 (Analysis of the 64-bit Boundary in IPv6 Addressing). Thanks for the pointer. > Section 4.4 deals with Implementation and Deployment Issues and might be a > helpful read when considering a proposal that might lead to significant > pressure to deploy infrastructures designed to delegate prefixes longer than > /64. The proposal should not by any means induce preassure to delegate such prefixes. By "delegate" I think of a "routed delegation", like a prefix which on the last hop of the organisations infrastructure being an entry in the FIB and not configured locally. The whole idea of PI space is that it's not "delegateable" following the above definition. The proposal doesn't want to change that. The goal is to allow use of PI space in the organisations infrastructure and allow the use of prefixies (a /64 for example) in networks open to guest or the general public to stress this example. Best Max -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) From remco.vanmook at gmail.com Wed Oct 26 10:25:18 2016 From: remco.vanmook at gmail.com (Remco van Mook) Date: Wed, 26 Oct 2016 10:25:18 +0200 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: Message-ID: <993E7F45-DB4D-45AD-AE94-1CCFD5B7BC6B@gmail.com> I support this version of the policy proposal - all of my concerns I've voiced previously have been addressed. Remco > On 27 sep. 2016, at 15:08, Marco Schmidt wrote: > > Dear colleagues, > > The draft documents for version 4.0 of the policy proposal 2015-04, "RIPE Resource Transfer Policies" have now been published, along with an impact analysis conducted by the RIPE NCC. > > The goal of this proposal is to create a single document with all relevant information regarding the transfer of Internet number resources. > > Some of the differences from version 3.0 include: > > - Adding a reference in all related allocation and assignment policies to the new transfer policy document > - Clarification in the policy text and policy summary regarding transfers due to a change in the organisation?s business (such as a merger or acquisition) > > You can find the full proposal and the impact analysis at: > https://www.ripe.net/participate/policies/proposals/2015-04 > > And the draft documents at: > https://www.ripe.net/participate/policies/proposals/2015-04/draft > > We encourage you to read the draft document and send any comments to before 26 October 2016. > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From he at uninett.no Wed Oct 26 11:03:28 2016 From: he at uninett.no (Havard Eidnes) Date: Wed, 26 Oct 2016 11:03:28 +0200 (CEST) Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: References: Message-ID: <20161026.110328.97723036171708537.he@uninett.no> Hi, just to prevent any remote possibility of misunderstanding, I support this policy. Regards, - H?vard From noc at ntx.ru Wed Oct 26 12:22:59 2016 From: noc at ntx.ru (NTX NOC) Date: Wed, 26 Oct 2016 13:22:59 +0300 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: Greetings! As additional information for oppose this proposal I would like to say next: 1) RIPE has reserved space/free pool that it's also will be used under current polices for LIRs, there are a lot of space in it. And those space will be used for new LIRs. You can see that it will be enough for 10-15 years or more. https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph 2) Policy name should be not like /8 but on all free/reserve space because it should relay on all rest. So name "/8" is not correct. 3) last year changes about LIRs and it's /22 we see that they didn't make any significant change in new LIR stats. I told that already when it was discussion of 24 month limitation and multilirs registration. That doesn't make any sense on stats. Current rate will give 2-3 years more space enough from 185 space. So thats more then enough. Here is some stats for this year. 2016-1 214 219136 1.31% 48.49% 8134656 2016-2 280 287744 1.72% 46.77% 7846912 2016-3 285 291840 1.74% 45.03% 7555072 2016-4 314 321536 1.92% 43.11% 7233536 2016-5 312 336896 2.01% 41.1% 6896640 2016-6 239 244736 1.46% 39.64% 6651904 2016-7 231 236544 1.41% 38.23% 6415360 2016-8 300 303616 1.81% 36.42% 6111744 2016-9 317 325376 1.94% 34.48% 5786368 2016-10 279 284416 1.7% 32.78% 5501952 But we have in RIPE ~14Mlns IPs more as same as in 2013. So here I make conclusion that things that people told before about last space will expire too fast is not true. That's just normal situation. 4) This policy will make some other type of IPs, we make things more complex, but we should make things/rules/databases less complex. We don't need new one color of IP. 5) In case of such proposal ISPs will move to IPv6 more slowly. So RIPE push to everybody to go IPv6 and from other size they don't allow that to happen. Everybody understand that at America they just gave out all IPv4 and America is the most IPv6 country. So less limitations - more progress! So what do you select? 6) As far as RIPE control limitations - RIPE control the market. And this is not correct. As we see this is already not 1st time of the limitations (/22, then IPv4 transfer 24month hold, then stop multilirs, then limitations for companies overtaking that make impossible overtaking between different countries, problem still exists) So what do we select? I will be thankful for feedback. Yuri at NTX NOC On 19.10.2016 11:05, Marco Schmidt wrote: > Dear colleagues, > > The draft documents for version 3.0 of the policy proposal 2016-03, "Locking Down the Final /8 Policy" have now been published, along with an impact analysis conducted by the RIPE NCC. > > The goal of this proposal is to ban transfers of allocations made under the final /8 policy. Also the proposal specifies what resources must be added to the RIPE NCC IPv4 available pool. > > Some of the differences from version 2.0 include: > > - Clarification that changes to holdership of address space as a result of company mergers or acquisitions are not affected by proposed transfer restriction > - Legacy space handed over to the RIPE NCC will be added to the IPv4 available pool > > You can find the full proposal and the impact analysis at: > https://www.ripe.net/participate/policies/proposals/2016-03 > > And the draft documents at: > https://www.ripe.net/participate/policies/proposals/2016-03/draft > > We want to draw your attention to two changes, which we hope it will make your proposal evaluation easier. > > - Policy proposals now contain a diff tool that allows easy comparison of different proposal versions ? simply click on the ?View Changes? symbol right beside the list of proposal versions. > - The RIPE NCC impact analysis only mentions areas where the proposal is actually expected to have an impact. For example, if the analysis makes no comment about financial or legal impact, it means that no such impact is expected. > > We encourage you to read the draft document and send any comments to before 17 November 2016. > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > From sander at steffann.nl Wed Oct 26 13:05:56 2016 From: sander at steffann.nl (Sander Steffann) Date: Wed, 26 Oct 2016 13:05:56 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: <56F3149D-7F7E-4B83-8858-FDBC13E7B36A@steffann.nl> Hi Yuri, A bit of quick feedback: > 1) RIPE has reserved space/free pool that it's also will be used under > current polices for LIRs, there are a lot of space in it. And those > space will be used for new LIRs. You can see that it will be enough for > 10-15 years or more. That number is too optimistic. During the APWG session at RIPE73 we just got analysis from both the RIPE NCC and Geoff Huston, and both independently have shown that the pool has an expected remaining lifetime of 4 to 4.5 years. > 2) Policy name should be not like /8 but on all free/reserve space > because it should relay on all rest. So name "/8" is not correct. Yes, the working group is aware of that. The current policy is indeed about all the remaining IPv4 space in RIPE NCC (that is not reserved for other purposes). Policy proposals for cleaning up the policy language are welcome! > [...] > But we have in RIPE ~14Mlns IPs more as same as in 2013. It might look like RIPE NCC is not allocating much IPv4 space, but that impression is skewed. That is caused by IPv4 space coming to RIPE NCC from IANA. The statistics on what to expect from IANA in the coming years show that this is not sustainable and we are actually going through the remaining pool than the number appear to suggest. > 4) This policy will make some other type of IPs, we make things more > complex, but we should make things/rules/databases less complex. We > don't need new one color of IP. Well, the proposal did just get abandoned, so this implementation detail is definitely no longer relevant. > 5) In case of such proposal ISPs will move to IPv6 more slowly. So RIPE > push to everybody to go IPv6 and from other size they don't allow that > to happen. Everybody understand that at America they just gave out all > IPv4 and America is the most IPv6 country. So less limitations - more > progress! So what do you select? I'm not sure we can apply market economics as seen in the ARIN region directly to predict what would happen in the RIPE region... > 6) As far as RIPE control limitations - RIPE control the market. And > this is not correct. Yes, the RIPE community sets the rules for resource allocation, assignment and transfer policies in the RIPE region. For this the community has the address policy working group. Setting these policies is its function, this is as intended. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2084 bytes Desc: not available URL: From noc at ntx.ru Wed Oct 26 13:30:37 2016 From: noc at ntx.ru (noc) Date: Wed, 26 Oct 2016 13:30:37 +0200 Subject: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy) References: <56F3149D-7F7E-4B83-8858-FDBC13E7B36A@steffann.nl> Message-ID: An HTML attachment was scrubbed... URL: From sander at steffann.nl Wed Oct 26 15:42:01 2016 From: sander at steffann.nl (Sander Steffann) Date: Wed, 26 Oct 2016 15:42:01 +0200 Subject: [address-policy-wg] RIPE 2016-03 (Locking Down the Final /8 Policy) abandoned, not yet withdrawn Message-ID: <7860301D-AF55-43BE-B3D1-66EBA49B4977@steffann.nl> Hello working group, Remco van Mook, the author of 2016-03, has decided to abandon the 2016-03 policy proposal. The reasons he has given are: - Not because of a lack of consensus - that?s for the chairs to decide - Out of embarrassment for the ?discussion? and how it is damaging our community?s reputation - If anyone else wants to pick up from here, be my guest, but I think we need to discuss the process for that first. If there is anybody who wants to take over as the author of this policy proposal then please contact the working group chairs at apwg-chairs at ripe.net in the next two weeks. The deadline for authors to step forward is Friday the 11th of November. If nobody has offered to take over at that point the chairs will declare the proposal withdrawn. Cheers, Gert & Sander Your friendly neighbourhood working group chairs -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2084 bytes Desc: not available URL: From fransossen at yahoo.com Thu Oct 27 17:06:23 2016 From: fransossen at yahoo.com (fransossen at yahoo.com) Date: Thu, 27 Oct 2016 15:06:23 +0000 (UTC) Subject: [address-policy-wg] ALLOCATED PI / UNSPECIFIED next action In-Reply-To: <33985AE5-1467-48DE-8FDB-90EFF92ADA62@steffann.nl> References: <33985AE5-1467-48DE-8FDB-90EFF92ADA62@steffann.nl> Message-ID: <566891208.2166338.1477580783447@mail.yahoo.com> Hi, > On Thursday, October 20, 2016 2:38 PM, Sander Steffann wrote: > - increase of the routing table This would be the perfect moment to introduce the possibility to authenticate Route(6) creation for contiguous prefixes belonging to different organisations, this is out of scope for this WG, but the DB WG could pick this up. Many of those Allocated PI and Allocated unspecified are aggregated already, if the more specifics are converted to regular PI assignment rather than PA the aggregation in the IRR will be lost unless a mechanism is put in place to allow for it. Allowing the AS to somehow create a /xx aggregated route for the more specifics would be a nice thing and would also be beneficial to other operators that currently have to create separate entries while having contiguous ranges from various customers. Cheers, David