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