From adavies at ripe.net Fri Oct 2 12:16:14 2020 From: adavies at ripe.net (Alun Davies) Date: Fri, 2 Oct 2020 12:16:14 +0200 Subject: [address-policy-wg] =?utf-8?q?New_on_RIPE_Labs=3A_A_First_for_th?= =?utf-8?q?e_RIPE_NCC_-_Seizure_of_the_=E2=80=9CRight_to_Registration_of_I?= =?utf-8?q?Pv4_Addresses=E2=80=9D_for_the_Recovery_of_Money?= Message-ID: <3E77A03A-58D8-48B8-90B0-FB200782C4E6@ripe.net> Dear colleagues, We recently processed our first IPv4 transfer on the basis of a Dutch court order. In this RIPE Labs article, we provide an overview of the case and look at how things will work moving forwards: https://labs.ripe.net/Members/ciaran_byrne/seizure-of-the-right-to-registration-of-ipv4-addresses Kind regards, Alun Davies RIPE NCC From ebais at a2b-internet.com Mon Oct 5 16:13:11 2020 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 5 Oct 2020 14:13:11 +0000 Subject: [address-policy-wg] IPv4 status hierarchies In-Reply-To: <5E5F66CA-A7DC-455F-A1D7-0E43D3CCB8C1@ripe.net> References: <5E5F66CA-A7DC-455F-A1D7-0E43D3CCB8C1@ripe.net> Message-ID: <6E026B3F-263E-41D9-BF4C-E6B4BCA5EF08@a2b-internet.com> Dear WG, I want to bring the following email and questions of our PDO - Petrit Hasani to your attention that might have slipped over the vacation period. Please have a look at this discussion again and provide input if you can. Regards, Erik Bais Co-chair AP-WG. ( on behalf of the AP-WG Chair collective ) ?On 02/07/2020, 13:36, "address-policy-wg on behalf of Petrit Hasani" wrote: Dear colleagues, Thank you to everyone who responded to our earlier questions on the intent of the policy regarding IPv4 status hierarchies. While this was helpful, it would be great if we could have input from a wider group of people: - Should inetnums with these statuses be allowed to be created inside one another? - Should there be a limit on the minimum size of a sub-allocation? - Do we need a policy update? https://www.ripe.net/ripe/mail/archives/address-policy-wg/2020-June/013195.html We look forward to hearing from you. Cheers, -- Petrit Hasani Policy Officer RIPE NCC > On 16 Jun 2020, at 15:36, Petrit Hasani wrote: > > Dear colleagues, > > We are reviewing IPv4 status hierarchies in the RIPE Database (looking at objects with the same status as their less-specifics). > > Some cases are clear - "ASSIGNED PA" shouldn't be allowed under "ASSIGNED PA", for example. Other statuses might need a closer look and we would like guidance from this working group. > > The RIPE Database does not currently have any limitations on creating inetnums that have the status "SUB-ALLOCATED PA" or "LIR-PARTITIONED PA" under inetnums with the same status. This often results in chains of inetnums that have the same status, sometimes ending with the sub-allocation of a single IP address. > > Although this might not seem useful at first glance, there might be practical uses for a few levels of sub-allocation. For example, a global company could give sub-allocations to its national branches, which make smaller sub-allocations to their multiple daughter companies. These daughter companies could then create and maintain assignments for their actual networks. > > However, this is not allowed under a strict reading of the policy, as only the LIR itself can make sub-allocations, and these must be used for assignments. > > Section 5.3 "Sub-allocations" of the IPv4 Address Allocation and Assignment Policies (ripe-733) states: > > "Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA". > > [...] > > LIRs may make sub-allocations to multiple downstream network operators." > > https://www.ripe.net/publications/docs/ripe-733#54 > > Before making any changes, we want to be sure that we understand the intent of the policy and what the community wants us to do. Thus, we would like to hear from the Address Policy Working Group: > > - Should inetnums with these statuses be allowed to be created inside one another? > - Should there be a limit on the minimum size of a sub-allocation? > - Do we need a policy update? > > We look forward to your guidance. > > Kind regards, > -- > Petrit Hasani > Policy Officer > RIPE NCC > > > > > From ripedenis at yahoo.co.uk Mon Oct 5 16:45:44 2020 From: ripedenis at yahoo.co.uk (ripedenis at yahoo.co.uk) Date: Mon, 5 Oct 2020 14:45:44 +0000 (UTC) Subject: [address-policy-wg] IPv4 status hierarchies In-Reply-To: <6E026B3F-263E-41D9-BF4C-E6B4BCA5EF08@a2b-internet.com> References: <5E5F66CA-A7DC-455F-A1D7-0E43D3CCB8C1@ripe.net> <6E026B3F-263E-41D9-BF4C-E6B4BCA5EF08@a2b-internet.com> Message-ID: <1260079472.3251832.1601909144595@mail.yahoo.com> Colleagues I was about to post this to the DB-WG but it may be more appropriate to include it as part of this discussion... Yet another 4 year old NWI that needs to be progressed or closed. The details are here:https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005242.html In summary it concerns the assignment of a whole allocation. Because the range is the primary key (pkey) in the database you cannot have an allocation object and an assignment object with the same pkey. A common work around is to split the allocation and make two assignments. The suggestion is to allow "status:" to be a multiple attribute. This could be done quite easily and constrained in it's use by business rules in the database software. So the syntax could be changed in INET(6)NUM objects to:status:? ? ? ? ?[mandatory]? [multiple]? ? ?[ ] The business rules could make this multiple option only allowed in very limited situations. For example if an INETNUM object has 'status: ALLOCATED PA' it could be possible to add a second value 'status: ASSIGNED PA' or 'status: SUB-ALLLOCATED PA'. If the status in an INET6NUM object is 'status: ALLOCATED-BY-RIR' it could be possible to add a second value 'status: ALLOCATED-BY-LIR' or 'status: ASSIGNED'. The business rules could prevent any other multiple status values. The "descr:" attribute is already multiple so it can describe both the allocation and the assignment. Is this still considered to be an issue? cheersdenis co-chair DB-WG On Monday, 5 October 2020, 16:13:53 CEST, Erik Bais wrote: Dear WG,? I want to bring the following email and questions of our PDO - Petrit Hasani to your attention that might have slipped over the vacation period.? Please have a look at this discussion again and provide input if you can.? Regards, Erik Bais Co-chair AP-WG. ( on behalf of the AP-WG Chair collective ) ?On 02/07/2020, 13:36, "address-policy-wg on behalf of Petrit Hasani" wrote: ? ? Dear colleagues, ? ? ? ? Thank you to everyone who responded to our earlier questions on the intent of the policy regarding IPv4 status hierarchies. ? ? ? ? While this was helpful, it would be great if we could have input from a wider group of people: ? ? ? ? - Should inetnums with these statuses be allowed to be created inside one another? ? ? - Should there be a limit on the minimum size of a sub-allocation? ? ? - Do we need a policy update? ? ? ? ? https://www.ripe.net/ripe/mail/archives/address-policy-wg/2020-June/013195.html ? ? ? ? We look forward to hearing from you. ? ? ? ? Cheers, ? ? -- ? ? Petrit Hasani ? ? Policy Officer ? ? RIPE NCC ? ? ? ? ? ? ? ? ? ? ? ? > On 16 Jun 2020, at 15:36, Petrit Hasani wrote: ? ? > ? ? > Dear colleagues, ? ? > ? ? > We are reviewing IPv4 status hierarchies in the RIPE Database (looking at objects with the same status as their less-specifics). ? ? > ? ? > Some cases are clear - "ASSIGNED PA" shouldn't be allowed under "ASSIGNED PA", for example. Other statuses might need a closer look and we would like guidance from this working group. ? ? > ? ? > The RIPE Database does not currently have any limitations on creating inetnums that have the status "SUB-ALLOCATED PA" or "LIR-PARTITIONED PA" under inetnums with the same status. This often results in chains of inetnums that have the same status, sometimes ending with the sub-allocation of a single IP address. ? ? > ? ? > Although this might not seem useful at first glance, there might be practical uses for a few levels of sub-allocation. For example, a global company could give sub-allocations to its national branches, which make smaller sub-allocations to their multiple daughter companies. These daughter companies could then create and maintain assignments for their actual networks. ? ? > ? ? > However, this is not allowed under a strict reading of the policy, as only the LIR itself can make sub-allocations, and these must be used for assignments. ? ? > ? ? > Section 5.3 "Sub-allocations" of the IPv4 Address Allocation and Assignment Policies (ripe-733) states: ? ? > ? ? > "Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA". ? ? > ? ? > [...] ? ? > ? ? > LIRs may make sub-allocations to multiple downstream network operators." ? ? > ? ? > https://www.ripe.net/publications/docs/ripe-733#54 ? ? > ? ? > Before making any changes, we want to be sure that we understand the intent of the policy and what the community wants us to do. Thus, we would like to hear from the Address Policy Working Group: ? ? > ? ? > - Should inetnums with these statuses be allowed to be created inside one another? ? ? > - Should there be a limit on the minimum size of a sub-allocation? ? ? > - Do we need a policy update? ? ? > ? ? > We look forward to your guidance. ? ? > ? ? > Kind regards, ? ? > -- ? ? > Petrit Hasani ? ? > Policy Officer ? ? > RIPE NCC ? ? > ? ? > ? ? > ? ? > ? ? > ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stephane.Dodeller at swisscom.com Mon Oct 5 17:24:01 2020 From: Stephane.Dodeller at swisscom.com (Stephane.Dodeller at swisscom.com) Date: Mon, 5 Oct 2020 15:24:01 +0000 Subject: [address-policy-wg] IPv4 status hierarchies Message-ID: <5850561D-E7D7-4EDC-A41B-C37238AECD0A@swisscom.com> Dear Denis, Since the workaround you mention creates entries in the database that do not match in some cases the reality of what has been done (and allowed by the policy), especially during the ALLOCATED-UNSPECIFIED cleanup period, I support the change you mention. Best regards St?phane Dodeller Swisscom (ch.unisource) ?Le 05.10.20 16:48, ? address-policy-wg au nom de address-policy-wg-request at ripe.net ? a ?crit : Date: Mon, 5 Oct 2020 14:45:44 +0000 (UTC) From: "ripedenis at yahoo.co.uk" To: "address-policy-wg at ripe.net" , Erik Bais Subject: Re: [address-policy-wg] IPv4 status hierarchies Message-ID: <1260079472.3251832.1601909144595 at mail.yahoo.com> Content-Type: text/plain; charset="utf-8" Colleagues I was about to post this to the DB-WG but it may be more appropriate to include it as part of this discussion... Yet another 4 year old NWI that needs to be progressed or closed. The details are here:https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.net%2Fripe%2Fmail%2Farchives%2Fdb-wg%2F2016-May%2F005242.html&data=02%7C01%7CStephane.Dodeller%40swisscom.com%7C1824b65a8425487661aa08d8693dc293%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637375061263396078&sdata=nZJ18TdMGru4ajgL4qPbmyElMXw%2Fc%2FynnCNpPu2Rp9g%3D&reserved=0 In summary it concerns the assignment of a whole allocation. Because the range is the primary key (pkey) in the database you cannot have an allocation object and an assignment object with the same pkey. A common work around is to split the allocation and make two assignments. The suggestion is to allow "status:" to be a multiple attribute. This could be done quite easily and constrained in it's use by business rules in the database software. So the syntax could be changed in INET(6)NUM objects to:status:? ? ? ? ?[mandatory]? [multiple]? ? ?[ ] The business rules could make this multiple option only allowed in very limited situations. For example if an INETNUM object has 'status: ALLOCATED PA' it could be possible to add a second value 'status: ASSIGNED PA' or 'status: SUB-ALLLOCATED PA'. If the status in an INET6NUM object is 'status: ALLOCATED-BY-RIR' it could be possible to add a second value 'status: ALLOCATED-BY-LIR' or 'status: ASSIGNED'. The business rules could prevent any other multiple status values. The "descr:" attribute is already multiple so it can describe both the allocation and the assignment. Is this still considered to be an issue? cheersdenis co-chair DB-WG On Monday, 5 October 2020, 16:13:53 CEST, Erik Bais wrote: Dear WG,? I want to bring the following email and questions of our PDO - Petrit Hasani to your attention that might have slipped over the vacation period.? Please have a look at this discussion again and provide input if you can.? Regards, Erik Bais Co-chair AP-WG. ( on behalf of the AP-WG Chair collective ) ?On 02/07/2020, 13:36, "address-policy-wg on behalf of Petrit Hasani" wrote: ? ? Dear colleagues, ? ? ? ? Thank you to everyone who responded to our earlier questions on the intent of the policy regarding IPv4 status hierarchies. ? ? ? ? While this was helpful, it would be great if we could have input from a wider group of people: ? ? ? ? - Should inetnums with these statuses be allowed to be created inside one another? ? ? - Should there be a limit on the minimum size of a sub-allocation? ? ? - Do we need a policy update? ? ? ? ? https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.net%2Fripe%2Fmail%2Farchives%2Faddress-policy-wg%2F2020-June%2F013195.html&data=02%7C01%7CStephane.Dodeller%40swisscom.com%7C1824b65a8425487661aa08d8693dc293%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637375061263396078&sdata=5LGahksB3BwkFn0apTyFMGMg4tu4NSprj6AmdCpU0ek%3D&reserved=0 ? ? ? ? We look forward to hearing from you. ? ? ? ? Cheers, ? ? -- ? ? Petrit Hasani ? ? Policy Officer ? ? RIPE NCC ? ? ? ? ? ? ? ? ? ? ? ? > On 16 Jun 2020, at 15:36, Petrit Hasani wrote: ? ? > ? ? > Dear colleagues, ? ? > ? ? > We are reviewing IPv4 status hierarchies in the RIPE Database (looking at objects with the same status as their less-specifics). ? ? > ? ? > Some cases are clear - "ASSIGNED PA" shouldn't be allowed under "ASSIGNED PA", for example. Other statuses might need a closer look and we would like guidance from this working group. ? ? > ? ? > The RIPE Database does not currently have any limitations on creating inetnums that have the status "SUB-ALLOCATED PA" or "LIR-PARTITIONED PA" under inetnums with the same status. This often results in chains of inetnums that have the same status, sometimes ending with the sub-allocation of a single IP address. ? ? > ? ? > Although this might not seem useful at first glance, there might be practical uses for a few levels of sub-allocation. For example, a global company could give sub-allocations to its national branches, which make smaller sub-allocations to their multiple daughter companies. These daughter companies could then create and maintain assignments for their actual networks. ? ? > ? ? > However, this is not allowed under a strict reading of the policy, as only the LIR itself can make sub-allocations, and these must be used for assignments. ? ? > ? ? > Section 5.3 "Sub-allocations" of the IPv4 Address Allocation and Assignment Policies (ripe-733) states: ? ? > ? ? > "Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA". ? ? > ? ? > [...] ? ? > ? ? > LIRs may make sub-allocations to multiple downstream network operators." ? ? > ? ? > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.net%2Fpublications%2Fdocs%2Fripe-733%2354&data=02%7C01%7CStephane.Dodeller%40swisscom.com%7C1824b65a8425487661aa08d8693dc293%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637375061263396078&sdata=vCq4%2B%2B0el3rtQXcDOhrtqCCt2cqt9HzBoPui4fc0Lyc%3D&reserved=0 ? ? > ? ? > Before making any changes, we want to be sure that we understand the intent of the policy and what the community wants us to do. Thus, we would like to hear from the Address Policy Working Group: ? ? > ? ? > - Should inetnums with these statuses be allowed to be created inside one another? ? ? > - Should there be a limit on the minimum size of a sub-allocation? ? ? > - Do we need a policy update? ? ? > ? ? > We look forward to your guidance. ? ? > ? ? > Kind regards, ? ? > -- ? ? > Petrit Hasani ? ? > Policy Officer ? ? > RIPE NCC ? ? > ? ? > ? ? > ? ? > ? ? > ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: End of address-policy-wg Digest, Vol 108, Issue 2 ************************************************* From ebais at a2b-internet.com Mon Oct 12 11:03:53 2020 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 12 Oct 2020 09:03:53 +0000 Subject: [address-policy-wg] Draft Agenda RIPE81 - virtual AP-WG Message-ID: <27327AFA-9641-4C48-80EB-178868D8D05B@a2b-internet.com> Dear working group, dear RIPE meeting folks, Below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in online on the following time slot: Wednesday, Oct 28, 10:00 - 10:45 As we only have 1 time slot, we have a packed agenda. We don?t have any open policy discussions atm, however if you have any Address Policy related policy suggestions, feel free to reach out to us. Besides the usual PDO/RIR & Registration services updates, we will also have a presentation from the RIPE NCC legal team about the topic: Seizure of the ?Right to Registration of IPv4 Addresses? for the Recovery of Money. As WG Chairs we thought it would be a good topic to discuss in the AP-WG. So make sure you are present for the session. Regards, Gert D?ring & Erik Bais, APWG chairs ---------------------------------------------------------------------- Wednesday, 10:00-10:45 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. Current Policy Topics ? Petrit Hasani ? RIPE NCC PDO - 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 80 - brief overview of new proposals (if any) C. Feedback from NCC Registration Service - Nikolas Pediaditis (+ discussion with the group) D. Presentation about the Seizure of the ?Right to Registration of IPv4 Addresses? - Ciaran Byrne ( Legal Counsel of the RIPE NCC ) Z. AOB From taiwo.oyewande88 at gmail.com Fri Oct 16 13:34:58 2020 From: taiwo.oyewande88 at gmail.com (Taiwo Oyewande) Date: Fri, 16 Oct 2020 12:34:58 +0100 Subject: [address-policy-wg] Policy Reciprocity Message-ID: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> ?Hello, I am a co-author of the Resource Transfer Policy, which is the inter-RIR transfer proposal that has just reached consensus within Afrinic, and we are reaching out to you so as to inquire about its reciprocity with RIPE. Your assessment and analysis about this matter would highly be appreciated. Please find below the proposal for your reference. [ Resource Transfer Policy Authors: Anthony Ubah & Taiwo Oyewande Submission date: 21/09/2020 Version: 2.0 Amends: CPM 5.7 1. Summary of the problem being addressed by this proposal The current policy fails to support a two-way Inter-RIR policy, thereby hindering smooth business operation, development, and growth in the region. This proposal aims to establish an efficient and business-friendly mechanism to allow number resources to be transferred from/to other regions. This proposal outlines a model in which AFRINIC can freely transfer number resources to/from other regions, i.e. RIPE NCC, APNIC, ARIN and LACNIC. This includes both IPv4 addresses and AS numbers. 2. Summary of how this proposal addresses the problem With the exhaustion of IPv4, several regions have adopted a transfer policy to accommodate the shortage of resources. Number resources are allowed to transfer within the region itself, as well as with other regions. Such practice is effective and necessary when we are facing a shortage of resources. This helps facilitate business operations while reducing prices. Such Inter-RIR transfer, however, is not yet established in AFRINIC. This hinders business operation and development within the African region. The current proposal aims to establish an efficient and business-friendly mechanism to allow number resources to be transferred from/to other regions. Before moving to illustrate how this new mechanism works, let?s take a quick look at the situation of the current Consolidated Policy Manual: In Consolidated Policy Manual updated on 22 Feb 2019, only ?IPv4 resources transfer within the AFRINIC region? is mentioned. Regarding resource transfer to other regions, only the following is mentioned: 5.5.1.1.3 If an LIR plans to exchange or transfer address space, it needs to contact AFRINIC so that the changes are properly registered. The LIR remains responsible for all the allocations registered in the AFRINIC database until they have been transferred to another LIR or returned to AFRINIC. LIR's must ensure that all policies are applied. The lack of a clear guideline of resource transfer is detrimental to the continent?s development. It makes business operation difficult and it also hinders new business from establishing in the region. Also, as Inter RIR policy is enforced in other regions, it is important that AFRINIC keeps up with other RIRs to ensure smooth operation and coordination. 3. Proposal CPM 5.7 will be modified by this proposal as follows: 5.7 IPv4 Resources resource transfer Like the other Regional Internet Registries, AFRINIC will soon exhaust its IPv4 pool. In order to meet the needs of late resource requestors, a transfer policy for IPv4 resources within and outside the region is needed. The goal of this policy is to define conditions under which transfers must occur. The policy solves the issue of an African organization needing IPv4 number resources after the exhaustion of the AFRINIC IPv4 pool or when AFRINIC can no longer satisfy the needs of such an organization. 5.7.1 Summary of the policy This policy applies to any transfer request raised by a resource holder for resource transfer to and from the AFRINIC region. 5.7.2 IPv4 resources to be transferred - must be from an existing AFRINIC or any RIR member's account or from a Legacy Resource Holder. 5.7.3. Conditions on the source of the transfer 5.7.3.1 The source must be the current and rightful holder of the IPv4 address resources registered with any RIR , and shall not be involved in any disputes as to those resources' status. 5.7.3.2 Source entities are not eligible to receive any further IPv4 allocations or assignments from AFRINIC for a period of twelve (12) months after a transfer is approved. Incoming transferred resource cannot be transferred again for a period of twelve(12) months. 5.7.3.3 There is no upper limit regarding the amount of transfer, allocation and assignment of IPv4 number resources a source entity can receive as long as the transfer request is carried out under a mutual agreement between the source and the recipient. 5.7.4. Conditions on the recipient of the transfer 5.7.4.1 A transfer from another RIR to AFRINIC requires a need-based evaluation. AFRINIC must approve the recipient's need for the IPv4 number resources. In order for an organization to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resource needs before AFRINIC. That is to say, the organization must justify and demonstrate before AFRINIC its initial/additional allocation/assignment usage, as applicable, according to the policies in force. A transfer from AFRINIC to another RIR must follow the relevant policies. 5.7.4.2 The recipient must be an AFRINIC or any RIR member, legacy holders in any region 5.7.4.3 Incoming transferred legacy resources will still be regarded as legacy resources.] We are looking forward to hearing from you. Regards, Taiwo O -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Mon Oct 19 15:51:21 2020 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 19 Oct 2020 13:51:21 +0000 Subject: [address-policy-wg] FW: Policy Reciprocity In-Reply-To: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> Message-ID: Hi Petrit & Taiwo, Petrit, could you have a look at the following question from Taiwo in regards to the Afrinic policy proposal reciprocity with the current RIPE Transfer Policy. To Taiwo, Personally I would argue if reciprocity should be desired for the Afrinic region, as long as AFRINIC still holds IP numbers to be handed out. I personally would prefer the AFRINIC inter-rir transfer policy to be incoming from other RIR?s only, to avoid the AFRINIC space to be removed from the region. ( As I think Afrinic would need them more to develop its own inter regional growth. ) Am I correct to assume that Afrinic at the current distribution rate would have about 30 months of IP space left ? So perhaps opening the bi-directional inter-rir transfers, could start once the AFRINIC region actually has no space left in its free pool. In the RIPE region, there is a 24 month transfer limitation on the resource that was transferred itself, there is no further limitation on either the leaving (source) or receiving (target) entity to engage in other transactions. On the point : * 5.7.4.2 The recipient must be an AFRINIC or any RIR member, legacy holders in any region The AFRINIC legal team might have to look if this is phrased correctly, as you can?t (shouldn?t be able ) to move Afrinic Allocated space to a Legacy space holder.. Afrinic allocated space should only be able to move to any of the other RIR members. Not directly to a Legacy holder. Legacy space registered in the Afrinic region could go to any organisation, regardless if they are a RIR member. There might be other contractual requirements required in the receiving RIR.. as the RIPE legacy policy would explain for the RIPE region. I can see the intention, but that is not what the policy states. (or how I read it..) And on point : * 5.7.4.3 Incoming transferred legacy resources will still be regarded as legacy resources.] If you would remove the word incoming, it would provide a more bi-directional way of looking at it, from an AFRINIC perspective. And still leave it to the receiving RIR to apply their own Legacy ?policy? Regards, Erik Bais Co-chair of AP-WG https://www.ripe.net/publications/docs/ripe-682 - RIPE Transfer policy ( including intra and inter-rir transfers ) https://www.ripe.net/publications/docs/ripe-639 - RIPE NCC Services to Legacy Internet Resource Holders ( aka the RIPE Legacy services policy ) https://www.ripe.net/manage-ips-and-asns/legacy-resources/ripe-ncc-services-to-legacy-internet-resource-holders ( Services provided based on the type of contractual agreement with the RIPE NCC ) From: address-policy-wg on behalf of Taiwo Oyewande Date: Friday 16 October 2020 at 13:35 To: "address-policy-wg at ripe.net" Cc: Anthony Ubah Subject: [address-policy-wg] Policy Reciprocity Hello, I am a co-author of the Resource Transfer Policy, which is the inter-RIR transfer proposal that has just reached consensus within Afrinic, and we are reaching out to you so as to inquire about its reciprocity with RIPE. Your assessment and analysis about this matter would highly be appreciated. Please find below the proposal for your reference. [ Resource Transfer Policy Authors: Anthony Ubah & Taiwo Oyewande Submission date: 21/09/2020 Version: 2.0 Amends: CPM 5.7 1. Summary of the problem being addressed by this proposal The current policy fails to support a two-way Inter-RIR policy, thereby hindering smooth business operation, development, and growth in the region. This proposal aims to establish an efficient and business-friendly mechanism to allow number resources to be transferred from/to other regions. This proposal outlines a model in which AFRINIC can freely transfer number resources to/from other regions, i.e. RIPE NCC, APNIC, ARIN and LACNIC. This includes both IPv4 addresses and AS numbers. 2. Summary of how this proposal addresses the problem With the exhaustion of IPv4, several regions have adopted a transfer policy to accommodate the shortage of resources. Number resources are allowed to transfer within the region itself, as well as with other regions. Such practice is effective and necessary when we are facing a shortage of resources. This helps facilitate business operations while reducing prices. Such Inter-RIR transfer, however, is not yet established in AFRINIC. This hinders business operation and development within the African region. The current proposal aims to establish an efficient and business-friendly mechanism to allow number resources to be transferred from/to other regions. Before moving to illustrate how this new mechanism works, let?s take a quick look at the situation of the current Consolidated Policy Manual: In Consolidated Policy Manual updated on 22 Feb 2019, only ?IPv4 resources transfer within the AFRINIC region? is mentioned. Regarding resource transfer to other regions, only the following is mentioned: 5.5.1.1.3 If an LIR plans to exchange or transfer address space, it needs to contact AFRINIC so that the changes are properly registered. The LIR remains responsible for all the allocations registered in the AFRINIC database until they have been transferred to another LIR or returned to AFRINIC. LIR's must ensure that all policies are applied. The lack of a clear guideline of resource transfer is detrimental to the continent?s development. It makes business operation difficult and it also hinders new business from establishing in the region. Also, as Inter RIR policy is enforced in other regions, it is important that AFRINIC keeps up with other RIRs to ensure smooth operation and coordination. 3. Proposal CPM 5.7 will be modified by this proposal as follows: 5.7 IPv4 Resources resource transfer Like the other Regional Internet Registries, AFRINIC will soon exhaust its IPv4 pool. In order to meet the needs of late resource requestors, a transfer policy for IPv4 resources within and outside the region is needed. The goal of this policy is to define conditions under which transfers must occur. The policy solves the issue of an African organization needing IPv4 number resources after the exhaustion of the AFRINIC IPv4 pool or when AFRINIC can no longer satisfy the needs of such an organization. 5.7.1 Summary of the policy This policy applies to any transfer request raised by a resource holder for resource transfer to and from the AFRINIC region. 5.7.2 IPv4 resources to be transferred - must be from an existing AFRINIC or any RIR member's account or from a Legacy Resource Holder. 5.7.3. Conditions on the source of the transfer 5.7.3.1 The source must be the current and rightful holder of the IPv4 address resources registered with any RIR , and shall not be involved in any disputes as to those resources' status. 5.7.3.2 Source entities are not eligible to receive any further IPv4 allocations or assignments from AFRINIC for a period of twelve (12) months after a transfer is approved. Incoming transferred resource cannot be transferred again for a period of twelve(12) months. 5.7.3.3 There is no upper limit regarding the amount of transfer, allocation and assignment of IPv4 number resources a source entity can receive as long as the transfer request is carried out under a mutual agreement between the source and the recipient. 5.7.4. Conditions on the recipient of the transfer 5.7.4.1 A transfer from another RIR to AFRINIC requires a need-based evaluation. AFRINIC must approve the recipient's need for the IPv4 number resources. In order for an organization to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resource needs before AFRINIC. That is to say, the organization must justify and demonstrate before AFRINIC its initial/additional allocation/assignment usage, as applicable, according to the policies in force. A transfer from AFRINIC to another RIR must follow the relevant policies. 5.7.4.2 The recipient must be an AFRINIC or any RIR member, legacy holders in any region 5.7.4.3 Incoming transferred legacy resources will still be regarded as legacy resources.] We are looking forward to hearing from you. Regards, Taiwo O -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Mon Oct 19 15:59:19 2020 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 19 Oct 2020 15:59:19 +0200 Subject: [address-policy-wg] FW: Policy Reciprocity Message-ID: <5F8604B4-16F0-41E9-8B33-675B972C9917@consulintel.es> Hi Erik, Regarding your response on reciprocity: If we do that in AFRINIC, then, there is no reciprocity with ARIN, which is the bigger ?donor?. I already tried several models, for both LACNIC and AFRINIC, and they didn?t work out. Finally, making a full reciprocal proposal in LACNIC worked and it was implemented already since last July. I also included a ?security belt? in the AFRINIC proposal so the board can ?control? if anything is going wrong by six consecutive months, to stop the policy ? the community was happy initially with that, but later on, there were to other competitive proposals that make the people unhappy again ? Point 5.7.4.3 is broken, the idea was ?incoming transferred legacy resources will no longer be regarded as legacy?, because that?s what we have now already for intra-RIR (and this policy motifies that to become intra and inter). Regards, Jordi @jordipalet El 19/10/20 15:52, "address-policy-wg en nombre de Erik Bais" escribi?: Hi Petrit & Taiwo, Petrit, could you have a look at the following question from Taiwo in regards to the Afrinic policy proposal reciprocity with the current RIPE Transfer Policy. To Taiwo, Personally I would argue if reciprocity should be desired for the Afrinic region, as long as AFRINIC still holds IP numbers to be handed out. I personally would prefer the AFRINIC inter-rir transfer policy to be incoming from other RIR?s only, to avoid the AFRINIC space to be removed from the region. ( As I think Afrinic would need them more to develop its own inter regional growth. ) Am I correct to assume that Afrinic at the current distribution rate would have about 30 months of IP space left ? So perhaps opening the bi-directional inter-rir transfers, could start once the AFRINIC region actually has no space left in its free pool. In the RIPE region, there is a 24 month transfer limitation on the resource that was transferred itself, there is no further limitation on either the leaving (source) or receiving (target) entity to engage in other transactions. On the point : ? 5.7.4.2 The recipient must be an AFRINIC or any RIR member, legacy holders in any region The AFRINIC legal team might have to look if this is phrased correctly, as you can?t (shouldn?t be able ) to move Afrinic Allocated space to a Legacy space holder.. Afrinic allocated space should only be able to move to any of the other RIR members. Not directly to a Legacy holder. Legacy space registered in the Afrinic region could go to any organisation, regardless if they are a RIR member. There might be other contractual requirements required in the receiving RIR.. as the RIPE legacy policy would explain for the RIPE region. I can see the intention, but that is not what the policy states. (or how I read it..) And on point : ? 5.7.4.3 Incoming transferred legacy resources will still be regarded as legacy resources.] If you would remove the word incoming, it would provide a more bi-directional way of looking at it, from an AFRINIC perspective. And still leave it to the receiving RIR to apply their own Legacy ?policy? Regards, Erik Bais Co-chair of AP-WG https://www.ripe.net/publications/docs/ripe-682 - RIPE Transfer policy ( including intra and inter-rir transfers ) https://www.ripe.net/publications/docs/ripe-639 - RIPE NCC Services to Legacy Internet Resource Holders ( aka the RIPE Legacy services policy ) https://www.ripe.net/manage-ips-and-asns/legacy-resources/ripe-ncc-services-to-legacy-internet-resource-holders ( Services provided based on the type of contractual agreement with the RIPE NCC ) From: address-policy-wg on behalf of Taiwo Oyewande Date: Friday 16 October 2020 at 13:35 To: "address-policy-wg at ripe.net" Cc: Anthony Ubah Subject: [address-policy-wg] Policy Reciprocity Hello, I am a co-author of the Resource Transfer Policy, which is the inter-RIR transfer proposal that has just reached consensus within Afrinic, and we are reaching out to you so as to inquire about its reciprocity with RIPE. Your assessment and analysis about this matter would highly be appreciated. Please find below the proposal for your reference. [ Resource Transfer Policy Authors: Anthony Ubah & Taiwo Oyewande Submission date: 21/09/2020 Version: 2.0 Amends: CPM 5.7 1. Summary of the problem being addressed by this proposal The current policy fails to support a two-way Inter-RIR policy, thereby hindering smooth business operation, development, and growth in the region. This proposal aims to establish an efficient and business-friendly mechanism to allow number resources to be transferred from/to other regions. This proposal outlines a model in which AFRINIC can freely transfer number resources to/from other regions, i.e. RIPE NCC, APNIC, ARIN and LACNIC. This includes both IPv4 addresses and AS numbers. 2. Summary of how this proposal addresses the problem With the exhaustion of IPv4, several regions have adopted a transfer policy to accommodate the shortage of resources. Number resources are allowed to transfer within the region itself, as well as with other regions. Such practice is effective and necessary when we are facing a shortage of resources. This helps facilitate business operations while reducing prices. Such Inter-RIR transfer, however, is not yet established in AFRINIC. This hinders business operation and development within the African region. The current proposal aims to establish an efficient and business-friendly mechanism to allow number resources to be transferred from/to other regions. Before moving to illustrate how this new mechanism works, let?s take a quick look at the situation of the current Consolidated Policy Manual: In Consolidated Policy Manual updated on 22 Feb 2019, only ?IPv4 resources transfer within the AFRINIC region? is mentioned. Regarding resource transfer to other regions, only the following is mentioned: 5.5.1.1.3 If an LIR plans to exchange or transfer address space, it needs to contact AFRINIC so that the changes are properly registered. The LIR remains responsible for all the allocations registered in the AFRINIC database until they have been transferred to another LIR or returned to AFRINIC. LIR's must ensure that all policies are applied. The lack of a clear guideline of resource transfer is detrimental to the continent?s development. It makes business operation difficult and it also hinders new business from establishing in the region. Also, as Inter RIR policy is enforced in other regions, it is important that AFRINIC keeps up with other RIRs to ensure smooth operation and coordination. 3. Proposal CPM 5.7 will be modified by this proposal as follows: 5.7 IPv4 Resources resource transfer Like the other Regional Internet Registries, AFRINIC will soon exhaust its IPv4 pool. In order to meet the needs of late resource requestors, a transfer policy for IPv4 resources within and outside the region is needed. The goal of this policy is to define conditions under which transfers must occur. The policy solves the issue of an African organization needing IPv4 number resources after the exhaustion of the AFRINIC IPv4 pool or when AFRINIC can no longer satisfy the needs of such an organization. 5.7.1 Summary of the policy This policy applies to any transfer request raised by a resource holder for resource transfer to and from the AFRINIC region. 5.7.2 IPv4 resources to be transferred - must be from an existing AFRINIC or any RIR member's account or from a Legacy Resource Holder. 5.7.3. Conditions on the source of the transfer 5.7.3.1 The source must be the current and rightful holder of the IPv4 address resources registered with any RIR , and shall not be involved in any disputes as to those resources' status. 5.7.3.2 Source entities are not eligible to receive any further IPv4 allocations or assignments from AFRINIC for a period of twelve (12) months after a transfer is approved. Incoming transferred resource cannot be transferred again for a period of twelve(12) months. 5.7.3.3 There is no upper limit regarding the amount of transfer, allocation and assignment of IPv4 number resources a source entity can receive as long as the transfer request is carried out under a mutual agreement between the source and the recipient. 5.7.4. Conditions on the recipient of the transfer 5.7.4.1 A transfer from another RIR to AFRINIC requires a need-based evaluation. AFRINIC must approve the recipient's need for the IPv4 number resources. In order for an organization to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resource needs before AFRINIC. That is to say, the organization must justify and demonstrate before AFRINIC its initial/additional allocation/assignment usage, as applicable, according to the policies in force. A transfer from AFRINIC to another RIR must follow the relevant policies. 5.7.4.2 The recipient must be an AFRINIC or any RIR member, legacy holders in any region 5.7.4.3 Incoming transferred legacy resources will still be regarded as legacy resources.] We are looking forward to hearing from you. Regards, Taiwo O ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phasani at ripe.net Tue Oct 20 11:38:45 2020 From: phasani at ripe.net (Petrit Hasani) Date: Tue, 20 Oct 2020 11:38:45 +0200 Subject: [address-policy-wg] Policy Reciprocity In-Reply-To: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> Message-ID: Dear Taiwo and Address Policy WG, Thank you for submitting a request to the RIPE Address Policy Working Group. Clarifying your message for the community: This version of the proposal ?Resource Transfer Policy? (AFPUB-2019-V4-003) was published yesterday on the AFRINIC website as version 4, submitted on 5th of October 2020: https://afrinic.net/policy/proposals/2019-v4-003-d4#proposal Even though, as Taiwo states, it was initially announced that the proposal had reached consensus in AFRINIC, the working group chairs seem to have allowed one more week of discussion: https://lists.afrinic.net/pipermail/rpd/2020/011774.html The check for policy reciprocity for inter-RIR transfers is coordinated between the RIRs. There are some sections in this proposal which are not very clear and seem to impose some restriction on our own policies. We would need a bit more clarification on the intent of some of these parts before we can provide a final answer. For example, paragraph 5.7.4.2 does not take into account that we have resource holders in our service region that are not members of the RIPE NCC. We will ask AFRINIC for feedback on these points and we will provide them with our response. You can contact the AFRINIC policy officer for an update. When another RIR approves a policy proposal that impacts other RIRs (such as inter-RIR transfers with AFRINIC), we will inform the RIPE community accordingly. Kind regards, -- Petrit Hasani Policy Officer RIPE NCC > On 16 Oct 2020, at 13:34, Taiwo Oyewande wrote: > > ?Hello, > > I am a co-author of the Resource Transfer Policy, which is the inter-RIR transfer proposal that has just reached consensus within Afrinic, and we are reaching out to you so as to inquire about its reciprocity with RIPE. > > Your assessment and analysis about this matter would highly be appreciated. > > Please find below the proposal for your reference. > > [ > > Resource Transfer Policy > > Authors: Anthony Ubah & Taiwo Oyewande > > Submission date: 21/09/2020 > > Version: 2.0 > > Amends: CPM 5.7 > > > 1. Summary of the problem being addressed by this proposal > > The current policy fails to support a two-way Inter-RIR policy, thereby hindering smooth business operation, development, and growth in the region. This proposal aims to establish an efficient and business-friendly mechanism to allow number resources to be transferred from/to other regions. This proposal outlines a model in which AFRINIC can freely transfer number resources to/from other regions, i.e. RIPE NCC, APNIC, ARIN and LACNIC. This includes both IPv4 addresses and AS numbers. > > 2. Summary of how this proposal addresses the problem > > With the exhaustion of IPv4, several regions have adopted a transfer policy to accommodate the shortage of resources. Number resources are allowed to transfer within the region itself, as well as with other regions. > Such practice is effective and necessary when we are facing a shortage of resources. This helps facilitate business operations while reducing prices. > Such Inter-RIR transfer, however, is not yet established in AFRINIC. This hinders business operation and development within the African region. The current proposal aims to establish an efficient and business-friendly mechanism to allow number resources to be transferred from/to other regions. Before moving to illustrate how this new mechanism works, let?s take a quick look at the situation of the current Consolidated Policy Manual: > In Consolidated Policy Manual updated on 22 Feb 2019, only ?IPv4 resources transfer within the AFRINIC region? is mentioned. > Regarding resource transfer to other regions, only the following is mentioned: > 5.5.1.1.3 If an LIR plans to exchange or transfer address space, it needs to contact AFRINIC so that the changes are properly registered. > The LIR remains responsible for all the allocations registered in the AFRINIC database until they have been transferred to another LIR or returned to AFRINIC. LIR's must ensure that all policies are applied. > The lack of a clear guideline of resource transfer is detrimental to the continent?s development. It makes business operation difficult and it also hinders new business from establishing in the region. > Also, as Inter RIR policy is enforced in other regions, it is important that AFRINIC keeps up with other RIRs to ensure smooth operation and coordination. > > 3. Proposal > > CPM 5.7 will be modified by this proposal as follows: > > 5.7 IPv4 Resources resource transfer > > Like the other Regional Internet Registries, AFRINIC will soon exhaust its IPv4 pool. In order to meet the needs of late resource requestors, a transfer policy for IPv4 resources within and outside the region is needed. The goal of this policy is to define conditions under which transfers must occur. The policy solves the issue of an African organization needing IPv4 number resources after the exhaustion of the AFRINIC IPv4 pool or when AFRINIC can no longer satisfy the needs of such an organization. > > 5.7.1 Summary of the policy > > This policy applies to any transfer request raised by a resource holder for resource transfer to and from the AFRINIC region. > > 5.7.2 IPv4 resources to be transferred - must be from an existing AFRINIC or any RIR member's account or from a Legacy Resource Holder. > > 5.7.3. Conditions on the source of the transfer > > 5.7.3.1 The source must be the current and rightful holder of the IPv4 address resources registered with any RIR , and shall not be involved in any disputes as to those resources' status. > > 5.7.3.2 Source entities are not eligible to receive any further IPv4 allocations or assignments from AFRINIC for a period of twelve (12) months after a transfer is approved. Incoming transferred resource cannot be transferred again for a period of twelve(12) months. > > 5.7.3.3 There is no upper limit regarding the amount of transfer, allocation and assignment of IPv4 number resources a source entity can receive as long as the transfer request is carried out under a mutual agreement between the source and the recipient. > > 5.7.4. Conditions on the recipient of the transfer > > 5.7.4.1 A transfer from another RIR to AFRINIC requires a need-based evaluation. AFRINIC must approve the recipient's need for the IPv4 number resources. In order for an organization to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resource needs before AFRINIC. That is to say, the organization must justify and demonstrate before AFRINIC its initial/additional allocation/assignment usage, as applicable, according to the policies in force. > > A transfer from AFRINIC to another RIR must follow the relevant policies. > > 5.7.4.2 The recipient must be an AFRINIC or any RIR member, legacy holders in any region > > 5.7.4.3 Incoming transferred legacy resources will still be regarded as legacy resources.] > > > > We are looking forward to hearing from you. > > Regards, > > Taiwo O -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From ripedenis at yahoo.co.uk Tue Oct 20 20:30:10 2020 From: ripedenis at yahoo.co.uk (ripedenis at yahoo.co.uk) Date: Tue, 20 Oct 2020 18:30:10 +0000 (UTC) Subject: [address-policy-wg] FW: Policy Reciprocity In-Reply-To: References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> Message-ID: <1441248791.2496412.1603218610511@mail.yahoo.com> HI Erik Legacy space is a pain and should be normalised at every opportunity. Because of the market this has become a huge financial asset. If the holders want to cash it in, once it is sold it should lose this special, untouchable status. The transfer policies are their means to sell it. These policies should insist on sold legacy space being normalised and subject to all RIR policies. cheersdenis? And on point : - 5.7.4.3?Incoming transferred legacy resources will still be regarded as legacy resources.] ? If you would remove the word incoming, it would provide a more bi-directional way of looking at it, from an AFRINIC perspective. And still leave it to the receiving RIR to apply their own Legacy ?policy? ? Regards, Erik Bais ? Co-chair of AP-WG ? https://www.ripe.net/publications/docs/ripe-682 ??????????? - RIPE Transfer policy ( including intra and inter-rir transfers ) https://www.ripe.net/publications/docs/ripe-639 ??????????? - RIPE NCC Services to Legacy Internet Resource Holders? ( aka the RIPE Legacy services policy ) https://www.ripe.net/manage-ips-and-asns/legacy-resources/ripe-ncc-services-to-legacy-internet-resource-holders ?( Services provided based on the type of contractual agreement with the RIPE NCC ) ? ? From: address-policy-wg on behalf of Taiwo Oyewande Date: Friday 16 October 2020 at 13:35 To: "address-policy-wg at ripe.net" Cc: Anthony Ubah Subject: [address-policy-wg] Policy Reciprocity ? Hello, I am a co-author of the Resource Transfer Policy, which is the inter-RIR transfer proposal that has just reached consensus within Afrinic, and we are reaching out to you so as to inquire about its reciprocity with RIPE. Your assessment and analysis about this matter would highly be appreciated. Please find below the proposal for your reference. [ ? Resource Transfer Policy Authors: Anthony Ubah & Taiwo Oyewande Submission date: 21/09/2020 Version: 2.0 Amends: CPM 5.7 ? 1. Summary of the problem being addressed by this proposal The current policy fails to support a two-way Inter-RIR policy, thereby hindering smooth business operation, development, and growth in the region. This proposal aims to establish an efficient and business-friendly mechanism to allow number resources to be transferred from/to other regions. This proposal outlines a model in which AFRINIC can freely transfer number resources to/from other regions, i.e. RIPE NCC, APNIC, ARIN and LACNIC. This includes both IPv4 addresses and AS numbers. ? 2. Summary of how this proposal addresses the problem With the exhaustion of IPv4, several regions have adopted a transfer policy to accommodate the shortage of resources. Number resources are allowed to transfer within the region itself, as well as with other regions. Such practice is effective and necessary when we are facing a shortage of resources. This helps facilitate business operations while reducing prices. Such Inter-RIR transfer, however, is not yet established in AFRINIC. This hinders business operation and development within the African region. The current proposal aims to establish an efficient and business-friendly mechanism to allow number resources to be transferred from/to other regions. Before moving to illustrate how this new mechanism works, let?s take a quick look at the situation of the current Consolidated Policy Manual: In Consolidated Policy Manual updated on 22 Feb 2019, only ?IPv4 resources transfer within the AFRINIC region? is mentioned. Regarding resource transfer to other regions, only the following is mentioned: 5.5.1.1.3?If an LIR plans to exchange or transfer address space, it needs to contact AFRINIC so that the changes are properly registered. The LIR remains responsible for all the allocations registered in the AFRINIC database until they have been transferred to another LIR or returned to AFRINIC. LIR's must ensure that all policies are applied. The lack of a clear guideline of resource transfer is detrimental to the continent?s development. It makes business operation difficult and it also hinders new business from establishing in the region. Also, as Inter RIR policy is enforced in other regions, it is important that AFRINIC keeps up with other RIRs to ensure smooth operation and coordination. ? 3. Proposal CPM 5.7 will be modified by this proposal as follows:? ? 5.7 IPv4 Resources resource transfer Like the other Regional Internet Registries, AFRINIC will soon exhaust its IPv4 pool. In order to meet the needs of late resource requestors, a transfer policy for IPv4 resources within and outside the region is needed. The goal of this policy is to define conditions under which transfers must occur. The policy solves the issue of an African organization needing IPv4 number resources after the exhaustion of the AFRINIC IPv4 pool or when AFRINIC can no longer satisfy the needs of such an organization. 5.7.1?Summary of the policy This policy applies to any transfer request raised by a resource holder for resource transfer to and from the AFRINIC region. 5.7.2??IPv4 resources to be transferred - must be from an existing AFRINIC or any RIR member's account or from a Legacy Resource Holder. 5.7.3. Conditions on the source of the transfer 5.7.3.1?The source must be the current and rightful holder of the IPv4 address resources registered with any RIR , and shall not be involved in any disputes as to those resources' status. 5.7.3.2 ?Source entities are not eligible to receive any further IPv4 allocations or assignments from AFRINIC for a period of twelve (12) months after a transfer is approved. Incoming transferred resource cannot be transferred again for a period of twelve(12) months. 5.7.3.3?There is no upper limit regarding the amount of transfer, allocation and assignment of IPv4 number resources a source entity can receive as long as the transfer request is carried out under a mutual agreement between the source and the recipient. 5.7.4. Conditions on the recipient of the transfer 5.7.4.1?A transfer from another RIR to AFRINIC requires a need-based evaluation. AFRINIC must approve the recipient's need for the IPv4 number resources. In order for an organization to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resource needs before AFRINIC. That is to say, the organization must justify and demonstrate before AFRINIC its initial/additional allocation/assignment usage, as applicable, according to the policies in force. A transfer from AFRINIC to another RIR must follow the relevant policies. 5.7.4.2?? The recipient must be an AFRINIC or any RIR member, legacy holders in any region 5.7.4.3?Incoming transferred legacy resources will still be regarded as legacy resources.] We are looking forward to hearing from you. Regards, Taiwo O -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Tue Oct 20 23:46:59 2020 From: jim at rfc1035.com (Jim Reid) Date: Tue, 20 Oct 2020 22:46:59 +0100 Subject: [address-policy-wg] FW: Policy Reciprocity In-Reply-To: <1441248791.2496412.1603218610511@mail.yahoo.com> References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> <1441248791.2496412.1603218610511@mail.yahoo.com> Message-ID: <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> > On 20 Oct 2020, at 19:30, ripedenis--- via address-policy-wg wrote: > > Legacy space is a pain and should be normalised at every opportunity. Because of the market this has become a huge financial asset. If the holders want to cash it in, once it is sold it should lose this special, untouchable status. Why? What?s the rationale for that? What good will it achieve? What problem does that fix? If your concern is it?s too much of a resource drain on an RIR to track these transfers, then let?s first quantify the problem before deciding how to solve it. My gut feel is those overheads are marginal and also a tolerable part of doing business. It may well be less hassle to just let those costs be lost in the noise than trying to invent some sort of cost recovery scheme. Which would of course provide lots of opportunities for shed-painting and rat-holing. > The transfer policies are their means to sell it. These policies should insist on sold legacy space being normalised and subject to all RIR policies. Denis, I *strongly* disagree. Legacy space is like an RS-232 lead*: an annoyance from a bygone era that will always be with us. :-) We just have to suck it up. Unless of course one day the Internet stops using IPv4 and everyone?s on IPv6. [Who?s sniggering at the back!?!] * Kids, ask your grandparents... What?s the justification for "normalised at every opportunity? and what do you mean by that anyway? Forcing transferred legacy space to be subject to RIR policies is utterly wrong. First, the space was issued before the RIR system existed. It shouldn?t be subject to what amounts to retrospective legislation. That probably wouldn?t survive the flimsiest of challenges in the courts. Besides, we agreed that principle during the ERX exercise some years ago when European legacy space moved from ARIN to the NCC. Those legacy holders were not made to pay NCC fees or had their holdings of legacy space influence how their future IPv4 allocation/assignment requests got handled. Why go back on this principle now? What?s changed since then to justify that? Next, if transfers involving legacy space were forced to be subject to RIR policies, you?d just drive those transfers underground. Or the parties involved would contrive ?mergers? and ?reorganisations? to conceal the truth that addresses changed hands. That would be bad in far too many ways to list here. What?s more important, maintaining an accurate database of address space holders or upholding the purity of some doctrine about nearly dead IPv4 address policies that are irrelevant to a post-v4 world? FWIW we abandoned that notion of ideological purity when the LIR transfer policies were introduced. The consensus then (and now) was maintaining accurate info about who held address resources was more important than following a no longer credible policy of forcing LIRs to return their surplus space to the NCC for redistribution. Finally, suppose the recipient of a legacy transfer is not an LIR. Your suggestion implies they?d have to become one. That?ll attract the attention of legislators, regulators and the competition authorities faster than you can say anti-trust lawsuit. From shane at time-travellers.org Wed Oct 21 09:17:22 2020 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 21 Oct 2020 09:17:22 +0200 Subject: [address-policy-wg] FW: Policy Reciprocity In-Reply-To: <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> <1441248791.2496412.1603218610511@mail.yahoo.com> <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> Message-ID: Jim, On 20/10/2020 23.46, Jim Reid wrote: > > >> On 20 Oct 2020, at 19:30, ripedenis--- via address-policy-wg wrote: >> >> Legacy space is a pain and should be normalised at every opportunity. Because of the market this has become a huge financial asset. If the holders want to cash it in, once it is sold it should lose this special, untouchable status. > > Why? What?s the rationale for that? What good will it achieve? What problem does that fix? I think you have it completely backwards. Every single question you ask here should apply to all address held. If there is a rationale for any of the RIPE policies, then that rationale should apply uniformly. Holding an Internet number resource means cooperating with other holders of Internet number resources. The RIR system in general and the RIPE policies in our region describe the ground rules for this cooperation. Just because you started peering before things got organized doesn't mean that you shouldn't have to follow the same set of rules that modern networks operate under. I thought it was a mistake to treat legacy space differently when I first I learned about it 22 years ago, and I still think that it is a mistake. Cheers, -- Shane From erik at bais.name Wed Oct 21 09:20:57 2020 From: erik at bais.name (Erik Bais) Date: Wed, 21 Oct 2020 07:20:57 +0000 Subject: [address-policy-wg] FW: Policy Reciprocity In-Reply-To: <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> <1441248791.2496412.1603218610511@mail.yahoo.com> <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> Message-ID: <8052382E-C22F-4D2F-8F90-48A85DCCA487@bais.name> Thanks Jim, I couldn't have said it better myself. Also, with the Legacy transfers, there needs to be proper documentation to make sure all records from the past match up AND there is going to be an update in the RIR registry that will make sure the records are up to date. Updating the registry with accurate information while we do changes in the database on the actual owner and user of the Legacy space is a huge plus for the accuracy. Erik ?On 20/10/2020, 23:47, "address-policy-wg on behalf of Jim Reid" wrote: > On 20 Oct 2020, at 19:30, ripedenis--- via address-policy-wg wrote: > > Legacy space is a pain and should be normalised at every opportunity. Because of the market this has become a huge financial asset. If the holders want to cash it in, once it is sold it should lose this special, untouchable status. Why? What?s the rationale for that? What good will it achieve? What problem does that fix? If your concern is it?s too much of a resource drain on an RIR to track these transfers, then let?s first quantify the problem before deciding how to solve it. My gut feel is those overheads are marginal and also a tolerable part of doing business. It may well be less hassle to just let those costs be lost in the noise than trying to invent some sort of cost recovery scheme. Which would of course provide lots of opportunities for shed-painting and rat-holing. > The transfer policies are their means to sell it. These policies should insist on sold legacy space being normalised and subject to all RIR policies. Denis, I *strongly* disagree. Legacy space is like an RS-232 lead*: an annoyance from a bygone era that will always be with us. :-) We just have to suck it up. Unless of course one day the Internet stops using IPv4 and everyone?s on IPv6. [Who?s sniggering at the back!?!] * Kids, ask your grandparents... What?s the justification for "normalised at every opportunity? and what do you mean by that anyway? Forcing transferred legacy space to be subject to RIR policies is utterly wrong. First, the space was issued before the RIR system existed. It shouldn?t be subject to what amounts to retrospective legislation. That probably wouldn?t survive the flimsiest of challenges in the courts. Besides, we agreed that principle during the ERX exercise some years ago when European legacy space moved from ARIN to the NCC. Those legacy holders were not made to pay NCC fees or had their holdings of legacy space influence how their future IPv4 allocation/assignment requests got handled. Why go back on this principle now? What?s changed since then to justify that? Next, if transfers involving legacy space were forced to be subject to RIR policies, you?d just drive those transfers underground. Or the parties involved would contrive ?mergers? and ?reorganisations? to conceal the truth that addresses changed hands. That would be bad in far too many ways to list here. What?s more important, maintaining an accurate database of address space holders or upholding the purity of some doctrine about nearly dead IPv4 address policies that are irrelevant to a post-v4 world? FWIW we abandoned that notion of ideological purity when the LIR transfer policies were introduced. The consensus then (and now) was maintaining accurate info about who held address resources was more important than following a no longer credible policy of forcing LIRs to return their surplus space to the NCC for redistribution. Finally, suppose the recipient of a legacy transfer is not an LIR. Your suggestion implies they?d have to become one. That?ll attract the attention of legislators, regulators and the competition authorities faster than you can say anti-trust lawsuit. From jim at rfc1035.com Wed Oct 21 10:32:47 2020 From: jim at rfc1035.com (Jim Reid) Date: Wed, 21 Oct 2020 09:32:47 +0100 Subject: [address-policy-wg] FW: Policy Reciprocity In-Reply-To: References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> <1441248791.2496412.1603218610511@mail.yahoo.com> <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> Message-ID: <0D458FEE-D77B-4FEA-B602-52D69761D006@rfc1035.com> > On 21 Oct 2020, at 08:17, Shane Kerr wrote: > > If there is a rationale for any of the RIPE policies, then that rationale should apply uniformly. ONLY to the resources that were issued under those policies. Frankly, it?s about time to stop obsessing about policies (for IPv4?? sheesh!!) and pay attention to outcomes. > I thought it was a mistake to treat legacy space differently when I first I learned about it 22 years ago, and I still think that it is a mistake. Fair enough Shane. [Though I don?t agree legacy space is/was a mistake.] However nobody can rewind history. So until someone invents time travel, we just have to live with what you think was a mistake. From jordi.palet at consulintel.es Wed Oct 21 11:07:04 2020 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 21 Oct 2020 11:07:04 +0200 Subject: [address-policy-wg] FW: Policy Reciprocity In-Reply-To: <0D458FEE-D77B-4FEA-B602-52D69761D006@rfc1035.com> References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> <1441248791.2496412.1603218610511@mail.yahoo.com> <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> <0D458FEE-D77B-4FEA-B602-52D69761D006@rfc1035.com> Message-ID: <61241A67-6AF4-442F-B4EA-99DDE2513C76@consulintel.es> I agree with Shane here. We shall correct mistakes ASAP. Legacy was a mistake, just because we didn't have the RIR system before, nothing else. It was not a conscious decision, nobody understood at that time that Internet as a "global" thing will need those resources and will become scarce. It is not fair that legacy holders are not bind to policies and services (and their cost) from the RIRs the same way as non-legacy. We "rewind history" in real life all the time. There are laws (and customs) that as time passes, we discover that were wrong or broken or need to be adapted to new times, and we change them, sometimes we need to compensate for the law change, or give some "timeout" before making the new law in-force, but we do it. Yes, somebody can say it is not fair, but it is also not fair the other way around (it is even more unfair). Transfers are a way to correct that, as it has been said (and done in other regions). And every day it has less sense to keep the resources legacy: you need other resources from the RIR (like IPv6, other ASN, etc.), so then you sign the service agreement. RIPE region is a bit special on that, in the sense that we have a single fee for everything, but in other regions is not the same way, and it is somehow proportional to the "amount" of resources you hold. I also think that's unfair. Of course, that's a different discussion ... Could you imagine a country that charges the same "single flat-rate tax" to every "family" or "citizen" regardless of having different income? Regards, Jordi @jordipalet ?El 21/10/20 10:33, "address-policy-wg en nombre de Jim Reid" escribi?: > On 21 Oct 2020, at 08:17, Shane Kerr wrote: > > If there is a rationale for any of the RIPE policies, then that rationale should apply uniformly. ONLY to the resources that were issued under those policies. Frankly, it?s about time to stop obsessing about policies (for IPv4?? sheesh!!) and pay attention to outcomes. > I thought it was a mistake to treat legacy space differently when I first I learned about it 22 years ago, and I still think that it is a mistake. Fair enough Shane. [Though I don?t agree legacy space is/was a mistake.] However nobody can rewind history. So until someone invents time travel, we just have to live with what you think was a mistake. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jim at rfc1035.com Wed Oct 21 12:16:29 2020 From: jim at rfc1035.com (Jim Reid) Date: Wed, 21 Oct 2020 11:16:29 +0100 Subject: [address-policy-wg] fairness and legacy resources In-Reply-To: <61241A67-6AF4-442F-B4EA-99DDE2513C76@consulintel.es> References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> <1441248791.2496412.1603218610511@mail.yahoo.com> <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> <0D458FEE-D77B-4FEA-B602-52D69761D006@rfc1035.com> <61241A67-6AF4-442F-B4EA-99DDE2513C76@consulintel.es> Message-ID: <8D7725A9-F87D-4E66-9F1C-FFE9445C2BB6@rfc1035.com> > On 21 Oct 2020, at 10:07, JORDI PALET MARTINEZ via address-policy-wg wrote: > > It is not fair that legacy holders are not bind to policies and services (and their cost) from the RIRs the same way as non-legacy. Maybe, maybe not. There are plenty of other far more expensive cost centres in the NCC?s budget that are not fairly shared across the membership and nobody?s whining about them. Just look at all those cheapskates who get DNS and whois lookups from the NCC for free. Many of them aren?t even from the RIPE community. They should be paying. :-) > We "rewind history" in real life all the time. There are laws (and customs) that as time passes, we discover that were wrong or broken or need to be adapted to new times That?s not rewriting history Jordi. You should know better. Whenever customs and laws change, the new measures do not apply to whatever had happened in the past. They apply to the present and future. For instance, suppose a government changes increases income tax. They don?t make you pay the increased rate for all the preceding years before the rate went up. > Transfers are a way to correct that, as it has been said (and done in other regions). And every day it has less sense to keep the resources legacy: you need other resources from the RIR (like IPv6, other ASN, etc.), so then you sign the service agreement. I?ve already explained why that?s utterly wrong. If you think legacy holders should pay something, I maybe agree with that in principle. [But definitely not signing a service agreement which forces a legacy holder to become an LIR.] And maybe that?s a discussion that could be had once there was some hard data. My gut feel is the cost to the NCC of looking after legacy space is negligible and not worth worrying about. It?ll barely be a rounding error in the Registry Services budget. Setting up and running a system to recover that insignificant amount of money from legacy holders will cost far more: contracts, invoicing, staff time, etc. Assuming there was a legal basis for imposing those charges. Which there almost certainly isn?t. OTOH devising such a system will provide endless opportunities for the shed-painting and rat-holing that some members of our community *love*. Who cares about the underlying issue? Just think of all the months we can waste bickering over the policy and process minutiae. In any case, the RIPE community and the NCC membership simply shouldn?t attempt this sort of micro-management. That?s the path to madness: ?I want X EUR off my fee because I didn?t use any of the training courses last year. Or RIPEstat. Or take part in a hackathon. Or update my database entries. Or....?. It may well be reasonable to say something?s not fair. For some definition of fair. But it can sometimes be even more unreasonable to attempt to correct that -- extra costs, more complexity, higher administrative overheads, -- etc it simply isn?t worth the effort. Or addressing that unfairness creates other unfairnesses elsewhere. Sometimes pragmatic decisions have to be made because these are the least-worst solutions for the perceived level of unfairness. > RIPE region is a bit special on that, in the sense that we have a single fee for everything, but in other regions is not the same way, and it is somehow proportional to the "amount" of resources you hold. I also think that's unfair. Of course, that's a different discussion ... Indeed. And a discussion to be had somewhere else, perhaps at the NCC?s AGM. The NCC used to have a byzantine charging scheme for setting membership fees based (roughly) on the member?s allocation of NCC-issued resources. Broadly speaking, the biggest LIRs paid more. However that system was hard to administer and created too many problems. So the membership applied common sense and voted to have a flat fee. If you want legacy holders to pay, both the RIPE and NCC policy making machinery is open to you. From jordi.palet at consulintel.es Wed Oct 21 12:35:22 2020 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 21 Oct 2020 12:35:22 +0200 Subject: [address-policy-wg] fairness and legacy resources In-Reply-To: <8D7725A9-F87D-4E66-9F1C-FFE9445C2BB6@rfc1035.com> References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> <1441248791.2496412.1603218610511@mail.yahoo.com> <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> <0D458FEE-D77B-4FEA-B602-52D69761D006@rfc1035.com> <61241A67-6AF4-442F-B4EA-99DDE2513C76@consulintel.es> <8D7725A9-F87D-4E66-9F1C-FFE9445C2BB6@rfc1035.com> Message-ID: ?El 21/10/20 12:16, "address-policy-wg en nombre de Jim Reid" escribi?: > On 21 Oct 2020, at 10:07, JORDI PALET MARTINEZ via address-policy-wg wrote: > > It is not fair that legacy holders are not bind to policies and services (and their cost) from the RIRs the same way as non-legacy. Maybe, maybe not. There are plenty of other far more expensive cost centres in the NCC?s budget that are not fairly shared across the membership and nobody?s whining about them. Just look at all those cheapskates who get DNS and whois lookups from the NCC for free. Many of them aren?t even from the RIPE community. They should be paying. :-) [Jordi] Not saying not to that. It is a community/membership decision to keep offering those services, and do it for free or find a way to only offer for free to members and a subscription fee for others, etc. > We "rewind history" in real life all the time. There are laws (and customs) that as time passes, we discover that were wrong or broken or need to be adapted to new times That?s not rewriting history Jordi. You should know better. Whenever customs and laws change, the new measures do not apply to whatever had happened in the past. They apply to the present and future. For instance, suppose a government changes increases income tax. They don?t make you pay the increased rate for all the preceding years before the rate went up. [Jordi] No, is not always like that. If there is a new tax for something, of course typically you will not pay for the past years, but you will pay for the new years since the tax is established. If you don't want to pay that tax, then you can release the "resource" that is covered by that tax. In Spain there are many examples of that, and I'm sure this is true for many other countries worldwide. > Transfers are a way to correct that, as it has been said (and done in other regions). And every day it has less sense to keep the resources legacy: you need other resources from the RIR (like IPv6, other ASN, etc.), so then you sign the service agreement. I?ve already explained why that?s utterly wrong. If you think legacy holders should pay something, I maybe agree with that in principle. [But definitely not signing a service agreement which forces a legacy holder to become an LIR.] And maybe that?s a discussion that could be had once there was some hard data. My gut feel is the cost to the NCC of looking after legacy space is negligible and not worth worrying about. It?ll barely be a rounding error in the Registry Services budget. Setting up and running a system to recover that insignificant amount of money from legacy holders will cost far more: contracts, invoicing, staff time, etc. Assuming there was a legal basis for imposing those charges. Which there almost certainly isn?t. [Jordi] The point is that, as I said, RIPE region is somehow "special" on that, so even if here could be negligible, it not in other regions. OTOH devising such a system will provide endless opportunities for the shed-painting and rat-holing that some members of our community *love*. Who cares about the underlying issue? Just think of all the months we can waste bickering over the policy and process minutiae. In any case, the RIPE community and the NCC membership simply shouldn?t attempt this sort of micro-management. That?s the path to madness: ?I want X EUR off my fee because I didn?t use any of the training courses last year. Or RIPEstat. Or take part in a hackathon. Or update my database entries. Or....?. [Jordi] No discussion on this point, fully agree! It may well be reasonable to say something?s not fair. For some definition of fair. But it can sometimes be even more unreasonable to attempt to correct that -- extra costs, more complexity, higher administrative overheads, -- etc it simply isn?t worth the effort. Or addressing that unfairness creates other unfairnesses elsewhere. Sometimes pragmatic decisions have to be made because these are the least-worst solutions for the perceived level of unfairness. [Jordi] Agree as well ... however, sometimes is not a matter of how much is the cost, but about is or looks as simply unfair. And yes, resolving an unfairness here may create an unbalance in the other side, but this is real life, nothing different. > RIPE region is a bit special on that, in the sense that we have a single fee for everything, but in other regions is not the same way, and it is somehow proportional to the "amount" of resources you hold. I also think that's unfair. Of course, that's a different discussion ... Indeed. And a discussion to be had somewhere else, perhaps at the NCC?s AGM. The NCC used to have a byzantine charging scheme for setting membership fees based (roughly) on the member?s allocation of NCC-issued resources. Broadly speaking, the biggest LIRs paid more. However that system was hard to administer and created too many problems. So the membership applied common sense and voted to have a flat fee. [Jordi] Not a member, so can't bring it back to the AGM ... but what it makes sense for 1 out of 5 RIRs, seems to be the contrary as in the case of the other 4. Not convinced that's common sense! If you want legacy holders to pay, both the RIPE and NCC policy making machinery is open to you. [Jordi] Undoubtedly, it's already "on the works" ... ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From gert at space.net Wed Oct 21 13:06:55 2020 From: gert at space.net (Gert Doering) Date: Wed, 21 Oct 2020 13:06:55 +0200 Subject: [address-policy-wg] FW: Policy Reciprocity In-Reply-To: <61241A67-6AF4-442F-B4EA-99DDE2513C76@consulintel.es> References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> <1441248791.2496412.1603218610511@mail.yahoo.com> <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> <0D458FEE-D77B-4FEA-B602-52D69761D006@rfc1035.com> <61241A67-6AF4-442F-B4EA-99DDE2513C76@consulintel.es> Message-ID: <20201021110655.GT2485@Space.Net> Hi, On Wed, Oct 21, 2020 at 11:07:04AM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: > I agree with Shane here. > > We shall correct mistakes ASAP. Legacy was a mistake, just because we didn't have the RIR system before, nothing else. It was not a conscious decision, nobody understood at that time that Internet as a "global" thing will need those resources and will become scarce. There is no contractual basis on which to "fix" anything here. Legacy holders that are willing to change their resources into regular RIPE space can do this today. For those that do not want to do so, let me repeat: there is no contractual basis to make them do something they do not want. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer 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: 833 bytes Desc: not available URL: From gert at space.net Wed Oct 21 13:09:06 2020 From: gert at space.net (Gert Doering) Date: Wed, 21 Oct 2020 13:09:06 +0200 Subject: [address-policy-wg] fairness and legacy resources In-Reply-To: <8D7725A9-F87D-4E66-9F1C-FFE9445C2BB6@rfc1035.com> References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> <1441248791.2496412.1603218610511@mail.yahoo.com> <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> <0D458FEE-D77B-4FEA-B602-52D69761D006@rfc1035.com> <61241A67-6AF4-442F-B4EA-99DDE2513C76@consulintel.es> <8D7725A9-F87D-4E66-9F1C-FFE9445C2BB6@rfc1035.com> Message-ID: <20201021110906.GU2485@Space.Net> Hi, On Wed, Oct 21, 2020 at 11:16:29AM +0100, Jim Reid wrote: > If you want legacy holders to pay, both the RIPE and NCC policy making machinery is open to you. "The NCC policy machinery by means of the AGM". The *RIPE* policy machinery has no say in "what should some folks pay that do not fall under RIPE policy". Or, more general, in "pay". Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer 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: 833 bytes Desc: not available URL: From nick at foobar.org Wed Oct 21 13:16:18 2020 From: nick at foobar.org (Nick Hilliard) Date: Wed, 21 Oct 2020 12:16:18 +0100 Subject: [address-policy-wg] FW: Policy Reciprocity In-Reply-To: <0D458FEE-D77B-4FEA-B602-52D69761D006@rfc1035.com> References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> <1441248791.2496412.1603218610511@mail.yahoo.com> <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> <0D458FEE-D77B-4FEA-B602-52D69761D006@rfc1035.com> Message-ID: Jim Reid wrote on 21/10/2020 09:32: > Fair enough Shane. [Though I don?t agree legacy space is/was a > mistake.] However nobody can rewind history. So until someone invents > time travel, we just have to live with what you think was a mistake. more to the point, the legacy policy resources document says that if RIPE community policy is created or updated, it only applies to legacy address space if the policy says so explicitly. The consequence of this is that legacy address holders can easily veto any future changes to legacy address policy that they don't like. Some people think this is a great idea; other don't and feel this was a mistake. Either way it's irrelevant because it's not really possible to back out of this sort of policy arrangement. The most sensible approach in the circumstances is leave it and move on. Nick From jordi.palet at consulintel.es Wed Oct 21 13:40:30 2020 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 21 Oct 2020 13:40:30 +0200 Subject: [address-policy-wg] FW: Policy Reciprocity In-Reply-To: <20201021110655.GT2485@Space.Net> References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> <1441248791.2496412.1603218610511@mail.yahoo.com> <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> <0D458FEE-D77B-4FEA-B602-52D69761D006@rfc1035.com> <61241A67-6AF4-442F-B4EA-99DDE2513C76@consulintel.es> <20201021110655.GT2485@Space.Net> Message-ID: <2F50C536-3AF1-4ED3-9F14-B54712111E8D@consulintel.es> Right, however, a policy (proposal), could be in the direction of what services are only for members with a contract. Regards, Jordi @jordipalet ?El 21/10/20 13:07, "address-policy-wg en nombre de Gert Doering" escribi?: Hi, On Wed, Oct 21, 2020 at 11:07:04AM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: > I agree with Shane here. > > We shall correct mistakes ASAP. Legacy was a mistake, just because we didn't have the RIR system before, nothing else. It was not a conscious decision, nobody understood at that time that Internet as a "global" thing will need those resources and will become scarce. There is no contractual basis on which to "fix" anything here. Legacy holders that are willing to change their resources into regular RIPE space can do this today. For those that do not want to do so, let me repeat: there is no contractual basis to make them do something they do not want. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From farmer at umn.edu Wed Oct 21 13:56:43 2020 From: farmer at umn.edu (David Farmer) Date: Wed, 21 Oct 2020 06:56:43 -0500 Subject: [address-policy-wg] Assignments have legacy status, not IP addresses themselves Message-ID: The concept that the legacy status applies independently to resources or IP addresses, separate from their assignment to a resource holder, seems incorrect. The legacy status applies to the assignment of resources to a resource holder before the creation of the RIRs, but not to the resources or the IP addresses themselves. All IPv4 addresses were created at the same time. When they were assigned for use differs; therefore, when they were assigned for use and to whom they are assigned for use is what matters. When addresses are transferred to a different organization, a new assignment is made, or in other words, they are reassigned. And it seems proper that the new assignment no longer has the legacy status, as they are now assigned to a different organization. When a merger or acquisition occurs, we also call that a transfer, but it is a transfer to a new version of the same organization, not to a different organization. In this case, it seems propers that the assignment maintains its legacy status, as the same organization, just a different version of the same organization, continues to hold the assignment. The legacy status is important and is not a mistake because, as a community, we believe it is important to maintain the uniqueness of the assignments made before the creation of the RIRs. However, at least in my opinion, it is a mistake to believe that the legacy status applies to IP addresses independent of who holds the assignment. Thank you. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Wed Oct 21 13:58:29 2020 From: gert at space.net (Gert Doering) Date: Wed, 21 Oct 2020 13:58:29 +0200 Subject: [address-policy-wg] FW: Policy Reciprocity In-Reply-To: <2F50C536-3AF1-4ED3-9F14-B54712111E8D@consulintel.es> References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> <1441248791.2496412.1603218610511@mail.yahoo.com> <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> <0D458FEE-D77B-4FEA-B602-52D69761D006@rfc1035.com> <61241A67-6AF4-442F-B4EA-99DDE2513C76@consulintel.es> <20201021110655.GT2485@Space.Net> <2F50C536-3AF1-4ED3-9F14-B54712111E8D@consulintel.es> Message-ID: <20201021115829.GV2485@Space.Net> Hi, On Wed, Oct 21, 2020 at 01:40:30PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: > Right, however, a policy (proposal), could be in the direction of what services are only for members with a contract. Indeed, but that would be ncc-services then. And arguably "member things that cost money" might still see a redirect to AGM. Because, that's what deals with "members" and "money" (and "voting about ways to spend and charge money"). Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer 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: 833 bytes Desc: not available URL: From ripedenis at yahoo.co.uk Wed Oct 21 14:10:16 2020 From: ripedenis at yahoo.co.uk (ripedenis at yahoo.co.uk) Date: Wed, 21 Oct 2020 12:10:16 +0000 (UTC) Subject: [address-policy-wg] FW: Policy Reciprocity In-Reply-To: References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> <1441248791.2496412.1603218610511@mail.yahoo.com> <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> <0D458FEE-D77B-4FEA-B602-52D69761D006@rfc1035.com> Message-ID: <1987162358.2904882.1603282216404@mail.yahoo.com> It is not only address policy they can veto. Correct me if I am mistaken, but I understood they can veto any policy they don't like. The internet is critical infrastructure that impacts the lives of almost every human on the planet (and non human lives). It is an essential tool but cyberspace is also a dangerous world. We should not have a group of untouchables in a system based on cooperation and consensus. "Either way it's irrelevant because it's not really possible to?back out of this sort of policy arrangement. The most sensible approach in the circumstances is leave it and move on." This attitude will not work indefinitely. At some point legislators will step in. When you have the power to impose rules you don't need a time machine. cheersdenis On Wednesday, 21 October 2020, 13:16:35 CEST, Nick Hilliard wrote: Jim Reid wrote on 21/10/2020 09:32: > Fair enough Shane. [Though I don?t agree legacy space is/was a > mistake.] However nobody can rewind history. So until someone invents > time travel, we just have to live with what you think was a mistake. more to the point, the legacy policy resources document says that if RIPE community policy is created or updated, it only applies to legacy address space if the policy says so explicitly. The consequence of this is that legacy address holders can easily veto any future changes to legacy address policy that they don't like. Some people think this is a great idea; other don't and feel this was a mistake.? Either way it's irrelevant because it's not really possible to back out of this sort of policy arrangement. The most sensible approach in the circumstances is leave it and move on. Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Wed Oct 21 14:22:52 2020 From: jim at rfc1035.com (Jim Reid) Date: Wed, 21 Oct 2020 13:22:52 +0100 Subject: [address-policy-wg] RIPE policy making In-Reply-To: <1987162358.2904882.1603282216404@mail.yahoo.com> References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> <1441248791.2496412.1603218610511@mail.yahoo.com> <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> <0D458FEE-D77B-4FEA-B602-52D69761D006@rfc1035.com> <1987162358.2904882.1603282216404@mail.yahoo.com> Message-ID: <472705C3-B21E-4948-B2C6-D9B310C31389@rfc1035.com> > On 21 Oct 2020, at 13:10, ripedenis--- via address-policy-wg wrote: > > It is not only address policy they can veto. Correct me if I am mistaken, but I understood they can veto any policy they don't like. Anyone is free to participate in RIPE policy making. Nobody has a veto though because we make decisions by consensus. There?s a notional veto at the impact assessment stage of the PDP. For instance if the NCC says ?this proposal is unworkable/illegal/too expensive - don't do it?. I paraphrase. From jordi.palet at consulintel.es Wed Oct 21 15:41:26 2020 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 21 Oct 2020 15:41:26 +0200 Subject: [address-policy-wg] Assignments have legacy status, not IP addresses themselves In-Reply-To: References: Message-ID: Hi David, I never though on this from your perspective, and I think you?re right. However, the point about M&A it is a bit more complex. If it is just a pure ?renaming? of the company I will agree with you, but there are cases, where is not really a new ?version of the organization?, in fact it may be just a way for a business to obtain IP addresses, or an ISP join/buy smaller ones to become bigger, etc. I think trying to differentiate those cases will make it very difficult. However, there is an independent problem, which is getting services for free, which are being covered by the rest of the membership. Regards, Jordi @jordipalet El 21/10/20 13:57, "address-policy-wg en nombre de David Farmer via address-policy-wg" escribi?: The concept that the legacy status applies independently to resources or IP addresses, separate from their assignment to a resource holder, seems incorrect. The legacy status applies to the assignment of resources to a resource holder before the creation of the RIRs, but not to the resources or the IP addresses themselves. All IPv4 addresses were created at the same time. When they were assigned for use differs; therefore, when they were assigned for use and to whom they are assigned for use is what matters. When addresses are transferred to a different organization, a new assignment is made, or in other words, they are reassigned. And it seems proper that the new assignment no longer has the legacy status, as they are now assigned to a different organization. When a merger or acquisition occurs, we also call that a transfer, but it is a transfer to a new version of the same organization, not to a different organization. In this case, it seems propers that the assignment maintains its legacy status, as the same organization, just a different version of the same organization, continues to hold the assignment. The legacy status is important and is not a mistake because, as a community, we believe it is important to maintain the uniqueness of the assignments made before the creation of the RIRs. However, at least in my opinion, it is a mistake to believe that the legacy status applies to IP addresses independent of who holds the assignment. Thank you. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From apwg at c4inet.net Wed Oct 21 15:49:25 2020 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Wed, 21 Oct 2020 14:49:25 +0100 Subject: [address-policy-wg] FW: Policy Reciprocity In-Reply-To: <1987162358.2904882.1603282216404@mail.yahoo.com> References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> <1441248791.2496412.1603218610511@mail.yahoo.com> <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> <0D458FEE-D77B-4FEA-B602-52D69761D006@rfc1035.com> <1987162358.2904882.1603282216404@mail.yahoo.com> Message-ID: <20201021134925.GA66965@cilantro.c4inet.net> On Wed, Oct 21, 2020 at 12:10:16PM +0000, ripedenis--- via address-policy-wg wrote: > It is not only address policy they can veto. Correct me if I am mistaken, but I understood they can veto any policy they don't like. The internet is critical infrastructure that impacts the lives of almost every human on the planet (and non human lives). It is an essential tool but cyberspace is also a dangerous world. We should not have a group of untouchables in a system based on cooperation and consensus. > Aside from the argumentum ad passiones fallacy, the fact of the matter is that the NCC can't force any organisation it does not have a contract with to do anything. It's a question of "how many divisions does the RIPE NCC have?". >This attitude will not work indefinitely. At some point legislators will step in. When you have the power to impose rules you don't need a time machine. I'm getting somewhat tired of this argument cropping up in *every* policy proposal discussion lately. This is a) FUD and b) intervention in advance of evidence. If legislators want to make law, they'll make law, regardless of what RIPE does. That battle will have to be fought when it is joined, no precautionary obedience will change anything. rgds, Sascha Luck From hank at interall.co.il Wed Oct 21 16:06:37 2020 From: hank at interall.co.il (Hank Nussbacher) Date: Wed, 21 Oct 2020 17:06:37 +0300 Subject: [address-policy-wg] fairness and legacy resources In-Reply-To: <8D7725A9-F87D-4E66-9F1C-FFE9445C2BB6@rfc1035.com> References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> <1441248791.2496412.1603218610511@mail.yahoo.com> <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> <0D458FEE-D77B-4FEA-B602-52D69761D006@rfc1035.com> <61241A67-6AF4-442F-B4EA-99DDE2513C76@consulintel.es> <8D7725A9-F87D-4E66-9F1C-FFE9445C2BB6@rfc1035.com> Message-ID: <505634ea-cd49-7f9b-d615-e637ca428ecb@interall.co.il> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ripe-legacy.jpg Type: image/jpeg Size: 34221 bytes Desc: not available URL: From jordi.palet at consulintel.es Wed Oct 21 16:13:58 2020 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 21 Oct 2020 16:13:58 +0200 Subject: [address-policy-wg] fairness and legacy resources In-Reply-To: <505634ea-cd49-7f9b-d615-e637ca428ecb@interall.co.il> References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> <1441248791.2496412.1603218610511@mail.yahoo.com> <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> <0D458FEE-D77B-4FEA-B602-52D69761D006@rfc1035.com> <61241A67-6AF4-442F-B4EA-99DDE2513C76@consulintel.es> <8D7725A9-F87D-4E66-9F1C-FFE9445C2BB6@rfc1035.com> <505634ea-cd49-7f9b-d615-e637ca428ecb@interall.co.il> Message-ID: <6996604F-2564-4421-BCC6-3B82DC1B0B66@consulintel.es> ?Hi Hans, I was talking in general, not just in this region. Also, they need be bound to the policies, which is not the case in all the regions. As said, those are separate problems, not the same in all the RIRs, but closely related and also related to the transfers as a possible way to avoid the ?continuity? of all those differential situations. Regards, Jordi @jordipalet El 21/10/20 16:06, "address-policy-wg en nombre de Hank Nussbacher" escribi?: On 21/10/2020 13:16, Jim Reid wrote: If you think legacy holders should pay something, I maybe agree with that in principle. [But definitely not signing a service agreement which forces a legacy holder to become an LIR.] And maybe that?s a discussion that could be had once there was some hard data. ... If you want legacy holders to pay, both the RIPE and NCC policy making machinery is open to you. Legacy holders already pay. See screenshot from my LIR bill for 2020. Been like that since our 2016 bill. Regards, Hank Caveat: The views expressed above are solely my own and do not express the views or opinions of my employer ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripedenis at yahoo.co.uk Wed Oct 21 16:32:02 2020 From: ripedenis at yahoo.co.uk (ripedenis at yahoo.co.uk) Date: Wed, 21 Oct 2020 14:32:02 +0000 (UTC) Subject: [address-policy-wg] FW: Policy Reciprocity In-Reply-To: <20201021134925.GA66965@cilantro.c4inet.net> References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> <1441248791.2496412.1603218610511@mail.yahoo.com> <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> <0D458FEE-D77B-4FEA-B602-52D69761D006@rfc1035.com> <1987162358.2904882.1603282216404@mail.yahoo.com> <20201021134925.GA66965@cilantro.c4inet.net> Message-ID: <1111586645.3016623.1603290722545@mail.yahoo.com> HI Sascha I think you are wrong on both your points. Firstly you are making the classic confusion between RIPE NCC and RIPE. Policies are made by the RIPE community based on consensual agreement. Once agreed it is expected all affected parties will accept and follow a policy. Presumably the contract members have with the RIPE NCC requires them to follow future RIPE policies. But legacy resource holders are still part of the RIPE community and probably take part in the discussions on policies. As part of an industry based on cooperation and consensual driven policy they do have an obligation to follow all policies agreed, even if it is not legally enforceable. "If legislators want to make law, they'll make law, regardless of?what RIPE does." This is not true. The years of discussions between the RIRs and governments and LEAs on internet governance have shown that as long as the industry acts responsibly and manages the internet in a way that governments and LEAs can accept then things can continue as they are now. It is a balance and balances have tipping points. I think David Farmer made a good point: "The concept that the legacy status applies independently to resources or IP addresses, separate?from their?assignment to a resource holder, seems incorrect. The legacy status applies to the assignment of resources to a resource holder before the creation of the RIRs, but not to the resources or the IP addresses themselves. " I agree with this statement. The legacy status should only apply to 'contractual ownership' or 'administrative management' of resources, not to consensual policy driven operational use of address space. Even if the contracts under which they received their legacy address space suggested they could assign the same rights to a buyer of the address space, the environment under which address space is used is governed by policies now. ALL address space used in this environment should be subject to the policies governing this environment, regardless of administrative status. cheersdenis On Wednesday, 21 October 2020, 15:49:43 CEST, Sascha Luck [ml] wrote: On Wed, Oct 21, 2020 at 12:10:16PM +0000, ripedenis--- via address-policy-wg wrote: > It is not only address policy they can veto. Correct me if I am mistaken, but I understood they can veto any policy they don't like. The internet is critical infrastructure that impacts the lives of almost every human on the planet (and non human lives). It is an essential tool but cyberspace is also a dangerous world. We should not have a group of untouchables in a system based on cooperation and consensus. > Aside from the argumentum ad passiones fallacy, the fact of the matter is that the NCC can't force any organisation it does not have a contract with to do anything. It's a question of "how many divisions does the RIPE NCC have?". >This attitude will not work indefinitely. At some point legislators will step in. When you have the power to impose rules you don't need a time machine. I'm getting somewhat tired of this argument cropping up in *every* policy proposal discussion lately. This is a) FUD and b) intervention in advance of evidence. If legislators want to make law, they'll make law, regardless of what RIPE does. That battle will have to be fought when it is joined, no precautionary obedience will change anything. rgds, Sascha Luck -------------- next part -------------- An HTML attachment was scrubbed... URL: From apwg at c4inet.net Wed Oct 21 16:58:39 2020 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Wed, 21 Oct 2020 15:58:39 +0100 Subject: [address-policy-wg] FW: Policy Reciprocity In-Reply-To: <1111586645.3016623.1603290722545@mail.yahoo.com> References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> <1441248791.2496412.1603218610511@mail.yahoo.com> <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> <0D458FEE-D77B-4FEA-B602-52D69761D006@rfc1035.com> <1987162358.2904882.1603282216404@mail.yahoo.com> <20201021134925.GA66965@cilantro.c4inet.net> <1111586645.3016623.1603290722545@mail.yahoo.com> Message-ID: <20201021145839.GB66965@cilantro.c4inet.net> Hi Denis, On Wed, Oct 21, 2020 at 02:32:02PM +0000, ripedenis at yahoo.co.uk wrote: >I think you are wrong on both your points. Firstly you are making the classic confusion between RIPE NCC and RIPE. Policies are made by the RIPE community based on consensual agreement. Once agreed it is expected all affected parties will accept and follow a policy. Presumably the contract members have with the RIPE NCC requires them to follow future RIPE policies. But legacy resource holders are still part of the RIPE community and probably take part in the discussions on policies. As part of an industry based on cooperation and consensual driven policy they do have an obligation to follow all policies agreed, even if it is not legally enforceable. How many divisions does the RIPE community have? This question was, anecdotally and rhetorically, asked by Stalin wrt the Pope. This is not a bad analogy as the Vatican can make all sorts of rules but can only "enforce" them vs members of the roman catholic church (and with less than absolute success at that) "Politics is the art of the possible, the attainable." --Otto v. Bismarck >"If legislators want to make law, they'll make law, regardless of??what RIPE does." >This is not true. The years of discussions between the RIRs and governments and LEAs on internet governance have shown that as long as the industry acts responsibly and manages the internet in a way that governments and LEAs can accept then things can continue as they are now. It is a balance and balances have tipping points. Fistly, let me address a point which I missed in my previous: WHICH legislator? EUPARL? UKPARL? Putin? Erdogan? The King of Saudi Arabia? All within the RIPE service region. Secondly, I stand over my point. Legislators will legislate if they see an advantage in doing so and if they listen to anyone it will not be the RIPE community. I may yet happen that a nation state will think it advantageous to lay claim to the ownership of certain integers and there will be nothing the RIPE community or the NCC can do about this, so why worry about this now? >I think David Farmer made a good point: >"The concept that the legacy status applies independently to resources or IP addresses, separate??from their??assignment to a resource holder, seems incorrect. The legacy status applies to the assignment of resources to a resource holder before the creation of the RIRs, but not to the resources or the IP addresses themselves. " >I agree with this statement. The legacy status should only apply to 'contractual ownership' or 'administrative management' of resources, not to consensual policy driven operational use of address space. Even if the contracts under which they received their legacy address space suggested they could assign the same rights to a buyer of the address space, the environment under which address space is used is governed by policies now. ALL address space used in this environment should be subject to the policies governing this environment, regardless of administrative status. I would want to hear the opinion of an actual lawyer about this, so far it sounds like mere wishful thinking. rgds, Sascha Luck From farmer at umn.edu Wed Oct 21 17:30:41 2020 From: farmer at umn.edu (David Farmer) Date: Wed, 21 Oct 2020 10:30:41 -0500 Subject: [address-policy-wg] Assignments have legacy status, not IP addresses themselves In-Reply-To: References: Message-ID: Yes, there are many complexities involved with M&As, nevertheless, when two organizations merge, it seems reasonable for any assignments the original organizations had that were legacy status prior to the merger to maintain their legacy status with the newly merged organization. A more complicated situation is when a small part of an organization is transferred and the result of the transaction are two separate organizations. In my mind, if there are other substantial assets, other than just the IP addresses, like maybe a customer base, are involved then maintaining the legacy status makes sense. However, if the only substantial assets transferred are IP addresses then it is not an M&A transfer, but a reassignment to a different organization. Service fees, and who pays what, are not Internet Resource Policy issues, they are business issues that fall under the organizational governance of each RIR. Thanks On Wed, Oct 21, 2020 at 8:41 AM JORDI PALET MARTINEZ via address-policy-wg < address-policy-wg at ripe.net> wrote: > Hi David, > > > > I never though on this from your perspective, and I think you?re right. > > > > However, the point about M&A it is a bit more complex. If it is just a > pure ?renaming? of the company I will agree with you, but there are cases, > where is not really a new ?version of the organization?, in fact it may be > just a way for a business to obtain IP addresses, or an ISP join/buy > smaller ones to become bigger, etc. I think trying to differentiate those > cases will make it very difficult. > > > > However, there is an independent problem, which is getting services for > free, which are being covered by the rest of the membership. > > > > Regards, > > Jordi > > @jordipalet > > El 21/10/20 13:57, "address-policy-wg en nombre de David Farmer via > address-policy-wg" address-policy-wg at ripe.net> escribi?: > > > > The concept that the legacy status applies independently to resources or > IP addresses, separate from their assignment to a resource holder, seems > incorrect. The legacy status applies to the assignment of resources to a > resource holder before the creation of the RIRs, but not to the resources > or the IP addresses themselves. > > > > All IPv4 addresses were created at the same time. When they were assigned > for use differs; therefore, when they were assigned for use and to whom > they are assigned for use is what matters. > > When addresses are transferred to a different organization, a new > assignment is made, or in other words, they are reassigned. And it seems > proper that the new assignment no longer has the legacy status, as they are > now assigned to a different organization. > > When a merger or acquisition occurs, we also call that a transfer, but it > is a transfer to a new version of the same organization, not to a different > organization. In this case, it seems propers that the assignment maintains > its legacy status, as the same organization, just a different version of > the same organization, continues to hold the assignment. > > > > The legacy status is important and is not a mistake because, as a > community, we believe it is important to maintain the uniqueness of the > assignments made before the creation of the RIRs. However, at least in my > opinion, it is a mistake to believe that the legacy status applies to IP > addresses independent of who holds the assignment. > > > > Thank you. > -- > > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Wed Oct 21 18:46:15 2020 From: randy at psg.com (Randy Bush) Date: Wed, 21 Oct 2020 09:46:15 -0700 Subject: [address-policy-wg] FW: Policy Reciprocity In-Reply-To: References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> <1441248791.2496412.1603218610511@mail.yahoo.com> <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> <0D458FEE-D77B-4FEA-B602-52D69761D006@rfc1035.com> Message-ID: > The most sensible approach in the circumstances is leave it and move > on. considering it is his birthday, WWRS? i suspect about what you just said. randy From erik at bais.name Thu Oct 22 16:42:56 2020 From: erik at bais.name (Erik Bais) Date: Thu, 22 Oct 2020 14:42:56 +0000 Subject: [address-policy-wg] FW: Policy Reciprocity In-Reply-To: <2F50C536-3AF1-4ED3-9F14-B54712111E8D@consulintel.es> References: <7114A945-FE29-4256-A9FA-57434CC1933D@gmail.com> <1441248791.2496412.1603218610511@mail.yahoo.com> <4B0B82F2-4C6C-42D2-AFCE-08AF01D83292@rfc1035.com> <0D458FEE-D77B-4FEA-B602-52D69761D006@rfc1035.com> <61241A67-6AF4-442F-B4EA-99DDE2513C76@consulintel.es> <20201021110655.GT2485@Space.Net> <2F50C536-3AF1-4ED3-9F14-B54712111E8D@consulintel.es> Message-ID: <05CF5F77-81CC-46B8-B20E-54FE9566B0E5@bais.name> > Right, however, a policy (proposal), could be in the direction of what services are only for members with a contract. That is already what is in the current policy for legacy holders .. https://www.ripe.net/publications/docs/ripe-639 <=- RIPE NCC Services to Legacy Internet Resource Holders https://www.ripe.net/manage-ips-and-asns/legacy-resources/ripe-ncc-services-to-legacy-internet-resource-holders <=- shiny colours in a nice matrix showing exactly what the options are. And here an example of a policy with a specific Legacy holder part in it, the policy: Resource Certification for non-members : https://www.ripe.net/participate/policies/proposals/2013-04 2013-04 provided a way to include legacy holders into the RPKI system, by requirement that there is a contractual agreement in place with the RIPE NCC. Regards, Erik Bais ?On 21/10/2020, 13:41, "address-policy-wg on behalf of JORDI PALET MARTINEZ via address-policy-wg" wrote: Right, however, a policy (proposal), could be in the direction of what services are only for members with a contract. Regards, Jordi @jordipalet El 21/10/20 13:07, "address-policy-wg en nombre de Gert Doering" escribi?: Hi, On Wed, Oct 21, 2020 at 11:07:04AM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: > I agree with Shane here. > > We shall correct mistakes ASAP. Legacy was a mistake, just because we didn't have the RIR system before, nothing else. It was not a conscious decision, nobody understood at that time that Internet as a "global" thing will need those resources and will become scarce. There is no contractual basis on which to "fix" anything here. Legacy holders that are willing to change their resources into regular RIPE space can do this today. For those that do not want to do so, let me repeat: there is no contractual basis to make them do something they do not want. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jordi.palet at consulintel.es Wed Oct 28 13:05:01 2020 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 28 Oct 2020 13:05:01 +0100 Subject: [address-policy-wg] stockpiling IPv6 Message-ID: Hi all, After Nikolas presentation today, I've been thinking on possible ways to resolve this, so before sending a possible policy proposal, I think it deserves some discussion. The intent of the proposal 2018-01 (https://www.ripe.net/participate/policies/proposals/2018-01), was to align the IPv4 and IPv6 policies in the matter of an LIR vs organization. We must remind that the allocation/assignment of resources is based on justified need. And yes, we have a lot of IPv6 space, but it is really justified and the same organization, having different LIRs, can use it as a trick for stockpiling if there is not such justified need? In IPv4 this is not "a problem" because we don't have more space. Well ... not exactly true ... some organizations could have used "the trick" to get more IPv4 space by creating multiple LIRs. In other regions, I think this is not a problem because the cost of the membership is not per "LIR" (flat rate in RIPE NCC), but based on the size of the allocation/assignment. So, because IPv6 is not a scarce resource, it seems there is no incentive to pay more for getting more if you're not really using it. However, in RIPE NCC, if you created several LIRs for getting more IPv4 allocations, *even if you don't use/need it* you can get (and thus stockpile) IPv6 *at no extra cost*. I clearly think this is not a good thing. It seems to me that the problem lies in section 5.1.1. Initial allocation criteria, and exactly here: b) have a plan for making sub-allocations to other organisations and/or End Site assignments within two years. So, is the problem that "a plan" is not sufficient if it is not "verified" and the "bad guys" know that the chances for having it verified are too small? Do we need some text about "recovery if not announced and used" ? Other ideas? Remember that the problem is not only about scarcity. This extra space may be used "intermittently" for bad or even criminal activities and we have a responsibility on that as a community. Regards, Jordi @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From nick at foobar.org Wed Oct 28 13:08:55 2020 From: nick at foobar.org (Nick Hilliard) Date: Wed, 28 Oct 2020 12:08:55 +0000 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: References: Message-ID: <96c85e8b-eca7-f332-2d45-2bd7923e10d7@foobar.org> JORDI PALET MARTINEZ via address-policy-wg wrote on 28/10/2020 12:05: > However, in RIPE NCC, if you created several LIRs for getting more > IPv4 allocations, *even if you don't use/need it* you can get (and > thus stockpile) IPv6 *at no extra cost*. [...] > Do we need some text about "recovery if not announced and used" ? tl;dr: no. Nick From jordi.palet at consulintel.es Wed Oct 28 13:13:13 2020 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 28 Oct 2020 13:13:13 +0100 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: <96c85e8b-eca7-f332-2d45-2bd7923e10d7@foobar.org> References: <96c85e8b-eca7-f332-2d45-2bd7923e10d7@foobar.org> Message-ID: <0D0CE3FD-FF71-457D-9015-D9A98B0CE0DA@consulintel.es> Hi Nick, Could you explain why not? Clearly it is something that should part of the NCC verification duties, but we have been told several times, in other policy proposals, that we need to make it explicit so they can "act". Otherwise, do you have other suggestions, or do you think the we should ignore the stockpiling? Regards, Jordi @jordipalet ?El 28/10/20 13:09, "address-policy-wg en nombre de Nick Hilliard" escribi?: JORDI PALET MARTINEZ via address-policy-wg wrote on 28/10/2020 12:05: > However, in RIPE NCC, if you created several LIRs for getting more > IPv4 allocations, *even if you don't use/need it* you can get (and > thus stockpile) IPv6 *at no extra cost*. [...] > Do we need some text about "recovery if not announced and used" ? tl;dr: no. Nick ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From sergey at devnull.ru Wed Oct 28 13:20:20 2020 From: sergey at devnull.ru (Sergey Myasoedov) Date: Wed, 28 Oct 2020 13:20:20 +0100 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: <0D0CE3FD-FF71-457D-9015-D9A98B0CE0DA@consulintel.es> References: <96c85e8b-eca7-f332-2d45-2bd7923e10d7@foobar.org> <0D0CE3FD-FF71-457D-9015-D9A98B0CE0DA@consulintel.es> Message-ID: Hi Jordi, > Otherwise, do you have other suggestions, or do you think the we should ignore the stockpiling? A 'stockpiling' on the obsoleted resource is a result of semi-free market. Just let the IPv4 go, and market and technology will do the rest. And yes, I am the market player. -- Kind regards, Sergey Myasoedov > On 28 Oct 2020, at 13:13, JORDI PALET MARTINEZ via address-policy-wg wrote: > > Hi Nick, > > Could you explain why not? > > Clearly it is something that should part of the NCC verification duties, but we have been told several times, in other policy proposals, that we need to make it explicit so they can "act". > > Otherwise, do you have other suggestions, or do you think the we should ignore the stockpiling? > > Regards, > Jordi > @jordipalet > > > > ?El 28/10/20 13:09, "address-policy-wg en nombre de Nick Hilliard" escribi?: > > JORDI PALET MARTINEZ via address-policy-wg wrote on 28/10/2020 12:05: >> However, in RIPE NCC, if you created several LIRs for getting more >> IPv4 allocations, *even if you don't use/need it* you can get (and >> thus stockpile) IPv6 *at no extra cost*. > [...] >> Do we need some text about "recovery if not announced and used" ? > > tl;dr: no. > > Nick > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > From jordi.palet at consulintel.es Wed Oct 28 13:25:45 2020 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 28 Oct 2020 13:25:45 +0100 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: References: <96c85e8b-eca7-f332-2d45-2bd7923e10d7@foobar.org> <0D0CE3FD-FF71-457D-9015-D9A98B0CE0DA@consulintel.es> Message-ID: <3ABB65D4-39D5-44AA-8D23-5ABDC88FF1C8@consulintel.es> Hi Sergey, Note that I'm not intending to change anything on IPv4 ... Regards, Jordi @jordipalet ?El 28/10/20 13:20, "address-policy-wg en nombre de Sergey Myasoedov via address-policy-wg" escribi?: Hi Jordi, > Otherwise, do you have other suggestions, or do you think the we should ignore the stockpiling? A 'stockpiling' on the obsoleted resource is a result of semi-free market. Just let the IPv4 go, and market and technology will do the rest. And yes, I am the market player. -- Kind regards, Sergey Myasoedov > On 28 Oct 2020, at 13:13, JORDI PALET MARTINEZ via address-policy-wg wrote: > > Hi Nick, > > Could you explain why not? > > Clearly it is something that should part of the NCC verification duties, but we have been told several times, in other policy proposals, that we need to make it explicit so they can "act". > > Otherwise, do you have other suggestions, or do you think the we should ignore the stockpiling? > > Regards, > Jordi > @jordipalet > > > > ?El 28/10/20 13:09, "address-policy-wg en nombre de Nick Hilliard" escribi?: > > JORDI PALET MARTINEZ via address-policy-wg wrote on 28/10/2020 12:05: >> However, in RIPE NCC, if you created several LIRs for getting more >> IPv4 allocations, *even if you don't use/need it* you can get (and >> thus stockpile) IPv6 *at no extra cost*. > [...] >> Do we need some text about "recovery if not announced and used" ? > > tl;dr: no. > > Nick > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From elvis at velea.eu Wed Oct 28 13:32:32 2020 From: elvis at velea.eu (Elvis Daniel Velea) Date: Wed, 28 Oct 2020 05:32:32 -0700 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: <3ABB65D4-39D5-44AA-8D23-5ABDC88FF1C8@consulintel.es> References: <3ABB65D4-39D5-44AA-8D23-5ABDC88FF1C8@consulintel.es> Message-ID: Hi Jordi, what is the problem you want to solve? Is the ?IPv6 stockpiling? creating any issues? As far as I know, we have plenty of IPv6 available and by forcing return or imposing conditions on mergers/transfers you only create hurdles for the people that actually use IPv6. I?d say this is a non problem and actually advise RIPE NCC RS to stop tracking/presenting on this unless this issue causes them complications in justifying additional allocation requests from the IANA. Elvis Excuse the briefness of this mail, it was sent from a mobile device. > On Oct 28, 2020, at 05:26, JORDI PALET MARTINEZ via address-policy-wg wrote: > > ?Hi Sergey, > > Note that I'm not intending to change anything on IPv4 ... > > Regards, > Jordi > @jordipalet > > > > ?El 28/10/20 13:20, "address-policy-wg en nombre de Sergey Myasoedov via address-policy-wg" escribi?: > > Hi Jordi, > >> Otherwise, do you have other suggestions, or do you think the we should ignore the stockpiling? > > A 'stockpiling' on the obsoleted resource is a result of semi-free market. Just let the IPv4 go, and market and technology will do the rest. > > And yes, I am the market player. > > -- > Kind regards, > Sergey Myasoedov > > >> On 28 Oct 2020, at 13:13, JORDI PALET MARTINEZ via address-policy-wg wrote: >> >> Hi Nick, >> >> Could you explain why not? >> >> Clearly it is something that should part of the NCC verification duties, but we have been told several times, in other policy proposals, that we need to make it explicit so they can "act". >> >> Otherwise, do you have other suggestions, or do you think the we should ignore the stockpiling? >> >> Regards, >> Jordi >> @jordipalet >> >> >> >> ?El 28/10/20 13:09, "address-policy-wg en nombre de Nick Hilliard" escribi?: >> >> JORDI PALET MARTINEZ via address-policy-wg wrote on 28/10/2020 12:05: >>> However, in RIPE NCC, if you created several LIRs for getting more >>> IPv4 allocations, *even if you don't use/need it* you can get (and >>> thus stockpile) IPv6 *at no extra cost*. >> [...] >>> Do we need some text about "recovery if not announced and used" ? >> >> tl;dr: no. >> >> Nick >> >> >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> >> >> >> > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > From aleksbulgakov at gmail.com Wed Oct 28 13:33:26 2020 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Wed, 28 Oct 2020 14:33:26 +0200 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: References: Message-ID: Hi all. What's bad if someone has several /29 IPv6? Are they running out? How many IPv6 has each RIR? In total the mount of IPv4 is about 4.29 billions against IPv6 with the mount 3.4*10^38. I understand that the NCC tries to find additional funds and implements additional restrictions to force their members to make additional spending. But we should carefully implement new policies. --- Kind regards, Alex ??, 28 ???. 2020 ?., 14:05 JORDI PALET MARTINEZ via address-policy-wg < address-policy-wg at ripe.net>: > Hi all, > > After Nikolas presentation today, I've been thinking on possible ways to > resolve this, so before sending a possible policy proposal, I think it > deserves some discussion. > > The intent of the proposal 2018-01 ( > https://www.ripe.net/participate/policies/proposals/2018-01), was to > align the IPv4 and IPv6 policies in the matter of an LIR vs organization. > > We must remind that the allocation/assignment of resources is based on > justified need. And yes, we have a lot of IPv6 space, but it is really > justified and the same organization, having different LIRs, can use it as a > trick for stockpiling if there is not such justified need? > > In IPv4 this is not "a problem" because we don't have more space. Well ... > not exactly true ... some organizations could have used "the trick" to get > more IPv4 space by creating multiple LIRs. > > In other regions, I think this is not a problem because the cost of the > membership is not per "LIR" (flat rate in RIPE NCC), but based on the size > of the allocation/assignment. So, because IPv6 is not a scarce resource, it > seems there is no incentive to pay more for getting more if you're not > really using it. > > However, in RIPE NCC, if you created several LIRs for getting more IPv4 > allocations, *even if you don't use/need it* you can get (and thus > stockpile) IPv6 *at no extra cost*. > > I clearly think this is not a good thing. > > It seems to me that the problem lies in section 5.1.1. Initial allocation > criteria, and exactly here: > b) have a plan for making sub-allocations to other organisations and/or > End Site assignments within two years. > > So, is the problem that "a plan" is not sufficient if it is not "verified" > and the "bad guys" know that the chances for having it verified are too > small? > > Do we need some text about "recovery if not announced and used" ? > > Other ideas? > > Remember that the problem is not only about scarcity. This extra space may > be used "intermittently" for bad or even criminal activities and we have a > responsibility on that as a community. > > Regards, > Jordi > @jordipalet > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Wed Oct 28 13:39:38 2020 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 28 Oct 2020 13:39:38 +0100 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: References: <3ABB65D4-39D5-44AA-8D23-5ABDC88FF1C8@consulintel.es> Message-ID: <8F383005-17DB-4620-B569-AA482007EABF@consulintel.es> Hi Elvis & Aleksey (to avoid one extra email), As said, it is a matter of responsibility. I'm not the NCC, neither work for them. I think it is a community matter and there is a clear principle here: "justified need". I also agree that the justification can't be too strict, but there is always a right balance point. If an organization has 20 LIRs and they can *justify the need* even for a /12 for each LIR, I'm *perfectly fine* with that. What I don't think is right is that we bypass the justified need. If we want to do that, let's remove it from all the policies. Regards, Jordi @jordipalet ?El 28/10/20 13:32, "address-policy-wg en nombre de Elvis Daniel Velea" escribi?: Hi Jordi, what is the problem you want to solve? Is the ?IPv6 stockpiling? creating any issues? As far as I know, we have plenty of IPv6 available and by forcing return or imposing conditions on mergers/transfers you only create hurdles for the people that actually use IPv6. I?d say this is a non problem and actually advise RIPE NCC RS to stop tracking/presenting on this unless this issue causes them complications in justifying additional allocation requests from the IANA. Elvis Excuse the briefness of this mail, it was sent from a mobile device. > On Oct 28, 2020, at 05:26, JORDI PALET MARTINEZ via address-policy-wg wrote: > > ?Hi Sergey, > > Note that I'm not intending to change anything on IPv4 ... > > Regards, > Jordi > @jordipalet > > > > ?El 28/10/20 13:20, "address-policy-wg en nombre de Sergey Myasoedov via address-policy-wg" escribi?: > > Hi Jordi, > >> Otherwise, do you have other suggestions, or do you think the we should ignore the stockpiling? > > A 'stockpiling' on the obsoleted resource is a result of semi-free market. Just let the IPv4 go, and market and technology will do the rest. > > And yes, I am the market player. > > -- > Kind regards, > Sergey Myasoedov > > >> On 28 Oct 2020, at 13:13, JORDI PALET MARTINEZ via address-policy-wg wrote: >> >> Hi Nick, >> >> Could you explain why not? >> >> Clearly it is something that should part of the NCC verification duties, but we have been told several times, in other policy proposals, that we need to make it explicit so they can "act". >> >> Otherwise, do you have other suggestions, or do you think the we should ignore the stockpiling? >> >> Regards, >> Jordi >> @jordipalet >> >> >> >> ?El 28/10/20 13:09, "address-policy-wg en nombre de Nick Hilliard" escribi?: >> >> JORDI PALET MARTINEZ via address-policy-wg wrote on 28/10/2020 12:05: >>> However, in RIPE NCC, if you created several LIRs for getting more >>> IPv4 allocations, *even if you don't use/need it* you can get (and >>> thus stockpile) IPv6 *at no extra cost*. >> [...] >>> Do we need some text about "recovery if not announced and used" ? >> >> tl;dr: no. >> >> Nick >> >> >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> >> >> >> > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From me at cynthia.re Wed Oct 28 13:46:35 2020 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Wed, 28 Oct 2020 13:46:35 +0100 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: References: Message-ID: Hi, While I will admit it's a bit odd to allocate that much v6 space to a single entity, I don't see how this is going to cause issues based on what is currently happening, like this is not happening at scale. Sure there might be a /21 (256x /29) of IPv6 space assigned to LIRs who already had a /29. but there are many large ISPs who alone have more space than this. Telia has a /20, China Telecom has a /16. Additionally there is no real incentive to request multiple /29s other than very rare cases. unless LIRs requesting like 16x /29s are a common occurrence, this is a non issue imo. disclaimer: I do have 3x /29 for a reason that may seem like a waste to some people and my specific issue could probably be solved by RIPE allowing me to split my /29 into /32s. -Cynthia On Wed, 28 Oct 2020, 13:05 JORDI PALET MARTINEZ via address-policy-wg, < address-policy-wg at ripe.net> wrote: > Hi all, > > After Nikolas presentation today, I've been thinking on possible ways to > resolve this, so before sending a possible policy proposal, I think it > deserves some discussion. > > The intent of the proposal 2018-01 ( > https://www.ripe.net/participate/policies/proposals/2018-01), was to > align the IPv4 and IPv6 policies in the matter of an LIR vs organization. > > We must remind that the allocation/assignment of resources is based on > justified need. And yes, we have a lot of IPv6 space, but it is really > justified and the same organization, having different LIRs, can use it as a > trick for stockpiling if there is not such justified need? > > In IPv4 this is not "a problem" because we don't have more space. Well ... > not exactly true ... some organizations could have used "the trick" to get > more IPv4 space by creating multiple LIRs. > > In other regions, I think this is not a problem because the cost of the > membership is not per "LIR" (flat rate in RIPE NCC), but based on the size > of the allocation/assignment. So, because IPv6 is not a scarce resource, it > seems there is no incentive to pay more for getting more if you're not > really using it. > > However, in RIPE NCC, if you created several LIRs for getting more IPv4 > allocations, *even if you don't use/need it* you can get (and thus > stockpile) IPv6 *at no extra cost*. > > I clearly think this is not a good thing. > > It seems to me that the problem lies in section 5.1.1. Initial allocation > criteria, and exactly here: > b) have a plan for making sub-allocations to other organisations and/or > End Site assignments within two years. > > So, is the problem that "a plan" is not sufficient if it is not "verified" > and the "bad guys" know that the chances for having it verified are too > small? > > Do we need some text about "recovery if not announced and used" ? > > Other ideas? > > Remember that the problem is not only about scarcity. This extra space may > be used "intermittently" for bad or even criminal activities and we have a > responsibility on that as a community. > > Regards, > Jordi > @jordipalet > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Wed Oct 28 13:51:38 2020 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 28 Oct 2020 13:51:38 +0100 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: References: Message-ID: <53F426FB-9995-4788-928A-392D25AED0B6@consulintel.es> Hi Cynthia, Exactly, that?s the point, there is no incentive ? the only incentive is stockpiling, just in case IPv6 becomes scarse and may create a problem like the lack of IPv4, even if this takes 30 years, or 100 years, and you want to secure the funding of the kids of your kids by having a resource that then, will be subjected to market price and transfers. If I understood correctly from Nikolas presentation (please, correct me if I?m wrong), the bigger ISPs, typically have a single LIR with a big allocation, but they don?t have (because they aren?t typically interested in games, just justified need), multiple LIRs with multiple IPv6 allocations (or at least not big ones). Regards, Jordi El 28/10/20 13:47, "address-policy-wg en nombre de Cynthia Revstr?m via address-policy-wg" escribi?: Hi, While I will admit it's a bit odd to allocate that much v6 space to a single entity, I don't see how this is going to cause issues based on what is currently happening, like this is not happening at scale. Sure there might be a /21 (256x /29) of IPv6 space assigned to LIRs who already had a /29. but there are many large ISPs who alone have more space than this. Telia has a /20, China Telecom has a /16. Additionally there is no real incentive to request multiple /29s other than very rare cases. unless LIRs requesting like 16x /29s are a common occurrence, this is a non issue imo. disclaimer: I do have 3x /29 for a reason that may seem like a waste to some people and my specific issue could probably be solved by RIPE allowing me to split my /29 into /32s. -Cynthia On Wed, 28 Oct 2020, 13:05 JORDI PALET MARTINEZ via address-policy-wg, wrote: Hi all, After Nikolas presentation today, I've been thinking on possible ways to resolve this, so before sending a possible policy proposal, I think it deserves some discussion. The intent of the proposal 2018-01 (https://www.ripe.net/participate/policies/proposals/2018-01), was to align the IPv4 and IPv6 policies in the matter of an LIR vs organization. We must remind that the allocation/assignment of resources is based on justified need. And yes, we have a lot of IPv6 space, but it is really justified and the same organization, having different LIRs, can use it as a trick for stockpiling if there is not such justified need? In IPv4 this is not "a problem" because we don't have more space. Well ... not exactly true ... some organizations could have used "the trick" to get more IPv4 space by creating multiple LIRs. In other regions, I think this is not a problem because the cost of the membership is not per "LIR" (flat rate in RIPE NCC), but based on the size of the allocation/assignment. So, because IPv6 is not a scarce resource, it seems there is no incentive to pay more for getting more if you're not really using it. However, in RIPE NCC, if you created several LIRs for getting more IPv4 allocations, *even if you don't use/need it* you can get (and thus stockpile) IPv6 *at no extra cost*. I clearly think this is not a good thing. It seems to me that the problem lies in section 5.1.1. Initial allocation criteria, and exactly here: b) have a plan for making sub-allocations to other organisations and/or End Site assignments within two years. So, is the problem that "a plan" is not sufficient if it is not "verified" and the "bad guys" know that the chances for having it verified are too small? Do we need some text about "recovery if not announced and used" ? Other ideas? Remember that the problem is not only about scarcity. This extra space may be used "intermittently" for bad or even criminal activities and we have a responsibility on that as a community. Regards, Jordi @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Wed Oct 28 13:54:09 2020 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 28 Oct 2020 13:54:09 +0100 (CET) Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: References: Message-ID: On Wed, 28 Oct 2020, JORDI PALET MARTINEZ via address-policy-wg wrote: > We must remind that the allocation/assignment of resources is based on > justified need. And yes, we have a lot of IPv6 space, but it is really > justified and the same organization, having different LIRs, can use it > as a trick for stockpiling if there is not such justified need? My only concern here is routing table size over time, and it's not a very big concern of mine. One area that perhaps could be optimized is to have some kind of process where if someone is merging multiple LIRs and they're not yet using some of the /29, they might be given the option to hand back address space and receive a larger, contiguous address block if they so choose. If we give 65k ASNs a /29 each, this is a /13 worth of addresses. This is not a concern, addresswise. Routing table wise, if this can be cut in half or something, could be worth doing. -- Mikael Abrahamsson email: swmike at swm.pp.se From nick at foobar.org Wed Oct 28 14:03:21 2020 From: nick at foobar.org (Nick Hilliard) Date: Wed, 28 Oct 2020 13:03:21 +0000 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: <0D0CE3FD-FF71-457D-9015-D9A98B0CE0DA@consulintel.es> References: <96c85e8b-eca7-f332-2d45-2bd7923e10d7@foobar.org> <0D0CE3FD-FF71-457D-9015-D9A98B0CE0DA@consulintel.es> Message-ID: <499f6dc8-b32b-eebc-24d3-73c3593774d6@foobar.org> Hi Jordi, JORDI PALET MARTINEZ via address-policy-wg wrote on 28/10/2020 12:13: > Could you explain why not? because the purpose of a registry is to ensure accurate registration information rather than to micromanage resources. As far as I can see, the RIPE NCC is doing its job here and there's no need to instruct it to go off and do something else. There's no shortage of ipv6 address space and no reason to think that we will ever end up with a future shortage. So there is no reason for people to treat ipv6 address blocks as having future scarcity value, which means that there is no motivation to "stockpile". I.e. the entire basis of your argument is void. Nick From jim at rfc1035.com Wed Oct 28 14:07:16 2020 From: jim at rfc1035.com (Jim Reid) Date: Wed, 28 Oct 2020 13:07:16 +0000 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: <96c85e8b-eca7-f332-2d45-2bd7923e10d7@foobar.org> References: <96c85e8b-eca7-f332-2d45-2bd7923e10d7@foobar.org> Message-ID: > On 28 Oct 2020, at 12:08, Nick Hilliard wrote: > > [...] >> Do we need some text about "recovery if not announced and used" ? > > tl;dr: no. +1 From max at rfc2324.org Wed Oct 28 14:12:26 2020 From: max at rfc2324.org (Maximilian Wilhelm) Date: Wed, 28 Oct 2020 14:12:26 +0100 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: <96c85e8b-eca7-f332-2d45-2bd7923e10d7@foobar.org> References: <96c85e8b-eca7-f332-2d45-2bd7923e10d7@foobar.org> Message-ID: <20201028131226.GM22874@principal.rfc2324.org> Anno domini 2020 Nick Hilliard scripsit: > JORDI PALET MARTINEZ via address-policy-wg wrote on 28/10/2020 12:05: > > However, in RIPE NCC, if you created several LIRs for getting more > > IPv4 allocations, *even if you don't use/need it* you can get (and > > thus stockpile) IPv6 *at no extra cost*. > [...] > > Do we need some text about "recovery if not announced and used" ? > > tl;dr: no. What he said. Best Max -- "Wer nicht mehr liebt und nicht mehr irrt, der lasse sich begraben." -- Johann Wolfgang von Goethe From jim at rfc1035.com Wed Oct 28 14:16:43 2020 From: jim at rfc1035.com (Jim Reid) Date: Wed, 28 Oct 2020 13:16:43 +0000 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: References: Message-ID: > On 28 Oct 2020, at 12:05, JORDI PALET MARTINEZ via address-policy-wg wrote: > > However, in RIPE NCC, if you created several LIRs for getting more IPv4 allocations, *even if you don't use/need it* you can get (and thus stockpile) IPv6 *at no extra cost*. > > I clearly think this is not a good thing. Why? What actual problems is this alleged stockpiling causing? Is there any v6 stockpiling taking place? Why would anyone need/want to stockpile v6 when the *lowest* allocation they?d get gives them orders of magnitude more address space than they could ever hope to use. I think the onus is on you to provide a clear problem statement before making policy proposals. It?s not at all clear there?s an actual problem to solve. From me at cynthia.re Wed Oct 28 14:18:17 2020 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Wed, 28 Oct 2020 14:18:17 +0100 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: <53F426FB-9995-4788-928A-392D25AED0B6@consulintel.es> References: <53F426FB-9995-4788-928A-392D25AED0B6@consulintel.es> Message-ID: Jordi, > Exactly, that?s the point, there is no incentive ? the only incentive is stockpiling, This was not at all my point, my point was that there is no incentive to stockpile IPv6 addresses. This is not a real issue, this is just trying to add more bureaucracy for no reason. -Cynthia On Wed, 28 Oct 2020, 13:51 JORDI PALET MARTINEZ via address-policy-wg, < address-policy-wg at ripe.net> wrote: > Hi Cynthia, > > > > Exactly, that?s the point, there is no incentive ? the only incentive is > stockpiling, just in case IPv6 becomes scarse and may create a problem like > the lack of IPv4, even if this takes 30 years, or 100 years, and you want > to secure the funding of the kids of your kids by having a resource that > then, will be subjected to market price and transfers. > > > > If I understood correctly from Nikolas presentation (please, correct me if > I?m wrong), the bigger ISPs, typically have a single LIR with a big > allocation, but they don?t have (because they aren?t typically interested > in games, just justified need), multiple LIRs with multiple IPv6 > allocations (or at least not big ones). > > > > Regards, > > Jordi > > > > > > El 28/10/20 13:47, "address-policy-wg en nombre de Cynthia Revstr?m via > address-policy-wg" address-policy-wg at ripe.net> escribi?: > > > > Hi, > > > > While I will admit it's a bit odd to allocate that much v6 space to a > single entity, I don't see how this is going to cause issues based on what > is currently happening, like this is not happening at scale. > > > > Sure there might be a /21 (256x /29) of IPv6 space assigned to LIRs who > already had a /29. but there are many large ISPs who alone have more space > than this. Telia has a /20, China Telecom has a /16. > > > > Additionally there is no real incentive to request multiple /29s other > than very rare cases. unless LIRs requesting like 16x /29s are a common > occurrence, this is a non issue imo. > > > > disclaimer: I do have 3x /29 for a reason that may seem like a waste to > some people and my specific issue could probably be solved by RIPE allowing > me to split my /29 into /32s. > > > > -Cynthia > > > > On Wed, 28 Oct 2020, 13:05 JORDI PALET MARTINEZ via address-policy-wg, < > address-policy-wg at ripe.net> wrote: > > Hi all, > > After Nikolas presentation today, I've been thinking on possible ways to > resolve this, so before sending a possible policy proposal, I think it > deserves some discussion. > > The intent of the proposal 2018-01 ( > https://www.ripe.net/participate/policies/proposals/2018-01), was to > align the IPv4 and IPv6 policies in the matter of an LIR vs organization. > > We must remind that the allocation/assignment of resources is based on > justified need. And yes, we have a lot of IPv6 space, but it is really > justified and the same organization, having different LIRs, can use it as a > trick for stockpiling if there is not such justified need? > > In IPv4 this is not "a problem" because we don't have more space. Well ... > not exactly true ... some organizations could have used "the trick" to get > more IPv4 space by creating multiple LIRs. > > In other regions, I think this is not a problem because the cost of the > membership is not per "LIR" (flat rate in RIPE NCC), but based on the size > of the allocation/assignment. So, because IPv6 is not a scarce resource, it > seems there is no incentive to pay more for getting more if you're not > really using it. > > However, in RIPE NCC, if you created several LIRs for getting more IPv4 > allocations, *even if you don't use/need it* you can get (and thus > stockpile) IPv6 *at no extra cost*. > > I clearly think this is not a good thing. > > It seems to me that the problem lies in section 5.1.1. Initial allocation > criteria, and exactly here: > b) have a plan for making sub-allocations to other organisations and/or > End Site assignments within two years. > > So, is the problem that "a plan" is not sufficient if it is not "verified" > and the "bad guys" know that the chances for having it verified are too > small? > > Do we need some text about "recovery if not announced and used" ? > > Other ideas? > > Remember that the problem is not only about scarcity. This extra space may > be used "intermittently" for bad or even criminal activities and we have a > responsibility on that as a community. > > Regards, > Jordi > @jordipalet > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at karotte.org Wed Oct 28 14:20:40 2020 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Wed, 28 Oct 2020 14:20:40 +0100 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: References: Message-ID: <20201028132040.gofyhxmoau6m7jx2@danton.fire-world.de> * JORDI PALET MARTINEZ via address-policy-wg [2020-10-28 13:06]: > It seems to me that the problem lies in section 5.1.1. Initial > allocation criteria, and exactly here: b) have a plan for making > sub-allocations to other organisations and/or End Site assignments > within two years. > > So, is the problem that "a plan" is not sufficient if it is not > "verified" and the "bad guys" know that the chances for having it > verified are too small? The "bad guys" could just add assignments and the plan is verified. The fundamental question is, why would "bad guys" want to stockpile IPv6 in any way that would hurt us as a community? What would be the ROI for them? I see this as a non-problem. > Do we need some text about "recovery if not announced and used" ? No. > Other ideas? Just leave it as it is until we actually have a problem or can see a problem arising. > Remember that the problem is not only about scarcity. This extra > space may be used "intermittently" for bad or even criminal > activities and we have a responsibility on that as a community. Well as long as filtering and RPKI is not perfect this can be done with a lot of other address space without leaving your contact data with the RIPE NCC. Regards Sebastian -- GPG Key: 0x58A2D94A93A0B9CE (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: 959 bytes Desc: not available URL: From jim at rfc1035.com Wed Oct 28 14:38:01 2020 From: jim at rfc1035.com (Jim Reid) Date: Wed, 28 Oct 2020 13:38:01 +0000 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: References: <53F426FB-9995-4788-928A-392D25AED0B6@consulintel.es> Message-ID: > On 28 Oct 2020, at 13:18, Cynthia Revstr?m via address-policy-wg wrote: > > This is not a real issue, this is just trying to add more bureaucracy for no reason. +1 IMO this proposal is an utterly pointless and unnecessary make-work exercise. There?s no justification for it. From jim at rfc1035.com Wed Oct 28 14:43:29 2020 From: jim at rfc1035.com (Jim Reid) Date: Wed, 28 Oct 2020 13:43:29 +0000 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: <53F426FB-9995-4788-928A-392D25AED0B6@consulintel.es> References: <53F426FB-9995-4788-928A-392D25AED0B6@consulintel.es> Message-ID: <42DB7EF4-EEBA-4517-9A0D-6085F37B4090@rfc1035.com> > On 28 Oct 2020, at 12:51, JORDI PALET MARTINEZ via address-policy-wg wrote: > > Exactly, that?s the point, there is no incentive ? the only incentive is stockpiling, just in case IPv6 becomes scarse and may create a problem like the lack of IPv4, even if this takes 30 years, or 100 years, and you want to secure the funding of the kids of your kids by having a resource that then, will be subjected to market price and transfers. This is beyond ridiculous. Why isn?t *anyone* worrying about the Y10K problem? I demand action! :-) PS The ?won't someone think of the children?? emotional rhetoric is a very strong indication someone doesn?t have an evidence-based argument. From jim at rfc1035.com Wed Oct 28 14:51:27 2020 From: jim at rfc1035.com (Jim Reid) Date: Wed, 28 Oct 2020 13:51:27 +0000 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: <8F383005-17DB-4620-B569-AA482007EABF@consulintel.es> References: <3ABB65D4-39D5-44AA-8D23-5ABDC88FF1C8@consulintel.es> <8F383005-17DB-4620-B569-AA482007EABF@consulintel.es> Message-ID: <08CF1AF9-AB4E-450F-AD60-6E6848EFB305@rfc1035.com> > On 28 Oct 2020, at 12:39, JORDI PALET MARTINEZ via address-policy-wg wrote: > > What I don't think is right is that we bypass the justified need. The notion of justified need makes no sense for IPv6. An ISP might give my mum a /64 or a /80. There?s no way she can demonstrate a *need* for so much address space. It?s at least a billion times more space than she could credibly use. Please stop trying to impose now dead IPv4 mindsets on IPv6. From wusel+ml at uu.org Wed Oct 28 14:51:12 2020 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Wed, 28 Oct 2020 14:51:12 +0100 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: References: Message-ID: On 28.10.20 14:16, Jim Reid wrote: > [?] It?s not at all clear there?s an actual problem to solve. This. Regards, -kai From farmer at umn.edu Wed Oct 28 14:56:06 2020 From: farmer at umn.edu (David Farmer) Date: Wed, 28 Oct 2020 08:56:06 -0500 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: <96c85e8b-eca7-f332-2d45-2bd7923e10d7@foobar.org> References: <96c85e8b-eca7-f332-2d45-2bd7923e10d7@foobar.org> Message-ID: On Wed, Oct 28, 2020 at 07:09 Nick Hilliard wrote: > JORDI PALET MARTINEZ via address-policy-wg wrote on 28/10/2020 12:05: > > However, in RIPE NCC, if you created several LIRs for getting more > > IPv4 allocations, *even if you don't use/need it* you can get (and > > thus stockpile) IPv6 *at no extra cost*. > [...] > > Do we need some text about "recovery if not announced and used" ? > > tl;dr: no. > > Nick > > There has never been a requirement to announce address blocks, private use of globally unique addressing is sufficient reason for an allocation in my opinion. Addresses don?t have to be announced to be in use. However, as a matter of basic principle, I think there should be a simple policy statement that completely unused address blocks should be returned to the original allocating RIR, especially if there are no plans to use the address blocks in the foreseeable future, but I don?t believe there needs to be any organized enforcement actions of this basic principle for IPv6 at this time, maybe several decades in the future some level of enforcement could become necessary and prudent. Nevertheless, having this basic principle in policy for several decades before it is needed would prevent any arguments to the contrary, when or if the time for such enforcement ever comes. Thanks -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob at rezero.org Wed Oct 28 14:59:11 2020 From: jacob at rezero.org (Jacob Slater) Date: Wed, 28 Oct 2020 13:59:11 +0000 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: <53F426FB-9995-4788-928A-392D25AED0B6@consulintel.es> References: <53F426FB-9995-4788-928A-392D25AED0B6@consulintel.es> Message-ID: Jordi, Is there currently an instance of mass IPv6 hoarding occurring? Not a theoretical ? an actual instance. Requiring justification for all allocations was required under IPv4 because there was a motivation to hoard that simply doesn?t exist under IPv6. With IPv4, we foresaw a shortage ? and thus a motivation for hoarding ? long before it happened. RFC 1883, the first IPv6 definition, was published in 1995 and cites ?Expanded Addressing Capabilities? as the first major change category. Requiring an allocation to be justified is not the baseline; it is an imposed requirement. It wasn?t imposed for initial /29 allocations to prevent most LIRs from having to spend time justifying a resource that isn?t that scarce, saving both the LIR and the NCC some time and effort. If this results in a LIR ending up with a few /29s in aggregate, I don?t really see a problem ? the resource just isn?t that limited. Regards, Jacob Slater On Wed, Oct 28, 2020 at 12:52 PM JORDI PALET MARTINEZ via address-policy-wg wrote: > > Hi Cynthia, > > > > Exactly, that?s the point, there is no incentive ? the only incentive is stockpiling, just in case IPv6 becomes scarse and may create a problem like the lack of IPv4, even if this takes 30 years, or 100 years, and you want to secure the funding of the kids of your kids by having a resource that then, will be subjected to market price and transfers. > > > > If I understood correctly from Nikolas presentation (please, correct me if I?m wrong), the bigger ISPs, typically have a single LIR with a big allocation, but they don?t have (because they aren?t typically interested in games, just justified need), multiple LIRs with multiple IPv6 allocations (or at least not big ones). > > > > Regards, > > Jordi > > > > > > El 28/10/20 13:47, "address-policy-wg en nombre de Cynthia Revstr?m via address-policy-wg" escribi?: > > > > Hi, > > > > While I will admit it's a bit odd to allocate that much v6 space to a single entity, I don't see how this is going to cause issues based on what is currently happening, like this is not happening at scale. > > > > Sure there might be a /21 (256x /29) of IPv6 space assigned to LIRs who already had a /29. but there are many large ISPs who alone have more space than this. Telia has a /20, China Telecom has a /16. > > > > Additionally there is no real incentive to request multiple /29s other than very rare cases. unless LIRs requesting like 16x /29s are a common occurrence, this is a non issue imo. > > > > disclaimer: I do have 3x /29 for a reason that may seem like a waste to some people and my specific issue could probably be solved by RIPE allowing me to split my /29 into /32s. > > > > -Cynthia > > > > On Wed, 28 Oct 2020, 13:05 JORDI PALET MARTINEZ via address-policy-wg, wrote: > > Hi all, > > After Nikolas presentation today, I've been thinking on possible ways to resolve this, so before sending a possible policy proposal, I think it deserves some discussion. > > The intent of the proposal 2018-01 (https://www.ripe.net/participate/policies/proposals/2018-01), was to align the IPv4 and IPv6 policies in the matter of an LIR vs organization. > > We must remind that the allocation/assignment of resources is based on justified need. And yes, we have a lot of IPv6 space, but it is really justified and the same organization, having different LIRs, can use it as a trick for stockpiling if there is not such justified need? > > In IPv4 this is not "a problem" because we don't have more space. Well ... not exactly true ... some organizations could have used "the trick" to get more IPv4 space by creating multiple LIRs. > > In other regions, I think this is not a problem because the cost of the membership is not per "LIR" (flat rate in RIPE NCC), but based on the size of the allocation/assignment. So, because IPv6 is not a scarce resource, it seems there is no incentive to pay more for getting more if you're not really using it. > > However, in RIPE NCC, if you created several LIRs for getting more IPv4 allocations, *even if you don't use/need it* you can get (and thus stockpile) IPv6 *at no extra cost*. > > I clearly think this is not a good thing. > > It seems to me that the problem lies in section 5.1.1. Initial allocation criteria, and exactly here: > b) have a plan for making sub-allocations to other organisations and/or End Site assignments within two years. > > So, is the problem that "a plan" is not sufficient if it is not "verified" and the "bad guys" know that the chances for having it verified are too small? > > Do we need some text about "recovery if not announced and used" ? > > Other ideas? > > Remember that the problem is not only about scarcity. This extra space may be used "intermittently" for bad or even criminal activities and we have a responsibility on that as a community. > > Regards, > Jordi > @jordipalet > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > From paul at prtsystems.ltd.uk Wed Oct 28 15:24:32 2020 From: paul at prtsystems.ltd.uk (Paul Thornton) Date: Wed, 28 Oct 2020 14:24:32 +0000 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: <499f6dc8-b32b-eebc-24d3-73c3593774d6@foobar.org> References: <96c85e8b-eca7-f332-2d45-2bd7923e10d7@foobar.org> <0D0CE3FD-FF71-457D-9015-D9A98B0CE0DA@consulintel.es> <499f6dc8-b32b-eebc-24d3-73c3593774d6@foobar.org> Message-ID: On 28/10/2020 13:03, Nick Hilliard wrote: > Hi Jordi, > > JORDI PALET MARTINEZ via address-policy-wg wrote on 28/10/2020 12:13: >> Could you explain why not? > > because the purpose of a registry is to ensure accurate registration > information rather than to micromanage resources.? As far as I can > see, the RIPE NCC is doing its job here and there's no need to > instruct it to go off and do something else. > > There's no shortage of ipv6 address space and no reason to think that > we will ever end up with a future shortage.? So there is no reason for > people to treat ipv6 address blocks as having future scarcity value, > which means that there is no motivation to "stockpile".? I.e. the > entire basis of your argument is void. +1. I also strongly believe that there is no real problem to solve here. Paul. From dfk at ripe.net Wed Oct 28 15:51:40 2020 From: dfk at ripe.net (Daniel Karrenberg) Date: Wed, 28 Oct 2020 15:51:40 +0100 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: References: Message-ID: On 28 Oct 2020, at 13:33, Aleksey Bulgakov wrote: > I understand that the NCC tries to find additional funds and implements > additional restrictions to force their members to make additional spending. The RIPE NCC does not do that. Daniel From danny at danysek.cz Wed Oct 28 20:12:08 2020 From: danny at danysek.cz (Daniel Suchy) Date: Wed, 28 Oct 2020 20:12:08 +0100 Subject: [address-policy-wg] stockpiling IPv6 In-Reply-To: References: Message-ID: <0380d433-e74c-8178-ed78-34a8fa821426@danysek.cz> Hello, some of these "stockpilled" IPv6 blocks are just result of merges and acquisitions. Business structure changes are happening on regular basis. I don't think there's real problem with LIRs holding multiple /29s. And I'm against any additional bureaucracy just due to hypothetical saving of few IPv6 blocks (it will cost too much time/money at NCC side). In addition, we still need to *promote* IPv6 usage. It's not a good idea to scare LIRS with risk of renumbering their networks due to "too many resources held" after the acquisition happened... Let's keep things simple. This topic seeks for problem where no real problem exists. - Daniel On 10/28/20 1:05 PM, JORDI PALET MARTINEZ via address-policy-wg wrote: > Hi all, > > After Nikolas presentation today, I've been thinking on possible ways to resolve this, so before sending a possible policy proposal, I think it deserves some discussion. > > The intent of the proposal 2018-01 (https://www.ripe.net/participate/policies/proposals/2018-01), was to align the IPv4 and IPv6 policies in the matter of an LIR vs organization. > > We must remind that the allocation/assignment of resources is based on justified need. And yes, we have a lot of IPv6 space, but it is really justified and the same organization, having different LIRs, can use it as a trick for stockpiling if there is not such justified need? > > In IPv4 this is not "a problem" because we don't have more space. Well ... not exactly true ... some organizations could have used "the trick" to get more IPv4 space by creating multiple LIRs. > > In other regions, I think this is not a problem because the cost of the membership is not per "LIR" (flat rate in RIPE NCC), but based on the size of the allocation/assignment. So, because IPv6 is not a scarce resource, it seems there is no incentive to pay more for getting more if you're not really using it. > > However, in RIPE NCC, if you created several LIRs for getting more IPv4 allocations, *even if you don't use/need it* you can get (and thus stockpile) IPv6 *at no extra cost*. > > I clearly think this is not a good thing. > > It seems to me that the problem lies in section 5.1.1. Initial allocation criteria, and exactly here: > b) have a plan for making sub-allocations to other organisations and/or End Site assignments within two years. > > So, is the problem that "a plan" is not sufficient if it is not "verified" and the "bad guys" know that the chances for having it verified are too small? > > Do we need some text about "recovery if not announced and used" ? > > Other ideas? > > Remember that the problem is not only about scarcity. This extra space may be used "intermittently" for bad or even criminal activities and we have a responsibility on that as a community. > > Regards, > Jordi > @jordipalet > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > >