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

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