<div dir="ltr"><div><span style="background-color:transparent">Dear PDWG,</span></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p style="font-size:small">I have a separate concern regarding the ASN used as the hierarchical anchor.<br><br>The proposal assumes that placing an ASN at the beginning of an AS-SET name makes the object globally unique and attributable to a specific resource holder. However, the proposed text only requires the first element to “consist of an ASN.” It does not expressly require that ASN to be globally assigned, present in the authoritative AFRINIC database, or successfully authenticated at creation.<br><br>That distinction matters because not every syntactically valid ASN identifies a unique operator. Private-use ASNs are deliberately not globally unique. Special-purpose, documentation, reserved, and unallocated ASNs likewise do not provide the holder attribution on which the proposal’s justification depends. RFC 6996, for example, reserves AS64512–AS65534 and AS4200000000–AS4294967294 for private use. <br><br>The policy should therefore state explicitly that: the leading ASN must be a globally assigned ASN with an authoritative aut-num object in the AFRINIC database; creation must successfully authenticate against that object’s authorised maintainer; private-use, reserved, documentation-only, special-purpose, and unallocated ASNs must not be accepted as namespace anchors; and the ASN must use the canonical ASPLAIN representation defined by RFC 5396. <br><br>This cannot safely be left to unspecified implementation behaviour. IRRd supports different authentication modes, including an opportunistic mode under which the check may pass when the corresponding aut-num object does not exist. The Impact Assessment does not identify which mode AFRINIC will use or define the required failure behaviour across WHOIS, MyAFRINIC, and API creation paths. <br><br>Without these safeguards, an AS-SET may satisfy the proposed naming syntax while failing the very uniqueness and proof-of-control properties used to justify the policy.<br><br>I therefore object to the proposal as currently written, and request that the ASN eligibility and authentication requirements be made deterministic before the proposal advances.<br><br>Regards,<br>Taye.<b><font face="times new roman, serif"></font></b></p><p style="font-size:small"><br></p><p style="font-size:small"><b><font face="times new roman, serif"><br></font></b></p><p style="font-size:small"><b><font face="times new roman, serif"><br></font></b></p><p style="font-size:small"><br></p><p style="font-size:small"><span style="font-family:"arial narrow",sans-serif"><span style="font-size:12.8px">                                        </span></span></p><p style="font-size:small"><b><br></b></p><p style="font-size:small"><br><br><br></p></div></div></div></div></div></div></div></div></div></div></div></div></div>