<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>So, let's recap:</p>
<p>- This proposal has been very controversial and had a reached
'consensus' according to the Co-Chais understanding despite the
many protests from many people from this group.<br>
- After the 'consensus' was declared in the PPM the proposal
suffered significant changes in the text, some of them as put
conditional by the Co-Chairs for the consensus, something really
odd. To mention one of the changes the one that changes legacy
resources status from one thing to the contrary of that.<br>
- These changes made after the PPM were never given enough time
for the WG to discuss it properly. One of the points that changed
about the Legacy Status had NEVER been discussed in the several
months of discussion by the WG.<br>
- During the Last-Call there were countless requests for this
proposal to be put back into discussion again as clearly it never
reached consensus<br>
- After the Last-call the Co-Chais decision about this 'consensus'
was appealed, twice.<br>
- Co-Chairs made something unprecedented after confirming the
consensus brought the proposal back to Last-call.<br>
- During the first and second Last-call periods the proposal
received at least 3 new versions, which some insist to call
"editorial review" but change several and significant parts
showing the proposal was not ready to progress and is been rush at
any cost to pass.<br>
- During the same period staff confirmed some of the RIRs, ARIN in
specially did NOT have reciprocity to the text that supposedly
reached consensus.<br>
- Still with the situation unknown the authors keep presenting new
text revisions for the proposal confirming once more that the
proposal was never ready to have any consensus declared and needed
further discussion despite how much important it can be for the
region. <br>
- These changes are called "editorial changes" but in fact are
just newer versions which require time for the WG to discuss
properly.<br>
</p>
<p>Facing all this how can a proposal have any consensus declared
with all this mess ?</p>
<p>Fernando<br>
</p>
<div class="moz-cite-prefix">On 30/10/2020 12:36, Anthony Ubah
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAHcb0ATV-GFzL4ae0UjUHko+5g5_eeessd_ABiFBZkh81Hu0JA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Dear Community,<br>
<br>
We have perused suggestions and opinions raised by the community
as regards the compatibility of the Resource Transfer Policy
proposed. Thus, my co-author and I have put these into
consideration in this editorial review.<br>
Below is the current proposal text for further discussions; <br>
<br>
5.7 IPv4 Resources resource transfer<br>
Like the other Regional Internet Registries, AFRINIC will soon
exhaust its IPv4 pool. In order to meet the needs of late
resource requestors, a transfer policy for IPv4 resources within
and outside the region is needed. The goal of this policy is to
define conditions under which transfers must occur. The policy
solves the issue of an African organization needing IPv4 number
resources after the exhaustion of the AFRINIC IPv4 pool or when
AFRINIC can no longer satisfy the needs of such an organization.
<br>
<br>
5.7.1 Summary of the policy<br>
This policy applies to any transfer request raised by a resource
holder for resource transfer to and from the AFRINIC region.<br>
<br>
5.7.2 Conditions on the source of the transfer<br>
5.7.2.1 The source must be the current and rightful holder of
the IPv4 address resources registered with any RIR, and shall
not be involved in any disputes as to those resources' status.<br>
5.7.2.2 Source entities are not eligible to receive any further
IPv4 allocations or assignments from AFRINIC for a period of
twelve (12) months after a transfer is approved. Allocated or
Incoming transferred resource cannot be transferred again for a
period of twelve (12) months.<br>
5.7.2.3 There is no upper limit regarding the amount of
transfer, allocation, and assignment of IPv4 number resources a
source entity can receive as long as the transfer request is
carried out under a mutual agreement between the source and the
recipient.<br>
<br>
5.7.3. Conditions on the recipient of the transfer<br>
5.7.3.1 A transfer from another RIR to AFRINIC requires a
need-based evaluation. AFRINIC must approve the recipient's need
for the IPv4 number resources. In order for an organization to
qualify for receiving a transfer, it must first go through the
process of justifying its IPv4 resource needs before AFRINIC.
That is to say, the organization must justify and demonstrate
before AFRINIC its initial/additional allocation/assignment
usage, as applicable, according to the policies in force.<br>
A transfer from AFRINIC to another RIR must follow the relevant
policies.<br>
5.7.3.2 Incoming transferred legacy resources will still be
regarded as legacy resources.<br>
<br>
Kind Regards,<br>
<br>
Anthony Ubah</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
RPD mailing list
<a class="moz-txt-link-abbreviated" href="mailto:RPD@afrinic.net">RPD@afrinic.net</a>
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a>
</pre>
</blockquote>
</body>
</html>