<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body><div style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">
<p dir="auto">Hi Gugu & Nia</p>
<p dir="auto">Just to be clear, I’m the operator of AS329532 & AS213481, Which ASNs are you representing that have issues with this AS-SET proposal?</p>
<hr style="border: 0; height: 1px; background: #333; background-image: linear-gradient(to right, #ccc, #333, #ccc);">
<p dir="auto">Hendrik Visage<br>
Director/Owner<br>
HeViS.Co Systems t/a Envisage Cloud Solutions<br>
<a href="mailto:hvisage@hevis.co.za" style="color: #3983C4;">hvisage@hevis.co.za</a><br>
GSM/SMS/Signal: +27-84-612-5345<br>
InstantMessenger: <a href="https://t.me/hvisage" style="color: #3983C4;">https://t.me/hvisage</a></p>
<p dir="auto">On 19 Jul 2026, at 8:54, Gugu Dhlamini wrote:</p>
</div><blockquote class="embedded" style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;"><div id="B56A086D-178D-474B-9DB3-AA931BC14D3C">
<div dir="auto">Dear Hendrik,
<div dir="auto"><br></div>
<div dir="auto">I remain firmly opposed to your viewpoint, and I agree with Nonhlanhla. </div>
<div dir="auto"><br></div>
<div dir="auto">Your argument establishes that a closed hierarchical namespace can prevent future creation of flat-name collisions. It does not establish that this proposal solves the broader routing-authorisation problem being used to justify mandatory policy.</div>
<div dir="auto"><br></div>
<div dir="auto">The distinction remains important. Hierarchical naming can bind the creator of an AS-SET to the maintainer of an ASN. It does not verify that the contents of the set are accurate, current, complete, or authorised by every network represented within it. A hierarchically named object can still contain stale, excessive, or incorrect members. Tools such as bgpq4 will still expand those contents.</div>
<div dir="auto"><br></div>
<div dir="auto">The proposal therefore reduces one source of ambiguity. It does not make generated prefix filters inherently trustworthy.</div>
<div dir="auto"><br></div>
<div dir="auto">That matters because the policy is being defended not merely as a naming improvement, but as a necessary routing-security protection. The claimed benefit should be described honestly and proportionately. Attribution is improved. Semantic correctness is not guaranteed. The remaining failure modes do not disappear because the namespace has been closed.</div>
<div dir="auto"><br></div>
<div dir="auto">You also describe the proposal as the minimum intervention because it applies only to new AS-SETs. Narrow scope is relevant, but it does not by itself prove necessity. A rule may be small and still place an optional operational convention into the mandatory registry layer without first demonstrating that other technical controls are inadequate.</div>
<div dir="auto"><br></div>
<div dir="auto">The alternatives are not limited to voluntary good behaviour. They include explicit IRR source qualification, provenance display, collision detection, deterministic validation, tooling that refuses ambiguous references, stronger object-level authorization signals, and local rejection of untrusted data. The relevant question is whether those mechanisms can prevent silent ambiguity without making the registry the universal enforcement point.</div>
<div dir="auto"><br></div>
<div dir="auto">If a tool silently consumes an ambiguous name across multiple IRRs, that is also a tooling and validation failure. A coordination system should not answer every unsafe consumer assumption by expanding central compulsion at the producer layer.</div>
<div dir="auto"><br></div>
<div dir="auto">You further say that the namespace must be universal because IRR data is consumed globally. Global consumption does not automatically create global authority for one preferred implementation. It creates a need for clear source semantics, local validation, and explicit compatibility rules. The Internet has always depended on operators deciding which data sources they trust and how they validate them. That responsibility should not be quietly transferred upward each time a tool can be misconfigured or over-trusting.</div>
<div dir="auto"><br></div>
<div dir="auto">The fact that other RIRs closed their namespaces remains relevant experience. It is still not proof that AFRINIC must do the same through mandatory policy, nor that their adoption eliminated the underlying problem rather than only one visible symptom.</div>
<div dir="auto"><br></div>
<div dir="auto">A registry should maintain a truthful ledger and support safe coordination. It should not claim more than the proposed mechanism can actually deliver.</div>
<div dir="auto"><br></div>
<div dir="auto">This proposal prevents future flat-name creation. It does not validate AS-SET membership, guarantee accurate prefix filters, or establish that registry compulsion is the only technically sound response.</div>
<div dir="auto"><br></div>
<div dir="auto">For those reasons, my objection remains.</div>
<div dir="auto"><br></div>
<div dir="auto">Regards,</div>
<div dir="auto">Gugu</div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Sun, 19 Jul 2026, 6:17 am Hendrik Visage 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">Dear colleagues,<br>
The point about voluntary naming is where the argument breaks down. Hierarchical naming only protects you if the namespace is closed — if flat names remain creatable, any third party can still register a name that collides with or shadows yours, and your voluntary good behaviour does nothing to stop it. That is why every other RIR made it mandatory rather than advisory: the protection is only real when it's universal. On measurable harm: tools like bgpq4 expand AS-SET names, not ASNs, so when a name is ambiguous the generated prefix-filter can silently include the wrong prefixes or drop the right ones. That is a routing outcome, not a labelling aesthetic — and it is precisely the "accurate routing information" you say the registry should support. On least-restrictive: this proposal already is the minimum — new objects only, no renaming, no other set types, no ongoing registry discretion. It is hard to describe a narrower intervention that still closes the namespace. And the point about other RIRs isn't an appeal to conformity; IRR data is consumed globally as a single namespace by operators who query multiple sources, so AFRINIC remaining the one registry that permits flat names doesn't preserve our independence — it just makes our data the weak link in everyone else's filters. Finally, responding to objections individually is engaging with them on their merits; that is what the process asks for.<br>
Regards<br>
<br>
On 18 Jul 2026, at 21:49, Nia Petronella wrote:<br>
<br>
> Dear PDWG,<br>
><br>
> I agree with Asamkele, Gugu, and Tshepo, and I remain opposed to this<br>
> proposal.<br>
><br>
> Responding to objectors one by one does not resolve the common concern they<br>
> have raised. A collision between AS-SET labels is not a failure of ASN or<br>
> prefix uniqueness, and repeating that characterization does not make it<br>
> technically correct.<br>
><br>
> The proposal still has not demonstrated measurable operational harm, why<br>
> voluntary hierarchical naming is insufficient, or why mandatory registry<br>
> intervention is the least restrictive solution. Adoption by other RIRs is<br>
> relevant, but institutional uniformity is not proof of technical necessity.<br>
><br>
> A policy process should examine objections on their merits, not treat<br>
> repeated disagreement as something to be individually overcome. The<br>
> registry should support accurate routing information without converting<br>
> every preferred convention into compulsory policy.<br>
><br>
> I therefore support the objections already raised and maintain my<br>
> opposition.<br>
><br>
> Regards,<br>
> Nonhlanhla<br>
><br>
> On Sat, 18 Jul 2026, 9:46 pm <<a href="mailto:rpd-request@afrinic.net" target="_blank" rel="noreferrer">rpd-request@afrinic.net</a>> wrote:<br>
><br>
>> Send RPD mailing list submissions to<br>
>> <a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a><br>
>><br>
>> To subscribe or unsubscribe via the World Wide Web, visit<br>
>> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
>> or, via email, send a message with subject or body 'help' to<br>
>> <a href="mailto:rpd-request@afrinic.net" target="_blank" rel="noreferrer">rpd-request@afrinic.net</a><br>
>><br>
>> You can reach the person managing the list at<br>
>> <a href="mailto:rpd-owner@afrinic.net" target="_blank" rel="noreferrer">rpd-owner@afrinic.net</a><br>
>><br>
>> When replying, please edit your Subject line so it is more specific<br>
>> than "Re: Contents of RPD digest..."<br>
>><br>
>><br>
>> Today's Topics:<br>
>><br>
>> 1. Re: [Last Call] Draft Policy Proposal - Hierarchical Names<br>
>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage)<br>
>> 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names<br>
>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Asamkele Menzeleli)<br>
>> 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names<br>
>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Gugu Dhlamini)<br>
>><br>
>><br>
>> ----------------------------------------------------------------------<br>
>><br>
>> Message: 1<br>
>> Date: Sat, 18 Jul 2026 20:28:16 +0200<br>
>> From: Hendrik Visage <<a href="mailto:hvisage@hevis.co.za" target="_blank" rel="noreferrer">hvisage@hevis.co.za</a>><br>
>> To: Asamkele Menzeleli <<a href="mailto:asamkele.menzeleli18@maharishinstitute.org" target="_blank" rel="noreferrer">asamkele.menzeleli18@maharishinstitute.org</a>><br>
>> Cc: <a href="mailto:rpd-owner@afrinic.net" target="_blank" rel="noreferrer">rpd-owner@afrinic.net</a>, <a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a><br>
>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical<br>
>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)<br>
>> Message-ID: <<a href="mailto:6F54C5B9-4C90-42F4-ACFD-6E4C57F5BD66@hevis.co.za" target="_blank" rel="noreferrer">6F54C5B9-4C90-42F4-ACFD-6E4C57F5BD66@hevis.co.za</a>><br>
>> Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
>><br>
>> Hello Asamkele,<br>
>> Respectfully, this proposal does exactly what you're asking for ? it<br>
>> maintains uniqueness. Flat AS-SET names can be registered by anyone, so<br>
>> two operators can create the same name and there is no way to tell<br>
>> afterwards which ASN it belongs to. That is a uniqueness failure in the<br>
>> registry's own data, and fixing it is squarely within the mandate you<br>
>> describe, not an expansion of it. The proposal adds no governance layer:<br>
>> it applies only to newly created AS-SETs, leaves existing objects<br>
>> untouched, and doesn't extend to route-sets or anything else. And the<br>
>> operational necessity is already demonstrated ? APNIC, RIPE, ARIN, and<br>
>> LACNIC have all implemented hierarchical AS-SET naming, which would<br>
>> leave AFRINIC as the only registry whose IRR data still permits name<br>
>> collisions.<br>
>> Regards<br>
>><br>
>> ---<br>
>> Hendrik Visage<br>
>> Director/Owner<br>
>> HeViS.Co Systems t/a Envisage Cloud Solutions<br>
>> <a href="mailto:hvisage@hevis.co.za" target="_blank" rel="noreferrer">hvisage@hevis.co.za</a><br>
>> GSM/SMS/Signal: +27-84-612-5345<br>
>> InstantMessenger: <a href="https://t.me/hvisage" rel="noreferrer noreferrer" target="_blank">https://t.me/hvisage</a><br>
>><br>
>> On 17 Jul 2026, at 19:26, Asamkele Menzeleli wrote:<br>
>><br>
>>> Hello everyone,<br>
>>><br>
>>> I object to this proposal.<br>
>>><br>
>>> I also agree with Nonhlanhla's point regarding mandate laundering. We<br>
>>> should be careful not to confuse policy development with expanding<br>
>>> institutional authority.<br>
>>><br>
>>> Policies should reflect demonstrated operational realities and<br>
>>> technical<br>
>>> necessity. They should not become governance mechanisms that gradually<br>
>>> enlarge the registry's role beyond maintaining uniqueness, accurate<br>
>>> records, and operational coordination.<br>
>>><br>
>>> A registry should record reality, not create new layers of governance<br>
>>> through policy.<br>
>>><br>
>>> Regards,<br>
>>> Asamkele Menzeleli<br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="https://lists.afrinic.net/pipermail/rpd/attachments/20260718/cd333640/attachment-0001.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20260718/cd333640/attachment-0001.html</a><br>
>>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 2<br>
>> Date: Sat, 18 Jul 2026 21:05:38 +0200<br>
>> From: Asamkele Menzeleli <<a href="mailto:asamkele.menzeleli18@maharishinstitute.org" target="_blank" rel="noreferrer">asamkele.menzeleli18@maharishinstitute.org</a>><br>
>> To: <a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a><br>
>> Cc: <a href="mailto:rpd-owner@afrinic.net" target="_blank" rel="noreferrer">rpd-owner@afrinic.net</a><br>
>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical<br>
>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)<br>
>> Message-ID:<br>
>> <CAP3o3_aaSmMp7onNPHESjeoAScNZCZbg_FFjed=<br>
>> <a href="mailto:Yxp%2BMhGJFpQ@mail.gmail.com" target="_blank" rel="noreferrer">Yxp+MhGJFpQ@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> Dear Hendrik,<br>
>><br>
>> I disagree with your characterization.<br>
>><br>
>> A collision between two AS-SET names is not the same as a failure of<br>
>> Internet number-resource uniqueness. The uniqueness function of the<br>
>> registry concerns ASNs, prefixes, proof of control and accurate<br>
>> registration of those resources. An AS-SET is an operational routing-policy<br>
>> object. Confusing the naming convention of that object with the uniqueness<br>
>> of the underlying number resource expands the meaning of ?uniqueness? far<br>
>> beyond its proper technical scope.<br>
>><br>
>> The fact that two operators may choose the same flat label may justify<br>
>> better tooling, clearer warnings, stronger validation or voluntary<br>
>> hierarchical naming. It does not automatically justify a mandatory policy<br>
>> rule.<br>
>><br>
>> That distinction is precisely the concern I raised. Institutional authority<br>
>> often expands by redefining a useful administrative preference as a<br>
>> technical necessity. Once every data-quality issue is described as a<br>
>> uniqueness failure, there is effectively no limit to what may be brought<br>
>> into mandatory registry policy.<br>
>><br>
>> The proposal?s limited scope does not answer that concern. A new<br>
>> enforcement power does not cease to be enforcement merely because it<br>
>> applies prospectively or begins with one object type. The correct test is<br>
>> whether the rule is indispensable to preserving the operation of running<br>
>> networks, and whether a less restrictive mechanism cannot achieve the same<br>
>> outcome.<br>
>><br>
>> You also repeat that the other four RIRs have implemented hierarchical<br>
>> naming. That demonstrates institutional adoption elsewhere. It does not<br>
>> demonstrate that AFRINIC operators have authorized the same rule, that<br>
>> actual routing failures in this region require it, or that voluntary and<br>
>> technical alternatives are inadequate. Four registries making the same<br>
>> choice is not a substitute for evidence.<br>
>><br>
>> A registry should record operational reality accurately and provide<br>
>> operators with tools to manage routing information safely. It should not<br>
>> turn every preferred convention into mandatory governance merely because<br>
>> uniformity looks tidy from the registry side.<br>
>><br>
>> My objection therefore remains. The proposal has not shown that compulsory<br>
>> hierarchical naming is necessary to protect number-resource uniqueness, nor<br>
>> that the registry should extend its mandatory policy authority into this<br>
>> area.<br>
>><br>
>> Regards,<br>
>> Asamkele Menzeleli<br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="https://lists.afrinic.net/pipermail/rpd/attachments/20260718/e46cf6c9/attachment-0001.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20260718/e46cf6c9/attachment-0001.html</a><br>
>>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 3<br>
>> Date: Sat, 18 Jul 2026 21:45:03 +0200<br>
>> From: Gugu Dhlamini <<a href="mailto:gugudhlamini343@gmail.com" target="_blank" rel="noreferrer">gugudhlamini343@gmail.com</a>><br>
>> To: "<a href="mailto:asamkele.menzeleli18@maharishinstitute.org" target="_blank" rel="noreferrer">asamkele.menzeleli18@maharishinstitute.org</a>"<br>
>> <<a href="mailto:asamkele.menzeleli18@maharishinstitute.org" target="_blank" rel="noreferrer">asamkele.menzeleli18@maharishinstitute.org</a>>, "<br>
>> <a href="mailto:hvisage@hevis.co.za" target="_blank" rel="noreferrer">hvisage@hevis.co.za</a>"<br>
>> <<a href="mailto:hvisage@hevis.co.za" target="_blank" rel="noreferrer">hvisage@hevis.co.za</a>>, <a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>, <a href="mailto:rpd-owner@afrinic.net" target="_blank" rel="noreferrer">rpd-owner@afrinic.net</a><br>
>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical<br>
>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)<br>
>> Message-ID:<br>
>> <<br>
>> <a href="mailto:CADMrvbPw1Dyu7JU9unFWz4zTZSd4QGQdMup_ibDd9nKcWwuP-w@mail.gmail.com" target="_blank" rel="noreferrer">CADMrvbPw1Dyu7JU9unFWz4zTZSd4QGQdMup_ibDd9nKcWwuP-w@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> Dear PDWG,<br>
>><br>
>> I agree with Asamkele and disagree with Hendrik?s perspective.<br>
>><br>
>> This is substantially the same argument Hendrik made in response to Tshepo:<br>
>> that because a naming collision can occur, the issue must therefore be<br>
>> treated as a failure of registry uniqueness and made subject to mandatory<br>
>> policy. That conclusion does not follow.<br>
>><br>
>> A collision between AS-SET labels is not the same as duplicate allocation<br>
>> of an ASN or IP prefix. The underlying number resources remain unique. What<br>
>> is being discussed is the naming and interpretation of an operational<br>
>> routing object. That may justify better tools, warnings, validation,<br>
>> documentation, or voluntary hierarchical naming, but it does not<br>
>> automatically justify expanding mandatory registry authority.<br>
>><br>
>> There is also an important ethical question here. Policy power should not<br>
>> be enlarged merely because the proposed requirement appears useful, tidy,<br>
>> or widely adopted elsewhere. The burden lies with those seeking compulsion<br>
>> to show actual harm, necessity, proportionality, and the failure of less<br>
>> restrictive alternatives. Operators should not be forced to surrender<br>
>> discretion simply because an institution prefers uniformity.<br>
>><br>
>> The fact that four other RIRs adopted a similar convention is not proof<br>
>> that AFRINIC must do the same. Institutional repetition is not technical<br>
>> necessity, and participation in the PDWG should not become a ritual for<br>
>> ratifying choices already made elsewhere.<br>
>><br>
>> The registry should preserve number-resource uniqueness, registry accuracy,<br>
>> and operational continuity. It should not stretch those concepts until<br>
>> every preferred operational convention becomes mandatory policy.<br>
>><br>
>> For these reasons, I support Asamkele?s objection and remain opposed to the<br>
>> proposal.<br>
>><br>
>> Regards,<br>
>> Nonhlanhla<br>
>> On Sat, 18 Jul 2026, 9:08 pm Asamkele Menzeleli <<br>
>> <a href="mailto:asamkele.menzeleli18@maharishinstitute.org" target="_blank" rel="noreferrer">asamkele.menzeleli18@maharishinstitute.org</a>> wrote:<br>
>><br>
>>> Dear Hendrik,<br>
>>><br>
>>> I disagree with your characterization.<br>
>>><br>
>>> A collision between two AS-SET names is not the same as a failure of<br>
>>> Internet number-resource uniqueness. The uniqueness function of the<br>
>>> registry concerns ASNs, prefixes, proof of control and accurate<br>
>>> registration of those resources. An AS-SET is an operational<br>
>> routing-policy<br>
>>> object. Confusing the naming convention of that object with the<br>
>> uniqueness<br>
>>> of the underlying number resource expands the meaning of ?uniqueness? far<br>
>>> beyond its proper technical scope.<br>
>>><br>
>>> The fact that two operators may choose the same flat label may justify<br>
>>> better tooling, clearer warnings, stronger validation or voluntary<br>
>>> hierarchical naming. It does not automatically justify a mandatory policy<br>
>>> rule.<br>
>>><br>
>>> That distinction is precisely the concern I raised. Institutional<br>
>>> authority often expands by redefining a useful administrative preference<br>
>> as<br>
>>> a technical necessity. Once every data-quality issue is described as a<br>
>>> uniqueness failure, there is effectively no limit to what may be brought<br>
>>> into mandatory registry policy.<br>
>>><br>
>>> The proposal?s limited scope does not answer that concern. A new<br>
>>> enforcement power does not cease to be enforcement merely because it<br>
>>> applies prospectively or begins with one object type. The correct test is<br>
>>> whether the rule is indispensable to preserving the operation of running<br>
>>> networks, and whether a less restrictive mechanism cannot achieve the<br>
>> same<br>
>>> outcome.<br>
>>><br>
>>> You also repeat that the other four RIRs have implemented hierarchical<br>
>>> naming. That demonstrates institutional adoption elsewhere. It does not<br>
>>> demonstrate that AFRINIC operators have authorized the same rule, that<br>
>>> actual routing failures in this region require it, or that voluntary and<br>
>>> technical alternatives are inadequate. Four registries making the same<br>
>>> choice is not a substitute for evidence.<br>
>>><br>
>>> A registry should record operational reality accurately and provide<br>
>>> operators with tools to manage routing information safely. It should not<br>
>>> turn every preferred convention into mandatory governance merely because<br>
>>> uniformity looks tidy from the registry side.<br>
>>><br>
>>> My objection therefore remains. The proposal has not shown that<br>
>> compulsory<br>
>>> hierarchical naming is necessary to protect number-resource uniqueness,<br>
>> nor<br>
>>> that the registry should extend its mandatory policy authority into this<br>
>>> area.<br>
>>><br>
>>> Regards,<br>
>>> Asamkele Menzeleli<br>
>>> _______________________________________________<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>
>>><br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="https://lists.afrinic.net/pipermail/rpd/attachments/20260718/7d3628bc/attachment.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20260718/7d3628bc/attachment.html</a><br>
>>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Subject: Digest Footer<br>
>><br>
>> _______________________________________________<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>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> End of RPD Digest, Vol 222, Issue 45<br>
>> ************************************<br>
>><br>
<br>
> _______________________________________________<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>
<br>
<br>
_______________________________________________<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></div></blockquote>
<div class="markdown" style="white-space: normal;">
</div>
</div>
</body>
</html>