Re: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer)
* Marco Schmidt
I think it makes sense to allow PI transfers, at least when taking into account that we already do so for PA. So I'm generally supportive of this proposal 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. 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? 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? 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...) Tore
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
* Erik Bais
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.
Yeah, I fully understand why you want to remove the requirement that the original criteria must be unchanged for the assignment to remain valid. This requirement was always completely out of touch with operational realities anyway. Good riddance! However, considering that the NCC no longer has any mandate to evaluate the validity of the given criteria, asking assignees to send updates to the NCC whenever they want to change the way the assignment is being used seems rather pointless to me. After all there's not much the NCC would do with that information except to archive it somewhere. If you want to allow people to change how they're using their assignments, then I'd prefer that you let them do so freely, without introducing any new bureaucracy and forms. If I may, here's my suggested version of a new 6.3: «All assignments are valid as long they are properly registered in the RIPE Database. If an assignment is based on information that turns out to be invalid, the assignment is no longer valid.»
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.
Understood, thanks for elaborating. Tore
participants (2)
-
Erik Bais -
Tore Anderson