[rpd] new version of policy proposal AFPUB-2019-IPv4-002-DRAFT02

[Owen DeLong]

> On Nov 7, 2019, at 11:41 , JORDI PALET MARTINEZ <jordi.palet at consulintel.es> wrote:

> 

> Hi Owen,

> 

> Thanks for the inputs, below in-line with ->.

> 

> 

> El 7/11/19 18:53, "Owen DeLong" <owen at delong.com <mailto:owen at delong.com>> escribió:

> 

>    Jordi,

> 

>    Comments on specific sections:

> 

>    5.7

>    	First, this policy should apply to all organizations with justified needs. There’s no reason

>    	to exclude organizations who could get resources from AfriNIC from using the transfer

>    	policy if they so choose. Further, the application should be to both recipient organizations

>    	(as stated) and source organizations (excluded by present language).

> 

>    	Recommended alternate language:

> 

>    		This policy applies to organizations with a justified need for IPv4 resources

>    		(recipients) and organizations with IPv4 resources that are no longer needed by

>    		the organization (sources).

> 

> -> Good point, you're right on that, because it is clear that we are talking about AFRINIC, when enters in phase 2.

> 

>    5.7.2

> 

>    	Policy should set source criteria only if the source is within the AfriNIC region. Source

>    	criteria for sources outside of AfriNIC should be set by the source RIR. Further, a

>    	source organization should not be permanently barred from acquiring additional

>    	resources, so I have added a suggestion to allow them to acquire resources via

>    	transfer 24 months after acting as a source.

> 

>    	Recommended alternate language:

> 

>    	5.7.2 — as is

> 

>    	5.7.2.1 A source must be validated by the applicable source RIR according to their

>    		policies and procedures. A source within the AfriNIC region must be in good

>    		standing (all invoices paid) and must be the rightful registrant of the resources

>    		to be transferred and there must be no dispute as to the status of said resources.

> 

> -> I'm fine with this

> 

>    	5.7.2.2 Source entities will not be eligible to receive any further IPv4 address allocations

>    		or assignments from AfriNIC. Source entities may, if they can show justified

>    		need receive resources via transfer after a period of not less than 24 months

>    		has elapsed from their last outbound transfer.

> 

> 

> -> We have a long discussion about this a about 3 months ago. I'm happy with your proposed text (previously we had 12 months) but I think it was clear that "if you have transferred resources, and need more, use the profit from that transfer to buy more", otherwise, even if 24 months is a long period, is prone to speculation, or even more ... you are using reserves that are better serving people that never transferred resources. Anyway, I will love to hear other voices on this before doing any change here.


Note that my wording does not allow them to receive resources by any mechanism other than transfer
once they have made an outbound transfer.

But it doesn’t allow speculation by repeated transfers because it introduces a 24 month lag sale and
future acquisition by transfer.

As such, I think this achieves your intended result.

While that’s also true of the language in the PDF, I think the intent is not as clear since no mention of
permission of inbound transfers is made, only the prohibition of Allocation or Assignment.
I believe my proposed language has the advantage of both preventing flipping transfers and also
making it clear that inbound future transfers can be achieved if needed.


>    	5.7.2.3 An organization which has received resources in the AfriNIC registry within the

>    		preceding twelve months will not be approved as a transfer source.

> 

> -> Same meaning, shorter and more clarity. I like it. Small modification:

> 

> 5.7.2.3 An organization which has received IPv4 resources from AFRINIC within preceding 12 months will not be approved as a transfer source.


Agreed… An unfortunate omission on my part.


>    5.7.3.1 is a bit vaguely worded. Suggest:

> 

>    	5.7.3.1 Recipient organizations within the AfriNIC service region must be approved

>    		by AfriNIC staff using the same policies and procedures as if the request

>    		were being satisfied from the AfriNIC free pool.

> 

> 

> -> fine for me as well, a bit shorter:

> 

> Recipient organizations within the AFRINIC service region must be approved with the same policies and procedures as if the request were being satisfied from the AFRINIC pool.


This is also workable.


>    5.7.3.2 is also a bit convoluted. Suggest:

> 

>    	5.7.3.2 Recipients in other RIRs must be approved by the staff in that RIR according

>    		to that RIR’s policies and procedures.

> 

> -> again agree and shorter:

> Recipients in other RIRs must be approved according to that RIR policies and procedures.


Almost…

Recipients in other RIRs must be approved according to that RIR’s policies and procedures.

(The ’s to make a possessive relationship to the policies and procedures is needed in English syntax).


>    5.7.3.3 is unnecessary and incorrect in some cases. Many organizations that receive

>    resources in the ARIN region are not members, for example. Any intended effect

>    in 5.7.3.3 is a subset of the requirements already expressed in 5.7.3.2 and I presume

>    that the unintended effects do not need to be preserved. Suggest striking 5.7.3.3

>    completely.

> 

> -> You're right with the new wording we don't need to say what to do if in AFRINIC or other regions, is already implicit now.

> 

> 

>    5.7.4 — I think there is a better way to express the actual intent here… Suggest:

> 

>    	5.7.4 Transfer of ASN with resources

> 

>    		In the case where the majority of an operating network, including the

>    		addresses and the physical infrastructure are being transferred, any

>    		applicable ASN(s) may also be transferred at the same time in order

>    		to preserve operational integrity and expedience.

> 

> -> I don't think we should mention "and the physical infrastructure" as it may not be the case. I suggest a this:

> 

> 5.7.4 Transfer or ASN with IPv4 Resources

> 

> In the case where the majority of the IPv4 resources are being transferred, any relevant ASN(s) may also be transferred at the same time, if the relevant policies are fulfilled.


I don’t think that the ASN transfer should be allowed if the physical infrastructure isn’t moving. In such a case, renumbering the peering sessions is trivial compared to migrating the functionality.

The migration of an ASN is only useful/necessary in a case where the ownership of the “service” for lack of a better term is being transferred in place and there is a desire for continuity of operations without disruption.

If moving to new hardware, then the disruption of new peering sessions with a different ASN is the least of the difficulties and there is no need to transfer the ASN.


>    5.7.5 — This doesn’t belong in the policy text and should be provided instead as

>    	guidance to the board and staff for scheduled implementation of the policy.

> 

>    	Leaving this in the policy text results in a policy manual which contains an

>    	ever growing set of anachronisms.

> 

> -> The community asked for something explicit in the policy text. If the staff can confirm that we don't need that as part of the policy text and the community accepts that, I'm fine as well. However, if you look at the exhaustion phase, etc., there is timing there. Note that I'm also convinced that it is very difficult to get this proposal, if it reach consensus in December, to be implemented before moving to phase 2, but the staff don't think so (they said it can be implemented in 6 months), and expressed it in the analysis impact (requesting timing as part of the policy, if I got it correctly).


Policies which define when we enter certain phases of exhaustion cannot be avoided. Naturally, they will need to be cleaned up later as they become anachronistic as well.

However, I see no reason to increase that need unnecessarily. The community can include instructions to board and staff about implementation in the problem statement, or
summary sections of the proposal without needing them enshrined in the policy text, IMHO.
 

>    5.7.6	Who determines what information is or is not confidential? Policy should

>    		specify exactly what is required to be disclosed and if it wishes to make

>    		additional disclosures optional, it should state what those are and that

>    		they should be published if disclosed. The list in the existing proposal

>    		is a good start on the minimum mandatory information. If we want that

>    		as the extent of the policy, suggested rewording:

> 

>    		5.7.6 Required Disclosures for Transfers

>    			Parties shall be required to disclose and AfriNIC shall publish

>    			in a specific location, a history of all completed transfers including

>    			at least the following information about each transfer:

> 

>    			+	Date of the Transfer

>    			+	Identification/description of the Resources Transferred (e.g. 192.168.48.0/20, AS3223959)

>    			+	Source RIR

>    			+	Source ORG-ID

>    			+	Recipient RIR

>    			+	Recipient ORG-ID

> 

> -> Agree with your confidentiality point. I think a shorter version may be:

> 

> 5.7.6 Required Disclosure for Transfers

> 

> AFRINIC shall publish in a specific location, a history of all completed transfers, including at least: Date of each transfer, identification/description of resources transferred, source RIR and organization, recipient RIR and organization.


Also workable. My intent in making it a bit more explicit and using bullet points was to make future revision to the requirements a simpler matter should the community desire to add or remove required information.

Owen


> 

>    Owen

> 

>> On Nov 7, 2019, at 07:50 , JORDI PALET MARTINEZ via RPD <rpd at afrinic.net> wrote:

>> 

>> Hi all,

>> 

>> As I've indicated last Monday, during the weekend I've updated the policy proposal AFPUB-2019-IPv4-002-DRAFT02 "IPv4 Inter-RIR Resource Transfers (Comprehensive Scope)" and I'm attaching it here in PDF, so all can read even if not yet published in the website.

>> 

>> This update tries to address:

>> 1) All the issues and inputs from the RPD List and the previous meeting.

>> 2) The staff impact analysis.

>> 

>> At the same time, as it was clear that the community is not interested in a "legacy" only policy proposal (I also expressed myself my concern about that during the meeting, but I wanted to offer "both" choices, just in case), I'm formally withdrawing the proposal AFPUB-2019-IPv4-001-DRAFT01 "IPv4 Inter-RIR Legacy Resource Transfers".

>> 

>> Thanks in advance for reading and contributing!

>> 

>> Regards,

>> Jordi

>> @jordipalet

>> 

>> 

>> 

>> 

>> 

>> **********************************************

>> IPv4 is over

>> Are you ready for the new Internet ?

>> http://www.theipv6company.com

>> The IPv6 Company

>> 

>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

>> 

>> <AFPUB-2019-IPv4-002-DRAFT02.pdf>_______________________________________________

>> RPD mailing list

>> RPD at afrinic.net

>> https://lists.afrinic.net/mailman/listinfo/rpd

> 

> 

> 

> 

> 

> **********************************************

> IPv4 is over

> Are you ready for the new Internet ?

> http://www.theipv6company.com <http://www.theipv6company.com/>

> The IPv6 Company

> 

> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20191107/09caa13d/attachment-0001.html>