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