2015-04 New Policy Proposal (RIPE Resource Transfer Policies)
Dear colleagues, A new RIPE Policy Proposal, "RIPE Resource Transfer Policies" has been made and is now available for discussion. The goal of this proposal is to create a single document with all relevant information regarding the transfer of Internet number resources. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-04 We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 14 September. Regards Marco Schmidt Policy Development Officer RIPE NCC
On 14 August 2015 at 10:54, Marco Schmidt <mschmidt@ripe.net> wrote:
https://www.ripe.net/participate/policies/proposals/2015-04
We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 14 September.
Couple of questions/comments...
From 1.0
Shouldn't the scope be explicit as to what is/isn't included
From 2.1
"Transfers can be on a permanent or non-permanent basis." How is this going to be recorded and managed within the context of reflecting it being a non-permanent transfer?
From 2.2
"assigned by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit ASNs)" Rather than "such as" this needs to be a definitive list of what is classed as a restricted resource
From 3.1
Again a list of conditions or references to policies that impose restrictions needed
From 4.0
M&A process is mentioned, should there be other references to this? Especially as M&A (as I understand it) allows 2.2 to be overridden General - As this is about transfers should this also cover returning resources to ripe NCC so all types of transfers be included - broadly support the unification of transfer policy into a single document, just things bits are missing or muddy J -- James Blessing 07989 039 476
On Fri, Aug 14, 2015 at 12:17 PM, James Blessing < james.blessing@despres.co.uk> wrote:
On 14 August 2015 at 10:54, Marco Schmidt <mschmidt@ripe.net> wrote:
Thanks for putting in the time and effort, Erik! Couple of questions/comments...
From 1.0
Shouldn't the scope be explicit as to what is/isn't included
I agree that this would help.
From 2.1
"Transfers can be on a permanent or non-permanent basis."
How is this going to be recorded and managed within the context of reflecting it being a non-permanent transfer?
Wouldn't that be up to the RIPE NCC?
From 2.2
"assigned by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit ASNs)"
Rather than "such as" this needs to be a definitive list of what is classed as a restricted resource
I concur, but I don't think it should be listed in the same document. My first thought is that this list should be maintained by the RIPE NCC. Keeping that list in a separate document means changing fewer documents when policy changes, or reality reaches a pre-set limit set in policy. That separate list should reference the policy documents enabling the restrictions.
From 3.1
Again a list of conditions or references to policies that impose restrictions needed
I'm a bit confused both by the point and by your response to it, maybe I'm just tired, but I think both could be clearer. :)
From 4.0
M&A process is mentioned, should there be other references to this? Especially as M&A (as I understand it) allows 2.2 to be overridden
"The document proposes to include the transfer restrictions to mergers and acquisitions. This is done to make the policy more in line with the intention of the transfer policy restrictions when proposed." General
- As this is about transfers should this also cover returning resources to ripe NCC so all types of transfers be included
I'm not sure that this would be useful, but 2015-04 could 1) include a reference to the policy for that, and 2) make it even clearer that this is a document for transfers between resource holders. I don't think it's useful to consider the RIR a resource holder in this context. - broadly support the unification of transfer policy into a single
document, just things bits are missing or muddy
Agreed, but the document is largely clarifying more than muddying, IMHO. -- Jan
Hi James,
Couple of questions/comments...
From 1.0
Shouldn't the scope be explicit as to what is/isn't included
It states what is included ... are you missing anything specific ?
From 2.1
"Transfers can be on a permanent or non-permanent basis."
How is this going to be recorded and managed within the context of reflecting it being a non-permanent transfer?
That is taken directly from the current policy text and it is managed by the RIPE NCC. I must admit that I haven't seen non-permanent transfers myself (yet), so I would have to ask the NCC on how they are exposing that if at all publicly. The text itself isn't different to what there is already there.
From 2.2
"assigned by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit ASNs)"
Rather than "such as" this needs to be a definitive list of what is classed as a restricted resource
The part between the round brackets was put there as the current examples to what are the almost depleted resources. As IPv4 isn't completely depleted yet ( due to the final /8 policy ) and neither are 16-bit ASN's.. That implies that other resources like IPv6 or 32-bit ASN's are not restrictive by a 24 month transfer restriction as there is no logical requirement that we could find to put it in the policy.
From 3.1
Again a list of conditions or references to policies that impose restrictions needed
You mean other than what is currently in the proposed text ? Currently all resources that we have are possible to be transferred ...
From 4.0
M&A process is mentioned, should there be other references to this? Especially as M&A (as I understand it) allows 2.2 to be overridden
An M&A is not a transfer ... a M&A is a change in a business where one company or service offering with assets/resources are going from one company to another company. That can be in the same company ( Look at companies like IBM or Philips or GE for instance that are splitting off services to a new business unit .. or buying competing companies and incorporating that into their own business / service..) Sometimes there are stocks being sold, however there are more ways of M&A's within today's business. Typical the goal of M&A's are not the (number) resources, but other services/assets/added value that would create the value ... And with a transfer, the goal is getting or selling the specified resource. Also the M&A is a business (operational) process.. and transfers are a policy.
General
- As this is about transfers should this also cover returning resources to ripe NCC so all types of transfers be included
The text is pretty clear imho on what it covers.. any number resource to and from the RIPE NCC service region ... Both TO and FROM the RIPE region ...
- broadly support the unification of transfer policy into a single document, just things bits are missing or muddy
I hope that we made a good start here :) Erik Bais
Hi, On Fri, Aug 14, 2015 at 11:54:04AM +0200, Marco Schmidt wrote:
A new RIPE Policy Proposal, "RIPE Resource Transfer Policies" has been made and is now available for discussion.
To add a bit of info: this is the unified transfer policy Erik promised, that is "a new document that has the transfer policy for all transferrable resources" and all the other policy documents only refer to it. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
You can find the full proposal at:
first of all, a large thank-you for handling this policy aggregation. This will make things a lot easier for organisations to understand how RIPE transfer policy works. Although policy reworking like this is completely thankless, it's important to do. I've gone down through the new policy and compared it against the old. As expected, there is plenty of optimisation going on, but optimisation means changes and changes mean that we need to understand what's been changed. Enumerating some of the changes: "Resources are excluded from transfers when RIPE Policies mandate their return to the RIPE NCC.": this is completely new text. approve. ipv6 transfer policy: added "Transfers must be reflected in the RIPE Database. Transfers can be on a permanent or non-permanent basis.". approve. ipv6 transfer policy: removed "The block that is to be re-allocated must not be smaller than the minimum allocation size at the time of re-allocation". for the record, this is an interesting consequence of section 2.1, paragraph 3. I.e. no point in repeating policy that already exists. asn transfer policy: added "scarce resources ... cannot be transferred by the resource holder within 24 months". I don't disagree with this, nor with the genericisation of this transfer restriction. all policies: the tightening of the policy text in section 2.1 concerning who's currently responsible for the resource ("the original resource holder ... policies are applied") is good. asn + ipv6 policies: added statement that ripe policies apply for the duration of transfer and during the transfer process itself - to align with the ipv4 policy. This is good, but other RIRs may claim that their policies apply during the transfer process. Would it be worth discussing at a higher level whether there should be a global policy for which RIR policy applies during the transfer process? all policies: "Resources are excluded from transfers when RIPE Policies mandate their return to the RIPE NCC". Mmm. I'd be careful about inserting something like this. Can you explain the intention and the meaning of this clause? all policies: removed statement about publishing stats on non-approved transfers. Whoa, what's going on here? Not ok. Nick
On Mon, Aug 31, 2015 at 10:22:09PM +0100, Nick Hilliard wrote:
first of all, a large thank-you for handling this policy aggregation. This will make things a lot easier for organisations to understand how RIPE transfer policy works. Although policy reworking like this is completely thankless, it's important to do.
I support this statement. And thank you for diffing/summarising this big document as well.
"Resources are excluded from transfers when RIPE Policies mandate their return to the RIPE NCC.": this is completely new text. approve.
[...]
all policies: "Resources are excluded from transfers when RIPE Policies mandate their return to the RIPE NCC". Mmm. I'd be careful about inserting something like this. Can you explain the intention and the meaning of this clause?
Can't have it both ways ;p As for myself, I would like to see some clarification on this myself.
asn transfer policy: added "scarce resources ... cannot be transferred by the resource holder within 24 months". I don't disagree with this, nor with the genericisation of this transfer restriction.
I do (disagree). IMO this should be a separate policy change, not something to be hidden in a huge re-work. Generally I would prefer if this re-work would only aggregate the transfer policies and any material changes, in particular, restrictions, would be left to later proposals. It will also speed the approval of the proposal if there were no potentially contentious changes. As it stands I'll have to, provisionally, declare opposition to this proposal pending a more careful re-read to find any other little landmines that may be hidden in there. rgds, Sascha Luck
On 31/08/2015 23:18, Sascha Luck [ml] wrote:
Can't have it both ways ;p As for myself, I would like to see some clarification on this myself.
have cake, eat cake. As you point out, I changed my mind mid-email. It happens.
asn transfer policy: added "scarce resources ... cannot be transferred by the resource holder within 24 months". I don't disagree with this, nor with the genericisation of this transfer restriction.
I do (disagree). IMO this should be a separate policy change, not something to be hidden in a huge re-work.
The only thing that's changing is that asn16s are now be included in the 24m restriction. IPv4 addresses are already there. Nick
* Nick Hilliard
first of all, a large thank-you for handling this policy aggregation. This will make things a lot easier for organisations to understand how RIPE transfer policy works. Although policy reworking like this is completely thankless, it's important to do.
Hear hear.
all policies: removed statement about publishing stats on non-approved transfers. Whoa, what's going on here? Not ok.
I might be to blame for this one. Let me elaborate: 2012-05, which introduced this requirement, said the following: «Recording when address transfers were denied on the basis of needs evaluation (without identifying the block or the proposed recipient) is also important, because it facilitates greater awareness of the impact of RIPE NCC’s application of needs assessment policies on the transfer market.» However, needs assessment for IPv4 transfers (which was the only type allowed at the time) was removed by 2013-03. Thus I considered the requirement to be defunct policy as the NCC no longer would have any reason to not approve of transfers, but I didn't get around to remove it as part of 2013-03. That has irked me since, so I suggested to Erik that maybe he could clean it away in his transfer unification proposal instead. That said, I now realise that since 2014-12 and 2014-13 passed there might again be requests for IPv6/ASN transfers that the NCC might not approve of, making 2015-04's removal of the publishing requirement an actual change to effective policy. In light of that I suppose my suggestion might have been a bad one. My apologies, Erik. Tore
wow Nick, thanks for the diff. I have not had time to carefully ready all the documents, so, this reply is only to your comments. I'll send an other e-mail If I find anything else worth mentioning once I get the time to compare all the current policy documents to the new policy proposal. On 01/09/15 00:22, Nick Hilliard wrote:
You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2015-04 first of all, a large thank-you for handling this policy aggregation. This will make things a lot easier for organisations to understand how RIPE transfer policy works. Although policy reworking like this is completely thankless, it's important to do. big thanks, Erik I've gone down through the new policy and compared it against the old. As expected, there is plenty of optimisation going on, but optimisation means changes and changes mean that we need to understand what's been changed.
Enumerating some of the changes:
"Resources are excluded from transfers when RIPE Policies mandate their return to the RIPE NCC.": this is completely new text. approve. I would like this to be clarified. I don't recall having any policies mandating a return of a resource to the RIPE NCC.
ipv6 transfer policy: added "Transfers must be reflected in the RIPE Database. Transfers can be on a permanent or non-permanent basis.". approve. +1
ipv6 transfer policy: removed "The block that is to be re-allocated must not be smaller than the minimum allocation size at the time of re-allocation". for the record, this is an interesting consequence of section 2.1, paragraph 3. I.e. no point in repeating policy that already exists. ok
asn transfer policy: added "scarce resources ... cannot be transferred by the resource holder within 24 months". I don't disagree with this, nor with the genericisation of this transfer restriction. I do not disagree with this change. I would, as Sacha said, prefer to discuss it in a separate policy proposal. all policies: the tightening of the policy text in section 2.1 concerning who's currently responsible for the resource ("the original resource holder ... policies are applied") is good.
asn + ipv6 policies: added statement that ripe policies apply for the duration of transfer and during the transfer process itself - to align with the ipv4 policy. This is good, but other RIRs may claim that their policies apply during the transfer process. Would it be worth discussing at a higher level whether there should be a global policy for which RIR policy applies during the transfer process? I also believe that as long as a resource is registered in a registry's db, that registry's policy must apply.
all policies: "Resources are excluded from transfers when RIPE Policies mandate their return to the RIPE NCC". Mmm. I'd be careful about inserting something like this. Can you explain the intention and the meaning of this clause? same as above.. I'd like this to be explained.
all policies: removed statement about publishing stats on non-approved transfers. Whoa, what's going on here? Not ok. IMHO, aggregated stats should still exist for non-approved transfers. Nick
regards, elvis
Hi Nick,
You can find the full proposal at:
first of all, a large thank-you for handling this policy aggregation. Let's see if we can get it across the room :)
And thank you for the diff ... I'm a bit behind on my mail replies, but let's get started on the discussion here...
This will make things a lot easier for organisations to understand how RIPE transfer policy works. Although policy reworking like this is completely thankless, it's important to do.
As stated earlier, I made some of the mess in the current policy text, and I said I would make a proposal to clean it up. The current text was required to get the current policies in place .. and most of the transfer procedures are currently (almost) the same for all resources.. That was done intentionally when I made the policies, in order to be able to make this clean-up easier ...
I've gone down through the new policy and compared it against the old. As expected, there is plenty of optimisation going on, but optimisation means changes and changes mean that we need to understand what's been changed.
Enumerating some of the changes:
"Resources are excluded from transfers when RIPE Policies mandate their return to the RIPE NCC.": this is completely new text. approve.
To clarify here ... although all types of number resources can be transferred.. ( AS, IPv4, IPv6 ) there are some specific resources ( like v4 for IXP usage ) are not allowed to be transferred and MUST be returned.. https://www.ripe.net/publications/docs/ripe-649#61 So in itself it is a more specific statement in the intent of the policy, this new policy isn't going to change the transfer options if the current policy states that it must be returned..
ipv6 transfer policy: added "Transfers must be reflected in the RIPE Database. Transfers can be on a permanent or non-permanent basis.". approve.
ipv6 transfer policy: removed "The block that is to be re-allocated must not be smaller than the minimum allocation size at the time of re-allocation". for the record, this is an interesting consequence of section 2.1, paragraph 3. I.e. no point in repeating policy that already exists.
asn transfer policy: added "scarce resources ... cannot be transferred by the resource holder within 24 months". I don't disagree with this, nor with the genericisation of this transfer restriction.
I also addressed this in the email of James. And it was also discussed during the AS transfer policy in the room at the AP-WG. The transfer policy time restriction is for scarce resources .. ( like IPv4 and 16-bits ASN's.) and not for IPv6 or 32-bit ASn's.
all policies: the tightening of the policy text in section 2.1 concerning who's currently responsible for the resource ("the original resource holder ... policies are applied") is good.
asn + ipv6 policies: added statement that ripe policies apply for the duration of transfer and during the transfer process itself - to align with the ipv4 policy. This is good, but other RIRs may claim that their policies apply during the transfer process. Would it be worth discussing at a higher level whether there should be a global policy for which RIR policy applies during the transfer process?
When dealing with the Inter RIR-policy, one should look at both RIR sides for the inter RIR policy in both regions. I must admit that I tried to keep the current inter RIR policy text the same as it already was, to avoid any possible delay of the current policy or other RIR board freaking out over a specific word that might change the policy in their view.. or the impact. I'm just pointing in that respect to the statement of the APNIC board to single handed freeze any transfers up front between APNIC and RIPE, just to look at the possible policy impact..
all policies: "Resources are excluded from transfers when RIPE Policies mandate their return to the RIPE NCC". Mmm. I'd be careful about inserting something like this. Can you explain the intention and the meaning of this clause?
The reason to include this was to be extra careful .. Yes we can transfer everything ... unless policy states it otherwise. So this policy document doesn't override things as implemented for Internet Exchange reservations ... https://www.ripe.net/publications/docs/ripe-649#61
all policies: removed statement about publishing stats on non-approved transfers. Whoa, what's going on here? Not ok.
There is no need .. from what I've understood, the RIPE NCC didn't had any situation after the post depletion policy text clean-up (http://www.ripe.net/ripe/policies/proposals/2013-03) that transfers could be denied .. And if there is no situation to not approve transfers, why publish the number that is not going to change ? If documents for transfers are not approved, they are not denied transferred, the tickets will not be processed because the paperwork isn't correct. Btw.. did you see that nr. 4.0 will also implement if a new field in the transfer statistics ... - Whether it was a transfer or merger/acquisition As it will also make a slight change in the transfer restrictions .. as it closes the 'loophole' to have transfers now also restricted after M&A's and not only after allocation by RIPE NCC or transfers. The point 2.2 wording ( cannot be transferred by the resource holder within 24 months from the date the resource was received. ) is the cause of that.. and as such the statistics should reflect that info. Hence that update there.. Regards, Erik Bais
On Wed, Sep 02, 2015 at 12:37:22AM +0200, Erik Bais wrote:
To clarify here ... although all types of number resources can be transferred.. ( AS, IPv4, IPv6 ) there are some specific resources ( like v4 for IXP usage ) are not allowed to be transferred and MUST be returned.. https://www.ripe.net/publications/docs/ripe-649#61
So in itself it is a more specific statement in the intent of the policy, this new policy isn't going to change the transfer options if the current policy states that it must be returned..
OK, didn't actually know this restriction existed.
I also addressed this in the email of James. And it was also discussed during the AS transfer policy in the room at the AP-WG. The transfer policy time restriction is for scarce resources .. ( like IPv4 and 16-bits ASN's.) and not for IPv6 or 32-bit ASn's.
A holding period for ASN16 is a material change in assignment policy and should be in a separate proposal, not hidden in a (in itself valuable) transfer policy aggregation proposal.
Btw.. did you see that nr. 4.0 will also implement if a new field in the transfer statistics ...
- Whether it was a transfer or merger/acquisition
As it will also make a slight change in the transfer restrictions .. as it closes the 'loophole' to have transfers now also restricted after M&A's and not only after allocation by RIPE NCC or transfers.
What is this supposed to mean? The 24-month timer resets if a resource is acquired by M&A? Pretty substantial change IMO. Again, this should be subject to a separate proposal. And perhaps a membership vote as it materially affects the M&A procedure. People, the RIPE community should not make policy like the US House of Representatives - by this I mean hiding your wish list in marginally related legislation in the hope that it will go unnoticed. This proposal is a much needed aggregation of scattered policy items and a laudable effort by the author. It is ill served by trying to make changes to policy at the same time. As a result, I will oppose 2015-04 until I am satisfied that there is no material change in policy contained within, and am looking forward to discuss such changes on their own merits. rgds, Sascha Luck
Hi Sascha,
On Wed, Sep 02, 2015 at 12:37:22AM +0200, Erik Bais wrote:
To clarify here ... although all types of number resources can be transferred.. ( AS, IPv4, IPv6 ) there are some specific resources ( like v4 for IXP usage ) are not allowed to be transferred and MUST be returned.. https://www.ripe.net/publications/docs/ripe-649#61
OK, didn't actually know this restriction existed.
We learn something new from each other every day :)
I also addressed this in the email of James. And it was also discussed during the AS transfer policy in the room at the AP-WG. The transfer policy time restriction is for scarce resources .. ( like IPv4 and 16-bits ASN's.) and not for IPv6 or 32-bit ASn's.
A holding period for ASN16 is a material change in assignment policy and should be in a separate proposal, not hidden in a (in itself valuable) transfer policy aggregation proposal.
Yes it is a change to the actual wording of the actual transfer policy for ASN's, it was stated in Amsterdam during the AP WG policy discussion that leaving out transfer restrictions in the policy for ASn's was a bit too far and it was suggested ( at the mic ) to look at almost depleted or scarce resources to have transfer restrictions as we currently have in policy for IPv4. By taking the wording as we have in front of us, it points out what it means, the intention is clear ... and it will leave the policy by itself accurate if 16 bit AS numbers have depleted .. without having to go over a re-writing of the policy here ... Both IPv6 and AS numbers have in the current policy no transfer restrictions ... I don't see a benefit to (have it) introduce for IPv6, but after the discussion in Amsterdam in the room, a restriction for 16-bit ASn's was desired. And that is also why it is currently here. This is not a 180 degree change of direction as it would make it more in line with other number resources .. 16-bit AS is in a similar state as IPv4.. it's gone.. get over it .. move on .. IPv6 is the new way, same as with 32-bit ASN's.. no restrictions..
Btw.. did you see that nr. 4.0 will also implement if a new field in the transfer statistics ...
- Whether it was a transfer or merger/acquisition
As it will also make a slight change in the transfer restrictions .. as it closes the 'loophole' to have transfers now also restricted after M&A's and not only after allocation by RIPE NCC or transfers.
What is this supposed to mean? The 24-month timer resets if a resource is acquired by M&A? Pretty substantial change IMO. Again, this should be subject to a separate proposal. And perhaps a membership vote as it materially affects the M&A procedure.
I don't think we have to re-hash all discussions as done in Elvis his proposal, which was viewed by the community as required and not strict enough as it didn't included M&A's.. Doing a membership vote would make it less open as it is just member that would vote on how to proceed here.. and it would only apply to PA space.. as member don't vote on PI resources ... So what would the impact be ... Is anything going to change based on the proposal in order to make do a M&A. - No. Will it give a more transparent view on resources changing holder ? Yes.. Will it remove the loophole of speculators, buying resources via M&A and transferring those directly ? Yes. ( This is currently possible and not in line with the original intent of the transfer policy restrictions of the initial IPv4 transfer policy AND the amendment to that by 2015-01.. ) Business that have a legitimate reason for performing a M&A, can still do so. The only restriction is that they can't re-transfer ( same as with new LIR now can't with the newly allocated /22's ... ) within 24 months.
People, the RIPE community should not make policy like the US House of Representatives - by this I mean hiding your wish list in marginally related legislation in the hope that it will go unnoticed. This proposal is a much needed aggregation of scattered policy items and a laudable effort by the author. It is ill served by trying to make changes to policy at the same time.
I think that by clearly pointing it out, during the discussion as it was not questioned during the initial reviews, it shows that it was not the intention of hiding anything ... The fact that people may not understand what they are reading because they don't have the complete overview of all policy implication changes is something that we can avoid ... It is not the intention of misleading people or trying to hide anything.. it is the other way around .. as I specifically pointed out to think about something that was missed. By clearly pointing out what certain text actually means and creating an 'Ahh ha' reflex ... 'Is that what the result is ... '. It means that people learned something they didn't knew before.. or just realized something that they missed.. Just like that you didn't knew that there are still specific usages for IPv4 for which IP space is specifically reserved (in the final /8) that are specifically excluded from the transfers .. as they MUST be returned..
As a result, I will oppose 2015-04 until I am satisfied that there is no material change in policy contained within, and am looking forward to discuss such changes on their own merits.
I hope I gave some additional insight in the actual changes and my reasoning behind it and as this is a policy that will create a general document across all resources ( hopefully for a long time to come..) it will have some changes and I hope that the document will reflect the intention of the community from all discussions that we already had in the past on the topics. Regards, Erik Bais
On Thu, Sep 03, 2015 at 02:36:12PM +0200, Erik Bais wrote:
A holding period for ASN16 is a material change in assignment policy and should be in a separate proposal, not hidden in a (in itself valuable) transfer policy aggregation proposal. ASN's, it was stated in Amsterdam during the AP WG policy discussion that leaving out transfer restrictions in the policy for ASn's was a bit too far and it was suggested ( at the mic ) to look at almost depleted or scarce resources to have transfer restrictions as we currently have in policy for IPv4. By taking the wording as we have in front of us, it points out what it means, the intention is clear ... and it will leave the policy by itself accurate if 16 bit AS numbers have depleted .. without having to go over a re-writing of the policy here ...
Just because it was stated at the meeting doesn't mean it shouldn't be discussed here. I can't be the only one who wasn't there and doesn't know what was said there.
Both IPv6 and AS numbers have in the current policy no transfer restrictions ... I don't see a benefit to (have it) introduce for IPv6, but after the discussion in Amsterdam in the room, a restriction for 16-bit ASn's was desired. And that is also why it is currently here. This is not a 180 degree change of direction as it would make it more in line with other number resources .. 16-bit AS is in a similar state as IPv4.. it's gone.. get over it .. move on .. IPv6 is the new way, same as with 32-bit ASN's.. no restrictions..
I've not even a problem with the change, in fact I didn't register that ASNs were even transferrable until I re-read -638 just now. As for that, I think ASN(16) *should* be transferred a) only together with IP resources b) if uninterrupted routeability is required. I'm not hung up on this though, it won't affect my non-/support either way.
I don't think we have to re-hash all discussions as done in Elvis his proposal, which was viewed by the community as required and not strict enough as it didn't included M&A's..
That's not what I remember. I remember a few people shouting very loudly and repeatedly and no discussion as it was off-topic for that proposal. And now we don't need an actually discussion? Mind, if yelling loudly is how you get policy made in the RIPE community, rest assured I can yell VERY loudly. I can, in fact, even automate the yelling if need be.
Is anything going to change based on the proposal in order to make do a M&A. - No.
I have to, reluctantly, agree with you here but it took me a while to find the relevant text in the NCC documentation. I would sleep easier though if it was clearly spelled out in this proposal that M&A are governed by ripe-648 and not by this transfer policy. ripe-648 doesn't say this clearly either but implies it in ss. 2.0 and 3.0
Will it remove the loophole of speculators, buying resources via M&A and transferring those directly ? Yes. ( This is currently possible and not in line with the original intent of the transfer policy restrictions of the initial IPv4 transfer policy AND the amendment to that by 2015-01.. )
It still allows someone to amass "more than their fair /22" by buying other businesses but this is something outside the purview of RIPE policy and should certainly remain so.
Business that have a legitimate reason for performing a M&A, can still do so. The only restriction is that they can't re-transfer ( same as with new LIR now can't with the newly allocated /22's ... ) within 24 months.
Just for the record, it is neither up to the NCC nor the RIPE community to decide whether a merger or an acquisition is "legitimate".
I think that by clearly pointing it out, during the discussion as it was not questioned during the initial reviews, it shows that it was not the intention of hiding anything ... The fact that people may not understand what they are reading because they don't have the complete overview of all policy implication changes is something that we can avoid ... It is not the intention of misleading people or trying to hide anything.. it is the other way around .. as I specifically pointed out to think about something that was missed.
IMO, it's too easy to just look at it as a much needed and necessary aggregation of transfer policy in one document (and I hope the whole community agrees that we owe you some beer for going through the effort) and ignore the actual *changes* to the policies...
By clearly pointing out what certain text actually means and creating an 'Ahh ha' reflex ... 'Is that what the result is ... '. It means that people learned something they didn't knew before.. or just realized something that they missed.. Just like that you didn't knew that there are still specific usages for IPv4 for which IP space is specifically reserved (in the final /8) that are specifically excluded from the transfers .. as they MUST be returned..
And, as it happens, the policy isn't actually very clear on this (except in the specific case of an IXP getting a larger assignment!) and may require more careful ring-fencing of the IXP pool.
I hope I gave some additional insight in the actual changes and my reasoning behind it and as this is a policy that will create a general document across all resources ( hopefully for a long time to come..) it will have some changes and I hope that the document will reflect the intention of the community from all discussions that we already had in the past on the topics.
Granted, but I'd prefer it in the future if such an aggregation would not incorporate any material changes to the policies involved (should then also pass quickly and without much debate) and any changes would then be processed in a separate proposal. I guess you realised this, as those changes are actually in the rationale *against* this proposal ;) That said, I now see no reason not to support the proposal with the addition of the statement that M&A procedure is not affected by this. rgds, Sascha Luck
On 03/09/2015 18:09, Sascha Luck [ml] wrote:
Mind, if yelling loudly is how you get policy made in the RIPE community, rest assured I can yell VERY loudly. I can, in fact, even automate the yelling if need be.
please don't: rfc7282 works much better. Nick
On Wed, Sep 02, 2015 at 12:37:22AM +0200, Erik Bais wrote:
To clarify here ... although all types of number resources can be transferred.. ( AS, IPv4, IPv6 ) there are some specific resources ( like v4 for IXP usage ) are not allowed to be transferred and MUST be returned.. https://www.ripe.net/publications/docs/ripe-649#61
Hmm. -649 s6.1 doesn't actually say that IXP PI must be returned and can't be transferred. At most it could be read as implied by "A /16 will be held in reserve for exclusive use by Internet Exchange Points" Even if interpreted restrictively, this would still allow transfers to other IXPs... May I suggest, though, that this statement: "Resources are excluded from transfers when RIPE Policies mandate their return to the RIPE NCC." be moved to s2.2 "Transfer Restrictions"? IMO it's a more logical place to find it if one were looking to find out whether a resource is eligible for transfer. rgds, Sascha Luck
On 02/09/2015 14:40, Sascha Luck [ml] wrote:
Hmm. -649 s6.1 doesn't actually say that IXP PI must be returned and can't be transferred.
649 section 6.1 says: -- This space will be used to run an IXP peering LAN; other uses are forbidden. -- i.e. if you're planning to transfer the address space to some other organisation, I'm reading this as meaning that it must either be another IXP as defined in "IPv6 Address Space for Internet Exchange Points", or else it will default back to the RIPE NCC. Nick
On Wed, Sep 02, 2015 at 02:48:07PM +0100, Nick Hilliard wrote:
649 section 6.1 says:
-- This space will be used to run an IXP peering LAN; other uses are forbidden. --
I actually read that as "This space *as assigned to this end-user*[...]" Does IXP space come out of a separate pool from any other ipv4? That section could maybe do with de-ambiguisation if only to protect the space for IXPs rgds, Sascha Luck
On 02/09/2015 14:55, Sascha Luck [ml] wrote:
Does IXP space come out of a separate pool from any other ipv4?
from what I understand, it comes out of a dedicated /16. RIPE NCC will be able to confirm whether this is a contiguous /16 or not. Nick
From what I see, it looks like it is in the following range ..
cat delegated-ripencc-extended-latest | grep '|185.1.' | grep '|256|' resulting in the following info : http://pastebin.com/3SHQsKxi Missing 'only' the following result : ripencc|PL|ipv4|185.1.10.0|512|20130403|assigned ripencc||ipv4|185.1.39.0|256||reserved It would be my wild guess that we are talking about the 185.1.x.y range :) Erik Bais -----Oorspronkelijk bericht----- Van: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] Namens Nick Hilliard Verzonden: woensdag 2 september 2015 16:27 Aan: Sascha Luck [ml] <apwg@c4inet.net> CC: address-policy-wg@ripe.net Onderwerp: Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) On 02/09/2015 14:55, Sascha Luck [ml] wrote:
Does IXP space come out of a separate pool from any other ipv4?
from what I understand, it comes out of a dedicated /16. RIPE NCC will be able to confirm whether this is a contiguous /16 or not. Nick
Hi Nick, On 02/09/2015 16:27, Nick Hilliard wrote:
On 02/09/2015 14:55, Sascha Luck [ml] wrote:
Does IXP space come out of a separate pool from any other ipv4? from what I understand, it comes out of a dedicated /16. RIPE NCC will be able to confirm whether this is a contiguous /16 or not.
185.1.0.0/16 is the /16 reserved for IXP assignments. However, according to the RIPE-649: "/IP space returned by IXPs will be added to the reserved pool maintained for IXP use/" [1]. This means that we will also make new IXP assignments from an IP block different than 185.1.0.0/16, when re-using the "IP space returned by IXPs". [1] https://www.ripe.net/publications/docs/ripe-649#61 I hope this clarifies Andrea Cima RIPE NCC
On Thu, Sep 03, 2015 at 03:17:47PM +0200, Andrea Cima wrote:
185.1.0.0/16 is the /16 reserved for IXP assignments.
However, according to the RIPE-649: "/IP space returned by IXPs will be added to the reserved pool maintained for IXP use/" [1]. This means that we will also make new IXP assignments from an IP block different than 185.1.0.0/16, when re-using the "IP space returned by IXPs".
[1] https://www.ripe.net/publications/docs/ripe-649#61
I hope this clarifies
Thanks for the clarification, Andrea. This would support the interpretation that any assignment out of this pool is for IXP use only. -649 doesn't, though, explicitly require an IXP to return that space except in the specific case of getting a larger assignment. With all the horses biting each other over the empty cribbage like we've seen recently, it may be a good idea to state this requirement more explicitly in order to ring-fence the pool. Full disclosure: I was tangentially involved in winding up an IXP not long ago, and it was not clear to me until now that the assignment could not be transferred (even to another IXP). rgds, Sascha Luck
Hi Sascha,
May I suggest, though, that this statement: "Resources are excluded from transfers when RIPE Policies mandate their return to the RIPE NCC." be moved to s2.2 "Transfer Restrictions"? IMO it's a more logical place to find it if one were looking to find out whether a resource is eligible for transfer.
I see your point and I think that we need to have a look if that wouldn't just be re-stating what is already in the policy earlier.. Erik Bais
You can find the full proposal at:
one more issue:
The rules for Internet number resource transfers (including legacy resources) to and from the RIPE NCC service region (often referred to as inter-RIR transfers)
It's good that this policy specifically includes legacy resources. It would be useful to clarify in the policy whether inbound transfers of legacy resources are subject to regular RIPE community number resource policies or the "RIPE NCC Services to Legacy Internet Resource Holders" policy. My reading would be the latter, but as it's unstated, there is a potential ambiguity here which has the potential of causing future problems. Nick
Hi, I'd like to put another idea into this policy, as I just ran into this issue. But before proposing it, I want to point out that I really like the 24 month hold-period before transfer in general to reduce the effect of "Create LIR - get /22 - sell /22 - close LIR". Still I would like to propose an exception to this 24month hold period for the case of "swapping" IP-Space: Here the issue I have. My LIR leased our last /22 to a transit customer. This transit customer is now being taken over by another LIR. This LIR does not want to renumber the end-users, but also does not want to lease the IPs anymore. Therefore this LIR proposed to request his last /22 and transfer it to us and at the same time we transfer our /22 to his LIR. So far - so good, but this is not working with current policy-text for the next 24 month, as the current policy forces us to wait 24 months before we can do that. In practice this does not make real difference, as we could simply make a contract that I lease his /22 and he leases mine for the next 24 months, but I think this actually doesn't make sense and also has never been the intention of the policy. For this reason I'd like to propose an exception on this 24month period in section 2.2 of the current proposal 2015-04 as follows: "This 24 months period is not needed, if two LIR swap allocations of identical size." What do you think about that? Thanks and best regards Jens Ott PS: @Gert: Did you realize that I signed with full name and also changed the sender's name for writing to the list ... so now there's no more reason to call me Jens 'Opteamax' :D On 14.08.2015 11:54, Marco Schmidt wrote:
Dear colleagues,
A new RIPE Policy Proposal, "RIPE Resource Transfer Policies" has been made and is now available for discussion.
The goal of this proposal is to create a single document with all relevant information regarding the transfer of Internet number resources.
You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2015-04
We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 14 September.
Regards
Marco Schmidt Policy Development Officer RIPE NCC
!DSPAM:637,55cdbc45319867115668180!
-- Jens Ott Geschäftsführer Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo@opteamax.de HRB: 23144, Amtsgericht Montabaur Geschäftsführer: Jens Ott Umsatzsteuer-ID.: DE264133989
participants (12)
-
Andrea Cima -
Elvis Daniel Velea -
Erik Bais -
Erik Bais -
Gert Doering -
James Blessing -
Jan Ingvoldstad -
Jens Ott - Opteamax GmbH -
Marco Schmidt -
Nick Hilliard -
Sascha Luck [ml] -
Tore Anderson