Search RPD Archives
[rpd] IPv4 Inter-RIR Resource Transfers (Comprehensive Scope) - AFPUB-2019-IPv4-002-DRAFT07
Owen DeLong
owen at delong.com
Tue Nov 16 15:11:29 UTC 2021
Then include that link in the statement in the proposed policy that says it doesn’t apply to M&A as in:
…this policy does not apply to M&A, (instead, see https://afrinic.net/resources/transfers#mergers)…
And you will have resolved this particular objection to my satisfaction.
Owen
> On Nov 16, 2021, at 00:58 , JORDI PALET MARTINEZ via RPD <rpd at afrinic.net> wrote:
>
> Hi Owen,
>
> Regarding M&A, the internal procedure has been published for many years at:
> https://afrinic.net/resources/transfers#mergers <https://afrinic.net/resources/transfers#mergers>
>
> You can see that I already tried to approach this in a policy proposal:
>
> https://www.afrinic.net/policy/proposals/2019-gen-004-d1#proposal <https://www.afrinic.net/policy/proposals/2019-gen-004-d1#proposal>
>
> However, didn’t got traction and I thought it may be better to take on this again once we have resolved the transfer problem.
>
>
> Regards,
> Jordi
>
> @jordipalet
>
>
>
>
>
> El 14/11/21 10:24, "Owen DeLong" <owen at delong.com <mailto:owen at delong.com>> escribió:
>
>
>
>
>> On Nov 14, 2021, at 00:46 , JORDI PALET MARTINEZ via RPD <rpd at afrinic.net <mailto:rpd at afrinic.net>> wrote:
>>
>> Responses below, in-line.
>>
>> Saludos,
>> Jordi
>>
>> @jordipalet
>>
>>
>>
>>
>>
>> El 12/11/21 19:48, "Owen DeLong" <owen at delong.com <mailto:owen at delong.com>> escribió:
>>
>>
>>
>>
>>
>>> On Nov 12, 2021, at 00:42 , JORDI PALET MARTINEZ via RPD <rpd at afrinic.net <mailto:rpd at afrinic.net>> wrote:
>>>
>>> Hi Owen, all,
>>>
>>> As you know, most of us aren’t native English speakers, so it is easy that we can make mistakes. However, those mistakes can be corrected, as we did in previous proposals, at the PPM, or even during the last-call if they reach consensus. So, if we all agree on your suggestions regarding 5.7, I will’ve no problem on that. Could the staff, before the PPM, tell us if this alternative wording still has for them the same interpretation, and consequently it is a clear editorial change?
>>>
>>> Regarding 5.7.1, in our previous discussion (https://lists.afrinic.net/pipermail/rpd/2021/013837.html <https://lists.afrinic.net/pipermail/rpd/2021/013837.html>), we already agreed that this paragraph is not needed, but it was requested by the staff to make it clearer. In other RIRs there is nothing like that text. It doesn’t harm to have it. Today, M&A is an internal procedure. If tomorrow the community decides that it must be a policy, then we just need to include in that policy proposal the removal of that text. In fact, once we resolve the transfers, I plan to resubmit my proposal for M&A.
>>
>> I am not saying it is not needed. I am saying that it either needs to reference an existing M&A policy or we need to cover M&A here. If there is no existing M&A policy than excluding M&A here is ridiculous. If there is an existing M&A policy, include its section number here as a reference and be done.
>>
>> One of those two things should happen.
>>
>> Otherwise, we’ve literally got no policy to cover the most common form of resource transfer, while specifically excluding it from the one transfer policy we will have. Currently it is not excluded from the existing transfer policy, so this is a serious and dangerous change if we don’t address it.
>>
>> [Jordi] There is an internal procedure published for M&A. I don’t agree it must be a procedure, but a policy, however, trying to fix it at the same time as the transfers proved (because a previous proposal that I submitted for that) that will make more difficult any chance for consensus. So, we shall be coherent and split both problems. In fact, in other RIRs is also different policies and if I recall correctly only in RIPE it is an internal procedure not a policy.
>
> Then there should be some public place that the procedure is documented and we should at the very least point to that.
>
>
>
>>
>>> Regarding 5.7.2.2/3, the 16 months are considered using an existing timing in the CPM section 5.4.5, times 2. I think it is a very simple way to agree on that, otherwise, each community member will have a different view and we will not be able to reach consensus. I don’t think it is so important and if the community believes that it need to be amended, we could make it after the proposal reach consensus, considering that the implementation of such policy will typically take 1 year and the timing is not critical for the implementation time (is just a parameter in the scripts).
>>
>> I do not favor coming to consensus on a policy with a silly clock with a plan to amend the clock later. I think we should come to consensus on a complete policy including timing. I propose 24 months, but I would find 12 or 18 months acceptable.
>>
>> I think 8 months is a rather silly timeline as well.
>>
>> [Jordi] Well, I’m not sure if it is right calling “silly” a timing in a policy that has been adopted by the community. And then it makes sense to use that timing for other timers that are related. At the end I think this is a matter of personal preference, not a subject for objecting a policy, because then, every community member can decide that for them 7 weeks or 7 months, instead of 8 weeks/months, makes more sense. This is a totally subjective discussion and we should try to keep them outside of policy discussion if we want to move on.
>
> I call it as I see it. It’s a very arbitrary number with no rationale. That’s pretty much the definition of “silly”.
>
> I disagree that the lockout/hold-down times are not a matter for objecting to the policy. If the community can’t come to consensus on the timing, then you don’t have consensus on the policy since the timing is part of the policy proposal.
>
>
>>> Regarding 5.7.4, most of the text on this section is more an example that anything else, because the other 4 RIRs already have a cooperation system to exchange this information and make it public, so as said in the policy text “This doesn’t exclude the publication of the same or other information as a result of the operating agreement among the RIRs.”.
>>
>> I understand, but I believe the data I proposed SHOULD become part of the mandatory minimum information. Is there some objection to adding the data I requested specifically?
>> If not, we should simply add those items to the list and move on. If so, what is the rationale for excluding it from the list?
>>
>> [Jordi] I’m fine with that, I believe that as they don’t change the intent, they could also be considered editorial changes.
>
> Agreed, but I object to the policy without those “editorial” changes.
>
>
>>> Regarding 5.7.5, the text has been amended as we discussed in the previous round and with the inputs from the staff. I’m not going to discuss with you “personal views” (which I also have my owns and not necessarily in favor of recent Board actions) vs this proposal text. If we believe that things are broken, we shall address that in other places, not in every single proposal, because *anything* in the PCM can be used as weapon against the members and community, if the staff/board decides so, and this is consequently not a problem for any specific policy text, it is a wider organization issue. If you remove 5.7.5, following the RSA, the staff still can do *exactly the same* and even more, and can *deny* the transfers and reclaim the resources because the justification of the need is no longer there. As such, this will be even more against the members and the community than keeping 5.7.5.
>>
>> This text provides broad discretion to personnel who have indicated a tendency to abuse that discretion and act in a manner which is not equitable across the entire membership.
>> That’s provable fact, not personal view.
>>
>> Given that, I strongly object to the inclusion of this provision. Of course staff wants it. It gives them broad power to weaponize AFRINIC and hold hostage transfers that they don’t want to approve. It creates a perfect opportunity for them to engage in shakedowns or solicit bribes to approve transfers. This provision is a recipe for enhanced corruption and therefore I strongly object to its inclusion as written or in any form which continues to include any such discretion.
>>
>> [Jordi] See my previous email on this, so we avoid repeating ourselves …
>
> Noted and replied. This time, since you expressed an intent to protect transfer sources, I included proposed protective language as an alternative to the current 5.7.5.
>
>>> Regarding 5.7.6, I agree with you, but the staff is suggesting that it adds clarity as I just explained in my previous email. I don’t think it harms so I will say let’s keep it.
>>
>> I will reiterate… Staff here is paid by the membership to serve the membership and the community, not the other way around. We should not be contorting policy in an effort to appease staff. It does not add clarity, it adds FUD. It is harmful and should be stricken.
>>
>> I object to the policy so long as it contains this provision.
>>
>> [Jordi] Same, see previous email.
>
> I saw your previous email. It seemed to suggest that you wanted to keep 5.7.6.
>
> Owen
>
>
>>
>> Owen
>>
>>
>>
>>>
>>>
>>> Regards,
>>> Jordi
>>>
>>> @jordipalet
>>>
>>>
>>>
>>>
>>>
>>> El 10/11/21 18:51, "Owen DeLong via RPD" <rpd at afrinic.net <mailto:rpd at afrinic.net>> escribió:
>>>
>>> This version has the following problems;
>>>
>>> Proposal:
>>> 5.7 This policy applies to any entity with a justified need for IPv4 resources (recipients) and entities with IPv4 resources which no longer need (sources).
>>> The resources to be transferred must be from an existing Resource Holder (including Legacy Resource Holders) in the AFRINIC service region/other RIRs.
>>>
>>> Correction:
>>> 5.7 This policy applies to any entity with a justified need for IPv4 resources (recipient) and any entity with IPv4 resources which are no longer needed (source).
>>>
>>> The resources to be transferred must be from an existing Resource Holder (including Legacy Resource Holders). At least one of the parties (source or recipient) must be an AFRINIC resource holder or be eligible to become an AFRINIC resource holder as a result of the transfer (per 5.7.3.1, et. al.).
>>>
>>> Reasoning:
>>> First, the syntax of the first sentence was awkward and had an invalid mix of singular and plural. Grammatical and syntax correction, but original meaning preserved.
>>>
>>> Second, the sentence was awkwardly worded and did not achieve what I believe to be the author’s true intent.
>>>
>>> Proposal 5.7.1 …M&A not covered…
>>>
>>> Correction:
>>> instead of simply stating that M&A transactions are not covered by the policy, reference should be made to the policy under which they are covered. If there is no such policy, then the exception should be removed from this policy.
>>>
>>> Reasoning:
>>> M&A transactions occur, both inter and intra-RIR. That is simply the current reality. Prohibiting them from being recognized puts policy out of step with reality and guarantees inaccurate registration information.
>>>
>>> Proposal 5.7.2.2 …Not less than 16 months…
>>>
>>> 16 months seems a very arbitrary period of time (1 1/3 years). Suggest that this should be modified to 12, 18, or 24 months. Suggest a similar change to 5.7.2.3 as well.
>>> Personally, I would favor 24 months, with 18 as my second choice.
>>>
>>> Proposal 5.7.4: Suggest adding the following to the required information list:
>>> Source ORG-ID
>>> Recipient ORG-ID
>>>
>>> I continue to object to 5.7.5. In the situation with an ethical RIR, I agree this provision would not be a problem. However, with the current crew of shake down artists in control of the AFRINIC management and board where we have seen made up interpretations of the bylaws and the CPM used in an effort to extort money from members, this provision is perfectly positioned to be weaponized in order to deny legitimate resource holders the ability to protect their rights.
>>>
>>> Proposal Section 5.7.6 is non-operative and has no effect. Therefore, it should be stricken IMHO.
>>>
>>> Owen
>>>
>>> _______________________________________________ RPD mailing list RPD at afrinic.net <mailto:RPD at afrinic.net> https://lists.afrinic.net/mailman/listinfo/rpd <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.
>>>
>>> _______________________________________________
>>> RPD mailing list
>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
>>> https://lists.afrinic.net/mailman/listinfo/rpd <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.
>>
>> _______________________________________________
>> RPD mailing list
>> RPD at afrinic.net <mailto:RPD at afrinic.net>
>> https://lists.afrinic.net/mailman/listinfo/rpd <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.
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net <mailto:RPD at afrinic.net>
> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20211116/119d77ca/attachment-0001.html>
More information about the RPD
mailing list