[rpd] New version of policy Proposal - IPv4 Inter-RIR Resource Transfers.

Fri Oct 8 23:09:21 UTC 2021

Owen, I think you may be too poisoned about your view about staff and 
your exotic view on how the current policies should apply to this topic, 
so some of your points may be considered more a desire than what it 
really is.

I don't quiet agree that this type of thing should not go under a proper 
analysis of the staff and as you may guess we will not always have a 
binary scenario for them to analyze. So your desire to remove this from 
them cannot work properly. Good or bad there is always a certain amount 
of subjectivity and in theory that is to protect African resources from 
being send out of the region if there is something that should stop that 
from happening. The most important thing in my view is that resources as 
protected from mismanagement and be allowed to be transferred when it 
should not.
I would love to have binary, exact and mathematical thing for most 
things on life, but that reality is not like that.

I am not sure as well the policy should include non RIR members that may 
only exist in ARIN due this weird different things work out there.

With that said I am not saying I agree with this proposal as written at 
this point.

Regards
Fernando

On 08/10/2021 17:50, Owen DeLong via RPD wrote:
>
>
>> On Oct 8, 2021, at 1:07 PM, JORDI PALET MARTINEZ via RPD 
>> <rpd at afrinic.net> wrote:
>>
>> Hi Owen,
>> The modification of 5.7 was done to add clarity to the text. I don’t 
>> understand where you see the problem, if there was no problem about 
>> reciprocity in the previous versions.
>> This is the new text:
>> The resources to be transferred must be from an existing RIR member’s 
>> account or from a Legacy Resource Holder in the AFRINIC service 
>> region/other RIRs.
>
> There are lots of resource holders in other RIRs (at least in ARIN) 
> who are not RIR members.
>
> The current wording precludes those resource holders from 
> participating in said transfers.
>
>> It clearly says AFRINIC/other RIRs, so what I’m missing?
>
> That not all RIRs require membership to have resources. IIRC, this is 
> the case with sponsored PI in RIPE as well.
>> Regarding 5.7.1, the M&A today is not a policy, but an internal 
>> procedure (as it happens in RIPE, for example). I don’t agree this 
>> should be an internal procedure, but that’s what we have today. My 
>> plan is to, once we have fixed this, make a proposal for that, but I 
>> think it is better to go step by step, so adding a reference will be 
>> breaking it in the future (or requiring one more change in this part 
>> of the text). It is not needed. If you look at the existing text for 
>> intra-RIR that it is in the policy manual today, there is no such 
>> reference.
>
> OK… Ugly, but ok.
>
>> 5.7.5 is to make explicit something that was already there. When you 
>> attempt an intra-RIR transfer, **all** the parties are verified. This 
>> is the same in other RIRs. However, I’m also adding a “protection” to 
>> the failed transfers, because today, if AFRINIC strictly follows the 
>> intra-RIR transfer and it fails because, for example, the destination 
>> doesn’t meet the policies, then the source will lose the resources, 
>> as he clearly demonstrated that doesn't need them and that’s the 
>> reason, he is willing to transfer.
>> What your text for 5.7.5 is proposing seems to be a restriction of 
>> some of the RSA and CPM text. I don’t think that’s right, otherwise, 
>> each proposal or part of the CPM can actually “change” what is 
>> already written in the RSA and/or CPM and create a mess.
>
> I am proposing not allowing staff to block a transfer because they 
> decide they don’t like a registrant.
>
> I am not proposing limitations on other sections of the CPM, but 
> limitations on the excuses staff can use to block a transfer to the 
> criteria that can be measured objectively and without subjecting 
> transfer participants (receive or supply) to arbitrary and capricious 
> misinterpretations of the CPM by a staff which has shown a clear 
> propensity to engage in same.
>
>> I’m happy to accept suggestions from anyone, as usual, but they 
>> should be reasonable and consistent.
>
> I believe that my suggestions were both reasonable and consistent, 
> with the exception of the 5.7.1 as noted.
>
>> If we want to change the CPM in other sections, let’s do it, but not 
>> make each part of the CPM modifying others or modifying the RSA.
>
> I am not attempting to change the other CPM sections. I am attempting 
> to limit staff authority to block transfers.
>
>> If we want to change the RSA, I guess this can be done, but probably 
>> via membership. The RPD is fine to suggest that, but not by means of 
>> a policy proposal, right?
>
> I am not attempting to change the RSA. I am attempting to limit the 
> staff authority to block transfers. My intent is for these
> limits to apply strictly to transactions occurring under this proposed 
> section.
>
> Owen
>
>> Regards,
>>
>> Jordi
>>
>> @jordipalet
>>
>> El 8/10/21 21:44, "Owen DeLong via RPD" <rpd at afrinic.net> escribió:
>> I oppose this version of the policy proposal.
>> Section 5.7 needs to be amended to allow the source of the 
>> transferred resources
>> to be a resource holder from any RIR, not just AFRINIC.
>> This may seem like a minor NIT, but as written, the policy would be 
>> outbound only
>> and not symmetrical (thus not reciprocal), so fixing this is 
>> important. Admittedly,
>> the text in 5.7 is inconsistent with the subsequent text in this 
>> regard, but
>> it is possible to interpret the limitations expressed in the proposed 
>> 5.7 as
>> overriding the expressed possibilities in the subsequent proposed 
>> sections.
>> I suspect that the 5.7 text is an accident on the part of the author 
>> and that
>> this limitation was not intended.
>> 5.7.1 should point to the policy that does cover M&A transfers rather 
>> than simply
>> state that this policy does not apply to them.
>> I oppose section 5.7.5 because AFRINIC has already demonstrated a 
>> propensity
>> to make arbitrary and capricious decisions about compliance based not 
>> on the
>> actual text of the contracts, bylaws, or CPM, but on their own creative
>> interpretations thereof.
>> The pre-check authorized by section 5.7.5 should be limited to 
>> deterministic
>> factors which can achieve a binary outcome strictly on provable facts 
>> and not
>> be subject to staff interpretation and judgment, as staff has already
>> proven on numerous occasions that it cannot be trusted to exercise 
>> good judgment
>> or achieve prudent or accurate determinations in such matters.
>> Proposed modified text:
>> 5.7 IPv4 Transfers
>> This policy applies to organizations with a justified need for IPv4 
>> resources (recipients) and organizations with IPv4 resources which no 
>> longer need (sources).
>>
>> The resources to be transferred must be from an existing resource 
>> holder of a direct allocation or assignment from an IANA[1] 
>> accredited RIR or a legacy resource holder registered and recognized 
>> as the current registrant of the addresses to be transferred by the 
>> applicable IANA[1] accredited RIR.
>> 5.7.1 — Mostly fine, just add the needed cross-reference to the M&A 
>> policy section.
>> 5.7.5 Transfer pre-check
>> Where the source of a transfer is a resource member of AFRINIC, 
>> AFRINIC will perform a pre-check prior to authorizing the transfer 
>> which shall include validation of the following items:
>> +Resource member is a member in good standing
>> +Resource member is the current registrant of record for the 
>> resources being transferred
>> +Resource member’s registration of the resources is not credibly 
>> disputed by any third party
>> +Resource member’s fees are current with AFRINIC
>> [1] At the time of writing, this IANA function is performed by ICANN 
>> in accordance with ICP-2.
>> Author is, of course welcome to accept, decline, or modify these 
>> proposed edits as they see fit, but these edits, as
>> written, would allow me to support the proposal as written.
>> Owen
>>
>>
>>> On Oct 4, 2021, at 10:33 AM, PDWG Chair <dacostadarwin at gmail.com> wrote:
>>> Hello PDWG Members,
>>> We have received a new version of policy Proposal - IPv4 Inter-RIR 
>>> Resource Transfers (Comprehensive Scope) - 
>>> AFPUB-2019-IPv4-002-DRAFT06 from author Jordi Palet Martinez.
>>>
>>>
>>> The proposal contents are published at:
>>> https://afrinic.net/policy/proposals/2019-ipv4-002-d6
>>> Please take some time to go through the proposal contents and 
>>> provide your
>>> feedback.
>>> Regards,
>>> PDWG Co-Chair.
>>> _______________________________________________
>>> RPD mailing list
>>> RPD at afrinic.net
>>> https://lists.afrinic.net/mailman/listinfo/rpd
>> _______________________________________________ RPD mailing 
>> listRPD at afrinic.nethttps://lists.afrinic.net/mailman/listinfo/rpd
>>
>> **********************************************
>> 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.
>>
>> _______________________________________________
>> RPD mailing list
>> RPD at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20211008/7efe02f0/attachment-0001.html>