[address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer)

Hi Tore, 

> A few comments though:

> 1) The new policy says: «Changes to the original criteria must be
> documented in the RIPE Registry, or the assignment will no longer be
> considered valid». What exactly are the implications of this
> requirement? I am assuming that the «RIPE Registry» is not the RIPE DB;
> as the original criteria isn't documented in the RIPE DB to begin with.

The new phrase as it states in the policy proposal is:  
- 6.3 Validity of an Assignment

- An assignment is valid as long as the original criteria on which it was
based remain valid and it is properly registered in the RIPE Database.
Changes to the original criteria must be documented in the RIPE Registry, or
the assignment will no longer be 
- considered valid. An assignment that was based on information that turns
out to be incorrect is no longer valid.

There is indeed a difference with what we see in the RIPE DB and the actual
RIPE Registry. (The RIPE back-end) 
The reason of why I kept it in the policy is, is to keep the original policy
text as much as possible and not change entire PI criteria. 

The change to the original part is the deletion of:  
- If an assignment is made for a specific purpose and that purpose no longer
exists, the assignment is no longer valid.

And also we kept the sentence that if PI assignments were requested in the
past under false / falsified information and that those assignments can't be
changed into a valid assignment via a transfer. 
Think in that respect about incorrect company information or false ID's etc.


> As I understand it, any criteria that somehow involves «operating a
> network» is a valid assignment criteria (cf. section 3.0.3), with no
> requirement for specifics. I'm thinking that it might be better to
> simply say something along the lines of an assignment being valid for as
> long as it is being used according to the policy, rather than worrying
> about the «original criteria» and how it possibly have changed. Most
> networks evolve and change over time; it wouldn't surprise me if a
> majority of assignments are now being used differently than originally
> documented in their associated assignment request form. That's not a bad
> thing though, is it?

That is also why we removed the part in 6.4 that if an assignment is made
for a specific purpose and that purpose no longer exist, the assignment is
no longer valid. (in the policy proposal) 

> 2) Editorial: The new section 6.4 «Transfers of PI space» appears to me
> to be pretty much a carbon copy of section 5.5 «Transfers of
> Allocations» with a tiny bit changed here and there. Rather than
> duplicating all that text, would it not be better to move 5.5 out of
> section 5, and re-title and generalise it so that it applies equally to
> PI and PA? 

Good point .. we spoke about this and decided to get this through and then
(via a 2 phased approach) take the transfer parts away in a new proposal to
get them changed into a new RIPE document (away from RIPE 606)
During the Athens meeting it was agreed that I would propose a Transfer
policy for PI. (that is what I've done) 
There are some other tasks that we came across during the prep for this
proposal that I would like to fix (like the ability to transfer IPv6 and AS
number resources), which would be able to in the above mentioned phase 2. 

> 3) The new section 6.4 speaks of «Non-approved transfers». Under which
> circumstances would a transfer not be approved, exactly? Do we really
> need this language anymore? (I'm regretting that 2013-03 didn't do away
> with it already. Oh well...)

Good point.. especially since the only non-approved PA transfer in the past,
would under the current operations, be approved from what I've heard..
however the goal of this proposal is to get the same result for both IPv4 PA
and PI space.
That is also for instance why I kept the same restrictions as with PA and
also the same reporting structure.  

It would make it a lot easier later to merge them together and get this in a
separate Transfer document for all kinds of resources.. regardless of color
of origin.  

Thanks for the feedback,
Erik Bais