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

Hi Nick, 

>> 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. 
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