<div dir="auto"><div>Salama Jordi</div><div dir="auto"><br></div><div dir="auto">Thanks for your feedback. So like I had indicated earlier, the issues I pointed out exist and you have ack the same its just the approach perhaps which I think the PDWG must take on addressing them is where we part. But the issues need to be addressed.</div><div dir="auto"><br></div><div dir="auto">On the other hand, the i dont have issues working with you on proposals. The way I see it, its best the PDWG take up proposals aways from us who author them and take ownership of them.</div><div dir="auto"><br></div><div dir="auto">I think Alain send a proposal to the PDWG seeking participants who can co-author with him. This is a better approach as it transparently allows some members on the WG to join in or not to join in....</div><div dir="auto"><br></div><div dir="auto">In all cases,  would like to request that we pull this back into WG and we fix what needs to be fixed as WG. Staff can also advice further based on what has been raised by some members.</div><div dir="auto"><br></div><div dir="auto">Sorry I have been dealing with lots of other issues so didnt put so much time initially to comment in earlier version but this why its a PDP process.</div><div dir="auto"><br></div><div dir="auto">Tuko pamoja kaka and dont feel like others dont want to work with you. Its not the case.</div><div><br></div><div data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Cheers,</div><div><b>.</b><b>/noah</b></div><div><b><br></b></div></div></div></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sat, 1 Aug 2026, 11:33 am jordi.palet--- via RPD, <<a href="mailto:rpd@afrinic.net">rpd@afrinic.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="line-break:after-white-space">Hi Noah,<div><br></div><div>Unfortunately, googling I found too many definitions of what is “perspective Kaka”, so not sure about your context. Anyway, my “short" considerations follow.</div><div><br></div><div>1) The change to 8 months, was to resolve the discrepancy as in the CPM you have 12 months, but then the softlanding change to 8 months. So the point was the same as other changes in this proposal: to align the CPM to avoid confusion to any reader. I could have done in the other way around: changing the 8 months back, to 12 months, but my understanding was “the community decided 8 months when working on the softlanding proposal, that decision is chronologically later than the 12 months, so why going back?”. And also, if anyone could have provided this input when I submitted v1 of the proposal, it could have been discussed and changed in v2.</div><div><br></div><div>2) I’ve already commented on this before. "Final and irreversible" is from the standing point on who is reading the CPM. We *all* know very well that any proposal can amend the CPM (in all the RIRs). The CPM is a live document, we have fixed the language and CPM for a given time, but we can always come back to revise it, so yes, it is actually "true at once” it provides suficiente clarity to who is reading the text when it is an active policy.</div><div><br></div><div>3) The refill of the /12 has a very important benefit for the community. If we reach the point where recovered resources are in quarantine, and there are pending requests, those pending requests can be satisfied immediately, instead of waiting for the quarantine period. There is no any cons on doing that, only benefit, despite that I believe it is certainly possible that the increase on IPv6 deployment will mean that we could not actually reach that point. It all depends on us doing the right thing and be more active deploying IPv6.</div><div><br></div><div>The PIER showed the problems and was presented every year. I’m not sure right now (because the broken web site), when we had the last PIER, but I can find a document from 2022 (after I recall a presentation from December 2025). Since then, for months (or even years) nobody talked about all that in the list, nobody presented any ideas. I asked the staff to refresh it (<a href="https://lists.afrinic.net/pipermail/rpd/2026/014716.html" target="_blank" rel="noreferrer">https://lists.afrinic.net/pipermail/rpd/2026/014716.html</a>), and about a month after, the staff created a summary (<a href="https://lists.afrinic.net/pipermail/rpd/2026/014725.html" target="_blank" rel="noreferrer">https://lists.afrinic.net/pipermail/rpd/2026/014725.html</a>), which again, with the broken site, now is not available (could we restore it, please?). We need to be proactive and as much up front as possible! There is not excuse to not work in policy development to fix issues, specially if they are clearly spelled out by the staff because they find these problems in their daily activity, same as members, or consultants working with members, may find the same or other issues working in projects.</div><div><br></div><div>Final comment. Yes, the proposal changes several things, but I think those changes are sufficiently clear on their own that doesn’t make sense to make one proposal for each individual change. If the discussion from v1 had raised that, I will had not any issue to split the proposal, but was not the case. Also, there was a clear problem statement, spelled out by the staff, as said, was there for months. Have you or anyone else even tried to discuss on the list?</div><div><br></div><div>To be clear: don’t take me wrong. I’m not pretending to attack or blame you or anyone else. It is just the way we work, or at least most of the community work. I try to be as proactive as possible, considering my own obligations, probably the difference is that I also believe that broken protocols (in IETF) or broken policies (in RIRs), even if that is not paid job, is also part of my obligation with the community, despite others dislike that - I just care on the global good, not who dislike me working on trying to fix problems, and yes, of course, I can make mistakes, but at least I try and I try my best and as early as possible so we have time for discussion, not just waiting for when the time for new proposals is gone, or during the LC.</div><div><br></div><div>You know very well, for example, in the PDP update proposals, how much I tried in pvt emails to you and other co-authors, co-chairs in copy, to follow the co-chairs recommendations to work together. Absolutely ignored. It seems you don’t like working with others. Fine, I decided not to submit my own proposal to avoid repeating the situation of reaching consensus both proposals and not being implementable. Now, I’m every day more convinced that I need to do that, I need to ignore people that don’t like to work with others, and proceed myself, because I don’t do this for me, but for the good of the community and the community deserves whatever I can do to help, even if others don’t like it because they may have their own personal priorities, not community priorities.</div><div><br></div><div>I think the lesson to learn is: the community must discuss the proposals in the early stage, not in the LC.</div><div><br id="m_3416578794439187488lineBreakAtBeginningOfMessage"><div>
<div>Regards,<br>Jordi<br><br>@jordipalet<br></div>

</div>
<div><br><blockquote type="cite"><div>El 31 jul 2026, a las 23:11, Noah <<a href="mailto:noah@neo.co.tz" target="_blank" rel="noreferrer">noah@neo.co.tz</a>> escribió:</div><br><div><div dir="auto"><div>Salama Jordi,</div><div dir="auto"><br></div><div dir="auto">Let me try to put things into perspective Kaka..</div><div dir="auto"><br></div><div dir="auto">Basically, the question afrinic staff put to us the PDWG was whether recovered IPv4 space falls under Phase 2 or needs a new policy, plus tidying up the conflicts between Soft-Landing and other CPM sections. </div><div dir="auto"><br></div><div dir="auto">The parts of the proposal that actually answer that are fine by me and can go ahead putting recovered space into the available pool under Phase 2 after a 12-month quarantine, since some sections already cover that. No issue with any of that.</div><div dir="auto"><br></div><div dir="auto">Kwaio, (shida yangu) as in my problem is with three things that came along for the ride and don't really belong to that question.</div><div dir="auto"><br></div><div dir="auto">First, the change from twelve months to eight, tightens the utilisation and SAW obligations on every assignee and every LIR making sub-allocations. My brother...whatever the merits, it has nothing to do with recovered space and it is not mentioned anywhere in your problem statement. A change to member obligations of that kind should stand on its own bro and be discussed by the PDWG as such, not slipped in alongside the recovered-space fixing hahahaha..... you get it? If you dont get it, forget about it... :-)</div><div dir="auto"><br></div><div dir="auto">Another thing bro the "final and irreversible" wording. I would point out that the proposal's own reasoning says it "doesn't prevent a better choice over the time." Both cannot be true at once. If the intention is simply to give us a predictable default for today and I would support that then the irreversibility language is doing more than the purpose needs, and more than afrinix staff's question asked for. </div><div dir="auto"><br></div><div dir="auto">Laskly, some of clauses and the /12 release-and-refill in 5.4.7.1 go beyond the specific conflicts you set out for the PDWG to resolve. A broad priority over other allocation criteria, together with releasing the reserved /12 and refilling it with space still in quarantine, is a bigger structural change and deserves its own conversation.....</div><div dir="auto"><br></div><div dir="auto">The reason I think this is worth raising now is coz the policy can always be changed later, In fact any of us can put our some but the IP addresses cannot. Once recovered IP space is mixed into the general pool/inventory and handed out, it is embedded in resource members networks and no future policy can pull it back into a separately managed pool.</div><div dir="auto"><br></div><div dir="auto">Kwaio, keeping that option open costs the PDWG almost nothing because the recovered space can sit under Phase 2 yesterday and today and still be tracked and reported as its own inventory pool. The interim purpose you describe does not require closing any doors, so I would rather we didn't as the PDWG.</div><div dir="auto"><br></div><div dir="auto">So I am not asking you to throw the proposal out. There are some issues here Kaka and for the future I would support what has been said earlier in the thread about the PDWG agreeing on the problem statement first when staff raise something, and only then asking for drafts. If we had done that here, most of this would not be surfacing at Last Call.</div><div dir="auto"><br></div><div><br></div><div data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Ahsante sana.....</div><div><b>.</b><b>/noah</b></div><div><b><br></b></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 31 Jul 2026, 11:15 pm jordi.palet--- via RPD, <<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="line-break:after-white-space">Hi all,<div><br></div><div>I think the arguments are being repeated, as it happened with a previous proposal, and repeating myself will not add anything new.</div><div><br></div><div>If the chair believe that I’ve not responded to anything key to complete the evaluation of the LC, I will be happy to further elaborate.</div><div><br></div><div>Tks!</div><div><br id="m_3416578794439187488m_-2182741802578769816lineBreakAtBeginningOfMessage"><div>
<div>Regards,<br>Jordi<br><br>@jordipalet<br></div>

</div>
<div><br><blockquote type="cite"><div>El 31 jul 2026, a las 18:26, NP Petronella <<a href="mailto:NPertuniaPetronella@outlook.com" rel="noreferrer noreferrer" target="_blank">NPertuniaPetronella@outlook.com</a>> escribió:</div><br><div>



<div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
Dear Co-chairs and colleagues,</div>
<div style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)" id="m_3416578794439187488m_-2182741802578769816ms-outlook-mobile-signature" dir="auto">
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
Thank you to Gregoire and Alain for their thoughtful interventions. Read together, their comments expose an important issue that should be resolved before DRAFT02 advances.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
Alain is correct to point out that section 5.4.3 of the current CPM already applies the Exhaustion Phase rules to all IPv4 space allocated, assigned, or otherwise managed by AFRINIC, regardless of whether that space originated from the Final /8.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
On that reading, recovered IPv4 space is not sitting in a policy vacuum. The existing CPM already supplies a default rule.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
This changes the nature of the discussion. DRAFT02 cannot simultaneously be presented as urgently “filling a gap” and as merely confirming what the CPM already requires.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
If the proposal simply restates section 5.4.3, then it is unnecessary. If it does more than restate the existing rule, then those additional provisions must be justified as substantive policy changes.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
DRAFT02 does substantially more. It:</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
declares Soft Landing phases final and irreversible;</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
requires all returned or recovered resources, regardless of their original pool, to enter the available-space framework;</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
gives AFRINIC discretion to shorten the quarantine period for broadly described operational reasons;</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
permits the existing /12 reserve to be released and replaced with recovered space, including space still under quarantine;</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
gives the Soft Landing section priority over other CPM allocation criteria; and</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
removes or changes several provisions that go beyond the narrow question of recovered-space treatment.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
These are not merely clarifications of section 5.4.3. They alter the policy architecture governing a finite and economically significant body of IPv4 resources.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
Gregoire’s reference to the Dynamic IPv4 Pools Exhaustion Management Framework is therefore directly relevant. The Working Group is not choosing between “DRAFT02” and “no rule.” The current CPM already provides an interim rule.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
The real choice is whether recovered space should remain subject to the existing default or be governed through a more specific framework with separate pools, clearer controls, and defined anti-abuse safeguards.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
There is also no necessary reason why applying existing Phase 2 allocation criteria must erase the provenance or separate accounting of recovered resources. AFRINIC could continue recording recovered prefixes as a distinct inventory class while the community
 evaluates the long-term framework.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
That would preserve policy optionality.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
Once recovered prefixes are fully commingled with the ordinary Phase 2 pool and allocated, the community cannot later reconstruct a dedicated recovered-space pool without affecting operationally embedded allocations. A future policy may remain procedurally
 possible, but the resources already distributed will no longer be available to it.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
This is the distinction between changing policy later and preserving the ability to make a meaningful choice later.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
Before DRAFT02 proceeds, I suggest that the co-chairs request:</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
a clause-by-clause explanation of what DRAFT02 changes beyond existing section 5.4.3;</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
a comparative assessment of DRAFT02 and the Dynamic Framework, including depletion, concentration, reserve integrity, anti-abuse controls, and operational complexity;</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
separate and auditable reporting of recovered-space inventory and allocations; and</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
clarification of which provisions are genuinely necessary to answer the recovered-space question and which should be considered through separate proposals.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
A policy should not duplicate an existing rule and then use that duplication to introduce irreversibility, supremacy, and additional administrative discretion around it.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
The safer approach is to preserve the existing default while the community compares the available models using actual inventory and allocation data. That protects the remaining IPv4 resources without prematurely locking them into one institutional framework.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
For these reasons, I support the concerns raised by both Gregoire and Alain, and I object to AFPUB-2026-IPv4-001-DRAFT02 advancing in its current form.</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
<br>
</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
Regards,</div>
<div dir="auto" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(33,33,33)">
Nonhlanhla</div>
</div>
</div>

_______________________________________________<br>RPD mailing list<br><a href="mailto:RPD@afrinic.net" rel="noreferrer noreferrer" target="_blank">RPD@afrinic.net</a><br><a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br></div></blockquote></div><br></div><br>**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
<a href="http://www.theipv6company.com/" rel="noreferrer noreferrer" target="_blank">http://www.theipv6company.com</a><br>
The IPv6 Company<br>
<br>
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.<br>
<br>
</div>_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" rel="noreferrer noreferrer" target="_blank">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
</blockquote></div>
</div></blockquote></div><br></div><br>**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
<a href="http://www.theipv6company.com" target="_blank" rel="noreferrer">http://www.theipv6company.com</a><br>
The IPv6 Company<br>
<br>
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.<br>
<br>
</div>_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" target="_blank" rel="noreferrer">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
</blockquote></div>