<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 8, 2016, at 04:49 , ALAIN AINA <<a href="mailto:aalain@trstech.net" class="">aalain@trstech.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hello,<div class=""><br class=""></div><div class="">inline...<br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 7, 2016, at 9:41 PM, Owen DeLong <<a href="mailto:owen@delong.com" class="">owen@delong.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""> a /13 for unforeseen future<br class=""></blockquote><br class="">I am absolutely opposed to this.<br class=""></blockquote><div class=""><br class=""></div><div class="">This proposal stays in the spirit of the current soft landing policy. We propose to reduce the reserve to accommodate new entrants and critical infrastructures. </div></div></div></blockquote><div class=""><br class=""></div>Unless I am mistaken, the current soft landing does NOT include a “Strategic Reserve” for purposes to be determined later.</div></div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">It does. See section 5.4.7 of the CPM:</div><div class=""><br class=""></div><div class="">=======</div><div class=""><p class="">5.4.7 <strong class="">IPv4 Address Space Reserve</strong> </p><p class=""><a id="A12IPv4addressblock" name="A12IPv4addressblock" class=""></a>5.4.7.1 A /12 IPv4 address block will be in reserve out of the final /8. This /12 IPv4 address block shall be preserved by AFRINIC for some future uses, as yet unforeseen. The Internet is innovative and we cannot predict with certainty what might happen. Therefore, it is prudent to keep this block in reserve, just in case some future requirement creates a demand for IPv4 addresses.</p><div class=""> 5.4.7.2 When AFRINIC, can no longer meet any more requests for address space (from the Final /8 or from any other available address space), the Board may at its discretion and considering the demand and other factors at the time replenish the exhaustion pool with whatever address space (or part thereof) that may be available to AFRINIC at the time, in a manner that is in the best interest of the community.</div><div class="">======</div><div class=""><br class=""></div></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""> This is a new feature of this proposal.</div></div></blockquote><div class=""><br class=""></div><div class="">No.</div><div class=""><br class=""></div><div class="">It is the reserve set by section 5.4.7, we am calling in the explanation message “Strategic Reserve”.</div><div class="">We propose to reduce this reserve to /13 to accommodate critical infrastructures( /16) and New comers(/14). Other improvement is that instead of the board deciding at its sole discretion how to use this reserve, we suggest AFRINIC and the community to decide. </div><div class=""><br class=""></div></div></div></div></div></blockquote><div><br class=""></div>I stand corrected. I favor deleting this provision, nonetheless.</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">This is a “Strategic Reserve” for future use on which community will decide as we go. As such i would like to hear from people in the region on the Strategic Reserve; 3.125% of the specific last /8 (102/8)</div></div></blockquote><div class=""><br class=""></div>I’m not sure if you intended this to be a vaguely worded implication that I am not in the region or not. While it is true that I do not reside in the region, as I have stated previously, I work for a company that has substantial operations in the region and yet has not yet consumed any AfriNIC resources while supporting virtually every single African internet user with improved internet experiences. Like it or not, while I used to be an interested bystander, for the last 19 months, I have been a participating stakeholder and not merely an interested bystander.</div></div></blockquote><div class=""><br class=""></div><div class="">Take it easy. All true and we appreciate your contributions. I was just saying that after we have heard from "the bystander", we shall hear from people in this region who are the direct impacted by this decision.</div></div></div></div></div></blockquote><div><br class=""></div>And I’m saying that I am in the region and am directly impacted by these decisions, even though I don’t happen to reside there. I am no longer a bystander.</div><div><br class=""></div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Andrew Alston is very much in the region and has also been vehemently opposed to this provision.</div></div></blockquote><div class=""><br class=""></div><div class="">Nothing new as you could see from the rpd archives and the recording of the AFRINIC-24 meeting. The only remark i could make is that Andrew has a conflict of Interest as he is co-author of the competing policy proposal which was introduced 3 days after our submission.</div><div class="">So i would only consider technical and data analysis discussions with Andrew on this matter.</div></div></div></div></div></blockquote><div><br class=""></div>I don’t see that as a conflict of interest. Andrew offered a proposal which, IMHO, is a more desirable alternative to yours.</div><div><br class=""></div><div>An accusation of conflict of interest is a serious thing which should not be thrown around so lightly. It describes a situation in which a person has duties to two organizations which duties are in conflict with each other. An example would be a lawyer representing both plaintiff and defendant, a real estate agent representing both seller and buyer, or a board member acting on a policy which seeks to provide an unbalanced benefit to an organization which employs said board member.</div><div><br class=""></div><div>As near as I can tell, none of this applies to Andrew in this context. His preference for a proposal that he wrote is merely an extension of the reasons he wrote it in the first place… Namely that he thinks it proposes a better alternative than the one you are discussing here.</div><div><br class=""></div><div>I will note that my original comments were a consolidated statement about both of the proposals and things I liked and didn’t like across the board in each of them.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">There’s been very little support for it on the list so far.</div></div></blockquote><div class=""><br class=""></div><div class=""><div class="">If we were to count numbers right now, i could say it is Andrew and Owen against the 3 co-authors of this proposal …</div><div class="">Much has been said and i think we should move forward unless we want to open this again.</div></div></div></div></div></div></blockquote><div><br class=""></div>I’m not sure what you mean by open this again. To the best of my knowledge, neither proposal yet has anything remotely resembling what I would call consensus. To the best of my knowledge, discussion on both proposals remains open so there is nothing to “open again” that I can see.</div><div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><div class="">A quick reference is the minutes of the discussions at AFRINIC-24 meeting : <a href="http://www.afrinic.net/en/library/policies/archive/ppm-minutes/1847-afrinic-24-pdwgpdp-minutes" class="">http://www.afrinic.net/en/library/policies/archive/ppm-minutes/1847-afrinic-24-pdwgpdp-minutes</a>.</div><div class=""><br class=""></div><div class="">One can read for Soft Landing - BIS (AFPUB-2016-V4-001-DRAFT-02)</div><div class=""><br class=""></div><div class="">====</div><div class="">The following feedback was received from the community after the presentation:</div><div class=""><ul class=""><li class="">There’s a need to set the minimum to /24 since anything smaller will be un-routable or filtered when routed.</li></ul></div></div></div></div></div></blockquote><div><br class=""></div>I have no strong opinion one way or the other on this.<br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><div class=""><ul class=""><li class="">Some felt that the IPv6 requirement should be removed, while others argued for this to remain.</li></ul></div></div></div></div></div></blockquote><div><br class=""></div>As much as I am an advocate of IPv6 DEPLOYMENT, forcing people to take IPv6 space without any requirement that it be deployed has been repeatedly shown not to further this objective, so I remain opposed. However, as stated above, there is no actual consensus on this matter at this time.</div><div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><div class=""><ul class=""><li class="">The feeling that this proposal discourages IPv6 uptake were shared, since it unnecessarily prolongs the lifetime of IPv4 when other regions have probably adopted IPv6.</li></ul></div></div></div></div></div></blockquote>Agreed. That is most certainly the case with this proposal, and especially with the provision in 5.4.7 of the existing policy and this proposal’s intent to preserve it.<br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><div class=""><ul class=""><li class="">It was noted by some that the current Soft Landing policy be maintained.</li></ul></div></div></div></div></div></blockquote>I’m all for modifying the current Soft Landing policy, but let’s do it in a useful way.<br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><div class=""><ul class=""><li class="">There were several statements for and against the proposal.</li></ul></div></div></div></div></div></blockquote>Which reaffirms my statement that it does not yet have anything approaching consensus.<br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><div class=""><p class="">The co-chairs determined that there was no consensus to push the proposal to last call, and decided to send it back to the mailing list for further discussions.</p></div></div></div></div></div></blockquote>And here we are having those discussions, while you appear to be attempting to get me to disengage from the discussion rather than providing a substantive rebuttal to my position.</div><div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><div class=""><div class="">====</div><div class=""><br class=""></div></div></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Any technology which would need this “strategic reserve” is a technology which does not exist yet. From my perspective, the only thing such a provision can do is encourage such technologies to be developed with dependencies on IPv4. This is absolutely wrong-headed. We should be encouraging new technologies to be developed WITHOUT dependencies on IPv4 and with full IPv6 support from day 1.</div></div></blockquote><div class=""><br class=""></div><div class="">Totally agree with you for the v6 support from day1. </div><div class=""> Having a reserve does not mean, we will necessary use it. Nobody went back to try use the 240/4 of the v4 space reserved for "future use" by RFC1112.</div></div></div></div></blockquote><div><br class=""></div>That’s because by the time we needed it, it would have required far too much recoding of far too many systems in order to be useful and the coding effort required likely exceeded the effort required to finish deploying IPv6, thus no benefit.</div><div><br class=""></div><div>Having a reserve creates the illusion that a safety net exists to protect people from their own bad judgment in implementing something depending on IPv4, whether or not that reserve ever gets used. Indeed, the longer it goes unused, the worse this aspect of its existence becomes. As such, such a reserve offers no benefit to the community and serves only as an incentive to engage in bad judgment.</div><div><br class=""></div><div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class="">As you can see from <a href="https://www.nro.net/rir-comparative-policy-overview/rir-comparative-policy-overview-2016-02#2-6" class="">https://www.nro.net/rir-comparative-policy-overview/rir-comparative-policy-overview-2016-02#2-6</a> AFRINIC will not be the first to set such reserve.</div></div></div></div></blockquote><div><br class=""></div>APNIC currently holds out a /16. In the grand scheme of APNIC space, this is a very tiny amount and I’m betting that when they start to run short of /22s in their last /8, this will be reverted quickly in the APNIC region.</div><div><br class=""></div><div>RIPE also holds out a /16 and the same caveats apply.</div><div><br class=""></div><div>AfriNIC, with a tiny fraction of the IPv4 resources held by those two RIRs and the largest post-depletion free pool on the planet currently reserves 16 times as much space for “unforeseen circumstances” and your proposal seeks only to cut that in half (8x). Only 2 of the other 4 RIRs have such a policy and I’m betting it will be reverted relatively soon in both cases. In both cases, that policy was put in place well before runout when IPv6 adoption was less than 0.01% worldwide.</div><div><br class=""></div><div>We’re in a very different time now.</div><div><br class=""></div><div>Owen</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">Hope this helps</div><div class=""><br class=""></div><div class="">—Alain</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">If you reward bad judgment (which is all that you can hope for from this provision), then you get an increase in bad judgment. One need look no further than the US financial crisis of 2008 for proof of this fact.</div><div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""><blockquote type="cite" class=""><div style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class=""> IPv6 address space (AFRINIC or upstreams) as requirement to IPv4 allocations<br class=""></blockquote><br class="">Can you clarify this<span class="Apple-converted-space"> </span></blockquote><div class=""><br class=""></div><div class=""> Section 3.8, allocations criteria in the proposal read:</div><div class="">……………...</div><div class="">LIR and End users requesting IPv4 must have IPv6 resources from AFRINIC (or request concomitantly with the IPv4) or from their upstreams.</div><br class=""><blockquote type="cite" class="">and how it is relevant or useful?<br class=""></blockquote><div class=""><br class=""></div><div class="">The last /8 (102/8) gotten through the global soft landing policy aims among other objectives to encourage a smooth transition to IPv6. </div><div class="">So if you need space from this last /108, show your IPv6.</div><div class=""><br class=""></div><div class="">Current allocations/assignment criteria for v6 are as below from CPM: </div><div class=""><br class=""></div><div class=""><p class=""><strong class="">6.5.1.1 Initial allocation criteria</strong></p><p class="">To qualify for an initial allocation of IPv6 address space, an organization must:</p><ol class="" style="list-style-type: lower-alpha;"><li class="">Be an LIR;</li><li class="">Not be an end site;</li><li class="">Show a detailed plan to provide IPv6 connectivity to organizations in the AFRINIC region.</li><li class="">Show a reasonable plan for making /48 IPv6 assignments to end sites in the AFRINIC region within twelve months. The LIR should also plan to announce the allocation as a single aggregated block in the inter-domain routing system within twelve months.</li></ol><div class="">===========</div><div class=""><br class=""></div><div class=""><p class=""><strong class="">6.8.2 Assignment Criteria</strong></p><ol class="" style="list-style-type: lower-alpha;"><li class="">Assignment target - End-sites which provide Public Internet services for a single administrative organisations' network, regardless of their size.</li><li class="">Assignment criteria:</li></ol><ul class=""><li class="">The end-site must not be an IPv6 LIR</li><li class="">The end-site must become an AFRINIC End User Member and pay the normal AFRINIC fee for its' membership category</li><li class="">The end site must either be a holder of IPv4 PI address space or qualify for an IPv4 PI assignment from AFRINIC under the IPv4 policy currently in effect.</li><li class="">The end-site must justify the need for the IPv6 PI address space.</li><li class="">The 'end-site' must show a plan to use and announce the IPv6 provider independent address space within twelve (12) months. After that period, if not announced, the assigned IPv6 PI address space should be reclaimed and returned to the free pool by AFRINIC.</li></ul></div></div><div class="">--------</div><div class="">If you do not have v6 or loose your v6 (review of allocations, etc…) you will not qualify for v4 in the last /8 unless justified.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Hope this helps</div><div class=""><br class=""></div><div class="">—Alain</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class=""><br class=""> We invite people to read the FAQ which is attached to the proposal and which helps with the understanding.<span class="Apple-converted-space"> </span><br class=""><br class=""> <a href="http://www.afrinic.net/en/community/policy-development/policy-proposals/1627-softlanding-bis-policy-faq-v2" class="">http://www.afrinic.net/en/community/policy-development/policy-proposals/1627-softlanding-bis-policy-faq-v2</a><br class=""><br class=""> From recent discussions, the authors of the solanding-bis proposal would be happy to consider making explicit in the proposal the following points:<br class=""><br class=""><br class=""> - Multiple new entrants under common ownership being treated as a single new entrant<br class=""></blockquote><br class="">If we are to have a new entrant reservation, this is a vital protection. Otherwise, anyone can find a friendly jurisdiction in the region and spin up as many new entrants as they like. Sort of like AWS for Coprorations to obtain addresses.<br class=""><br class="">We should also put some form of exclusion or protection against combining, consolidating, or trading in new-entrant space in any existing merger/acquisition transfer policy as well as for any future transfer/trade/sale policy that may be adopted.<br class=""><br class=""><blockquote type="cite" class=""> - Allocations to New entrants being used exclusively for IPv6 transitions mechanisms and services as explained in the FAQ<br class=""></blockquote><br class="">I think this is also a vital protection against new entrants seeking larger than acceptable allocations.<br class=""><br class="">Owen<br class=""><br class=""><blockquote type="cite" class=""><br class=""> Hope this helps<br class=""><br class=""> --Alain<span class="Apple-converted-space"> </span><br class=""><br class=""><blockquote type="cite" class="">On Nov 3, 2016, at 4:03 PM, Dewole Ajao <<a href="mailto:dewole@forum.org.ng" class="">dewole@forum.org.ng</a>> wrote:<br class=""><br class="">Thank you for the feedback, Owen. We look forward to the authors of both proposals considering the various inputs as well as offering further clarification to help the community better understand the rationale(s) behind the current drafts of their proposal(s).<br class=""><br class="">Regards,<br class="">Dewole.<br class=""><br class="">On 02/11/2016 23:16, Owen DeLong wrote:<br class=""><blockquote type="cite" class="">Thanks for doing this… It’s very useful.<br class=""><br class="">There are elements from each of the proposals I like, but none of them would get my support in their current form.<br class=""><br class="">I like the idea of a reserved carve-out for critical infrastructure.<br class="">I like the idea of a small (/12, perhaps) cutout for new organizations that are late to the party to receive up to a /24 for transition purposes.<br class=""><br class="">I do not like the idea of a large reservation for new entrants to the exclusion of the needs of existing participants.<br class=""><br class="">I especially do not like the idea of reserving a block of addresses for some undefined future use. Any future development that would require such a thing should be done under IPv6. There is no excuse for such development to be done in a manner that requires IPv4 addresses at this point in the evolution of the internet. We should not reward or encourage backward-thinking engineering.<br class=""><br class="">I think that the reservation for critical infrastructure should be from a specific block.<br class=""><br class="">I think it would be reasonable, if there is need, for the new entrant block to be comprised of fragments totaling a /12 equivalent rather than necessarily blocking out a specific /12.<br class=""><br class="">I do not think that reclaimed space should be reserved for new entrants. Rather, I would prefer to see one of two approaches taken to reclaimed space:<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>1.<span class="Apple-tab-span" style="white-space: pre;"> </span>An annoucement is made on relevant mailing lists that the space has been received and applications will be accepted beginning at a<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span>certain date and time. Such date and time to be not less than 14 days after the announcement is sent out.<br class=""><br class="">or<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>2.<span class="Apple-tab-span" style="white-space: pre;"> </span>A waiting list of unmet requests is created and the space is offered to those requestors on the waiting list on a FIFO basis.<br class=""><br class="">If we are to have a new-entrant block (I consider this optional, but desirable), it should be strictly for purposes of providing the addresses needed for transitional technologies (CGN, 6rd, etc.) and we should not allocate more than a /24 to any single new entrant. Multiple new entrants under common ownership should be treated as a single new entrant in most cases.<br class=""><br class="">Owen<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Nov 2, 2016, at 13:49 , Dewole Ajao <<a href="mailto:dewole@forum.org.ng" class="">dewole@forum.org.ng</a>> wrote:<br class=""><br class="">Good day,<br class=""><br class="">As indicated in an earlier email, please take some time to view and comment on<span class="Apple-converted-space"> </span><a href="https://goo.gl/FDLmZF" class="">https://goo.gl/FDLmZF</a><span class="Apple-converted-space"> </span>with a view toward fine-tuning and producing an improved IPv4 runout management plan.<br class=""><br class="">Thank you.<br class=""><br class="">Dewole Ajao<br class="">PDWG Co-Chair<br class=""><br class="">_______________________________________________<br class="">RPD mailing list<br class=""><a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a><br class=""><a href="https://lists.afrinic.net/mailman/listinfo/rpd" class="">https://lists.afrinic.net/mailman/listinfo/rpd</a><br class=""></blockquote></blockquote><br class=""><br class="">_______________________________________________<br class="">RPD mailing list<br class=""><a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a><br class=""><a href="https://lists.afrinic.net/mailman/listinfo/rpd" class="">https://lists.afrinic.net/mailman/listinfo/rpd</a><br class=""></blockquote><br class=""><br class=""> _______________________________________________<br class=""> RPD mailing list<br class=""> <a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a><br class=""> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" class="">https://lists.afrinic.net/mailman/listinfo/rpd</a><br class=""><br class=""><br class="">_______________________________________________<br class="">RPD mailing list<br class=""><a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a><br class=""><a href="https://lists.afrinic.net/mailman/listinfo/rpd" class="">https://lists.afrinic.net/mailman/listinfo/rpd</a><br class=""></blockquote><br class=""></blockquote></div><br class="" style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">RPD mailing list</span><br style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a></span><br style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><a href="https://lists.afrinic.net/mailman/listinfo/rpd" class="">https://lists.afrinic.net/mailman/listinfo/rpd</a></span></blockquote></div><br class=""></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">RPD mailing list<br class=""><a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a><br class="">https://lists.afrinic.net/mailman/listinfo/rpd<br class=""></blockquote></div><br class=""></body></html>