You are here: Home > Participate > Join a Discussion > RIPE Forum
RIPE Forum v1.4.1

Address Policy Working Group

Threaded
Collapse

[address-policy-wg] Policy Reciprocity

User Image

Taiwo Oyewande

2020-10-16 13:34:58 CET

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
User Image

Erik Bais

2020-10-19 15:51:21 CET

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 <address-policy-wg-bounces _at_ ripe _dot_ net> on behalf of Taiwo Oyewande <taiwo.oyewande88 _at_ gmail _dot_ com>
Date: Friday 16 October 2020 at 13:35
To: "address-policy-wg _at_ ripe _dot_ net" <address-policy-wg _at_ ripe _dot_ net>
Cc: Anthony Ubah <ubah.tonyiyke _at_ gmail _dot_ com>
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
User Image

Petrit Hasani

2020-10-20 11:38:45 CET

RIPE NCC staff member

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 <taiwo.oyewande88 _at_ gmail _dot_ com> 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

ripedenis@yahoo.co.uk

2020-10-20 20:30:10 CET

 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 <address-policy-wg-bounces _at_ ripe _dot_ net> on behalf of Taiwo Oyewande <taiwo.oyewande88 _at_ gmail _dot_ com>
Date: Friday 16 October 2020 at 13:35
To: "address-policy-wg _at_ ripe _dot_ net" <address-policy-wg _at_ ripe _dot_ net>
Cc: Anthony Ubah <ubah.tonyiyke _at_ gmail _dot_ com>
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
   

Jim Reid

2020-10-20 23:46:59 CET


> On 20 Oct 2020, at 19:30, ripedenis--- via address-policy-wg <address-policy-wg _at_ ripe _dot_ net> 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.


User Image

Shane Kerr

2020-10-21 09:17:22 CET

Jim,

On 20/10/2020 23.46, Jim Reid wrote:
> 
> 
>> On 20 Oct 2020, at 19:30, ripedenis--- via address-policy-wg <address-policy-wg _at_ ripe _dot_ net> 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

User Image

Erik Bais

2020-10-21 09:20:57 CET

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" <address-policy-wg-bounces _at_ ripe _dot_ net on behalf of jim _at_ rfc1035 _dot_ com> wrote:

    
    
    > On 20 Oct 2020, at 19:30, ripedenis--- via address-policy-wg <address-policy-wg _at_ ripe _dot_ net> 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.
    
    
    

Jim Reid

2020-10-21 10:32:47 CET


> On 21 Oct 2020, at 08:17, Shane Kerr <shane _at_ time-travellers _dot_ org> 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.


User Image

Jordi Palet Martinez

2020-10-21 11:07:04 CET

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" <address-policy-wg-bounces _at_ ripe _dot_ net en nombre de jim _at_ rfc1035 _dot_ com> escribió:



    > On 21 Oct 2020, at 08:17, Shane Kerr <shane _at_ time-travellers _dot_ org> 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.





Jim Reid

2020-10-21 12:16:29 CET


> On 21 Oct 2020, at 10:07, JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg _at_ ripe _dot_ net> 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.
User Image

Jordi Palet Martinez

2020-10-21 12:35:22 CET

El 21/10/20 12:16, "address-policy-wg en nombre de Jim Reid" <address-policy-wg-bounces _at_ ripe _dot_ net en nombre de jim _at_ rfc1035 _dot_ com> escribió:


    > On 21 Oct 2020, at 10:07, JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg _at_ ripe _dot_ net> 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.





User Image

Gert Doering

2020-10-21 13:06:55 CET

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
User Image

Gert Doering

2020-10-21 13:09:06 CET

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

Nick Hilliard

2020-10-21 13:16:18 CET

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

User Image

Jordi Palet Martinez

2020-10-21 13:40:30 CET

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" <address-policy-wg-bounces _at_ ripe _dot_ net en nombre de gert _at_ space _dot_ net> 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.





User Image

Gert Doering

2020-10-21 13:58:29 CET

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

ripedenis@yahoo.co.uk

2020-10-21 14:10:16 CET

 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 <nick _at_ foobar _dot_ org> 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

  

Jim Reid

2020-10-21 14:22:52 CET


> On 21 Oct 2020, at 13:10, ripedenis--- via address-policy-wg <address-policy-wg _at_ ripe _dot_ net> 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.


Sascha Luck [ml]

2020-10-21 15:49:25 CET

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


User Image

Hank Nussbacher

2020-10-21 16:06:37 CET

  
    
    body p { margin-bottom: 0cm; margin-top: 0pt; } 
  
  
    On 21/10/2020 13:16, Jim Reid wrote:
    
    8D7725A9-F87D-4E66-9F1C-FFE9445C2BB6 _at_ rfc1035 _dot_ com">
      
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

ripedenis@yahoo.co.uk

2020-10-21 16:32:02 CET

 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] <apwg _at_ c4inet _dot_ net> 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


  

Sascha Luck [ml]

2020-10-21 16:58:39 CET

Hi Denis,

On Wed, Oct 21, 2020 at 02:32:02PM +0000, ripedenis _at_ yahoo.co _dot_ 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

User Image

Randy Bush

2020-10-21 18:46:15 CET

> 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

User Image

Erik Bais

2020-10-22 16:42:56 CET

>     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" <address-policy-wg-bounces _at_ ripe _dot_ net on behalf of address-policy-wg _at_ ripe _dot_ net> 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" <address-policy-wg-bounces _at_ ripe _dot_ net en nombre de gert _at_ space _dot_ net> 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.