[address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)

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