<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Hendrik,</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I assume your comment was referring to the hierarchical AS-SET names with say three elements?</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
> Eg, ASyyyy:ASxxxx:AS-set</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
It's valid syntax as per the RFC so I think that should be the reason it is supported (originally I misread what Jaco meant, I see now he's just referring to some valid syntax).</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
It's usage is very rare (circa 2,92% of AS-SETs, see below), but because it's valid syntax I think it must be supported, not because of "gut feelings" about widely this feature is used..</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
-----</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Downloaded AS-SET data from the 5 RIRs plus RADB:</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
$ ls</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
afrinic.db apnic.db.as-set arin.db lacnic.db radb.db ripe.db.as-set</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
53.6k unique AS-SETs:</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
$ grep -E "^as-set: " * | awk '{print $NF}' | sort | uniq | wc -l</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
53674</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Just 1571 with three colons in them:</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
$ grep -E "^as-set: " * | awk '{print $NF}' | sort | uniq | grep -E ".*:.*:.*" | uniq | wc -l</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
1571</div>
<div id="Signature" class="elementToProof">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
And those belong to a total of 72 (!!) networks of all networks in the 5 RIRs + RADB:</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
$ grep -E "^as-set: " * | awk '{print $NF}' | sort | uniq | grep -E ".*:.*:.*" | awk -F ":" '{print $1}' | uniq | wc -l</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
72</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
With kind regards,</div>
<div class="elementToProof" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
James Bensley (he/him)</div>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Hendrik Visage <hvisage@hevis.co.za><br>
<b>Sent:</b> 28 May 2026 11:32<br>
<b>To:</b> Jaco Kroon <jaco@uls.co.za><br>
<b>Cc:</b> James Bensley <james@inter.link>; dacostadarwin@gmail.com <dacostadarwin@gmail.com>; rpd@afrinic.net <rpd@afrinic.net><br>
<b>Subject:</b> Re: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01.</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">⚠️ Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe.<br>
<br>
Organisation with network/ISP and separate hosting division<br>
Not that uncommon<br>
<br>
Sent from my mobile device<br>
<br>
> On 28 May 2026, at 10:14, Jaco Kroon <jaco@uls.co.za> wrote:<br>
><br>
> Hi James,<br>
><br>
>> On 2026/05/28 09:54, James Bensley wrote:<br>
>><br>
>> Hi Jaco,<br>
>><br>
>> Thank you for the support and your feedback.<br>
>><br>
>> I wrote the original proposal. Regarding this comment:<br>
>><br>
>> "The only thing that I found weird is that the second element has to be a name, why would "ASnum:ASnum2:AS-name" not be acceptable?"<br>
>><br>
>> If you have a use case for that, then that could be added to the proposal. Do you have a use case/requirement for this? I think this usage is very rare, but if you have this use case, please speak up :)<br>
><br>
> It's a hierarchy right, so what if I want to refer my customers by their AS numbers?<br>
><br>
> Eg, ASyyyy:ASxxxx:AS-set<br>
><br>
> It's an arbitrary and in my opinion unneeded restriction which can be removed. The only restriction is that the first component has to be ASnum where you have control over AS num. The rest can be left to the discretion of the ASnum admin surely?<br>
><br>
> So just drop bullet three entirely.<br>
><br>
>><br>
>><br>
>> Regarding this comment:<br>
>><br>
>> "The purpose/function of "3. Other set types such as route sets are excluded." is unclear - everything else speaks specifically to AS-SET so why is this mention required?"<br>
>><br>
>> Because route-sets can also support hierarchical names and in the past people have had the thought "well if we're making this change for AS-SETs let's also making it for Route-Sets whilst we're here" - but route-sets are extremely rarely used today and this
just adds scope which I think isn't needed. So it was just about trying to stop that scope creep.<br>
><br>
> I hear you.<br>
><br>
> 7.8 as as whole specifically states "AS-SET" - not "Set Types", and point 1 also makes it clears this refers specifically to AS-SET, which means point 3 can be dropped without changing the intent/meaning of 7.8 as a whole.<br>
><br>
> Point 4 also really adds no value, that's an operational issue, not a policy issue. Definitely a valid point and something to be aware but still operational, not policy.<br>
><br>
> Exceptions to the policy may need to be permitted on a case by case basis *if and only if* a non-hierarchical AS-SET has been accidentally deleted to allow recreation. IMHO these should require motivation to have them restored from where they can then be
edited again as per point 6.<br>
><br>
> Kind regards,<br>
> Jaco<br>
><br>
>><br>
>> With kind regards,<br>
>> James Bensley (he/him)<br>
>><br>
>> ________________________________________<br>
>> From: Jaco Kroon <jaco@uls.co.za><br>
>> Sent: 21 May 2026 14:06<br>
>> To: dacostadarwin@gmail.com <dacostadarwin@gmail.com>; rpd@afrinic.net <rpd@afrinic.net><br>
>> Subject: Re: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01.<br>
>><br>
>> Hi,<br>
>><br>
>> Definitely in support.<br>
>><br>
>> The only thing that I found weird is that the second element has to be a<br>
>> name, why would "ASnum:ASnum2:AS-name" not be acceptable?<br>
>><br>
>> The purpose/function of "3. Other set types such as route sets are<br>
>> excluded." is unclear - everything else speaks specifically to AS-SET so<br>
>> why is this mention required?<br>
>><br>
>> Kind regards,<br>
>> Jaco<br>
>><br>
>>> On 2026/05/20 19:37, dacostadarwin@gmail.com wrote:<br>
>>><br>
>>> Dear PDWG,<br>
>>><br>
>>> We have received a new draft policy proposal - Require newly created AS-SETs to have hierarchical names, ID AFPUB-2026-ASN-001-DRAFT01 from author James Bensley.<br>
>>><br>
>>> The proposal contents are published at:<br>
>>> <a href="https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft01">https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft01</a><br>
>>><br>
>>> We encourage you to take some time to go through the proposal contents and provide feedback as follows:<br>
>>><br>
>>> a) Do you support or oppose the proposal?<br>
>>><br>
>>> b) If you oppose the proposal, state your reasons?<br>
>>><br>
>>> c) Is there anything in the proposal that is not clear?<br>
>>><br>
>>> d) What changes could be made to this proposal to make it more effective?<br>
>>><br>
>>> Regards,<br>
>>> Vincent Ngundi & Darwin Da Costa<br>
>>> AFRINIC PDWG Co-Chairs<br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> RPD mailing list<br>
>>> RPD@afrinic.net<br>
>>> <a href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
>> _______________________________________________<br>
>> RPD mailing list<br>
>> RPD@afrinic.net<br>
>> <a href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
>> [CompanySignature]<br>
>> Inter..link GmbH | Boxhagener Straße 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello@inter.link<<a href="mailto:hello@inter.link">mailto:hello@inter.link</a>>
| Web: inter.link<<a href="https://inter.link">https://inter.link</a>><br>
><br>
> _______________________________________________<br>
> RPD mailing list<br>
> RPD@afrinic.net<br>
> <a href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
---<br>
<br>
Hendrik Visage<br>
<br>
hvisage@hevis.co.za<br>
<br>
<br>
HeViS.Co Systems Pty Ltd<br>
<br>
<a href="https://www.envisage.co.za">https://www.envisage.co.za</a><br>
<br>
<br>
<br>
<br>
</div>
</span></font></div>
</body>
</html>