question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?
Hi all, I keep thinking that ripe-682 (RIPE resource transfer policies), should have a provision (as it is the case in all the other RIRs), in order to "convert" the legacy resources to non-legacy, when they got transferred. I don't really recall if this was discussed during the relevant proposal discussion, and it will be great if someone can summarize it (I guess the author or chairs, or even the staff). I think we should consider amend that, unless the reasons it was not done at that time, persist today, or even if those reasons persist, may be the community has a different view. I think the text should be something such as: IPv4 legacy resources will no longer be regarded as legacy resources: - In the case of intra-RIR transfers. - In the case of inter-RIR, when incoming to RIPE service region. I think this is a benefit for the global community, because with that, we bring into the RIR system more and more legacy IPv4 resources, which increase the transparency and community control. In a presentation from ARIN for the 2016-2018 period it has been mention: - Overall space managed by ARIN decreased by ~14 million IPv4 addresses, due to Inter-RIR transfers - Overall ARIN issued space increased by ~30 million IPv4 addresses, due primarily to conversion of legacy space via in-region transfers Opinions? 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.
Hi, On Sat, Jul 13, 2019 at 01:37:19PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote:
I keep thinking that ripe-682 (RIPE resource transfer policies), should have a provision (as it is the case in all the other RIRs), in order to "convert" the legacy resources to non-legacy, when they got transferred.
What is it that you want to achieve with this? Legacy resources can be converted to PA today, if the holder wants that, but this is orthogonal to whether or not a transfer happened.
I think this is a benefit for the global community, because with that, we bring into the RIR system more and more legacy IPv4 resources, which increase the transparency and community control.
Legacy resources that are documented in the RIPE database *are* transparently documented today. Those get updated in a transfer, even if still "legacy". For legacy resources that are transferred outside RIPE NCC control, there is no lever to force the holders to do anything.
In a presentation from ARIN for the 2016-2018 period it has been mention: - Overall space managed by ARIN decreased by ~14 million IPv4 addresses, due to Inter-RIR transfers - Overall ARIN issued space increased by ~30 million IPv4 addresses, due primarily to conversion of legacy space via in-region transfers
Opinions?
We're not ARIN :-) - we have our own set of "how to deal with legacy addresses and address holders" policies, and they seem to serve us reasonably well. So: what is the problem that you want to address? 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
Hi Gert, I know we aren't ARIN and I've used that only as an example of the results of that provision. My personal view but looking for the good of the community is that it is better to get rid ASAP of the "legacy" status for as much resources we can, so they are fully part of the policy system. I think it is difficult to have a better opinion on this without understanding if I'm missing something from the original proposal discussion on this aspect. Regards, Jordi @jordipalet El 13/7/19 13:56, "address-policy-wg en nombre de Gert Doering" <address-policy-wg-bounces@ripe.net en nombre de gert@space.net> escribió: Hi, On Sat, Jul 13, 2019 at 01:37:19PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: > I keep thinking that ripe-682 (RIPE resource transfer policies), should have a provision (as it is the case in all the other RIRs), in order to "convert" the legacy resources to non-legacy, when they got transferred. What is it that you want to achieve with this? Legacy resources can be converted to PA today, if the holder wants that, but this is orthogonal to whether or not a transfer happened. > I think this is a benefit for the global community, because with that, we bring into the RIR system more and more legacy IPv4 resources, which increase the transparency and community control. Legacy resources that are documented in the RIPE database *are* transparently documented today. Those get updated in a transfer, even if still "legacy". For legacy resources that are transferred outside RIPE NCC control, there is no lever to force the holders to do anything. > In a presentation from ARIN for the 2016-2018 period it has been mention: > - Overall space managed by ARIN decreased by ~14 million IPv4 addresses, due to Inter-RIR transfers > - Overall ARIN issued space increased by ~30 million IPv4 addresses, due primarily to conversion of legacy space via in-region transfers > > Opinions? We're not ARIN :-) - we have our own set of "how to deal with legacy addresses and address holders" policies, and they seem to serve us reasonably well. So: what is the problem that you want to address? 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.
Hi, On Sat, Jul 13, 2019 at 02:04:11PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote:
My personal view but looking for the good of the community is that it is better to get rid ASAP of the "legacy" status for as much resources we can, so they are fully part of the policy system.
We have no contractual leverance to do anything to "legacy" addresses. These are addresses that were assigned outside the RIR system, so there exists no contracts with any RIR, and no way we can use our policies to make the holders do something "we want them to do". We can entice them to bring their space into the umbrella of RIPE DB documentation (by offering ROAs, for example) - and this is what we do today. Gert Doering -- NetMaster -- 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
You're right for addresses not being transferred. This is the same in other RIRs if those resources aren't transferred. What I'm suggesting will only be useful for those addresses that want to be transferred (within or to RIPE), but that's still sufficiently useful, in my opinion. If legacy holders, want to transfers those resources and escape from fulfilling the policies and contractual requirements, now they can do it in RIPE, but not in other regions. In my opinion this is bad for RIPE, because it means we may end up having here more and more non-policy/contractual-bound resources than the other regions that have this provision. In only see good thing doing that, and nothing bad, if we as a community want to have as much as possible everybody engaged with the same rules. Regards, Jordi @jordipalet El 13/7/19 14:21, "address-policy-wg en nombre de Gert Doering" <address-policy-wg-bounces@ripe.net en nombre de gert@space.net> escribió: Hi, On Sat, Jul 13, 2019 at 02:04:11PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: > My personal view but looking for the good of the community is that it is better to get rid ASAP of the "legacy" status for as much resources we can, so they are fully part of the policy system. We have no contractual leverance to do anything to "legacy" addresses. These are addresses that were assigned outside the RIR system, so there exists no contracts with any RIR, and no way we can use our policies to make the holders do something "we want them to do". We can entice them to bring their space into the umbrella of RIPE DB documentation (by offering ROAs, for example) - and this is what we do today. Gert Doering -- NetMaster -- 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.
Hi, On Sat, Jul 13, 2019 at 02:27:03PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote:
If legacy holders, want to transfers those resources and escape from fulfilling the policies and contractual requirements, now they can do it in RIPE, but not in other regions.
Repeat with me: there is no contract of any sort that the RIPE community can use to make legacy resource holders do *anything* unless they want it themselves. (And if they *want* to bring their space under the RIPE umbrella, they can do it today already). Gert Doering -- NetMaster -- 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
Hi Gert, If the received of the transfer is already bound by contracts with RIPE, he is the one that will "convert" the resources to non-legacy accepting that transfer. Of course, transfers from non-legacy holders to non-legacy holders are outside of the system. Regards, Jordi @jordipalet El 13/7/19 14:43, "address-policy-wg en nombre de Gert Doering" <address-policy-wg-bounces@ripe.net en nombre de gert@space.net> escribió: Hi, On Sat, Jul 13, 2019 at 02:27:03PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: > If legacy holders, want to transfers those resources and escape from fulfilling the policies and contractual requirements, now they can do it in RIPE, but not in other regions. Repeat with me: there is no contract of any sort that the RIPE community can use to make legacy resource holders do *anything* unless they want it themselves. (And if they *want* to bring their space under the RIPE umbrella, they can do it today already). Gert Doering -- NetMaster -- 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.
Hi Jordy, Legacy resources don’t fall under the contractual obligations that we as a community have setup. Financial or policy, unless decided/afreed upon by legacy resources themselves. That is described in the policy document RIPE NCC services for legacy resource holders. ( https://www.ripe.net/publications/docs/ripe-639 ) If you would view the RIPE NCC as a holder of IP space, that provides resources when a membership is present. If a member would not pay, the resources could be revoked. Legacy holders didn’t receive the resources from RIPE NCC and their resources can’t be revoked. As the RIPE NCC isn’t the top holder of the resource. If legacy is handed back, it would ( should ) go to IANA .. With the legacy services policy it was decided that the historic rights of legacy holders are honored and only if they decide that they want to include themselves in the community and services, it is possible. But only by their own decision. Stripping the legacy resource status after a transfer, would change the holder of the resource from the seller to the rir instead of the seller to the buyer. The RIPE NCC is providing an administrative service to maintain an accurate registry, also including Legacy resources.. Changing the legal status of legacy resources by force, will open up the RIPE NCC for liability charges and due to its monopoly in the RIPE region, that is not a good plan ... and knowing some Legacy holders, that is going to be a huge no-go. Your last email stated that non-legacy holder to non-legacy holder transfers are outside the system .. if we regard the RIPE policies inside the system ... non-legacy resources are ‘IN’ the system.. because you would say that they would be PI holders or RIPE NCC members ( LIR’s ) ... Legacy holder can be outside ( no contract ) the rir status .. or by their own choice inside the system .. Hope this explains a bit. Regards, Erik Bais Verstuurd vanaf mijn iPhone Op 13 jul. 2019 om 14:49 heeft JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>> het volgende geschreven: Hi Gert, If the received of the transfer is already bound by contracts with RIPE, he is the one that will "convert" the resources to non-legacy accepting that transfer. Of course, transfers from non-legacy holders to non-legacy holders are outside of the system. Regards, Jordi @jordipalet El 13/7/19 14:43, "address-policy-wg en nombre de Gert Doering" <address-policy-wg-bounces@ripe.net<mailto:address-policy-wg-bounces@ripe.net> en nombre de gert@space.net<mailto:gert@space.net>> escribió: Hi, On Sat, Jul 13, 2019 at 02:27:03PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: If legacy holders, want to transfers those resources and escape from fulfilling the policies and contractual requirements, now they can do it in RIPE, but not in other regions. Repeat with me: there is no contract of any sort that the RIPE community can use to make legacy resource holders do *anything* unless they want it themselves. (And if they *want* to bring their space under the RIPE umbrella, they can do it today already). Gert Doering -- NetMaster -- 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.
Legacy resources don’t fall under the contractual obligations that we as a community have setup. Financial or policy, unless decided/afreed upon by legacy resources themselves.
in a police state, there is no concern for contractual obligations from the ncc 'certifying' net engs to proposals such as this, we are heading down a very slippery slope. we are not, well at least should not be, the net police or regulatory body. randy
From a personal perspective, i would have preferred that no status changes are possible at all. However, some years ago, i did let that personal
Hi, Disclaimer: the organization i work for is a LIR and has legacy resources (both self-owned and sponsored). preference fall, in order to achieve a greater good, which was enabling RIPE NCC services to Legacy Resource Holders (proposal 2012-07, from aug/2012 to oct/2013). The bit i (still) don't like in the status change is "rewriting history". If it was pre-RIR, then it should remain pre-RIR. Because changing it can have some future (and unforeseen) implications. But the possibility of status change was included anyway in the proposal, as long as the holder agrees, in the process to regulate how RIPE NCC provides services to LRHs (which was, honestly, needed).
From the financial point of view, if the status is kept, EUR 50 per legacy block per year need to be payed (and the sucessive NCC boards have not changed the value since), and if the status is changed then the resources are binded to RIPE community policies, which might translate as integration in a LIR... so no extra EUR per year are payed.
The possible pitfall with changing the status is if the LIR violates RIPE policies (more than once), and then the *former* legacy block can be de-registered... My understanding (and i'm not a lawyer, so i won't risk any comments about liability) is that the RIPE NCC can't force anything to a Legacy Resource Holder, outside the established contract for services provision. That one, also states the possibility for the RIPE NCC to stop providing said services -- but this doesn't mean de-registering. In practice, it means no access to the Certification service. Not sure about reverse DNS, though... To sum up, i agree with Gert... and as i see it, the only thing RIPE NCC (and or the community) can do about legacy space is stop providing services -- but not, perhaps the most important one: registration in the whois database. Cheers, Carlos On Sun, 14 Jul 2019, Erik Bais wrote:
Hi Jordy, Legacy resources don?t fall under the contractual obligations that we as a community have setup. Financial or policy, unless decided/afreed upon by legacy resources themselves. That is described in the policy document RIPE NCC services for legacy resource holders. ( https://www.ripe.net/publications/docs/ripe-639 )
If you would view the RIPE NCC as a holder of IP space, that provides resources when a membership is present. If a member would not pay, the resources could be revoked. Legacy holders didn?t receive the resources from RIPE NCC and their resources can?t be revoked. As the RIPE NCC isn?t the top holder of the resource. If legacy is handed back, it would ( should ) go to IANA ..
With the legacy services policy it was decided that the historic rights of legacy holders are honored and only if they decide that they want to include themselves in the community and services, it is possible. But only by their own decision.
Stripping the legacy resource status after a transfer, would change the holder of the resource from the seller to the rir instead of the seller to the buyer.
The RIPE NCC is providing an administrative service to maintain an accurate registry, also including Legacy resources..
Changing the legal status of legacy resources by force, will open up the RIPE NCC for liability charges and due to its monopoly in the RIPE region, that is not a good plan ... and knowing some Legacy holders, that is going to be a huge no-go.
Your last email stated that non-legacy holder to non-legacy holder transfers are outside the system .. if we regard the RIPE policies inside the system ... non-legacy resources are ?IN?the system.. because you would say that they would be PI holders or RIPE NCC members ( LIR?s ) ... Legacy holder can be outside ( no contract ) the rir status .. or by their own choice inside the system ..
Hope this explains a bit.
Regards, Erik Bais
Verstuurd vanaf mijn iPhone Op 13 jul. 2019 om 14:49 heeft JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg@ripe.net> het volgende geschreven:
Hi Gert,
If the received of the transfer is already bound by contracts with RIPE, he is the one that will "convert" the resources to non-legacy accepting that transfer.
Of course, transfers from non-legacy holders to non-legacy holders are outside of the system.
Regards, Jordi @jordipalet
El 13/7/19 14:43, "address-policy-wg en nombre de Gert Doering" <address-policy-wg-bounces@ripe.net en nombre de gert@space.net> escribió:
Hi,
On Sat, Jul 13, 2019 at 02:27:03PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: If legacy holders, want to transfers those resources and escape from fulfilling the policies and contractual requirements, now they can do it in RIPE, but not in other regions.
Repeat with me: there is no contract of any sort that the RIPE community can use to make legacy resource holders do *anything* unless they want it themselves.
(And if they *want* to bring their space under the RIPE umbrella, they can do it today already).
Gert Doering -- NetMaster -- 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.
hi carlos,
My understanding (and i'm not a lawyer, so i won't risk any comments about liability) is that the RIPE NCC can't force anything to a Legacy Resource Holder, outside the established contract for services provision. That one, also states the possibility for the RIPE NCC to stop providing said services -- but this doesn't mean de-registering. In practice, it means no access to the Certification service. Not sure about reverse DNS, though...
the actual paperwork does, well did two months ago, include an *option* for the ncc to stop providing reverse dns. i suspect they would not exercise the option except in egregious circumstances. randy
Hi Erik, I’m not sure if I’m being able to explain myself … I know about ripe-639. What I’m saying is that we force the change of status from non-legacy to legacy if addresses are transferred to a new member or an existing member, as both of them will have all the legal bindings already with RIPE NCC. 639 was defined a couple of years before the transfers policy. It may be perfectly possible that at that time it was not considered this aspect. I know that every region is different, but we live in a global Internet, and it is surprising to me that we are the only out of 5 RIRs, that has not done this already. Regards, Jordi @jordipalet El 14/7/19 14:40, "address-policy-wg en nombre de Erik Bais" <address-policy-wg-bounces@ripe.net en nombre de ebais@a2b-internet.com> escribió: Hi Jordy, Legacy resources don’t fall under the contractual obligations that we as a community have setup. Financial or policy, unless decided/afreed upon by legacy resources themselves. That is described in the policy document RIPE NCC services for legacy resource holders. ( https://www.ripe.net/publications/docs/ripe-639 ) If you would view the RIPE NCC as a holder of IP space, that provides resources when a membership is present. If a member would not pay, the resources could be revoked. Legacy holders didn’t receive the resources from RIPE NCC and their resources can’t be revoked. As the RIPE NCC isn’t the top holder of the resource. If legacy is handed back, it would ( should ) go to IANA .. With the legacy services policy it was decided that the historic rights of legacy holders are honored and only if they decide that they want to include themselves in the community and services, it is possible. But only by their own decision. Stripping the legacy resource status after a transfer, would change the holder of the resource from the seller to the rir instead of the seller to the buyer. The RIPE NCC is providing an administrative service to maintain an accurate registry, also including Legacy resources.. Changing the legal status of legacy resources by force, will open up the RIPE NCC for liability charges and due to its monopoly in the RIPE region, that is not a good plan ... and knowing some Legacy holders, that is going to be a huge no-go. Your last email stated that non-legacy holder to non-legacy holder transfers are outside the system .. if we regard the RIPE policies inside the system ... non-legacy resources are ‘IN’ the system.. because you would say that they would be PI holders or RIPE NCC members ( LIR’s ) ... Legacy holder can be outside ( no contract ) the rir status .. or by their own choice inside the system .. Hope this explains a bit. Regards, Erik Bais Verstuurd vanaf mijn iPhone Op 13 jul. 2019 om 14:49 heeft JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg@ripe.net> het volgende geschreven: Hi Gert, If the received of the transfer is already bound by contracts with RIPE, he is the one that will "convert" the resources to non-legacy accepting that transfer. Of course, transfers from non-legacy holders to non-legacy holders are outside of the system. Regards, Jordi @jordipalet El 13/7/19 14:43, "address-policy-wg en nombre de Gert Doering" <address-policy-wg-bounces@ripe.net en nombre de gert@space.net> escribió: Hi, On Sat, Jul 13, 2019 at 02:27:03PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: If legacy holders, want to transfers those resources and escape from fulfilling the policies and contractual requirements, now they can do it in RIPE, but not in other regions. Repeat with me: there is no contract of any sort that the RIPE community can use to make legacy resource holders do *anything* unless they want it themselves. (And if they *want* to bring their space under the RIPE umbrella, they can do it today already). Gert Doering -- NetMaster -- 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. ********************************************** 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.
Hi Jordi.
I know about ripe-639.
What I’m saying is that we force the change of status from non-legacy to legacy if addresses are transferred to a new member or an existing member, as both of them will have all the legal bindings already with RIPE NCC.
A legal entity can have zero, one or more LIRs. You are saying that we can abuse the contract that we have with those with one or more LIRs to force them into a position that we don't apply to those with zero LIRs? Also: when I have multiple LIRs, which LIR should get the legacy resources? And if I can choose which LIR, then I choose "none".
639 was defined a couple of years before the transfers policy. It may be perfectly possible that at that time it was not considered this aspect.
This is incorrect. We have had transfers since RIPE-441 from December 2008. The choices around transfers were very consciously made.
I know that every region is different, but we live in a global Internet, and it is surprising to me that we are the only out of 5 RIRs, that has not done this already.
RIPE has respect for the rights of the people who came before it :) Sander
Hi Sander, I was referring to inter-RIR transfers, sorry not having been more explicit. I understand that the previous policies were only intra-RIR. The actual ones are both intra and inter. I don't think it is a matter of respect previous rights, because in that case, when we do *any* policy change, we may be not respecting the "previous rights" (conceded by the previous policy), of some members. The PDP is about the good of the overall community even if some times, some decisions aren't the best for the 100%. Regards, Jordi @jordipalet El 15/7/19 0:50, "Sander Steffann" <sander@steffann.nl> escribió: Hi Jordi. > I know about ripe-639. > > What I’m saying is that we force the change of status from non-legacy to legacy if addresses are transferred to a new member or an existing member, as both of them will have all the legal bindings already with RIPE NCC. A legal entity can have zero, one or more LIRs. You are saying that we can abuse the contract that we have with those with one or more LIRs to force them into a position that we don't apply to those with zero LIRs? Also: when I have multiple LIRs, which LIR should get the legacy resources? And if I can choose which LIR, then I choose "none". > 639 was defined a couple of years before the transfers policy. It may be perfectly possible that at that time it was not considered this aspect. This is incorrect. We have had transfers since RIPE-441 from December 2008. The choices around transfers were very consciously made. > I know that every region is different, but we live in a global Internet, and it is surprising to me that we are the only out of 5 RIRs, that has not done this already. RIPE has respect for the rights of the people who came before it :) Sander ********************************************** 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.
On Sun, 14 Jul 2019 at 17:56, JORDI PALET MARTINEZ via address-policy-wg < address-policy-wg@ripe.net> wrote:
What I’m saying is that we force the change of status from non-legacy to legacy if addresses are transferred to a new member or an existing member, as both of them will have all the legal bindings already with RIPE NCC.
If the goal is to have a correct and updated registry adding criteria by force to transfers is counter productive. For larger address space transactions this will simply lead to transfer of legal entities, or other legal constructs to circumvent the policies. I belive the community should focus strongly on an accurate registry as the main principle. Hans Petter -- -- Hans Petter Holen Mobile +47 45 06 60 54 | hph@oslo.net | http://hph.oslo.net
Hi,
I belive the community should focus strongly on an accurate registry as the main principle.
This ^^^ Sander
On Sun, 21 Jul 2019, Hans Petter Holen wrote:
I belive the community should focus strongly on an accurate registry as the main principle.
+1 Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm
On Sun, Jul 21, 2019 at 05:19:15PM -0400, Hans Petter Holen wrote:
On Sun, 14 Jul 2019 at 17:56, JORDI PALET MARTINEZ via address-policy-wg < address-policy-wg@ripe.net> wrote:
What I???m saying is that we force the change of status from non-legacy to legacy if addresses are transferred to a new member or an existing member, as both of them will have all the legal bindings already with RIPE NCC.
If the goal is to have a correct and updated registry adding criteria by force to transfers is counter productive.
For larger address space transactions this will simply lead to transfer of legal entities, or other legal constructs to circumvent the policies.
I belive the community should focus strongly on an accurate registry as the main principle.
One should remember that "the main" is distinct from "the only". Piotr -- Piotr Strzyżewski Silesian University of Technology, Computer Centre Gliwice, Poland
On 22 Jul 2019, at 14:16, Piotr Strzyzewski via address-policy-wg <address-policy-wg@ripe.net> wrote:
I belive the community should focus strongly on an accurate registry as the main principle.
One should remember that "the main" is distinct from "the only".
Except when those other policies detract from the main one. If we can't maintain an accurate registry, then what's the point?
On Mon, Jul 22, 2019 at 02:24:52PM +0100, Jim Reid wrote:
On 22 Jul 2019, at 14:16, Piotr Strzyzewski via address-policy-wg <address-policy-wg@ripe.net> wrote:
I belive the community should focus strongly on an accurate registry as the main principle.
One should remember that "the main" is distinct from "the only".
Except when those other policies detract from the main one. If we can't maintain an accurate registry, then what's the point?
IMHO, this is not the case here. Let's try not to fall in the false dilemma here. Piotr -- Piotr Strzyżewski Silesian University of Technology, Computer Centre Gliwice, Poland
On Mon, Jul 22, 2019 at 03:26:34PM +0200, Piotr Strzyzewski via address-policy-wg wrote:
Except when those other policies detract from the main one. If we can't maintain an accurate registry, then what's the point?
IMHO, this is not the case here. Let's try not to fall in the false dilemma here.
But it is the case... AFAICT, the only "sanction" a RIR has available for any party trading in legacy resources (and refusing to comply with orders to "hand them over") is to refuse to provide registry service for those. That won't stop transfers but will lead to those resources become unregistered or, even worse, incorrectly registered. rgds, Sascha Luck
On Mon, Jul 22, 2019 at 02:51:16PM +0100, Sascha Luck [ml] wrote:
On Mon, Jul 22, 2019 at 03:26:34PM +0200, Piotr Strzyzewski via address-policy-wg wrote:
Except when those other policies detract from the main one. If we can't maintain an accurate registry, then what's the point?
IMHO, this is not the case here. Let's try not to fall in the false dilemma here.
But it is the case... AFAICT, the only "sanction" a RIR has available for any party trading in legacy resources (and refusing to comply with orders to "hand them over") is to refuse to provide registry service for those. That won't stop transfers but will lead to those resources become unregistered or, even worse, incorrectly registered.
This situation pertains to all transfers, and sometimes a 10 year lease is just a 10 year lease, when it's paid monthly. But as for disguising legacy sales by doing them in this manner, you are quite mistaken. Nobody is spending $20 per address and then not having his ownership recorded in Whois. Or virtually nobody. Nobody I know, and I have done over 750 transfers beginning in the early 2000s. If the buyer doesn't get recorded, there is nothing but fighting in court to prevent
Argument against has been already mentioned by Mike Burns. You can find it here: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2019-July/012962.h... the subsequent re-sale of the block by the registrant. No buyer wants to risk waking up to find "his" block is now registered to somebody else in Whois, and the original registrant absconded with the money and disappeared.<< Piotr -- Piotr Strzyżewski Silesian University of Technology, Computer Centre Gliwice, Poland
Piotr Strzyzewski via address-policy-wg wrote on 22/07/2019 14:26:
IMHO, this is not the case here. Let's try not to fall in the false dilemma here.
there's no false dichotomy. Non legacy address space falls under various policies e.g. geographic association and being subject to high RIR costs. These policies are what causes legacy address space to cost more than RIR address space on the address market. If a legacy block is threatened with being converted from something more valuable to something less valuable, then people will avoid the RIR transfer route and we'll end up with less accurate registry info. Nick
"e.g. geographic association" -- really...?????? Cheers, Carlos On Mon, 22 Jul 2019, Nick Hilliard wrote:
Piotr Strzyzewski via address-policy-wg wrote on 22/07/2019 14:26:
IMHO, this is not the case here. Let's try not to fall in the false dilemma here.
there's no false dichotomy.
Non legacy address space falls under various policies e.g. geographic association and being subject to high RIR costs. These policies are what causes legacy address space to cost more than RIR address space on the address market.
If a legacy block is threatened with being converted from something more valuable to something less valuable, then people will avoid the RIR transfer route and we'll end up with less accurate registry info.
Nick
Carlos Friaças wrote on 23/07/2019 22:03:
"e.g. geographic association"
-- really...??????
Yep, really. https://www.nro.net/wp-content/uploads/comp-pol-2018v2.pdf see Section 1.3.4 - Out of region Use. + also: https://afrinic.net/policy/manual
5.4.6.2 AFRINIC resources are for AFRINIC service region and any use outside the region should be solely in support of connectivity back to the AFRINIC region. Nick
Hi Nick, All, On Tue, 23 Jul 2019, Nick Hilliard wrote:
Carlos Friaças wrote on 23/07/2019 22:03:
"e.g. geographic association"
-- really...??????
Yep, really.
Nice to have that written down (i.e. in a document, referring to an actual policy). However... how far is that (the geographic association bit) from operational reality...?
see Section 1.3.4 - Out of region Use.
+ also: https://afrinic.net/policy/manual
5.4.6.2 AFRINIC resources are for AFRINIC service region and any use outside the region should be solely in support of connectivity back to the AFRINIC region.
"in support of connectivity back to <some> region" Really sounds like a joke. Everything will fit... Anyway, nothing about that on the other four regions.....? :-) Cheers, Carlos
Nick
Carlos Friaças wrote on 24/07/2019 08:28:
However... how far is that (the geographic association bit) from operational reality...?
It means that if you breach the policy, then it's a policy violation, and the RIR policy violation procedures apply. Nick
On Mon, Jul 22, 2019 at 02:53:43PM +0100, Nick Hilliard wrote:
Piotr Strzyzewski via address-policy-wg wrote on 22/07/2019 14:26:
IMHO, this is not the case here. Let's try not to fall in the false dilemma here.
there's no false dichotomy.
Non legacy address space falls under various policies e.g. geographic association and being subject to high RIR costs. These policies are what causes legacy address space to cost more than RIR address space on the address market.
If a legacy block is threatened with being converted from something more valuable to something less valuable, then people will avoid the RIR transfer route and we'll end up with less accurate registry info.
Jordi has assured us, that those practices are in place in other RIRs (I am not using this as an argument in the discussion). Do you have any stats or observations from other RIRs to support such sinister prophecy? Piotr -- Piotr Strzyżewski Silesian University of Technology, Computer Centre Gliwice, Poland
On 22 Jul 2019, at 14:26, Piotr Strzyzewski via address-policy-wg <address-policy-wg@ripe.net> wrote:
IMHO, this is not the case here. Let's try not to fall in the false dilemma here.
I'm sorry Piotr, I strongly disagree. The idea that was being proposed imposes retroactive conditions on legacy address holders. Which is very wrong. Policies should never be imposed retroactively. If implemented, the suggested policy will discourage legacy holders from co-operating with the NCC, Which in turn encourages "creative" solutions to get around that hypothetical problem and therefore bring about new ways to undermine the integrity of the NCC database. I fail to see what the false dichotomy is. Or could be.
Disclaimer: i'm not deeply interested in transfers, that's not what the org i work for usually does... :) (please see inline) On Mon, 22 Jul 2019, Jim Reid wrote:
On 22 Jul 2019, at 14:26, Piotr Strzyzewski via address-policy-wg <address-policy-wg@ripe.net> wrote:
IMHO, this is not the case here. Let's try not to fall in the false dilemma here.
I'm sorry Piotr, I strongly disagree. The idea that was being proposed imposes retroactive conditions on legacy address holders. Which is very wrong. Policies should never be imposed retroactively.
I also don't really like the idea/concept. However, it may be argued that when a transfer happens, the "new owner" doesn't have the same rights than the legacy resource holder, because it didn't receive the space from the original source. But even with that, i still think a new proposal "converting" the status is not something favourable to a legacy resource holder. Plus, i still think the status shouldn't even be allowed to change... (but i know i'm most likely alone on that one...)
If implemented, the suggested policy will discourage legacy holders from co-operating with the NCC,
It has the same effect on coooperation with ARIN/AFRINIC/APNIC/LACNIC ?
Which in turn encourages "creative" solutions to get around that hypothetical problem and therefore bring about new ways to undermine the integrity of the NCC database.
Well, looking at the other 4 regions' status on this topic, probably the most creative solution is to push the transfer through the RIPE NCC... :-)) Regards, Carlos
I fail to see what the false dichotomy is. Or could be.
On Mon, Jul 22, 2019 at 03:27:27PM +0100, Jim Reid wrote:
On 22 Jul 2019, at 14:26, Piotr Strzyzewski via address-policy-wg <address-policy-wg@ripe.net> wrote:
IMHO, this is not the case here. Let's try not to fall in the false dilemma here.
I'm sorry Piotr, I strongly disagree. The idea that was being proposed imposes retroactive conditions on legacy address holders. Which is very wrong. Policies should never be imposed retroactively.
I fully understand your point of view. However, I see it a bit different. I do not perceive this as proposal which imposes retroactive conditions on legacy address holders. For me there is a clear and strong bond between _original_ legacy resource holder and its legacy address space (resource). That is why I see this as future action against the future holder of the resource after its future transfer.
If implemented, the suggested policy will discourage legacy holders from co-operating with the NCC, Which in turn encourages "creative" solutions to get around that hypothetical problem and therefore bring about new ways to undermine the integrity of the NCC database.
I fail to see what the false dichotomy is. Or could be.
Either, by accepting such ideas, we will be doomed and the registry will become poor quality or, by rejecting such ideas, we will have a good quality registry in the first place. Sorry for exagerrating here. Piotr -- Piotr Strzyżewski Silesian University of Technology, Computer Centre Gliwice, Poland
Thank you for the insight Hans Petter. Accuracy of the registry is the key goal for the community and should be the goal of all proposals. We (AP-WG chairs) don’t see a clear problem description nor sufficient support to proceed with the discussion into a formal PDP process. We like to thank all participants for their input and view in this discussion. Kind regards (on behalf of the AP-WG chair collective) Erik Bais From: address-policy-wg <address-policy-wg-bounces@ripe.net> on behalf of Hans Petter Holen <hph@oslo.net> Reply-To: "hph@oslo.net" <hph@oslo.net> Date: Sunday 21 July 2019 at 23:20 To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Cc: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Subject: Re: [address-policy-wg] question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers? On Sun, 14 Jul 2019 at 17:56, JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>> wrote: What I’m saying is that we force the change of status from non-legacy to legacy if addresses are transferred to a new member or an existing member, as both of them will have all the legal bindings already with RIPE NCC. If the goal is to have a correct and updated registry adding criteria by force to transfers is counter productive. For larger address space transactions this will simply lead to transfer of legal entities, or other legal constructs to circumvent the policies. I belive the community should focus strongly on an accurate registry as the main principle. Hans Petter -- -- Hans Petter Holen Mobile +47 45 06 60 54 | hph@oslo.net<mailto:hph@oslo.net> | http://hph.oslo.net
* Gert Doering
On Sat, Jul 13, 2019 at 01:37:19PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote:
I keep thinking that ripe-682 (RIPE resource transfer policies), should have a provision (as it is the case in all the other RIRs), in order to "convert" the legacy resources to non-legacy, when they got transferred.
What is it that you want to achieve with this?
+1 I've read this entire thread and I still have no idea what the motivation for this (pre-)proposal actually is. Is it a solution in search of a problem? Maybe if you could explain by example, Jordi? Were you involved in a transfer of legacy resources and stumbled across some kind of obstacle caused by current policies (that this proposal addresses)? Tore
Hi Tore, I think my previus email just explained it. The motivation is my personal view that we have a problem (as a community) by not bringing into the system the legacy resources. I'm alone with that view? I don't know, and that's why I'm asking. What is clear to me is that, according to existing policies, I share this view with 4/5 of the RIR communities. What is the effect of that? Simple, an unbalance of transfers among regions, because if someone for whatever reason want to get resources and keep them non-legacy, can just come to RIPE for that. This is good for RIPE? I don't think so, we could keep growing the non-legacy resources, while other regions get "cleaned". Regards, Jordi @jordipalet El 15/7/19 10:05, "address-policy-wg en nombre de Tore Anderson" <address-policy-wg-bounces@ripe.net en nombre de tore@fud.no> escribió: * Gert Doering > On Sat, Jul 13, 2019 at 01:37:19PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: >> I keep thinking that ripe-682 (RIPE resource transfer policies), should have a provision (as it is the case in all the other RIRs), in order to "convert" the legacy resources to non-legacy, when they got transferred. > > What is it that you want to achieve with this? +1 I've read this entire thread and I still have no idea what the motivation for this (pre-)proposal actually is. Is it a solution in search of a problem? Maybe if you could explain by example, Jordi? Were you involved in a transfer of legacy resources and stumbled across some kind of obstacle caused by current policies (that this proposal addresses)? Tore ********************************************** 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.
* JORDI PALET MARTINEZ via address-policy-wg
I think my previus email just explained it.
Not really...
The motivation is my personal view that we have a problem (as a community) by not bringing into the system the legacy resources.
I understand that you have that view. What I fail to understand is *why* you have that view. It might be self-evident to you how this is problematic. It is not to me.
I'm alone with that view? I don't know, and that's why I'm asking.
I'm a firm believer of the «if it ain't broke, don't fix it» approach, and I am yet to be convinced that the current policy is indeed «broke». Do the parties directly impacted by this policy in question, i.e., the legacy resource holders themselves (or would-be recipients of legacy resource transfers), share your view that there is a problem here that needs fixing? (It is unclear to me whether or not you represent such a directly impacted party yourself.)
What is clear to me is that, according to existing policies, I share this view with 4/5 of the RIR communities.
What is the effect of that? Simple, an unbalance of transfers among regions, because if someone for whatever reason want to get resources and keep them non-legacy, can just come to RIPE for that. This is good for RIPE? I don't think so, we could keep growing the non-legacy resources, while other regions get "cleaned".
How is it *bad* for the RIPE community, though? You seem to imply that legacy space is «dirty» and in need of «cleaning» but offer no explanation why. I understand that RPKI is not available for legacy resources in some other regions. Providing legacy holders with the option of moving their resources into the RIPE region might therefore be a net benefit for the Internet community at large (which obviously includes the RIPE community), as it might contribute to better routing security. Tore
Hi Tore, El 15/7/19 12:26, "address-policy-wg en nombre de Tore Anderson" <address-policy-wg-bounces@ripe.net en nombre de tore@fud.no> escribió: * JORDI PALET MARTINEZ via address-policy-wg > I think my previus email just explained it. Not really... > The motivation is my personal view that we have a problem (as a community) by not bringing into the system the legacy resources. I understand that you have that view. What I fail to understand is *why* you have that view. It might be self-evident to you how this is problematic. It is not to me. -> Because I think when there is an unfair situation (some folks bound to rules/policies, others not), there is a problem. > I'm alone with that view? I don't know, and that's why I'm asking. I'm a firm believer of the «if it ain't broke, don't fix it» approach, and I am yet to be convinced that the current policy is indeed «broke». Do the parties directly impacted by this policy in question, i.e., the legacy resource holders themselves (or would-be recipients of legacy resource transfers), share your view that there is a problem here that needs fixing? -> If you're a legacy holder, doesn't on you. If you're going to transfer, doesn't impact on you. The impact is only for the one that receive the transfer. (It is unclear to me whether or not you represent such a directly impacted party yourself.) -> To be clear, I don't have addresses to transfer, neither I'm looking for addresses to get transferred. > What is clear to me is that, according to existing policies, I share this view with 4/5 of the RIR communities. > > What is the effect of that? Simple, an unbalance of transfers among regions, because if someone for whatever reason want to get resources and keep them non-legacy, can just come to RIPE for that. This is good for RIPE? I don't think so, we could keep growing the non-legacy resources, while other regions get "cleaned". How is it *bad* for the RIPE community, though? You seem to imply that legacy space is «dirty» and in need of «cleaning» but offer no explanation why. -> Because is not subjected to the same rules (policies) as the non-legacy one. That's unfair. I understand that RPKI is not available for legacy resources in some other regions. Providing legacy holders with the option of moving their resources into the RIPE region might therefore be a net benefit for the Internet community at large (which obviously includes the RIPE community), as it might contribute to better routing security. Tore ********************************************** 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.
* JORDI PALET MARTINEZ via address-policy-wg
-> Because I think when there is an unfair situation (some folks bound to rules/policies, others not), there is a problem. ... -> Because is not subjected to the same rules (policies) as the non-legacy one. That's unfair.
Thank you for clarifying. I don't believe this «unfairness» rationale had been mentioned before. Others have explained how the legacy resources were given out with no RIR policy strings attached. You could make the opposite argument too, i.e., that it would be unfair behaviour by the RIPE community to try and retroactively annex legacy space in this way by unilaterally applying terms and conditions that were never agreed to in the first place. In any case, and to be perfectly honest, this rationale reads to like petty jealousy to me - «I can't do X with my RIPE ALLOCATED PA, so I don't want others to be able to do X either». I don't believe this kind of policy making is good for the community. I suspect the opposite is true, by turning legacy holders off from engaging with us. Keep in mind that they are under no obligation to do so. A more positive way to approach this perceived unfairness would be to focus on what X is, and see if the RIPE policy can be changed to permit it. Tore
On 15 Jul 2019, at 13:02, Tore Anderson <tore@fud.no> wrote:
I don't believe this kind of policy making is good for the community. I suspect the opposite is true, by turning legacy holders off from engaging with us. Keep in mind that they are under no obligation to do so.
+1
On 15.07.2019 14:02, Tore Anderson wrote:
You could make the opposite argument too, i.e., that it would be unfair behaviour by the RIPE community to try and retroactively annex legacy space in this way by unilaterally applying terms and conditions that were never agreed to in the first place.
Just as a reminder, this actually was done with ripe-452, when space that was handed out in 1993 under the new RIR regime, much later dubbed "PI", got strings attached retroactively: "According to policy detailed in ripe-452 […], a company holding Internet number resources must sign an End User Assignment Agreement with a Local Internet Registry (LIR) of their choice, or with the RIPE NCC directly by becoming a RIPE NCC member (LIR)". Thus there is precedence for "unilaterally applying terms and conditions that were never agreed to in the first place" by the RIPE Community; this happened in 2009 and was applied to address space handed out up to 16 years prior to any such terms and conditions. As for Jordi's approach, I agree with »don't fix it if it ain't broken«, and in terms of Legacy space I fail to see an issue in current policy. Regards, -kai
Hi Tore, El 15/7/19 14:02, "Tore Anderson" <tore@fud.no> escribió: * JORDI PALET MARTINEZ via address-policy-wg > -> Because I think when there is an unfair situation (some folks bound to rules/policies, others not), there is a problem. ... > -> Because is not subjected to the same rules (policies) as the non-legacy one. That's unfair. Thank you for clarifying. I don't believe this «unfairness» rationale had been mentioned before. Others have explained how the legacy resources were given out with no RIR policy strings attached. You could make the opposite argument too, i.e., that it would be unfair behaviour by the RIPE community to try and retroactively annex legacy space in this way by unilaterally applying terms and conditions that were never agreed to in the first place. -> We agree here. It may be considered unfair in one direction or the other one. It depends on the perspective. In any case, and to be perfectly honest, this rationale reads to like petty jealousy to me - «I can't do X with my RIPE ALLOCATED PA, so I don't want others to be able to do X either». -> I don't have resources of any type (legacy neither non-legacy) in any RIR, so my view is trying to be as objective as possible and looking for the fairness of the more global community. I don't believe this kind of policy making is good for the community. I suspect the opposite is true, by turning legacy holders off from engaging with us. Keep in mind that they are under no obligation to do so. -> I guess it is not still clear enoght. This doesn't affect legacy holders. It is only affecting the resources once they got transferred. A more positive way to approach this perceived unfairness would be to focus on what X is, and see if the RIPE policy can be changed to permit it. Tore ********************************************** 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.
On Mon, Jul 15, 2019, at 14:02, Tore Anderson wrote:
In any case, and to be perfectly honest, this rationale reads to like petty jealousy to me - «I can't do X with my RIPE ALLOCATED PA, so I don't want others to be able to do X either».
Hi, I see the situation a little differently: - if my understanding is correct, you can benefit from pretty much same (or most of) services with you legacy space as with your PI/PA space, however you don't really have the same obligations. Correct me if/where I'm wrong. - do you consider something normal that somebody "owns" numbers, just because somebody, someday told them "those are yours" ? I don't. For the moment I have to live with the fact that in many cases (not all) this is what is happening, but I would pretty much appreciate a change. However, pushing for a conversion from legacy to "RIR system" looks very delicate. Not sure that legally it can be forced (probably in some countries the regulator may be able to do something, but I wouldn't count on that). As for "do it for you own good", while this may not work today, some day everybody would better get into the RPKI bandwagon, at which point the RIRs would be in a strong position to "kindly" ask holders to convert the legacy resources to "RIR system". If the will id there, which is an entirely different issue. -- Radu-Adrian FEURDEAN
On Wed, Jul 17, 2019 at 06:01:44PM +0200, Radu-Adrian FEURDEAN wrote:
I see the situation a little differently: - if my understanding is correct, you can benefit from pretty much same (or most of) services with you legacy space as with your PI/PA space, however you don't really have the same obligations. Correct me if/where I'm wrong.
Correct, and the rationale for that is that it's better for the Internet to have these resources documented somewhere.
- do you consider something normal that somebody "owns" numbers, just because somebody, someday told them "those are yours" ? I don't. For the moment I have to live with the fact that in many cases (not all) this is what is happening, but I would pretty much appreciate a change.
Leaving the inherent silliness of "owning" or "administering" integers aside: I own my car because "somebody, someday" told me (after money changing hands, of course) "this is yours". The same applies to the computer I'm writing this on. If you'd like to change this you're welcome to try and take them off me and see how far you get ;)
However, pushing for a conversion from legacy to "RIR system" looks very delicate. Not sure that legally it can be forced (probably in some countries the regulator may be able to do something, but I wouldn't count on that). As for "do it for you own good", while this may not work today, some day everybody would better get into the RPKI bandwagon, at which point the RIRs would be in a strong position to "kindly" ask holders to convert the legacy resources to "RIR system". If the will id there, which is an entirely different issue.
I don't think the RIRs should get into the business of extortion any more than into theft. Nothing good can conceivably come off that. rgds, Sascha Luck
On Wed, 17 Jul 2019, Sascha Luck [ml] wrote: (...)
Leaving the inherent silliness of "owning" or "administering" integers aside:
I own my car because "somebody, someday" told me (after money changing hands, of course) "this is yours". The same applies to the computer I'm writing this on. If you'd like to change this you're welcome to try and take them off me and see how far you get ;)
Hi Sascha, All. If someone tries to hijack your car or your computer, jurisdiction should be clear, and you will know *where* to present a report. That, unfortunately has no paralell for IP addressing -- well, maybe except in the LACNIC region where they have WARP (Warning Advice and Reporting Point). I don't know how many people are aware about WARP's existence, i just found out about it quite recently :-)
However, pushing for a conversion from legacy to "RIR system" looks very delicate. Not sure that legally it can be forced (probably in some countries the regulator may be able to do something, but I wouldn't count on that). As for "do it for you own good", while this may not work today, some day everybody would better get into the RPKI bandwagon, at which point the RIRs would be in a strong position to "kindly" ask holders to convert the legacy resources to "RIR system". If the will id there, which is an entirely different issue.
I don't think the RIRs should get into the business of extortion any more than into theft. Nothing good can conceivably come off that.
Afaik access to the certification service (RPKI) is voluntary and is already available for legacy holders that engage with the RIR system (see ripe-724, republished yesterday from ripe-674 and ripe-615). Regards, Carlos
rgds, Sascha Luck
On Wed, Jul 17, 2019, at 18:28, Sascha Luck [ml] wrote:
Correct, and the rationale for that is that it's better for the Internet to have these resources documented somewhere.
This is about documentation change, not about keeping the documentation in place.
Leaving the inherent silliness of "owning" or "administering" integers aside:
Leaving that aside pretty much means supporting it (the silliness). The legacy vs RIR-administered debate is pretty much about the silliness vs normality of "owning integers".
I own my car because "somebody, someday" told me (after money changing hands, of course) "this is yours". The same applies to the computer I'm writing this on.
No. First, the car and the computer are not under the same regime. For the car, you own it when the registry has been updated with convincing documentation from the former owner. That usually implies some other things are up-to-date (technical control ok - to take some random thing). For the computer, it's pretty much the case, with a few exceptions like "enough" people disagreeing for certain reasons making it "no longer yours".
If you'd like to change this you're welcome to try and take them off me and see how far you get ;)
You do realize that some people do it, and for a computer it works much better than for a car. -- Radu-Adrian FEURDEAN
Hi, El 17/7/19 18:08, "address-policy-wg en nombre de Radu-Adrian FEURDEAN" <address-policy-wg-bounces@ripe.net en nombre de ripe-wgs@radu-adrian.feurdean.net> escribió: On Mon, Jul 15, 2019, at 14:02, Tore Anderson wrote: > In any case, and to be perfectly honest, this rationale reads to like > petty jealousy to me - «I can't do X with my RIPE ALLOCATED PA, so I > don't want others to be able to do X either». Hi, I see the situation a little differently: - if my understanding is correct, you can benefit from pretty much same (or most of) services with you legacy space as with your PI/PA space, however you don't really have the same obligations. Correct me if/where I'm wrong. - do you consider something normal that somebody "owns" numbers, just because somebody, someday told them "those are yours" ? I don't. For the moment I have to live with the fact that in many cases (not all) this is what is happening, but I would pretty much appreciate a change. However, pushing for a conversion from legacy to "RIR system" looks very delicate. Not sure that legally it can be forced (probably in some countries the regulator may be able to do something, but I wouldn't count on that). As for "do it for you own good", while this may not work today, some day everybody would better get into the RPKI bandwagon, at which point the RIRs would be in a strong position to "kindly" ask holders to convert the legacy resources to "RIR system". If the will id there, which is an entirely different issue. -> I don't think this is "delicate" at all. Nobody is being *forced* to do that. If you have legacy, you can do transfers outside the system and nobody can oppose to that. However, please read the complete email from Mike (yesterday), I don't think nobody noticed it ... and they key think here is the protection of the "buyer", which is secured if the addresses are converted to non-legacy. -- Radu-Adrian FEURDEAN ********************************************** 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.
Hi, On Wed, Jul 17, 2019 at 06:48:46PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote:
-> I don't think this is "delicate" at all. Nobody is being *forced* to do that. If you have legacy, you can do transfers outside the system and nobody can oppose to that. However, please read the complete email from Mike (yesterday), I don't think nobody noticed it ... and they key think here is the protection of the "buyer", which is secured if the addresses are converted to non-legacy.
If the buyer sees a benefit in coverting legacy space to non-legacy, they can do this today. Gert Doering -- NetMaster -- 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
We, as a community, should look for the benefit of the community. With that in mind, in that case we should have that to be the *only choice*. Alternatively the buyer can still do the process outside the policy process, because he is opting to not convert the resources to non-legacy. I've already said this, but let me to repeat it: This is my opinion, and it looks was the opinion of the other 4 RIR communities. You opinion can be diverse, of course, but it is clear that I'm not alone. El 17/7/19 19:54, "Gert Doering" <gert@space.net> escribió: Hi, On Wed, Jul 17, 2019 at 06:48:46PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: > -> I don't think this is "delicate" at all. Nobody is being *forced* to do that. If you have legacy, you can do transfers outside the system and nobody can oppose to that. However, please read the complete email from Mike (yesterday), I don't think nobody noticed it ... and they key think here is the protection of the "buyer", which is secured if the addresses are converted to non-legacy. If the buyer sees a benefit in coverting legacy space to non-legacy, they can do this today. Gert Doering -- NetMaster -- 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.
Hi, On Wed, Jul 17, 2019 at 08:01:44PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote:
We, as a community, should look for the benefit of the community.
You still fail to bring forward a clear reasoning this would be so. If you argue "the buyer wants this!" it's not an argument why this would be "beneficial for the community" - but more an argument for why no change is needed.
I've already said this, but let me to repeat it: This is my opinion, and it looks was the opinion of the other 4 RIR communities.
From what I've heard so far, this was not an explicit change but more a "it happened somewhere along the historic evolution of things". So, "the opinion of the other 4 RIR communities" might be exaggerating a slight bit
You opinion can be diverse, of course, but it is clear that I'm not alone.
I fail to see much support for your well-formulated problem statement. Gert Doering -- NetMaster -- 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
Hi Gert, I just sent an email with the clarification of the proposals in the other RIRs. The point here is that what I consider a valid argument (fairness for as much overall community as possible and a bad thing otherwise, so a problem), you think is not. This is a valid disagreement, of course and this is just part of the process to improve our policies. El 17/7/19 20:15, "Gert Doering" <gert@space.net> escribió: Hi, On Wed, Jul 17, 2019 at 08:01:44PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: > We, as a community, should look for the benefit of the community. You still fail to bring forward a clear reasoning this would be so. If you argue "the buyer wants this!" it's not an argument why this would be "beneficial for the community" - but more an argument for why no change is needed. > I've already said this, but let me to repeat it: This is my opinion, and it looks was the opinion of the other 4 RIR communities. From what I've heard so far, this was not an explicit change but more a "it happened somewhere along the historic evolution of things". So, "the opinion of the other 4 RIR communities" might be exaggerating a slight bit > You opinion can be diverse, of course, but it is clear that I'm not alone. I fail to see much support for your well-formulated problem statement. Gert Doering -- NetMaster -- 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.
JORDI PALET MARTINEZ via address-policy-wg wrote on 17/07/2019 19:22:
The point here is that what I consider a valid argument (fairness for as much overall community as possible and a bad thing otherwise, so a problem), you think is not. This is a valid disagreement, of course and this is just part of the process to improve our policies. Jordi,
this has nothing to do with fairness. The RIPE community has a policy for dealing with legacy resources and legacy resource holders. By having this policy, the RIPE Community has openly declared that it accepts that legacy resources are a fair and reasonable part of the number resource ecosystem. Nick
On Wed, Jul 17, 2019 at 08:13:05PM +0200, Gert Doering wrote: Hi,
You opinion can be diverse, of course, but it is clear that I'm not alone.
I fail to see much support for your well-formulated problem statement.
So count me as one of the supporters. I see at least two extra advantages of legacy space being converted to "regular" IP space: 1. RIPE-705 can be enforced on those entities. [1] 2. This close all possible loopholes similar to the one exploited in the past and presented by Janos during October 2016 GM under agenda point 6. [1] Look at two random examples: 151.80.183.140/30 and 192.94.58.0/24. In both cases I don't think that those companies were legacy at all. Piotr -- Piotr Strzyżewski Silesian University of Technology, Computer Centre Gliwice, Poland
On Thu, Jul 18, 2019, at 08:25, Piotr Strzyzewski via address-policy-wg wrote:
I fail to see much support for your well-formulated problem statement.
So count me as one of the supporters. I see at least two extra
Count me too. However, please note that we are AGAIN discussing about IPv4, since this issue does not exist with IPv6 addresses. -- Radu-Adrian FEURDEAN
-> I don't think this is "delicate" at all. Nobody is being *forced* to do that. If you have legacy, you can do transfers outside the system and nobody can oppose to that. However, please read the complete email from Mike (yesterday), I don't think nobody noticed it ... and they key think here is the protection of the "buyer", which is secured if the addresses are converted to non-legacy.
If the buyer sees a benefit in coverting legacy space to non-legacy, they can do this today. Gert Doering -- NetMaster Hi Gert, This is true but also irrelevant. The issue here is whether it is within the purview of the community to recognize transfers of legacy space only in exchange for change of status. What is the principled objection to the community trading the new service (of booked transfers) in exchange for the change of legacy status after the blocks are in the hands of new owners? What imposition is it on legacy holders, who are after all selling their blocks through the agency of the RIR? Don't get me wrong, I love RIPE legacy space and think all space should be similarly governed by the world's registries! RIPE treats legacy space as if RIPE were merely the title registry, registering all legal title changes. It's the imposition of restrictive policies that reduce the value of other blocks, or elevate legacy value if you want to view it that way. As I said earlier, if the restrictive policies disappeared the only bonus value of legacy space is fee avoidance. And really RIR fee avoidance is insignificant for virtually all buyers. Regards, Mike
Hi, On Wed, Jul 17, 2019 at 03:30:08PM -0400, Mike Burns wrote:
What is the principled objection to the community trading the new service (of booked transfers) in exchange for the change of legacy status after the blocks are in the hands of new owners? What imposition is it on legacy holders, who are after all selling their blocks through the agency of the RIR?
This is the wrong question to ask. "Why is changing the current system this way an improvement compared to what we have now? Improvement in which way, exactly, and who benefits?" We do not change policy just to change it, or because someone else did so, but to fix a problem, improve a process, shift unfairness some other way (these are never straightforward), etc. Policy proposals do not come cheap. Bottom-up policy making requires that people spend their time looking at policy proposals, make up their mind, voice their opinion and discuss to come to an agreement. If we flood the system with changes "for the sake of change" that neither have enough support to properly take off, nor have a clearly defined problem statement (that has some amount of support behind it), we are wearing out the system, and people will stop engaging. We already see this effect when trying to get people to comment on other proposals that *do* have a clear problem statement and a tight timeline. 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
Hi Gert, Thanks for your reply, inline answers below. This is the wrong question to ask. "Why is changing the current system this way an improvement compared to what we have now? Improvement in which way, exactly, and who benefits?" We do not change policy just to change it, or because someone else did so, but to fix a problem, improve a process, shift unfairness some other way (these are never straightforward), etc.
Jordi has already expressed the problem and supported his depiction of unfairness that can be shifted. He buttressed his expression by pointing to relevant policies at every other RIR as evidence that he is not alone in his view. I would say he established his problem statement as a desire to shift the unfairness of retaining special address status after the provision of services that never existed for legacy owners before the RIR system. (At least I am unaware of booked transfers being possible to legacy holders prior to the RIR system.)
Policy proposals do not come cheap. Bottom-up policy making requires that people spend their time looking at policy proposals, make up their mind, voice their opinion and discuss to come to an agreement. If we flood the system with changes "for the sake of change" that neither have enough support to properly take off, nor have a clearly defined problem statement (that has some amount of support behind it), we are wearing out the system, and people will stop engaging.
If we flood the system with comments from outside the region, issuing problem statement objections and irrelevancies about RIPE's contractual leverage over legacy holders and legacy holders' ability to voluntarily change status, we could also wear out the system. 😉
Regards, Mike
Hi, On Wed, Jul 17, 2019 at 04:05:05PM -0400, Mike Burns wrote:
Jordi has already expressed the problem and supported his depiction of unfairness that can be shifted. He buttressed his expression by pointing to relevant policies at every other RIR as evidence that he is not alone in his view. I would say he established his problem statement as a desire to shift the unfairness of retaining special address status after the provision of services that never existed for legacy owners before the RIR system. (At least I am unaware of booked transfers being possible to legacy holders prior to the RIR system.)
There is a *difference*, undoubtly so. Whether it is an *unfairness* or not seems to be very much a personal opinion - I have heard more disagrement than agreement. And of course transfers have been possible before the RIRs existed :-) - whether or not they are "booked transfers" depends a bit on "in which book" - I'm fairly sure you could send a mail to Jon Postel "I have given this class B to my friend because I do not need it anymore" and that was subsequently recorded. Of course not in "the RIPE NCC book", since that did not exist. I should point out one of the usual counterarguments against imposing too much bureaucracy, especially regarding transfers. We want proper documentation. Before almost everything else(!). Impose extra restrictions on transfers, and some people will decide that this is too much hassle and just do it under the desk, with creative contracts ("we do not transfer this network, I just lease it to you for 10 years"). Gert Doering -- NetMaster -- 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
I remain of the opinion that booked transfers did not happen before the RIR system, if only due to the presence of free addresses available with a similar mail to Jon Postel. I would love to find evidence that they did, but
This situation pertains to all transfers, and sometimes a 10 year lease is just a 10 year lease, when it's paid monthly. But as for disguising legacy sales by doing them in this manner, you are quite mistaken. Nobody is spending $20 per address and then not having his ownership recorded in Whois. Or virtually nobody. Nobody I know, and I have done over 750
However your point about too much bureaucracy is well-taken, and I support efforts to remove the delays, bureaucracies, and unnecessary restrictions
Hi Gert, And of course transfers have been possible before the RIRs existed :-) - whether or not they are "booked transfers" depends a bit on "in which book" - I'm fairly sure you could send a mail to Jon Postel "I have given this class B to my friend because I do not need it anymore" and that was subsequently recorded. Of course not in "the RIPE NCC book", since that did not exist. the fact remains that selling addresses was not contemplated at the time of the creation of the RIR system, and the ability to safely sell them via a change in the RIR registration is a new service. There is an argument as to whether new services should be afforded to non-dues paying legacy holders. You mention that there seems to be little support, but look at ARIN and RPKI for evidence supporting Jordi's opinion, read Scott Liebrand's post about ARIN's deliberations, and my own, for some measure of support for Jordi's problem statement, if the policies at every other registry are not evidence enough. I should point out one of the usual counterarguments against imposing too much bureaucracy, especially regarding transfers. We want proper documentation. Before almost everything else(!). Impose extra restrictions on transfers, and some people will decide that this is too much hassle and just do it under the desk, with creative contracts ("we do not transfer this network, I just lease it to you for 10 years"). transfers beginning in the early 2000s. If the buyer doesn't get recorded, there is nothing but fighting in court to prevent the subsequent re-sale of the block by the registrant. No buyer wants to risk waking up to find "his" block is now registered to somebody else in Whois, and the original registrant absconded with the money and disappeared. that would tend to drive transfers underground. Among these I include waiting periods and needs tests, and in those regards I am certainly in an un-supported position! Regards, Mike
It might be self-evident to you how this is problematic. It is not to me.
Because I think when there is an unfair situation (some folks bound to rules/policies, others not), there is a problem.
You cannot change history, and the fact that some assignments were made under different rules and prior to the RIRs coming into existence. Retroactively and forecfully from the RIR side changing the rules for these assignments, *that* would be unfair. Regards, - Håvard
I didn't said anything about retroactivity: - Holders of legacy that don't transfer them, aren't affected. - Transfers already done (from legacy resources) aren't affected The only affected ones are "new" transfers (if the policy reach consensus), and is only affecting the ones that get the resources, not the original holder. Again, please consider, if it is good that we are the only RIR not doing so. I don't think that's good. Regards, Jordi @jordipalet El 15/7/19 14:17, "address-policy-wg en nombre de Havard Eidnes via address-policy-wg" <address-policy-wg-bounces@ripe.net en nombre de address-policy-wg@ripe.net> escribió: >> It might be self-evident to you how this is problematic. It >> is not to me. > > Because I think when there is an unfair situation (some folks > bound to rules/policies, others not), there is a problem. You cannot change history, and the fact that some assignments were made under different rules and prior to the RIRs coming into existence. Retroactively and forecfully from the RIR side changing the rules for these assignments, *that* would be unfair. Regards, - Håvard ********************************************** 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.
Hi, On Tue, Jul 16, 2019 at 10:29:28AM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote:
Again, please consider, if it is good that we are the only RIR not doing so. I don't think that's good.
If this is the main argument ("I changed this in all the other RIRs, and now *you* are the only ones stubbornly refusing to follow my all-the-others-are-doing-this argument") - it's a somewhat weak one. You have failed to bring forward any reason for changing things, except "it is unfair that there is a difference" (without detailing what exactly the unfairness would be, who would be disadvantaged by this, exactly, and why they would be affected positively by this proposal) - and "all the other RIRs have changed this!" which is both not very compelling. I could also not see anyone speak up in a supportive way, so I'd consider this "sufficiently discussed, and no support to go for a formal proposal". 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
On 16 Jul 2019, at 09:46, Gert Doering <gert@space.net> wrote:
I could also not see anyone speak up in a supportive way, so I'd consider this "sufficiently discussed, and no support to go for a formal proposal".
I agree. Let's close this discussion and move on to the next Bad Idea.
Hi Jordi, Maybe you can provide any documentation available from the other RIRs about their rationale why they implemented this kind of policy? Maybe they have some strong arguments we are missing here? Gert Doering wrote at 2019-07-16 10:46:
Hi,
On Tue, Jul 16, 2019 at 10:29:28AM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote:
Again, please consider, if it is good that we are the only RIR not doing so. I don't think that's good.
If this is the main argument ("I changed this in all the other RIRs, and now *you* are the only ones stubbornly refusing to follow my all-the-others-are-doing-this argument") - it's a somewhat weak one.
You have failed to bring forward any reason for changing things, except
"it is unfair that there is a difference"
(without detailing what exactly the unfairness would be, who would be disadvantaged by this, exactly, and why they would be affected positively by this proposal) - and
"all the other RIRs have changed this!"
which is both not very compelling.
I could also not see anyone speak up in a supportive way, so I'd consider this "sufficiently discussed, and no support to go for a formal proposal".
Gert Doering -- APWG chair
Hi Jordi, All, I was doing some googling and easily found the references on ARIN/LACNIC/AFRINIC websites... ==== https://www.lacnic.net/1022/2/lacnic/legacy-resources "Transferred legacy resources will no longer be considered as such" ==== https://www.arin.net/resources/guide/legacy/services/ "When legacy number resources are transferred to another organization through a specified transfer (NRPM 8.3 and 8.4), the recipient organization is required to sign an RSA/LRSA, and the resources being transferred will not retain their legacy status." ==== https://afrinic.net/resources/transfers "Applicable to Transfer Recipient Transferred IPv4 legacy resources will no longer be regarded as legacy resources." ==== However, regarding APNIC, from what i read on https://www.apnic.net/community/policy/resources#8.3.-Transfer-of-Historical... it is not 100% clear to me that the transferred blocks lose their legacy/historical status. Can you list which policy proposals within each RIR that resulted in the above...? ...so we may have some clue about the timeline of such changes -- which may have been passed under the legacy holders radar... Additionally, maybe someone involved with transfers on a daily basis can comment if a block with legacy status has less/equal/more value than non-legacy blocks??? Cheers, Carlos On Tue, 16 Jul 2019, Michiel Klaver via address-policy-wg wrote:
Hi Jordi,
Maybe you can provide any documentation available from the other RIRs about their rationale why they implemented this kind of policy? Maybe they have some strong arguments we are missing here?
Gert Doering wrote at 2019-07-16 10:46:
Hi,
On Tue, Jul 16, 2019 at 10:29:28AM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote:
Again, please consider, if it is good that we are the only RIR not doing so. I don't think that's good.
If this is the main argument ("I changed this in all the other RIRs, and now *you* are the only ones stubbornly refusing to follow my all-the-others-are-doing-this argument") - it's a somewhat weak one.
You have failed to bring forward any reason for changing things, except
"it is unfair that there is a difference"
(without detailing what exactly the unfairness would be, who would be disadvantaged by this, exactly, and why they would be affected positively by this proposal) - and
"all the other RIRs have changed this!"
which is both not very compelling.
I could also not see anyone speak up in a supportive way, so I'd consider this "sufficiently discussed, and no support to go for a formal proposal".
Gert Doering -- APWG chair
Hi Carlos, Not sure if the specific proposals bring value, I think we need to understand "the whys", anyway, I found: LACNIC: https://www.lacnic.net/innovaportal/file/556/1/lac-2009-04v3-propuesta-sp.pd... (sorry Spanish) ARIN: https://www.arin.net/vault/policy/proposals/2009_1.html However, it doesn't mention legacy, so it should have modified afterwards, and I was unable to find it. AFRINIC: https://www.afrinic.net/policy/archive/ipv4-resources-transfer-within-the-af... Same problem as in ARIN, it has been modified afterwards, but can't find it. APNIC: http://archive.apnic.net/meetings/16/programme/sigs/docs/policy/addpol-prop-... https://www.apnic.net/community/policy/proposals/prop-006/ https://www.apnic.net/community/policy/proposals/prop-050/ I'm going to check with the policy officers of each RIR. Regards, Jordi @jordipalet El 16/7/19 11:39, "address-policy-wg en nombre de Carlos Friaças via address-policy-wg" <address-policy-wg-bounces@ripe.net en nombre de address-policy-wg@ripe.net> escribió: Hi Jordi, All, I was doing some googling and easily found the references on ARIN/LACNIC/AFRINIC websites... ==== https://www.lacnic.net/1022/2/lacnic/legacy-resources "Transferred legacy resources will no longer be considered as such" ==== https://www.arin.net/resources/guide/legacy/services/ "When legacy number resources are transferred to another organization through a specified transfer (NRPM 8.3 and 8.4), the recipient organization is required to sign an RSA/LRSA, and the resources being transferred will not retain their legacy status." ==== https://afrinic.net/resources/transfers "Applicable to Transfer Recipient Transferred IPv4 legacy resources will no longer be regarded as legacy resources." ==== However, regarding APNIC, from what i read on https://www.apnic.net/community/policy/resources#8.3.-Transfer-of-Historical... it is not 100% clear to me that the transferred blocks lose their legacy/historical status. Can you list which policy proposals within each RIR that resulted in the above...? ...so we may have some clue about the timeline of such changes -- which may have been passed under the legacy holders radar... Additionally, maybe someone involved with transfers on a daily basis can comment if a block with legacy status has less/equal/more value than non-legacy blocks??? Cheers, Carlos On Tue, 16 Jul 2019, Michiel Klaver via address-policy-wg wrote: > Hi Jordi, > > Maybe you can provide any documentation available from the other RIRs about > their rationale why they implemented this kind of policy? Maybe they have > some strong arguments we are missing here? > > > Gert Doering wrote at 2019-07-16 10:46: >> Hi, >> >> On Tue, Jul 16, 2019 at 10:29:28AM +0200, JORDI PALET MARTINEZ via >> address-policy-wg wrote: >>> Again, please consider, if it is good that we are the only RIR not doing >>> so. I don't think that's good. >> >> If this is the main argument ("I changed this in all the other RIRs, >> and now *you* are the only ones stubbornly refusing to follow my >> all-the-others-are-doing-this argument") - it's a somewhat weak one. >> >> You have failed to bring forward any reason for changing things, except >> >> "it is unfair that there is a difference" >> >> (without detailing what exactly the unfairness would be, who would >> be disadvantaged by this, exactly, and why they would be affected >> positively by this proposal) - and >> >> "all the other RIRs have changed this!" >> >> which is both not very compelling. >> >> >> I could also not see anyone speak up in a supportive way, so I'd consider >> this "sufficiently discussed, and no support to go for a formal proposal". >> >> Gert Doering >> -- APWG chair > ********************************************** 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.
However, regarding APNIC, from what i read on https://www.apnic.net/community/policy/resources#8.3.-Transfer-of-Historical -Internet-resources it is not 100% clear to me that the transferred blocks lose their legacy/historical status. Can you list which policy proposals within each RIR that resulted in the above...? ...so we may have some clue about the timeline of such changes -- which may have been passed under the legacy holders radar... Additionally, maybe someone involved with transfers on a daily basis can comment if a block with legacy status has less/equal/more value than non-legacy blocks??? Cheers, Carlos Can you list which policy proposals within each RIR that resulted in the above...? ...so we may have some clue about the timeline of such changes -- which may have been passed under the legacy holders radar... Additionally, maybe someone involved with transfers on a daily basis can comment if a block with legacy status has less/equal/more value than non-legacy blocks??? Cheers, Carlos Hi Carlos, We have done every version of transfer, I believe, and can speak from experience. In APNIC, the seller of historical resources can sign up as a temporary member with APNIC in order to be vetted before the sale, then when the block is transferred it loses its legacy status. Only RIPE transfer recipients can maintain legacy status, except for some M&A transfers. When I proposed a re-write of ARIN's transfer policy in 2011, I wrestled with the requirement that the blocks lose legacy status, but included the requirement that the recipient sign an RSA, at the time that meant it lost legacy status. https://lists.arin.net/pipermail/arin-ppml/2011-May/022171.html My feelings at the time, as a legacy holder, were that as long as we had the right to hold the blocks without regard to their utilization, and we had the right to sell the blocks, that losing the legacy status wouldn't be a big deal. In AFRINIC's case, there is the issue of whether addresses can be revoked for lack of utilization for originally intended and justified purposes under its RSA. You can read in the link above that in 2011, while I included language requiring an RSA of recipients in my policy proposal, I simultaneously requested a change to ARIN's RSA language to explicitly remove its ability to revoke for utilization or lack thereof. So in AFRINIC today, I would want to maintain legacy status because it protects me from revocation under RSA, if I was a buyer. The arguments from RIPE about their inability, due to a lack of contract, to force a change of status, is disingenuous to me. Sure they can't force legacy holders to do anything, but can legacy holders force RIPE to process transfers? Is RIPE bound, contractually or morally, to register transfers of legacy space in the same way they are bound to maintain existing registrations and original services to the legacy block owners? Must legacy rights be "grandfathered-in"? I think you can argue that transfers were not part of the original scope of legacy registrant services, and that the RIRs do have the right to insist on paid registration of transferred blocks while at the same time the RIRs continue to honor the legacy rights of the original registrants. That said, currently the value of legacy status is strictly tied to the lack of policy restrictions, and registration costs avoided. As policy restrictions become less restrictive, the added value of legacy status is merely the registration fee avoidance. We have brokered transfers of legacy blocks from APNIC and ARIN into RIPE, maintaining legacy status thereafter. So certainly there are some who ascribe greater value to legacy blocks, and greatest to RIPE legacy blocks. This is because RIPE has the least restrictive transfer policies related to RIPE space. RIPE legacy blocks can be transferred to any entity that the blocks can be legally sold to. No demonstration of need, recipient can be a natural person or any other legal entity, recipient does not need to be an LIR or RIPE member of any kind, and can be located anywhere in the world. RIPE will require documentation of the legal chain-of-custody and the sale, and if the legal documentation is sound, the transfer is processed. Remember that legacy holders might theoretically be able to legally transfer ownership rights to their blocks without registry interactions, but where does that leave the buyer? Almost every buyer wants his title registered publicly as protection of his assets. So legacy block transfer recipients have an incentive to comply with policies like needs tests and holding periods in order to acquire that public Whois registration of rights-ownership. Why can't we expect them to swallow and accept the change of legacy designation as an additional cost of acquiring that valuable registration in the RIR's database? Well, one reason is if they fear that their blocks will be revoked by an AFRINIC audit process if they aren't used for their original purpose down the road. TL;DR: Legacy blocks have a very slight additional value; AFRINIC RSA revocation language impacts this decision about legacy status Regards, Mike
Hi Michiel, I think the email from Mike (yesterday) responded to this together with my previous links to each RIR. Anyway, I've contacted to all the RIR policy officers, and even if not all them have responded yet with new information, this is a summary of the situation. 1) In ARIN, they ask for signing the RSA. This is the literal response I got from them: ARIN Policy 2009-1 does indeed require specified transfer resources to “receive” the resources under RSA. This policy was implemented in June 2009 and that version of the NRPM may be viewed at https://www.arin.net/vault/policy/archive/nrpm_20090601.pdf. Subsequent policy changes impacted NRPM section 8.3, and went on to add 8.4 and 8.5, clarifying that the requirement applies to both intra- and inter-RIR transfers with ARIN recipients. The Inter-RIR language specifically came about via ARIN Policy 2012-1 (https://www.arin.net/vault/policy/proposals/2012_1.html), which was implemented in July 2012 (https://www.arin.net/vault/policy/archive/nrpm_20120731.pdf). Since that time, other changes have occurred within Section 8, but none to my knowledge have impacted the requirement that recipients must “receive” the resources under RSA. 2) AFRINIC. There was a wrong link in their web page when I looked at this and provided the link here. After I checked that and observed the mismatch, they corrected it. So the correct link to the proposal is: https://www.afrinic.net/policy/archive/ipv4-resources-transfer-within-the-af... 3) LACNIC and APNIC, as explained in previous email. Even if I've asked them for explicit arguments when the discussion of each proposal was carried out I didn't get those responses, so again I think Mike email has the clearest view. Alternatively, there will be a chance if we investigate the mail archive discussion for each policy proposal in each RIR. Regards, Jordi @jordipalet El 16/7/19 11:05, "Michiel Klaver" <michiel@klaver.it> escribió: Hi Jordi, Maybe you can provide any documentation available from the other RIRs about their rationale why they implemented this kind of policy? Maybe they have some strong arguments we are missing here? Gert Doering wrote at 2019-07-16 10:46: > Hi, > > On Tue, Jul 16, 2019 at 10:29:28AM +0200, JORDI PALET MARTINEZ via > address-policy-wg wrote: >> Again, please consider, if it is good that we are the only RIR not >> doing so. I don't think that's good. > > If this is the main argument ("I changed this in all the other RIRs, > and now *you* are the only ones stubbornly refusing to follow my > all-the-others-are-doing-this argument") - it's a somewhat weak one. > > You have failed to bring forward any reason for changing things, except > > "it is unfair that there is a difference" > > (without detailing what exactly the unfairness would be, who would > be disadvantaged by this, exactly, and why they would be affected > positively by this proposal) - and > > "all the other RIRs have changed this!" > > which is both not very compelling. > > > I could also not see anyone speak up in a supportive way, so I'd > consider > this "sufficiently discussed, and no support to go for a formal > proposal". > > Gert Doering > -- APWG chair ********************************************** 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.
I can comment on the ARIN case. At the time we fully intended that legacy holders (and their legal successors) should continue to be able to use the address space they got pre-ARIN under the same terms under which they were assigned it. However, there was originally no provision for legacy address holders to be able to transfer space to unrelated parties. When we added policy to allow specified transfers, we (the ARIN community) agreed that legacy holders should be able to sell and transfer their legacy holdings, but that the recipient of the space would receive it under RSA, on equal footing with anyone else receiving new address space from ARIN. Scott
On Jul 17, 2019, at 11:19 AM, JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg@ripe.net> wrote:
Hi Michiel,
I think the email from Mike (yesterday) responded to this together with my previous links to each RIR. Anyway, I've contacted to all the RIR policy officers, and even if not all them have responded yet with new information, this is a summary of the situation.
1) In ARIN, they ask for signing the RSA. This is the literal response I got from them:
ARIN Policy 2009-1 does indeed require specified transfer resources to “receive” the resources under RSA. This policy was implemented in June 2009 and that version of the NRPM may be viewed at https://www.arin.net/vault/policy/archive/nrpm_20090601.pdf.
Subsequent policy changes impacted NRPM section 8.3, and went on to add 8.4 and 8.5, clarifying that the requirement applies to both intra- and inter-RIR transfers with ARIN recipients.
The Inter-RIR language specifically came about via ARIN Policy 2012-1 (https://www.arin.net/vault/policy/proposals/2012_1.html), which was implemented in July 2012 (https://www.arin.net/vault/policy/archive/nrpm_20120731.pdf).
Since that time, other changes have occurred within Section 8, but none to my knowledge have impacted the requirement that recipients must “receive” the resources under RSA.
2) AFRINIC. There was a wrong link in their web page when I looked at this and provided the link here. After I checked that and observed the mismatch, they corrected it. So the correct link to the proposal is: https://www.afrinic.net/policy/archive/ipv4-resources-transfer-within-the-af...
3) LACNIC and APNIC, as explained in previous email.
Even if I've asked them for explicit arguments when the discussion of each proposal was carried out I didn't get those responses, so again I think Mike email has the clearest view. Alternatively, there will be a chance if we investigate the mail archive discussion for each policy proposal in each RIR.
Regards, Jordi @jordipalet
El 16/7/19 11:05, "Michiel Klaver" <michiel@klaver.it> escribió:
Hi Jordi,
Maybe you can provide any documentation available from the other RIRs about their rationale why they implemented this kind of policy? Maybe they have some strong arguments we are missing here?
Gert Doering wrote at 2019-07-16 10:46:
Hi,
On Tue, Jul 16, 2019 at 10:29:28AM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote:
Again, please consider, if it is good that we are the only RIR not doing so. I don't think that's good.
If this is the main argument ("I changed this in all the other RIRs, and now *you* are the only ones stubbornly refusing to follow my all-the-others-are-doing-this argument") - it's a somewhat weak one.
You have failed to bring forward any reason for changing things, except
"it is unfair that there is a difference"
(without detailing what exactly the unfairness would be, who would be disadvantaged by this, exactly, and why they would be affected positively by this proposal) - and
"all the other RIRs have changed this!"
which is both not very compelling.
I could also not see anyone speak up in a supportive way, so I'd consider this "sufficiently discussed, and no support to go for a formal proposal".
Gert Doering -- APWG chair
********************************************** 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.
Moin, am 17.07.2019 um 20:45 schrieb Scott Leibrand:
I can comment on the ARIN case. At the time we fully intended that legacy holders (and their legal successors) should continue to be able to use the address space they got pre-ARIN under the same terms under which they were assigned it. However, there was originally no provision for legacy address holders to be able to transfer space to unrelated parties. When we added policy to allow specified transfers, we (the ARIN community) agreed that legacy holders should be able to sell and transfer their legacy holdings, but that the recipient of the space would receive it under RSA, on equal footing with anyone else receiving new address space from ARIN.
Maybe someone can quickly fill me in on how this happened under the RIR regime in the first place? I left hostmastery about twenty years ago, when 194/8 was in a state of "it's considered PA but wasn't always handed down that way, contractually; please fix this, LIRs" and space from 195/8 was clearly handed out as PA, based on and for a documented use case. Revisiting this field maybe ten years later, I learned that IP space now is a property that even can be sold (and has a value attached to it, too) — instead of needing to be returned if the inital use case doesn't exist anymore. This feels like a U-turn from ripe-083's "Finally, please understand that we are not working against you, but with the whole Internet community to achieve a fair distribution of the remaining address space" to me. I'm only following ap-wg for about 2,5 years now, a pointer to when and why a market for IPv4 was endorsed by the RIPE community would be very welcome. Which brings me to the main point: maybe it's time to put a stop to the trading of IPv4 space, instead of trying to fix loopholes in the policy system supporting that market? If there's no way to transfer legacy space except back to IANA, Internic's successor, there's no need for failing policies regarding the transfer. Same goes with PI space; this was assigned to End Users, thus the only possible receipient of that space can be the issuing RIR, if that End User is no more or stops using it itself. And the same goes for PA, of course: this space was allocated to a specific LIR in a non-portable way; if that LIR goes out of business, the space has to return to the issuing RIR. IF the RIRs are there to ensure "a fair distribution of the remaining address space", they SHOULD ensure they receive it back when the reason for the assignment or allocation ceases to exist. Therefore, from my perspective, the answer to the question in the subject should be: No, we should stop allowing any transfer of IPv4 space, except back to the issuing party. Thanks for reading, and no, I'm not joking or trolling here.Regards, -kai
Hi Gert, Just to be clear: I didn't change this in any RIR. I've proposed Inter-RIR transfers in LACNIC and AFRINIC, following their existing intra-RIR policies, which already had this legacy to non-legacy with the transfer, so I just kept it. I still think it is unfair to have a legacy status, and for me this is a good reason. As Jim said, it is about diversity, in this case of opinions. I'm going to investigate the reasons to have this in the other RIRs and come back to the list. Regards, Jordi @jordipalet El 16/7/19 10:46, "address-policy-wg en nombre de Gert Doering" <address-policy-wg-bounces@ripe.net en nombre de gert@space.net> escribió: Hi, On Tue, Jul 16, 2019 at 10:29:28AM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: > Again, please consider, if it is good that we are the only RIR not doing so. I don't think that's good. If this is the main argument ("I changed this in all the other RIRs, and now *you* are the only ones stubbornly refusing to follow my all-the-others-are-doing-this argument") - it's a somewhat weak one. You have failed to bring forward any reason for changing things, except "it is unfair that there is a difference" (without detailing what exactly the unfairness would be, who would be disadvantaged by this, exactly, and why they would be affected positively by this proposal) - and "all the other RIRs have changed this!" which is both not very compelling. I could also not see anyone speak up in a supportive way, so I'd consider this "sufficiently discussed, and no support to go for a formal proposal". 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.
Hi Jordi, Please keep the lingo correct.. you keep referring to non-legacy .. but your intention and this complete discussion is about Legacy space. Typically we are talking about inter-rir transfers from ARIN to RIPE if I read it correctly. As most Legacy space that comes into RIPE has an ARIN origin. There is APNIC as well, but just less transfers from APNIC to RIPE with legacy .. While I've done 'some' Legacy inter-rir transfers .. is there a problem with how it is being transferred ? There is the option currently for legacy resource holders to move IP space between RIR's (ARIN to RIPE for instance) for cost, policy, tools or rights acceptance reasons .. or just because their HQ is moving from the ARIN region to RIPE region. Why should they be stripped of their current status ? what is the intention here ? Regards, Erik Bais On 15/07/2019, 11:39, "address-policy-wg on behalf of JORDI PALET MARTINEZ via address-policy-wg" <address-policy-wg-bounces@ripe.net on behalf of address-policy-wg@ripe.net> wrote: Hi Tore, I think my previus email just explained it. The motivation is my personal view that we have a problem (as a community) by not bringing into the system the legacy resources. I'm alone with that view? I don't know, and that's why I'm asking. What is clear to me is that, according to existing policies, I share this view with 4/5 of the RIR communities. What is the effect of that? Simple, an unbalance of transfers among regions, because if someone for whatever reason want to get resources and keep them non-legacy, can just come to RIPE for that. This is good for RIPE? I don't think so, we could keep growing the non-legacy resources, while other regions get "cleaned". Regards, Jordi @jordipalet El 15/7/19 10:05, "address-policy-wg en nombre de Tore Anderson" <address-policy-wg-bounces@ripe.net en nombre de tore@fud.no> escribió: * Gert Doering > On Sat, Jul 13, 2019 at 01:37:19PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: >> I keep thinking that ripe-682 (RIPE resource transfer policies), should have a provision (as it is the case in all the other RIRs), in order to "convert" the legacy resources to non-legacy, when they got transferred. > > What is it that you want to achieve with this? +1 I've read this entire thread and I still have no idea what the motivation for this (pre-)proposal actually is. Is it a solution in search of a problem? Maybe if you could explain by example, Jordi? Were you involved in a transfer of legacy resources and stumbled across some kind of obstacle caused by current policies (that this proposal addresses)? Tore ********************************************** 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.
The intention is that we bring into the community rules (policies) as many addresses as possible. I think it is unfair to have some addresses bound to our policies (in whatever region), and others not. I know we can't mandate for the legacy holders, but we can, if as a community, we decide that for the beneficiaries of legacy transfers, by amending our policy to state that those addresses lose the legacy status with that transfer. Now is optional in RIPE, mandatory in all the other regions. To be clear, when I mention the other regions status: 1) In LACNIC the proposal, which I authored as well, passed consensus a month ago (now in implementation stage). It is also based in the existing intra-RIR policy, where the legacy status is lost once they get transferred. 2) In AFRINIC, at the moment, there is an inter-RIR proposal, which I'm the author. It is based in the existing intra-RIR policy, where the legacy status is lost once they get transferred. So right now, intra-RIR already lost the legacy status. Regards, Jordi @jordipalet El 15/7/19 12:32, "address-policy-wg en nombre de Erik Bais" <address-policy-wg-bounces@ripe.net en nombre de ebais@a2b-internet.com> escribió: Hi Jordi, Please keep the lingo correct.. you keep referring to non-legacy .. but your intention and this complete discussion is about Legacy space. Typically we are talking about inter-rir transfers from ARIN to RIPE if I read it correctly. As most Legacy space that comes into RIPE has an ARIN origin. There is APNIC as well, but just less transfers from APNIC to RIPE with legacy .. While I've done 'some' Legacy inter-rir transfers .. is there a problem with how it is being transferred ? There is the option currently for legacy resource holders to move IP space between RIR's (ARIN to RIPE for instance) for cost, policy, tools or rights acceptance reasons .. or just because their HQ is moving from the ARIN region to RIPE region. Why should they be stripped of their current status ? what is the intention here ? Regards, Erik Bais On 15/07/2019, 11:39, "address-policy-wg on behalf of JORDI PALET MARTINEZ via address-policy-wg" <address-policy-wg-bounces@ripe.net on behalf of address-policy-wg@ripe.net> wrote: Hi Tore, I think my previus email just explained it. The motivation is my personal view that we have a problem (as a community) by not bringing into the system the legacy resources. I'm alone with that view? I don't know, and that's why I'm asking. What is clear to me is that, according to existing policies, I share this view with 4/5 of the RIR communities. What is the effect of that? Simple, an unbalance of transfers among regions, because if someone for whatever reason want to get resources and keep them non-legacy, can just come to RIPE for that. This is good for RIPE? I don't think so, we could keep growing the non-legacy resources, while other regions get "cleaned". Regards, Jordi @jordipalet El 15/7/19 10:05, "address-policy-wg en nombre de Tore Anderson" <address-policy-wg-bounces@ripe.net en nombre de tore@fud.no> escribió: * Gert Doering > On Sat, Jul 13, 2019 at 01:37:19PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: >> I keep thinking that ripe-682 (RIPE resource transfer policies), should have a provision (as it is the case in all the other RIRs), in order to "convert" the legacy resources to non-legacy, when they got transferred. > > What is it that you want to achieve with this? +1 I've read this entire thread and I still have no idea what the motivation for this (pre-)proposal actually is. Is it a solution in search of a problem? Maybe if you could explain by example, Jordi? Were you involved in a transfer of legacy resources and stumbled across some kind of obstacle caused by current policies (that this proposal addresses)? Tore ********************************************** 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.
participants (19)
-
Carlos Friaças
-
Daniel Stolpe
-
Erik Bais
-
Gert Doering
-
Hans Petter Holen
-
Havard Eidnes
-
Jim Reid
-
JORDI PALET MARTINEZ
-
Kai 'wusel' Siering
-
Michiel Klaver
-
Mike Burns
-
Nick Hilliard
-
Piotr Strzyzewski
-
Radu-Adrian FEURDEAN
-
Randy Bush
-
Sander Steffann
-
Sascha Luck [ml]
-
Scott Leibrand
-
Tore Anderson