Search RPD Archives
[rpd] Transfer Policy Proposal v.3.docx
Daniel Yakmut
yakmutd at googlemail.com
Tue Sep 29 10:22:46 UTC 2020
Dear All,
I wish to start my comments from Jordi's statements. I totally agree
that we should look at policy proposals from the perspective of whether
is it good for the community.
1. There is a silent conspiracy of competition where community members
are competing against each other to push personal agenda, rather than
proposing a policy that truly serves the interest of all.
2. I agree that the attempts made by Jordi in getting the other two
Inter-RIR proposals authors to come to an agreement to have a common
document is laudable. However, I am also aware that the authors (Taiwo
and Co.) agree to Jordi's suggestion and had a discussion. The outcome
of the meeting suggests that Jordi and Taiwo's group have an open mind
towards having an acceptable and possibly a working proposal.
3. To further show good faith Jordi opted to support Taiwo and Co's
proposal (if I am not mistaken). I believe Jordi is still committed to
that and will want to see that we all support this effort especially
with the call of the Co-Chairs.
4. I don't want to believe we at an "Ego" war, where some people will
feel defeated, because there was no competition in the first place.
5. I am sure the spirit behind the Co-chairs call is to see an end to
this perceive competition which is unhealthy and time consuming.
6. We all agreed that Inter-RIR policy is desirable, and we cannot have
one in isolation of the other RIRs. Therefore, openness on this is very
important, hence we should align with a policy that pushes that.
7. I see a significant attempt to strangulate the Co-chairs because
their call did not go the way of some members of the community. I will
want to caution here that we can easily create a vicious cycle, where no
Co-chair can ever make a call on any proposal without being hanged. This
also can lead to members of the community refusing to be Co-chair and we
will one day be left stranded.
It is important we give the Co-chairs a breather and salute their
courage in navigating the maze of the issues on ground and bring us to
some point. I suggest we concentrate on refining the proposal on call.
Simply,
Daniel
On 29/09/2020 10:31 am, JORDI PALET MARTINEZ via RPD wrote:
>
> I don’t need to look into the video again. I was there, I recall all
> the details, I also understand Marcus point but we need to put
> everything in the right time and context, and recognize all the
> historic facts at the same time BUT look into what is best for the
> community:
>
> 1. My Inter-RIR proposal was the first one.
> 2. I think the **minimum** that people that don’t like a proposal
> should do, **before submitting a competitive proposal**, is to
> talk in the list and/or in private with the authors of an earlier
> proposal to try to agree. As an example of what I think is the
> right behavior: I did that before the Dakar meeting, for a
> completely different topic (it doesn’t matter for this
> discussion), and only after not having reaction from the authors
> in months and meeting them in Dakar, I submitted my “competing”
> proposal . Then I withdraw it in Hammamet under the promise from
> the authors that they will this time take it – nothing happened.
> 3. So, what I would have expected for proposal 2 and 3 authors is to
> first contact me to try to resolve it. Specially because one of
> the authors of one of those proposals was the one telling me in
> Hammamet that I was not doing right competing to them and “I was
> just a guest there …” (and no code of conduct was applied). Not
> nice. Even in that situation, I’m always be very happy, as I’ve
> said many times, to work with other committed authors. People that
> respond to emails, people that really want the good of the
> community, **even** if this is against their own personal views.
> I’ve demonstrated many times, that I’ve supported points or even
> complete proposals that I was personally against, but I recognize
> it was the good of the community.
> 4. Nevertheless, all that **doesn’t care at all**. Proposals are not
> about authors, are about what is the best for the community!
> 5. This is why my proposal has aspects that I was not agreeing or
> considering necessary, such as the ASN or the security belt:
> because I was hearing the community inputs. Consequently, I’ve
> been always happy to incorporate or remove or reword any points if
> that means reaching consensus in something that is good for the
> community. Of course, if I strongly believe that is “bad” I will
> try to find a middle-agreement point. This is what **consensus**
> means!
> 6. Before Luanda, co-chairs, staff and other authors can confirm,
> I’ve tried to find an agreement, organize a call, or even a
> meeting in Luanda among all (before the PPM), etc. and have a
> single proposal (note that I’m not saying this or that proposal,
> just something in common). I’ve even met in person one of the
> authors in the previous IETF, he got no time for trying to fix it.
> There was no way to agree. Somehow, I was thinking that one of the
> proposals was closer to what I think is the best for the community
> - again, NOT FOR ME, I’m irrelevant – I can “concede” (the latin
> original meaning of consensus) in what is not essential for me, if
> it is still good for the community.
> 7. I’ve been always open to keep finding an agreement and this is why
> I keep trying to fix, at the moment, not my proposal, but the one
> that looks closer to what is best to the community **even if is
> not my proposal – doesn’t care!**.
> 8. If we can’t resolve this now, I will proceed again with my
> proposal unless we can find a common agreement of what is the
> **best for the community**, not any authors personal preferences,
> not subjective views of anyone and 1^st respecting as much as we
> can the actual policy because some members already used that one
> and will not be fair that they now are “losers” in front of who is
> coming later (unless as part of the proposal we can give them back
> the same benefits).
>
> So please, let’s stop subjective considerations, including “this is
> not the right problem statement”, and many others, and concentrate in
> getting it right **for the best of the community**, being fair with
> all the parties as much as we can, including those that already
> applied to the actual CPM.
>
> Regards,
>
> Jordi
>
> @jordipalet
>
> El 29/9/20 11:05, "lucilla fornaro" <lucillafornarosawamoto at gmail.com
> <mailto:lucillafornarosawamoto at gmail.com>> escribió:
>
> Dear Marcus,
>
> I have watched the video that you linked carefully. I don't see how it
> can be relevant now. The video was uploaded 9 months ago, and it
> concerns another discussion. It is pointless for the current one.
>
> How is the co-chairs' behavior defamatory? There is no damaging of the
> good reputation of anyone.
>
> regards,
>
> Lucilla
>
> Il giorno mar 29 set 2020 alle ore 17:34 Marcus K. G. Adomey
> <madomey at hotmail.com <mailto:madomey at hotmail.com>> ha scritto:
>
> Hi Taiwo,
>
> If you watch the video below from section 3:07:30 - 3:11:00, you
> will notice that the cochairs attempted to force Jordi to drop his
> proposal and support Taiwo/Anthony proposal and then asked
> Taiwo/Anthony to drop theirs to support Jordi and both groups
> refused. The cochairs then suggested that the two can work
> together only to be told by remote participant that this is not
> how the PDP works and the cochairs then asked for staff analysis.
>
> This was a clear violation of the PDP by cochairs by attempting to
> force authors of 1st and 2nd proposals to work together knowing
> very well there is a 3rd similar proposal.
>
> Defamation is easy to prove within an open and transparent process.
>
> Link: https://youtu.be/DF0AFeaNiS0
>
> Marcus
>
> ------------------------------------------------------------------------
>
> *From:*Taiwo Oyewande <taiwo.oyewande88 at gmail.com
> <mailto:taiwo.oyewande88 at gmail.com>>
> *Sent:* Friday, September 25, 2020 5:24:07 PM
> *To:* Marcus K. G. Adomey <madomey at hotmail.com
> <mailto:madomey at hotmail.com>>; Noah <noah at neo.co.tz
> <mailto:noah at neo.co.tz>>
> *Cc:* Murungi Daniel <dmurungi at wia.co.tz
> <mailto:dmurungi at wia.co.tz>>; rpd >> AfriNIC Resource Policy
> <rpd at afrinic.net <mailto:rpd at afrinic.net>>
> *Subject:* Re: [rpd] Transfer Policy Proposal v.3.docx
>
> Hi all,
>
> Discussing a problem statement that will not be implemented in the
> CPM is not really taking us forward.
>
> There is an obvious war against the co chairs for doing a job that
> the community mandated them to do by the status of their election.
> The co-chairs discussed each points raised with the various
> authors and tried to see if all the points were duly addressed
> before making their decisions.
>
> I saw a false and misleading statement about the cochairs trying
> to get the authors of 2 of the 3 related policies against the
> authors of the 3rd policy. Is this what members of this working
> group has turned to?
>
> Trying to create a bad name for another member using scenarios
> that never occurred. I think that is the height of desperation and
> such defamation of character should not be encouraged on this list
>
> Taiwo
>
>
>
> On 25 Sep 2020, at 14:17, Marcus K. G. Adomey
> <madomey at hotmail.com <mailto:madomey at hotmail.com>> wrote:
>
>
>
> Dear all,
>
> The Policy “Resource Transfer Policy”
> (AFPUB-2019-V4-003-DRAFT01) proposed by Anthony Ikechukwu Ubah
> and Taiwo Oyewande is based on a fake problem for our region.
>
> (1) “The current policy fails to support a two-way Inter-RIR
> policy” – And so what? This was an intra-RIR transfer policy,
> not meant to be Inter-RIR
>
> (2) “there by hindering smooth business operation”
>
> Can the authors of the policy show how the current situation
> is “hindering smooth business operation?”
>
> Further, they should tell us what they mean by “smooth
> business operation”.
>
> (3) “development and growth in the region”
>
> Can the authors of the policy prove that the current status is
> hindering “development and growth in the region”?
>
> It is clear that the authors of the policy have used
> unsubstantiated claims to buttress the need for this policy.
>
> Basically, the Resource Transfer Policy is intended to take
> Internet Resources on one region to the other. We all know
> that Africa is at its developing stage and needs more internet
> resources to support its developmental process. Accepting this
> policy means that the little resources left in our region will
> be taken away, especially when we don’t have the mechanism in
> place to enforce the auditing of the use of the allocated
> resources.
>
> Moreover, any unmanaged inter-RIR transfer policy will weaken
> the development of the Internet in the region as we have no
> control over this global market which never played in our
> favor. It may also affect AFRINIC operations.
>
> Recent findings discussed on this list show how transferred
> resources are being used. The global community is yet to
> discuss the impact on transfer. I am more concerned for our
> region.
>
> Reconsider your decision and let us discuss the best approach
> to engage the Region into the global resources transfer world.
>
> Marcus
>
> ------------------------------------------------------------------------
>
> *From:*Murungi Daniel <dmurungi at wia.co.tz
> <mailto:dmurungi at wia.co.tz>>
> *Sent:* Wednesday, September 23, 2020 8:59 PM
> *To:* rpd >> AfriNIC Resource Policy <rpd at afrinic.net
> <mailto:rpd at afrinic.net>>
> *Subject:* Re: [rpd] Transfer Policy Proposal v.3.docx
>
> Hello,
>
> Can the authors of the resource transfer policy in the last
> call explain, which problem is being addressed?
>
> The problem statement is awkward to say the least. The issue
> with the problem statement was raised in Luanda and during the
> virtual AIS. How can we can adopt a proposal when the
> problem statement is out of scope of the PDP?
>
> ——-
> 1. Summary of the problem being addressed by this proposal
> The current policy fails to support a two-way Inter-RIR
> policy, thereby hindering smooth business operation,
> development, and growth in the region. This proposal aims to
> establish an efficient and business-friendly mechanism to
> allow a number of resources to be transferred from/to other
> regions. This proposal outlines a model in which AFRINIC can
> freely transfer number resources to/from other regions, i.e.
> RIPE NCC, APNIC, ARIN and LACNIC. This includes both
> IPv4 addresses and AS numbers.
> ——-
>
> Regards,
>
>
> Murungi Daniel
>
>
>
> On Sep 23, 2020, at 10:39 PM, Fernando Frediani
> <fhfrediani at gmail.com <mailto:fhfrediani at gmail.com>> wrote:
>
> Hello
>
> There is no much I can do other than state my *opposition
> to this proposal* to advance and reach any consensus
> mainly because 5.7.4.3 has been inverted from what was
> originally in the proposal and only changed at last minute
> due to some comments in the PPM going straight to last
> call which didn't give opportunity to the community
> re-evaluate this major change and if it's suitable to the
> region or not.
>
> Co-Chairs cannot advance this proposal to rough consensus
> the way it is and I urge and ask them again to bring it
> back to discussion to find out a resolution to these
> opened issues. Multiple people raised substantial concerns
> about it already. There is no way it can be considered
> 'rough consensus'.
>
> I also understand there may be a hurry to get a Inter-RIR
> transfer policy as soon as possible, but we must care
> about what is most important than that which is get
> policies to reflect what is really good for the region and
> not just to a few actors, even if it takes a bit longer. I
> support Jordi's suggestion to have another PPM in a few
> months so perhaps this proposal can advance from that
> point in time. LACNIC remained about 2 years without a
> Inter-RIR transfer policy after it run out of addresses
> for new organizations and survived. AfriNic will survive
> if it has to wait a few more months in order to get things
> really right.
>
> Now going to the merit of the proposal specially the main
> point I oppose (5.7.4.3):
> There is no sense at all to keep considering transferred
> legacy resources as legacy. This doesn't work that way and
> has a proper reason to be like that which is fix a
> historical internet problem and reduce legacy resources
> with time as they get transferred to 'normal'
> organizations who purchased them in the market for example.
> In this way organizations receiving these resources are
> bind to the same rules everybody else making it much fair
> to everybody and making no distinction between members.
> Allowing resources to remain considered legacy only
> contributed to abuses and unfairness allowing those who
> can pay more do whatever they like which is bad for the
> rest of the Internet community which are subject to the
> same rules that apply equally to them.
> If transferred legacy resources are not considered legacy
> anymore more and more they will apply equally for
> everybody as they become as a normal resource within any
> RIR. There has been a strong reason for this be like that
> until now and to continue like that.
>
> Regards
> Fernando
>
> On 23/09/2020 09:49, JORDI PALET MARTINEZ via RPD wrote:
>
> Hi Taiwo, all,
>
> I've looked into the doc.
>
> Let me say something before going into a more detailed analysis: I *fully support* this proposal, and I will be happy to withdraw it once:
>
> 1) The staff confirms that all the points on the staff analysis have been cleared and thus, the policy could be implemented and will be functional in the intended purpose.
>
> 2) The board ratifies the policy (which means also it passes the last call).
>
> Why? If anything in the process fails, I still believe my proposal is clearer and never mind is my proposal or this one I'm happy to work with the authors to make sure to resolve the issues that may happen as indicated in 1 and 2 above (hopefully there are no issues).
>
> I've now a more detailed analysis, please really, needs to be taken seriously with the staff or we may ruin the policy and not allow to be functional.
>
> There is something which doesn't make sense: The text in point 5.7. The CPM should be read always as "actual" so "soon will exhaust ..." is not logic, neither needed for the purpose of this policy. In addition, there are typos there ...
>
> This is an editorial change that according to the PDP should be possible as part of the last call. I will suggest to keep it simple:
>
> 5.7 IPv4 Resources transfer
>
> This policy applies to an organization with a justified need for IPv4 resources (recipients) and organizations with IPv4 resources which no longer need (sources).
>
> I see that the "disputes" issue has been resolved! Tks! Anyway, I think there is another editorial problem there.
>
> Actual text:
>
> 5.7.3.1 The source must be the current rightful holder of the IPv4 address resources registered with any RIR, and shall be in compliance with the policies of the receiving RIR, and shall not be involved in any dispute as to the status of those resources.
>
> I suggest:
>
> 5.7.3.1 The source must be the current rightful holder of the IPv4 address resources registered with any RIR, in compliance with the relevant policies, and shall not be involved in any dispute as to the status of those resources.
>
> Keeping the "policies of the receiving RIR" is contradictory ... changing it with "relevant policies" allows both RIRs to ensure that everything is correct.
>
> Grammar maybe, I'm not English native speaker:
>
> "for 12 months period" or "for a 12 months period"
>
> I think 5.7.3.3. doesn't add any value, it could be removed and doesn't change anything: if there is no limite, no need to mention it. If there is not agreement, clearly the transfer will not happen because the parties don't authorize it, and then the RIR(s) don't authorize it!
>
> Similarly 5.7.4.2. could be removed as well. We already said that the recipient should comply with policies (5.7.3.1), so what is this adding? Just superfluous text.
>
> Note also my imputs in the previous email, regarding the hold period and the legacy status. I think 5.7.4.3, should be "IPv4 legacy resources "Transferred incoming or within AFRINIC IPv4 legacy resources will no longer be regarded as legacy resources".
>
> 5.7.5.1 is already indicated by the staff as something problematic with the actual wording. The transferring party (the source) may not have any relation (not a member) with the receiving RIR. With this text we are enforcing *all the RIRs* to offer a standard template and process on our mandate. WE CAN'T DO THAT. Our policies only have a mandate in AFRINIC, not in the other RIRs.
>
> If we just remove section 5.7.5, and leave it to the staff as part of the operational procedure, the the problem is resolved because the existing process among the all other 4 RIRs for transfers will be "joined" by AFRINIC. It is just a matter of interconection among systems and processes!
>
> I think all this should be carefully studied among the authors and the staff and the chairs should make sure that the verstion coming to last call has corrected all those issues.
>
> I hope all this is useful.
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
> El 23/9/20 9:38, "Taiwo Oyewande"<taiwo.oyewande88 at gmail.com> <mailto:taiwo.oyewande88 at gmail.com> escribió:
>
> Hello PDWG,
>
> Attached is the updated version of the Resource Transfer Policy proposal. As recommended, changes have been effected on sub-section 5.7.3.2, and 5.7.4.3 according to the co-chair summary.
>
> _______________________________________________
>
> RPD mailing list
>
> RPD at afrinic.net <mailto: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.
>
> _______________________________________________
>
> RPD mailing list
>
> RPD at afrinic.net <mailto:RPD at afrinic.net>
>
> https://lists.afrinic.net/mailman/listinfo/rpd
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net <mailto:RPD at afrinic.net>
> https://lists.afrinic.net/mailman/listinfo/rpd
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net <mailto:RPD at afrinic.net>
> https://lists.afrinic.net/mailman/listinfo/rpd
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net <mailto: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
>
>
> **********************************************
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20200929/40c7d657/attachment-0001.html>
More information about the RPD
mailing list