2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates)
Dear colleagues, A new RIPE Policy proposal, 2017-01, "Publish statistics on Intra-RIR Legacy updates" is now available for discussion. The goal of this proposal is to require the RIPE NCC to publish all changes to the holdership of legacy resources in the existing transfer statistics. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2017-01 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 24 May 2017. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
All, On Tue, Apr 25, 2017 at 02:39:43PM +0200, Marco Schmidt wrote:
A new RIPE Policy proposal, 2017-01, "Publish statistics on Intra-RIR Legacy updates" is now available for discussion.
The goal of this proposal is to require the RIPE NCC to publish all changes to the holdership of legacy resources in the existing transfer statistics.
You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2017-01
It would be nice if the initial email for a new proposal could contain the textual changes to policy documents. It would make it infintely easier to comment inline on the changed sections.
4.0 Transfer Statistics [...] This list will contain information about approved changes. The following information will be published: [...] Whether it was a transfer according to this policy, a transfer due to changes to an organisation's business structure (such as a merger or acquisition) or a change in the RIPE Database to the organisation holding a Legacy Internet Resource.
Since when has the RIPE NCC a mandate to "approve" changes in legacy objects? (Except perhaps where a contractual relationship exists)
RIPE NCC Services to Legacy Internet Resource Holders [...] 1.1 Definitions [...] Registry services [...] Transfer services as per RIPE Resource Transfer Policies. Any change in the RIPE Database updating the organisation holding the Legacy Internet Resource can only be finalised once the RIPE NCC has received and verified a written request signed by authorised representatives of both the current holder and the new holder.
Since when does the RIPE NCC have the mandate to impose such a process on legacy resource holders?
Rationale
a. Arguments supporting the proposal
Providing complete statistics about IPv4 transfers and updates to the holdership of legacy resources would clearly show the whole picture of a young, unpredictable and volatile transfer market. We currently see only partial information and it is difficult to understand the real dimensions of the size and number of IPv4 transfers.
Over the past few years, this update has been requested by everyone analysing the IPv4 marketplace and presenting at RIPE, ARIN or APNIC conferences. The RIPE NCC already publishes statistics on inter-RIR transfers and adding this last bit (updates on who holds legacy resources) would be consistent with the community's requests around transparency and consistency.
Read this as: "This is the latest attempt to instrumentalise the (membership-funded) RIPE NCC as a free business intelligence resource for IPv4 address brokers."
In order to identify all legacy changes, a confirmation will be sent to the RIPE NCC to finalise the process (currently this is only checked for legacy resources that have a contractual relationship with the RIPE NCC or sponsoring LIR). This verification requirement does not impact the transfer of legacy resources or the updates in the RIPE Database. It only adds an additional step to increase the registration quality.
What makes you think imposing a bureaucratic requirement on legacy holders out of the blue will not be resisted? I remember the discussions around formalising the legacy resource relationship with the NCC and how the voluntary nature of any such relationship was emphasized in order to get any sort of consensus. In short, this proposal has the potential to: - benefit the few at a cost to all members, - sour relations with legacy resource holders, - have a deletorious effect on registry quality where resource holders do not wish to submit to a "verification" process, and therefore I, strenuously, object to this proposal (for whatever that may be worth) rgds, Sascha Luck
Hi Sascha, please see inline: On 4/25/17 7:10 PM, Sascha Luck [ml] wrote:
All,
On Tue, Apr 25, 2017 at 02:39:43PM +0200, Marco Schmidt wrote:
A new RIPE Policy proposal, 2017-01, "Publish statistics on Intra-RIR Legacy updates" is now available for discussion.
The goal of this proposal is to require the RIPE NCC to publish all changes to the holdership of legacy resources in the existing transfer statistics.
You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2017-01
It would be nice if the initial email for a new proposal could contain the textual changes to policy documents. It would make it infintely easier to comment inline on the changed sections. additions to the current policy documents in *bold*:
RIPE Resource Transfer Policies (currently ripe-682): * Whether it was a transfer according to this policy, a transfer due to changes to an organisation's business structure (such as a merger or acquisition) *or a change in the RIPE Database to the organisation holding a Legacy Internet Resource.* RIPE NCC Services to Legacy Internet Resource Holders (currently ripe-674): * *Transfer services as per****RIPE Resource Transfer Policies <http://www.ripe.net/publications/docs/transfer-policies>**. Any change in the RIPE Database updating the organisation holding the Legacy Internet Resource can only be finalised once the RIPE NCC has received and verified a written request signed by authorised representatives of both the current holder and the new holder.*
4.0 Transfer Statistics [...] This list will contain information about approved changes. The following information will be published: [...] Whether it was a transfer according to this policy, a transfer due to changes to an organisation's business structure (such as a merger or acquisition) or a change in the RIPE Database to the organisation holding a Legacy Internet Resource.
Since when has the RIPE NCC a mandate to "approve" changes in legacy objects? (Except perhaps where a contractual relationship exists)
It does not. And this policy proposal does not intend to give more 'power' to the RIPE NCC over the Legacy holders. What it will do is, for 'transfers' of Legacy space where both the old and the new holder want to have it verified by the RIPE NCC, both parties will need to sign a document where parties authorised to sign will confirm the change of the legacy holder (basically, a transfer). Transfers where the legacy holders do not want the RIPE NCC to acknowledge the change in the legacy holder will be marked as such. This policy proposal does not require both parties to sign such a document in order to complete a transfer.
RIPE NCC Services to Legacy Internet Resource Holders [...] 1.1 Definitions [...] Registry services [...] Transfer services as per RIPE Resource Transfer Policies. Any change in the RIPE Database updating the organisation holding the Legacy Internet Resource can only be finalised once the RIPE NCC has received and verified a written request signed by authorised representatives of both the current holder and the new holder.
Since when does the RIPE NCC have the mandate to impose such a process on legacy resource holders?
This is what the policy proposal will add. It currently does not have a mandate and the mandate will be given once this proposal becomes policy. It only requires the RIPE NCC to verify that authorised representatives sign a template where they accept and acknowledge the change of the legacy block and the fact that a new legacy holder now holds this block. If this policy proposal is approved and if the two organizations do not want to sign such a document, the RIPE NCC will mark the updated legacy resource in some way (maybe a remarks attribute) signaling that the IP block has been updated and the RIPE NCC has not been notified of such change. Therefore, the transfer is not 'finalised'.
Rationale
a. Arguments supporting the proposal
Providing complete statistics about IPv4 transfers and updates to the holdership of legacy resources would clearly show the whole picture of a young, unpredictable and volatile transfer market. We currently see only partial information and it is difficult to understand the real dimensions of the size and number of IPv4 transfers.
Over the past few years, this update has been requested by everyone analysing the IPv4 marketplace and presenting at RIPE, ARIN or APNIC conferences. The RIPE NCC already publishes statistics on inter-RIR transfers and adding this last bit (updates on who holds legacy resources) would be consistent with the community's requests around transparency and consistency.
Read this as: "This is the latest attempt to instrumentalise the (membership-funded) RIPE NCC as a free business intelligence resource for IPv4 address brokers." Please elaborate how this would be a business intelligence for the IPv4 address brokers. I represent an IPv4 address broker and can not see how this is going to help my business. I am also a RIPE NCC member and I pay my yearly membership, just as you do.
I can already see who is a legacy resource holder and I can already see the changes in the RIPE Database; how would publishing the statistics of IP transfers of legacy resources be of any help to my company?
In order to identify all legacy changes, a confirmation will be sent to the RIPE NCC to finalise the process (currently this is only checked for legacy resources that have a contractual relationship with the RIPE NCC or sponsoring LIR). This verification requirement does not impact the transfer of legacy resources or the updates in the RIPE Database. It only adds an additional step to increase the registration quality.
What makes you think imposing a bureaucratic requirement on legacy holders out of the blue will not be resisted? Why would someone resist it? It would add a security layer to the Buyer by having the RIPE NCC verify that the IP block transferred has the approval of the management of the original legacy holder.
I remember the discussions around formalising the legacy resource relationship with the NCC and how the voluntary nature of any such relationship was emphasized in order to get any sort of consensus. And, based on those discussions, this policy proposal does not require
In short, this proposal has the potential to:
- benefit the few at a cost to all members, what will be that cost? - sour relations with legacy resource holders, how so? - have a deletorious effect on registry quality where resource holders do not wish to submit to a "verification" process,
It would also prevent hijackers (that may have gotten their hands on the password of a maintainer of a legacy resource) from transferring IP blocks they do not hold. the RIPE NCC to approve the transfer of a Legacy. Where both parties request it by signing a transfer template, the RIPE NCC will confirm the transfer. they can still update the object, the RIPE NCC will only mark the update as not yet verified. The current situation already has a negative impact on the registry and this policy proposal could fix it when both the old and the new legacy holder will sign a transfer template and the RIPE NCC verifies the authenticity of the signatories.
and therefore I, strenuously, object to this proposal (for whatever that may be worth)
Even after the comments above, do you still object to the proposal? Is there any method to achieve the end goal (publishing complete transfer statistics) you would not object to?
rgds, Sascha Luck
Kind regards, Elvis -- Elvis Daniel Velea V4Escrow LLC Chief Executive Officer E-mail: elvis@v4escrow.net Mobile: +1 (702) 970 0921
Hi Elvis, On Tue, Apr 25, 2017 at 07:42:12PM +0300, Elvis Daniel Velea wrote:
What it will do is, for 'transfers' of Legacy space where both the old and the new holder want to have it verified by the RIPE NCC, both parties will need to sign a document where parties authorised to sign will confirm the change of the legacy holder (basically, a transfer).
Oh, this is *voluntary*? This is not obvious from the language of the proposed changes and one does not, perhaps, expect to see anything non-mandatory in a RIPE policy document ;p So let me see if I have this right: - Transfers of legacy space stay outside the NCC's purview to the extent they do now? - LRH who *want* to have a resource transfer verified can do so by submitting verification paperwork of some description? - Changes in the db wrt legacy resources where the LRHs do *not* want this are marked as "non-verified by NCC" or something like that but they are not rejected?
Even after the comments above, do you still object to the proposal?
If my above understanding is correct, and an updated proposal would insert some language to make the voluntary nature of the transaction clearer, I'll withdraw my objection on that point. As for the cost of it and possible defrayment of same, I'll wait for the Impact Statement before making a decision. Sorry for the misunderstanding, if that it was, and best regards, Sascha Luck
Hi Sascha, On 4/26/17 1:26 AM, Sascha Luck [ml] wrote:
Hi Elvis,
On Tue, Apr 25, 2017 at 07:42:12PM +0300, Elvis Daniel Velea wrote:
What it will do is, for 'transfers' of Legacy space where both the old and the new holder want to have it verified by the RIPE NCC, both parties will need to sign a document where parties authorised to sign will confirm the change of the legacy holder (basically, a transfer).
Oh, this is *voluntary*? kinda... I am expecting all Buyers to request this process when they decide to receive a Legacy Resource. I would definitely request it if I knew the RIPE NCC can provide an additional confirmation. This is not obvious from the language of the proposed changes and one does not, perhaps, expect to see anything non-mandatory in a RIPE policy document ;p hehe
I tried to make this change as simple and as easy as possible for the LRHs. I knew that some would not agree with having additional requirements added, so I tried to make it as such that it would not be mandatory. I don't like to add barriers that could affect the registry in the long run. Maybe we will need to have a version where the wording is more clear. Let's see what the others say and what will be the RIPE NCC's understanding of the text once they make the Impact Analysis.
So let me see if I have this right:
- Transfers of legacy space stay outside the NCC's purview to the extent they do now?
- LRH who *want* to have a resource transfer verified can do so by submitting verification paperwork of some description?
In an ideal world, all LRHs would want this as it would 'secure' their 'transfer'.
- Changes in the db wrt legacy resources where the LRHs do *not* want this are marked as "non-verified by NCC" or something like that but they are not rejected?
correct. A legacy resource that has been updated to reflect an other LRH will be marked somewhere in the lines of 'changed but not verified'.
Even after the comments above, do you still object to the proposal?
If my above understanding is correct, and an updated proposal would insert some language to make the voluntary nature of the transaction clearer, I'll withdraw my objection on that point.
ok, thank you for your understanding.
As for the cost of it and possible defrayment of same, I'll wait for the Impact Statement before making a decision. I doubt there will be any significant cost. We'll have to wait for the NCC to complete their Impact Analysis.
Sorry for the misunderstanding, if that it was, and best regards, Sascha Luck
thank you, Elvis
On Tue, Apr 25, 2017 at 5:41 PM, Elvis Daniel Velea <elvis@v4escrow.net> wrote:
Hi Sascha,
On 4/26/17 1:26 AM, Sascha Luck [ml] wrote:
Hi Elvis,
On Tue, Apr 25, 2017 at 07:42:12PM +0300, Elvis Daniel Velea wrote:
What it will do is, for 'transfers' of Legacy space where both the old and the new holder want to have it verified by the RIPE NCC, both parties will need to sign a document where parties authorised to sign will confirm the change of the legacy holder (basically, a transfer).
Oh, this is *voluntary*?
kinda... I am expecting all Buyers to request this process when they decide to receive a Legacy Resource. I would definitely request it if I knew the RIPE NCC can provide an additional confirmation.
Currently as written it's voluntary from the perspective of RIPE policy, but if almost all sophisticated buyers expect it, is it truly voluntary? Furthermore, doesn't having it be voluntary unnecessary expose unsophisticated buyers to a higher risk from fraudulent actors? Is caveat emptor really the fundamental concept we want enshrined in policy for the transfer of Legacy Resources? Then, what about any LRHs that want the additional protection of RIPE validating any and all attempted transfers of their resource by possibly fraudulent actors. It may be an additional requirement, but that can also be seen as additional layer of protection for both sides. For buyers there is some protection they not dealing with a fraudulent seller. For LRHs it makes it a little harder for someone to fraudulently sell their resources out from under them. We can't eliminate fraud, but making this mandatory seems like a minimal level of protection for both buyers and LRHs. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================
Greetings, While the proposal's title seems to be a positive approach, as i read it, its main goal is to add extra requirements for LRH by changing «RIPE NCC Services to Legacy Internet Resource Holders». I think protection (or just better alarms in place!) for Legacy address space is a good thing, however, i'm not sure an extra workload for the NCC and the LRH in the case they want to transfer their asset(s) is the way to go. I also agree with Sascha Luck's previous comment about LRH having to submit to an extra verification process. In its current terms, i also object to this proposal. Best Regards, Carlos Friaças On Tue, 25 Apr 2017, Marco Schmidt wrote:
Dear colleagues,
A new RIPE Policy proposal, 2017-01, "Publish statistics on Intra-RIR Legacy updates" is now available for discussion.
The goal of this proposal is to require the RIPE NCC to publish all changes to the holdership of legacy resources in the existing transfer statistics.
You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2017-01
As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer.
At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal.
We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 24 May 2017.
Regards,
Marco Schmidt Policy Development Officer RIPE NCC
Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
Hi Carlos, On 4/26/17 12:12 AM, Carlos Friacas wrote:
Greetings,
While the proposal's title seems to be a positive approach, as i read it, its main goal is to add extra requirements for LRH by changing «RIPE NCC Services to Legacy Internet Resource Holders».
The way I see it, this policy proposal does not add extra requirements, it adds an extra service.
I think protection (or just better alarms in place!) for Legacy address space is a good thing, however, i'm not sure an extra workload for the NCC and the LRH in the case they want to transfer their asset(s) is the way to go.
the extra workload is a document signed by the representatives of the two LRH (the Seller and the Buyer). The RIPE NCC verifies these kind of documents on a daily basis so I doubt that would be a whole lot of extra workload - they will confirm during the Impact Analysis.
I also agree with Sascha Luck's previous comment about LRH having to submit to an extra verification process.
As mentioned in my response to Sascha's e-mail, the LRH can and will still be able to update their objects in the RIPE Database even without any document signed. All this policy proposal does is that when the two parties want to finalise the transfer and request RIPE NCC's confirmation, they will need to sign a document. - the RIPE NCC would then verify the old holder is the legitimate LRH and - the RIPE NCC will also verify the transfer document is signed by authorised signatories on both the old and the new LRH.
In its current terms, i also object to this proposal.
Would there be any version that you would agree to, one that would consistently allow the RIPE NCC to publish the transfers of Intra-RIR legacy resources? They currently publish all but these.
Best Regards, Carlos Friaças
thank you, elvis
On Wed, 26 Apr 2017, Elvis Daniel Velea wrote:
Hi Carlos,
Hi,
On 4/26/17 12:12 AM, Carlos Friacas wrote:
Greetings,
While the proposal's title seems to be a positive approach, as i read it, its main goal is to add extra requirements for LRH by changing «RIPE NCC Services to Legacy Internet Resource Holders».
The way I see it, this policy proposal does not add extra requirements, it adds an extra service.
Which is exactly? and who will benefit from it? - only LRHs? - the whole community? - non-LRHs?
I think protection (or just better alarms in place!) for Legacy address space is a good thing, however, i'm not sure an extra workload for the NCC and the LRH in the case they want to transfer their asset(s) is the way to go. the extra workload is a document signed by the representatives of the two LRH (the Seller and the Buyer). The RIPE NCC verifies these kind of documents on a daily basis so I doubt that would be a whole lot of extra workload - they will confirm during the Impact Analysis.
Sure. And what would exactly configures a failed verification?
I also agree with Sascha Luck's previous comment about LRH having to submit to an extra verification process. As mentioned in my response to Sascha's e-mail, the LRH can and will still be able to update their objects in the RIPE Database even without any document signed.
You mean the "selling LRH"...? If my memory doesn't fail me, there are already some words about transfers on the current services' policy -- i need to double-check that.
All this policy proposal does is that when the two parties want to finalise the transfer
Is there a need for that...? How many LRH have expressed concerns about such a gap?
and request RIPE NCC's confirmation,
LRHs currently don't need to do this...?
they will need to sign a document. - the RIPE NCC would then verify the old holder is the legitimate LRH and
If the current holder has a services agreement in place with the NCC, this is already covered, right?
- the RIPE NCC will also verify the transfer document is signed by authorised signatories on both the old and the new LRH.
Here, i think the NCC will only need to get a new services agreement signed with the *new* holder, if the new holder wishes to...
In its current terms, i also object to this proposal. Would there be any version that you would agree to, one that would consistently allow the RIPE NCC to publish the transfers of Intra-RIR legacy resources?
As i previously said, stats (and potential hijack alarms) are a good thing. But this version still needs a lot of work, and especially also strong support from the LRHs -- otherwise, this verification mechanism you're trying to suggest will not add anything... And again, the NCC only has business regarding the services it provides to LRHs, but not over the address space itself... i think we are all aware about that bit. Best Regards, Carlos
They currently publish all but these.
Best Regards, Carlos Friaças
thank you, elvis
Hi, On 4/27/17 11:57 AM, Carlos Friacas wrote:
On Wed, 26 Apr 2017, Elvis Daniel Velea wrote:
The way I see it, this policy proposal does not add extra requirements, it adds an extra service.
Which is exactly? Transfer services according to the transfer policy. and who will benefit from it?
- only LRHs? LRH will have the option to register the transfer. - the whole community?
[...] the whole community the community will see better stats on how much is transferred.
- non-LRHs?
non-LRHs who want to purchase a LR will have the confirmation of the RIPE NCC that the IP block transfer has been verified by a third-party (the NCC)
I think protection (or just better alarms in place!) for Legacy address space is a good thing, however, i'm not sure an extra workload for the NCC and the LRH in the case they want to transfer their asset(s) is the way to go. the extra workload is a document signed by the representatives of the two LRH (the Seller and the Buyer). The RIPE NCC verifies these kind of documents on a daily basis so I doubt that would be a whole lot of extra workload - they will confirm during the Impact Analysis.
Sure. And what would exactly configures a failed verification?
A representative not having the proper authority to sign on behalf of the LRH. Or someone that has the maintainer password pretending to act on behalf of the LRH and trying to hijack the resource.
I also agree with Sascha Luck's previous comment about LRH having to submit to an extra verification process. As mentioned in my response to Sascha's e-mail, the LRH can and will still be able to update their objects in the RIPE Database even without any document signed.
You mean the "selling LRH"...?
If my memory doesn't fail me, there are already some words about transfers on the current services' policy -- i need to double-check that. LRH can be updated to point to an other company but a transfer in the real sense would only be confirmed once the RIPE NCC receives a signed document and can verify the signatory has the authority.
All this policy proposal does is that when the two parties want to finalise the transfer
Is there a need for that...? How many LRH have expressed concerns about such a gap? It is not a gap in the policies. Transfers of legacy space are currently not verified and/or approved by the RIPE NCC. Any update of a LR in the database object does not require the RIPE NCC to update the registry.
and request RIPE NCC's confirmation,
LRHs currently don't need to do this...? LRHs who have a contract with the RIPE NCC may need to request it, the ones that have opted not to have a contract are not required to present
yes the RIPE NCC any kind of documentation, they can just update the object in the RIPE Database and that's it.
they will need to sign a document. - the RIPE NCC would then verify the old holder is the legitimate LRH and
If the current holder has a services agreement in place with the NCC, this is already covered, right?
yes, I think.
- the RIPE NCC will also verify the transfer document is signed by authorised signatories on both the old and the new LRH.
Here, i think the NCC will only need to get a new services agreement signed with the *new* holder, if the new holder wishes to...
it's not that simple. What if the previous LRH does not have a services agreement? What if the new LRH does not want to sign one?
In its current terms, i also object to this proposal. Would there be any version that you would agree to, one that would consistently allow the RIPE NCC to publish the transfers of Intra-RIR legacy resources?
As i previously said, stats (and potential hijack alarms) are a good thing. But this version still needs a lot of work, and especially also strong support from the LRHs -- otherwise, this verification mechanism you're trying to suggest will not add anything...
What would you like me to work on? What is unclear. The mechanism will provide the Buyer an option to request the RIPE NCC to verify and confirm (finalise) the transfer. I expect this requirement to become the standard for transfers of LR.
And again, the NCC only has business regarding the services it provides to LRHs, but not over the address space itself... i think we are all aware about that bit.
I am aware of this and this policy proposal does not aim to give the RIPE NCC additional powers over the LR.
Best Regards, Carlos
Kind regards, Elvis -- Elvis Daniel Velea V4Escrow LLC Chief Executive Officer E-mail: elvis@v4escrow.net Mobile: +1 (702) 970 0921
Hi Elvis, Elvis Daniel Velea wrote: [...]
Is there a need for that...? How many LRH have expressed concerns about such a gap? It is not a gap in the policies. Transfers of legacy space are currently not verified and/or approved by the RIPE NCC. Any update of a LR in the database object does not require the RIPE NCC to update the registry.
If there is no gap in the policies and what you are proposing is service, why was this introduced to the Address Policy WG? The charter for the RIPE NCC Services Working Group makes it clear that it is the home for discussions about the introduction of new services and tools (https://www.ripe.net/participate/ripe/wg/services). Kind regards, Leo Vegoda
Hi Leo, Let me provide some insight on how Inter-RIR legacy transfer go from, for instance ARIN to RIPE. Once a ticket has been submitted via the ARIN system for a transfer, by the originating party, ARIN will process the transfer, verify the legitimacy of the holdership etc. and they will forward the ticket to RIPE NCC. The RIPE NCC will do the check with the receiving party if they are eligible for the transfer and can justify the needs assessment that is required. The RIPE NCC will request the parties (received and originating party) to indemnify the RIPE NCC for any changes in the RIPE DB .. the word is that it isn't a contract, but there are legal words involved and signatures required on paper and the RIPE NCC is the third party beneficiary of the paper that isn't a contract. ( the indemnification .. ) And then they will also request a copy of the company registration of the receiving party and the originating party for the correct documentation in the Registry (the RIPE NCC internal system). The RIPE NCC has a very strict verification system in place for transfers, so your assumption that they don't verify or approve transfers ... ( Specifically Legacy resources.. ) is not correct. They do verify and check . . . and check .. and check again .. And I rather have them do this once to many times. And this is almost similar for regular Legacy transfers if a parent prefix needs to be split .. as that can only be done by the RIPE NCC and the updating of the registry of the RIPE NCC for holdership changes must also be documented properly.. So if you ask the RIPE NCC to update the registry after a legacy transfer, they will ask you for some documents to proof who you are and to indemnify the RIPE NCC for any mistakes in the updating of the info if needed.. I never had ANY LHR ask me why they are not listed in the RIPE stats for transfer as a Legacy holder. Most of the sending and receiving parties would rather not be listed instead of being published on the transfer stats page. However for completion of the data about transfers, it could be interesting for some (mostly researchers and probably brokers.. ) to get an idea about the current market.. However if you maintain your own versioning of the RIPE database, you can also do this yourself internally and just diff the DB between last week and today if needed. As on your remark on the services WG as the Go-To WG for LHR .. that might swing both ways.. as most Transfer policy discussions have been done here. But I'm not arguing that you are incorrect on the point. Regards, Erik Bais A2B Internet & Prefix Broker -----Oorspronkelijk bericht----- Van: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] Namens Leo Vegoda Verzonden: vrijdag 28 april 2017 18:21 Aan: elvis@v4escrow.net; Carlos Friacas <cfriacas@fccn.pt> CC: address-policy-wg@ripe.net Onderwerp: Re: [address-policy-wg] [Ext] Re: 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) Hi Elvis, Elvis Daniel Velea wrote: [...]
Is there a need for that...? How many LRH have expressed concerns about such a gap? It is not a gap in the policies. Transfers of legacy space are currently not verified and/or approved by the RIPE NCC. Any update of a LR in the database object does not require the RIPE NCC to update the registry.
If there is no gap in the policies and what you are proposing is service, why was this introduced to the Address Policy WG? The charter for the RIPE NCC Services Working Group makes it clear that it is the home for discussions about the introduction of new services and tools (https://www.ripe.net/participate/ripe/wg/services). Kind regards, Leo Vegoda
Let me provide some insight on how Inter-RIR legacy transfer go from, for instance ARIN to RIPE.
i think there was a presentation on the actualy reality of this at some yuroopian ops meeting. see https://archive.psg.com/160524.ripe-transfer.pdf randy
Hi Erik, Erik Bais wrote: [...]
However if you maintain your own versioning of the RIPE database, you can also do this yourself internally and just diff the DB between last week and today if needed.
I did not realize the RIPE NCC's AUP had been changed to allow users to make copies of the database. This is an interesting change! Regards, Leo
Hi, On Fri, Apr 28, 2017 at 04:20:31PM +0000, Leo Vegoda wrote:
If there is no gap in the policies and what you are proposing is service, why was this introduced to the Address Policy WG? The charter for the RIPE NCC Services Working Group makes it clear that it is the home for discussions about the introduction of new services and tools (https://www.ripe.net/participate/ripe/wg/services).
The AP and NCC Services WG chairs debated this, and it's "sitting on the fence" - legacy stuff / NCC services obviously go to the NCC Services WG, but since it was felt that APWG "owns" the transfer policy document, which is potentially subject to change here, the proposal ended here. We've sent a heads up to the NCC Service WG so they are informed. Gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi Gert, Gert Doering wrote:
On Fri, Apr 28, 2017 at 04:20:31PM +0000, Leo Vegoda wrote:
If there is no gap in the policies and what you are proposing is service, why was this introduced to the Address Policy WG? The charter for the RIPE NCC Services Working Group makes it clear that it is the home for discussions about the introduction of new services and tools (https://www.ripe.net/participate/ripe/wg/services).
The AP and NCC Services WG chairs debated this, and it's "sitting on the fence" - legacy stuff / NCC services obviously go to the NCC Services WG, but since it was felt that APWG "owns" the transfer policy document, which is potentially subject to change here, the proposal ended here.
We've sent a heads up to the NCC Service WG so they are informed.
Thanks for the explanation! Regards, Leo
Hi Elvis Daniel, All, Though I would like to read the Impact Analysis before committing, I am in general support of this policy change. Improving transparency of basic IP transfer data is a good thing for the community for the aforementioned reasons. Particularly to improve the accuracy of transfer activity stats, trends and analysis. And I like that LRHs are not forced to opt-in, though there will be a clear incentive to do so in order to have a LR transfer verified by the RIPE NCC. Regards, James Kennedy -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Elvis Daniel Velea Sent: 28 April 2017 13:36 To: Carlos Friacas Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) Hi, On 4/27/17 11:57 AM, Carlos Friacas wrote:
On Wed, 26 Apr 2017, Elvis Daniel Velea wrote:
The way I see it, this policy proposal does not add extra requirements, it adds an extra service.
Which is exactly? Transfer services according to the transfer policy. and who will benefit from it?
- only LRHs? LRH will have the option to register the transfer. - the whole community?
[...] the whole community the community will see better stats on how much is transferred.
- non-LRHs?
non-LRHs who want to purchase a LR will have the confirmation of the RIPE NCC that the IP block transfer has been verified by a third-party (the NCC)
I think protection (or just better alarms in place!) for Legacy address space is a good thing, however, i'm not sure an extra workload for the NCC and the LRH in the case they want to transfer their asset(s) is the way to go. the extra workload is a document signed by the representatives of the two LRH (the Seller and the Buyer). The RIPE NCC verifies these kind of documents on a daily basis so I doubt that would be a whole lot of extra workload - they will confirm during the Impact Analysis.
Sure. And what would exactly configures a failed verification?
A representative not having the proper authority to sign on behalf of the LRH. Or someone that has the maintainer password pretending to act on behalf of the LRH and trying to hijack the resource.
I also agree with Sascha Luck's previous comment about LRH having to submit to an extra verification process. As mentioned in my response to Sascha's e-mail, the LRH can and will still be able to update their objects in the RIPE Database even without any document signed.
You mean the "selling LRH"...?
If my memory doesn't fail me, there are already some words about transfers on the current services' policy -- i need to double-check that. LRH can be updated to point to an other company but a transfer in the real sense would only be confirmed once the RIPE NCC receives a signed document and can verify the signatory has the authority.
All this policy proposal does is that when the two parties want to finalise the transfer
Is there a need for that...? How many LRH have expressed concerns about such a gap? It is not a gap in the policies. Transfers of legacy space are currently not verified and/or approved by the RIPE NCC. Any update of a LR in the database object does not require the RIPE NCC to update the registry.
and request RIPE NCC's confirmation,
LRHs currently don't need to do this...? LRHs who have a contract with the RIPE NCC may need to request it, the ones that have opted not to have a contract are not required to present
yes the RIPE NCC any kind of documentation, they can just update the object in the RIPE Database and that's it.
they will need to sign a document. - the RIPE NCC would then verify the old holder is the legitimate LRH and
If the current holder has a services agreement in place with the NCC, this is already covered, right?
yes, I think.
- the RIPE NCC will also verify the transfer document is signed by authorised signatories on both the old and the new LRH.
Here, i think the NCC will only need to get a new services agreement signed with the *new* holder, if the new holder wishes to...
it's not that simple. What if the previous LRH does not have a services agreement? What if the new LRH does not want to sign one?
In its current terms, i also object to this proposal. Would there be any version that you would agree to, one that would consistently allow the RIPE NCC to publish the transfers of Intra-RIR legacy resources?
As i previously said, stats (and potential hijack alarms) are a good thing. But this version still needs a lot of work, and especially also strong support from the LRHs -- otherwise, this verification mechanism you're trying to suggest will not add anything...
What would you like me to work on? What is unclear. The mechanism will provide the Buyer an option to request the RIPE NCC to verify and confirm (finalise) the transfer. I expect this requirement to become the standard for transfers of LR.
And again, the NCC only has business regarding the services it provides to LRHs, but not over the address space itself... i think we are all aware about that bit.
I am aware of this and this policy proposal does not aim to give the RIPE NCC additional powers over the LR.
Best Regards, Carlos
Kind regards, Elvis -- Elvis Daniel Velea V4Escrow LLC Chief Executive Officer E-mail: elvis@v4escrow.net Mobile: +1 (702) 970 0921
Hi James, On Tue, May 2, 2017 at 1:49 PM Kennedy, James <jkennedy@libertyglobal.com> wrote:
Hi Elvis Daniel, All,
Though I would like to read the Impact Analysis before committing, I am in general support of this policy change. Improving transparency of basic IP transfer data is a good thing for the community for the aforementioned reasons. Particularly to improve the accuracy of transfer activity stats, trends and analysis.
thank you for your support. I hope that the IA will convince you to provide your strong support to this policy proposal.
And I like that LRHs are not forced to opt-in, though there will be a clear incentive to do so in order to have a LR transfer verified by the RIPE NCC.
I expected to see opposition from the LRHs if this proposal would have included any limitations. That is why, on purpose, this policy proposal does not limit any of the rights of the LRHs. Kind regards, Elvis
Regards, James Kennedy
-- Elvis Daniel Velea V4Escrow LLC Chief Executive Officer E-mail: elvis@v4escrow.net Mobile: +1 (702) 970 0921 Excuse the briefness of this mail, it was sent from a mobile device.
A new RIPE Policy proposal, 2017-01, "Publish statistics on Intra-RIR Legacy updates" is now available for discussion.
The goal of this proposal is to require the RIPE NCC to publish all changes to the holdership of legacy resources in the existing transfer statistics.
that is not a goal, but rather the means. but a means to what end? i.e. what is the goal of this proposal; what problem does it intend to solve, or what wonderful opportunity does it hope to exploit? the written proposal says In addition to introducing greater transparency, this policy change would also protect legacy holders from potential hijacks. why is this true only for legacy space? randy
On 26/04/2017 02:46, Randy Bush wrote:
A new RIPE Policy proposal, 2017-01, "Publish statistics on Intra-RIR Legacy updates" is now available for discussion.
The goal of this proposal is to require the RIPE NCC to publish all changes to the holdership of legacy resources in the existing transfer statistics. that is not a goal, but rather the means. but a means to what end? i.e. what is the goal of this proposal; what problem does it intend to solve, or what wonderful opportunity does it hope to exploit?
the written proposal says
In addition to introducing greater transparency, this policy change would also protect legacy holders from potential hijacks.
why is this true only for legacy space? Further to this point: can RIPE NCC provide statistics for the past 3 years of the number of IP resource hijacks that have taken place?
Thanks, Hank
randy
Dear Hank, On 2017-04-26 07:17:35 CET, Hank Nussbacher wrote:
why is this true only for legacy space? Further to this point: can RIPE NCC provide statistics for the past 3 years of the number of IP resource hijacks that have taken place?
Thank you for your question. We are happy to provide some information here. Firstly, it’s important to note that the following numbers mainly refer to resources that are under a contractual relationship with the RIPE NCC. The RIPE Database contains several thousand parent legacy ranges that are not covered by a contractual relationship. Whoever has access to the maintainer can update all details of the resource object. We would only notice hijacks of these resources if the resource holder reports the hijack or the hijacker asks us to update our internal records. Since 2014, the RIPE NCC has concluded around 300 hijack cases for all types of resources, another 16 cases are still being investigated. We reported on resource hijacking in our 2016 Annual Report. As we mentioned there, legacy resources remain susceptible to hijacks using fraudulently provided statements and several cases are under active investigation. You can find this on page 18 here (PDF): https://www.ripe.net/participate/meetings/gm/meetings/may-2017/supporting-do... I hope this clarifies your question. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
Hi Elvis, I've read the proposal and I’m not sure I see what you are trying to solve here ... besides the obvious … Because if you look at the following URL: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tran sfers/inter-rir-transfers/inter-rir-ipv4-transfer-statistics There is a specific section for Inter-RIR transfers .. with a to RIPE and
From RIPE tab..
And in the To tab, you will see the following (as an example.. ) 157.97.0.0/16 ARIN A&F Networks B.V. 17/03/2016 147.28.0.0/16 ARIN RGnet, LLC 16/03/2016 192.83.230.0/24 ARIN RGnet, LLC 16/03/2016 198.133.206.0/24 ARIN RGnet, LLC 16/03/2016 And these are all Legacy Prefixes inter-rir transfers done .. and published.. So if the RIPE NCC is already registering the prefixes as part of the Inter RIR transfers .. even before they are marked as a Legacy prefix.. in the RIPE DB .. How will this policy make a difference ? And the change in the transfer document that the RIPE NCC is currently still implementing .. it clearly states the following : https://www.ripe.net/publications/docs/ripe-682#4-0-transfer-statistics * 4.0 Transfer Statistics * The RIPE NCC will publish a list of all transfers. This publication shall occur on a monthly basis or more frequently if the RIPE NCC so chooses. * This list will contain information about approved changes. The following information will be published: * The name of the offering party * The resource originally held by the offering party * The name(s) of the receiving party or parties * Each subdivided prefix (each partial block derived from that original block) or resource received * The date each resource was transferred * Whether it was a transfer according to this policy or a transfer due to changes to an organisation's business structure (such as a merger or acquisition) And I like to put the emphasis on : * The RIPE NCC will publish a list of all transfers. And * Whether it was a transfer according to this policy or a transfer due to changes to an organisation's business structure (such as a merger or acquisition) This paragraph 4 isn’t a part of the paragraph 3.. (3.0 Inter-RIR Transfers ) … or the limitations in paragraph 2 (2.0 Transfers within the RIPE NCC Service Region) And there is also no difference between RIPE PA or Legacy space in that section … So how I read (and wrote) the policy is that the Transfer statistics should be published on all transfers. * A transfer can be a change of resources from company name A to company name B .. (via the M&A process) * Or via the actual Transfer procedure … * Or a company name change .. ( company A is now known as company B, but same company, same owners etc. ) This is the least interesting one imho. There is no limitation for legacy resources .. and it doesn’t affect their legacy status .. under this policy. There is a difference between the RIPE DB and the RIPE registry.. if you want to update the DB, the LRH can do that themselves.. But if the LRH wants to update the registry (the RIPE NCC internal system), they should provide the proper documentation. And that is already in place in procedures.. So the actual change that you are asking is : In the Services to Legacy Resource Holder policy (https://www.ripe.net/publications/docs/ripe-639) .. Have Legacy Holders to agree to sign a document, that the RIPE NCC already has in the operational procedure. In which case the name of the policy is incorrect .. as it isn’t about Inter-RIR legacy updates .. or transfers .. but about the Services to LRH’s .. Perhaps we should see first what the RIPE NCC will implement with the 2015-04 … before we go look into additional policy … Regards, Erik Bais A2B Internet -----Oorspronkelijk bericht----- Van: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] Namens Marco Schmidt Verzonden: dinsdag 25 april 2017 14:40 Aan: address-policy-wg@ripe.net Onderwerp: [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) Dear colleagues, A new RIPE Policy proposal, 2017-01, "Publish statistics on Intra-RIR Legacy updates" is now available for discussion. The goal of this proposal is to require the RIPE NCC to publish all changes to the holdership of legacy resources in the existing transfer statistics. You can find the full proposal at: <https://www.ripe.net/participate/policies/proposals/2017-01> https://www.ripe.net/participate/policies/proposals/2017-01 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to < <mailto:address-policy-wg@ripe.net> address-policy-wg@ripe.net> before 24 May 2017. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- <https://www.ripe.net/participate/mail/forum> https://www.ripe.net/participate/mail/forum
Hello Erik, We would like to provide some clarification regarding your point on publishing transfer statistics for legacy updates. On 2017-05-02 15:39:39 CET, Erik Bais wrote:
And I like to put the emphasis on :
* The RIPE NCC will publish a list of all transfers.
And
* Whether it was a transfer according to this policy or a transfer due to changes to an organisation's business structure (such as a merger or acquisition)
This paragraph 4 isnt a part of the paragraph 3.. (3.0 Inter-RIR Transfers ) or the limitations in paragraph 2 (2.0 Transfers within the RIPE NCC Service Region)
And there is also no difference between RIPE PA or Legacy space in that section
So how I read (and wrote) the policy is that the Transfer statistics should be published on all transfers.
* A transfer can be a change of resources from company name A to company name B .. (via the M&A process)
* Or via the actual Transfer procedure
* Or a company name change .. ( company A is now known as company B, but same company, same owners etc. ) This is the least interesting one imho.
There is no limitation for legacy resources .. and it doesnt affect their legacy status .. under this policy.
The current Transfer Policy does not include the publishing of legacy updates within the RIPE NCC service region. The RIPE Policy, "RIPE NCC Services to Legacy Internet Resource Holders", clearly states that "Any existing or future RIPE policy referring to resources shall not apply to legacy resources unless the policy explicitly includes legacy resources in its scope." https://www.ripe.net/publications/docs/ripe-639#1-2-scope Legacy resources are mentioned in the scope of the Transfer Policies for inter-RIR transfers, but not for updates within our service region or transfer statistics. Of course, another difficulty is that the RIPE NCC is not involved in many of these legacy updates. Therefore, we would not be able to distinguish whether a legacy update relates to a resource transfer, a merger, or a company name change in any statistics that we published. We hope this is helpful. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
participants (11)
-
Carlos Friacas -
David Farmer -
Elvis Daniel Velea -
Erik Bais -
Gert Doering -
Hank Nussbacher -
Kennedy, James -
Leo Vegoda -
Marco Schmidt -
Randy Bush -
Sascha Luck [ml]