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