<!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">Good day Tshepo, Nonjabulo, Phetulo, Taye, Thulisile, colleagues,</p>
<p dir="auto">Apologies to the human readers for this voluminous post, but I’d<br>
rather address as much in one email than to flood the mailing list<br>
With even more messages as I’d rather do a digest type response for<br>
all the similar objections at once.</p>
<p dir="auto">For nearly two weeks we have been asking for technical substance;<br>
today, in the week Last Call closes, technical reasons have at last<br>
been presented. Before I respond to them, let me add a seventh<br>
question to the six of 23 July (015344):</p>
<p dir="auto">Question 7: could you please provide the technical issues,<br>
difficulties, and real-world examples where implementation of this<br>
draft policy - as three RIRs have already implemented it, and the<br>
fourth is formally proposing - would negatively affect your current<br>
or future operations? We would like to understand those too.<br>
Operational evidence of that kind would genuinely add to the body<br>
of knowledge on this proposal.</p>
<p dir="auto">Note: numbers like (015344) are message IDs in the RPD archive -<br>
prepend <a href="https://lists.afrinic.net/pipermail/rpd/2026/" style="color: #3983C4;">https://lists.afrinic.net/pipermail/rpd/2026/</a> and append<br>
.html to read any of them.</p>
<p dir="auto">So let's get to the objections we have been waiting two weeks for:</p>
<ol>
<li>object lifecycle under changes of ASN control (015387,<br>
escalated in 015391 and 015400) - answered by Jaco in (015388)<br>
and (015394)</li>
</ol>
<p dir="auto">1b) its delegated-maintainer extension (015398, pressed again in<br>
015400) - Jaco deferred to the RFC in (015399); the deferral is<br>
completed in section 1 below<br>
2) recursive expansion of members: references (015389) - answered<br>
in (015390)<br>
3) grandfathered flat objects (015392) - answered in (015395)<br>
4) multi-source name resolution (015393) - answered in (015396,<br>
015397)<br>
5) anchor-ASN eligibility and authentication (015401) - addressed<br>
in section 5 below<br>
6) implementation rollout process (015402) - addressed in section 6<br>
below; its delegation and 7.8.7 points are answered in section 1<br>
(the delegation question is 015398/015400 returning), and its<br>
benefit-scope point in the common ground just below</p>
<p dir="auto">I refer to and endorse Jaco's answers rather than repeat them. It<br>
was asked earlier in this Last Call that objections be addressed as<br>
grouped issues rather than piecemeal, and in that spirit I have<br>
collated the responses in a single email, adding what has not yet<br>
been shared: a precise statement of the authorisation model, the<br>
published data, and the cross-registry record.</p>
<p dir="auto">First, the common ground, because it is substantial. In today's own<br>
words:</p>
<ul>
<li>hierarchical naming "can strengthen creation authorisation" (015393)</li>
<li>the proposal "secures the first object name" (015389)</li>
<li>the concerns are "not questions about whether AS-SET membership<br>
is correct" (015387)</li>
<li>ASN-anchored naming "can reduce future flat-name collisions"<br>
(015402)</li>
</ul>
<p dir="auto">None of today's messages disputes what the proposal does. Each of<br>
today's objections asks it to also solve an adjacent problem -</p>
<ul>
<li>lifecycle</li>
<li>delegation semantics</li>
<li>expansion semantics</li>
<li>legacy objects</li>
<li>mirror copies</li>
<li>anchor eligibility</li>
</ul>
<ul>
<li>and every one of those problems exists today, everywhere, with or</li>
</ul>
<p dir="auto">without this policy. That is not the discovery of a defect. It is<br>
the discovery that the proposal has a scope, which it states and<br>
which was put on this record weeks ago (015119, 015120, 015123; and<br>
the draft's own sections 7.8.3-7.8.6).</p>
<ol>
<li>The authorisation model, changes of ASN control, and delegation<br>
(015387, 015391, 015398, 015400, 015402)</li>
</ol>
<p dir="auto">Jaco deferred to the RFC on the depth mechanics (015399). Rightly<br>
so - the RFC, followed to the top of the chain, completes his<br>
answer. (015398) states the rule correctly: a first-level object,<br>
AS12345:AS-CUSTOMERS, is created under the authorisation of the<br>
aut-num AS12345 as it stands at that moment - its maintainer chain,<br>
which follows the current registered holder. A deeper object,<br>
AS12345:AS-CUSTOMERS:AS-EU, is created under the authorisation of<br>
the maintainer of its immediate parent. Now ask where that parent<br>
came from: its own creation was authorised by the level above it,<br>
and so on, terminating at the aut-num itself. Every object in the<br>
tree exists because the level above authorised its creation.<br>
Delegation, where it exists, exists because the chain authorised<br>
it. And who controls each level is answerable, level by level, from<br>
the database as it stands - which is what verifiable control looks<br>
like in RPSL.</p>
<p dir="auto">The emphatic difference at the current state is that a flat name<br>
offers just a maintainer but no chain: no root, and no way to ask<br>
whether the name was ever anyone's to create - beyond that it must<br>
not already exist in THIS one database.</p>
<p dir="auto">(015400) concludes that because deeper control can be delegated,<br>
the "control model remains unspecified". The opposite is the case:<br>
the control model is fully specified - in the very RFC that<br>
(015398) cited, which is why deferring to it was the right answer.<br>
That deeper authority is delegated, and that delegated authority<br>
does not automatically follow the ASN, is not a gap in the model;<br>
it is the model, working as designed for twenty-seven years, for<br>
every hierarchical object family, at every RPSL-based registry. A<br>
policy does not "leave AFRINIC to interpret" what the RFC and the<br>
production database already define - any more than this proposal<br>
needs to restate what mnt-by means. What deterministically follows<br>
the ASN is the root of every chain: authority over creation and<br>
recreation at the first level of the namespace. That is precisely</p>
<ul>
<li>and only - what the proposal's attribution claim covers. The same</li>
</ul>
<p dir="auto">depth question returns in (015402); the answer above stands.</p>
<p dir="auto">These semantics are not invented by this proposal. They are RFC<br>
2622 (1999), operated by RPSL-based registries - AFRINIC's included</p>
<ul>
<li>for twenty-seven years. The proposal does not modify them; it</li>
</ul>
<p dir="auto">gates which names may come into existence, nothing else. The two<br>
outcomes (015398) poses are therefore both answered by the<br>
semantics already in production: descendants do not move<br>
automatically, so no delegated maintainer is overridden - exactly<br>
as for every delegated object today. And the new holder gains<br>
precisely what the name anchors: authority over creation and<br>
recreation at the first level of its namespace. What the new holder<br>
does not get - control over objects a previous holder's delegates<br>
still maintain - is what nobody has today under flat names, for any<br>
object, ever. A stale delegated descendant is today's universal<br>
condition; the proposal neither creates nor worsens it, and no<br>
registry in those twenty-seven years has defined the demanded<br>
delegation-and-revocation regime for set objects in policy.</p>
<p dir="auto">How ASN control actually changes in this region is likewise not a<br>
matter for speculation. AFRINIC publishes it:</p>
<p dir="auto"><a href="https://ftp.afrinic.net/pub/stats/afrinic/transfers/transfers_latest.json" style="color: #3983C4;">https://ftp.afrinic.net/pub/stats/afrinic/transfers/transfers_latest.json</a></p>
<p dir="auto">A full read of that file today: 75 ASN-carrying transfer events (91<br>
ASNs) from 2018 through 2026 - about nine such events a year - and<br>
every single one is a merger/acquisition succession, in which the<br>
organisation and its maintainer control pass together, so parent<br>
ASN and child objects move as one unit. That is the published<br>
record behind Jaco's description in (015394), with the frequency<br>
question answered exactly: none open-market, all successions that<br>
preserve the attribution chain by construction. Anyone can verify<br>
this from the file. So the concern of (015391) has been addressed -<br>
with our registry's own data.</p>
<p dir="auto">The cross-registry record answers the rest. I checked this week,<br>
across the policy, procedural and database-documentation layers of<br>
the other four RIRs. RIPE has required hierarchical names for new<br>
as-sets since December 2022 and operates full ASN transfers,<br>
including inter-RIR; APNIC likewise since July 2023 (prop-151);<br>
LACNIC's IRR has been structurally hierarchical since it launched<br>
in 2020; at ARIN hierarchical naming is available today and a<br>
mandate for new objects is formally proposed (ARIN-prop-342,<br>
pending) - the same direction. All four are silent on child as-set<br>
lifecycle at every layer. Across the deployed implementations that<br>
is roughly three and a half years of exactly the coexistence<br>
(015387) warns about - hierarchical mandates running over live ASN<br>
transfer markets - and I could not find one documented incident of<br>
the failure mode described. In every deployed implementation,<br>
lifecycle lives where it belongs: in standard RPSL authorisation<br>
and registry operations, not in naming-policy text.</p>
<p dir="auto">On 7.8.7 (015391, 015402): today the namespace has no rule at all -<br>
every creation, by anyone, of any name, is the exception. A closed<br>
default with documented-reason exceptions cannot be less<br>
deterministic than no default whatsoever. And credit where due:<br>
(015402) makes one point that verifies - the staff assessment's<br>
prose cites "7.8.6" for the restoration-of-deleted-objects<br>
exception, where 7.8.6 concerns editing and the exception clause is<br>
in fact 7.8.7. That is a cross-reference slip in the assessment's<br>
commentary, worth an erratum, and it changes nothing in the policy<br>
text: the clauses say what they say, and staff's own recorded<br>
caution about recall loopholes shows the right mechanism was<br>
analysed. As for the demanded exception criteria: 7.8.7 requires<br>
every exception to be documented with its reason - a discipline<br>
stricter than today, where no creation needs any reason at all.</p>
<ol start="2">
<li>Recursive expansion of members: references (015389)</li>
</ol>
<p dir="auto">Correct as far as it goes - and it concedes the top level is<br>
secured. What members: may contain is a content question, expressly<br>
outside this proposal's scope, and outside the naming policies of<br>
every registry that already runs this rule: none coupled naming to<br>
expansion semantics, because that coupling is a different and<br>
larger policy. Jaco has already named the constructive path<br>
(015390): a members-qualification rule would be a coherent separate<br>
proposal, and wording was invited. Meanwhile every new hierarchical<br>
set is one fewer ambiguous reference for the next expansion to fear</p>
<ul>
<li>the gap this concern describes narrows with adoption and stays</li>
</ul>
<p dir="auto">open without it.</p>
<ol start="3">
<li>Grandfathered flat objects and the transition window (015392)</li>
</ol>
<p dir="auto">The capability described - register flat names now, populate them<br>
later - exists today, permanently, with or without this proposal.<br>
Anyone may do it this afternoon. The proposal is the only mechanism<br>
before this Working Group that ever closes that window; declining<br>
it preserves the window forever. If gaming of the implementation<br>
gap is the genuine worry, the remedy is a short implementation<br>
period - a staff scheduling matter - not an indefinitely open<br>
namespace. And, respectfully: (015392) describes with precision the<br>
squatting behaviour whose future possibility this policy exists to<br>
end. An objection that demonstrates the attack is an argument for<br>
closing the door.</p>
<ol start="4">
<li>Multi-source resolution (015393)</li>
</ol>
<p dir="auto">Jaco's answer (015396, 015397) is complete: an ASN is delegated by<br>
exactly one registry, so a hierarchical name carries its<br>
authoritative source in its own first element. The question "which<br>
source is authoritative for this set?" has a deterministic answer<br>
precisely and only when the name is hierarchical; under a flat name<br>
that answer does not exist anywhere. The working-group draft cited<br>
in (015393) pursues the same determinism through source-qualified<br>
references - the two mechanisms are complements, not conflicts, and<br>
that draft's problem statement describes the flat-name condition<br>
this proposal removes for new AFRINIC sets. What a third-party<br>
mirror carries is today's condition for every object in every IRR<br>
database and is governed by no naming policy at any registry.</p>
<ol start="5">
<li>Anchor-ASN eligibility and authentication (015401)</li>
</ol>
<p dir="auto">Taye, this is the kind of message Last Call is for: specific,<br>
technical, and naming the exact requirements it wants. Three<br>
responses.</p>
<p dir="auto">First, on substance: the properties you list - the leading ASN<br>
globally assigned, an authoritative aut-num present, creation<br>
authenticated against that object's maintainer, private-use and<br>
reserved ranges (RFC 6996) excluded, canonical ASPLAIN form (RFC<br>
5396) - are, I would argue, what the Impact Assessment's own<br>
authorisation claim already entails. An anchor with no holder can<br>
authorise no one; a check that can pass in the absence of the<br>
aut-num it authenticates against would not be the check the<br>
assessment describes. So I read your list not as a new mechanism<br>
but as the strict, and correct, reading of the mechanism the<br>
proposal already claims.</p>
<p dir="auto">Second, on where it belongs: those are implementation semantics -<br>
the authentication mode of the database software and the eligible<br>
ASN ranges - and I would support AFRINIC staff recording exactly<br>
your list in the implementation guidance for this policy, alongside<br>
the failure behaviour per creation path. That is the normal home of<br>
such requirements at every registry, and section 7.8.7's<br>
documented-exception mechanism gives staff the instrument for any<br>
edge the guidance must handle. It is worth adding: even in the<br>
weakest imaginable configuration, an unattributable<br>
hierarchical-form name is no worse than today, where every name of<br>
any form requires no authorisation from anyone.</p>
<p dir="auto">Third, on form: yours is the closest any message in this Last Call<br>
has come to proposed text. If you formalise that list as wording -<br>
whether as implementation guidance or as a clarification for a<br>
future revision - I have no doubt this Working Group will engage it<br>
on its merits, exactly as was invited days ago (015390). It is the<br>
constructive instrument the process recognises.</p>
<ol start="6">
<li>Implementation rollout process (015402)</li>
</ol>
<p dir="auto">Warning-only phases, test vectors, baselines, rollback plans and<br>
scheduled reviews are implementation artifacts. They are produced<br>
by registry staff during implementation - at every RIR - and they<br>
appear in no naming policy anywhere: RIPE shipped its hierarchical<br>
requirement through the database release process, with release<br>
notes and a release-candidate test environment, on the strength of<br>
a policy text that contains none of those artifacts. Nothing in<br>
this proposal forbids a staged, warning-first deployment; that is<br>
exactly the kind of detail the implementation phase exists to<br>
define, and 7.8.7's documented-exception mechanism gives staff the<br>
instrument for edge handling during it. Taken at face value,<br>
(015402)'s final section is an argument about deployment<br>
scheduling, which follows ratification - not a reason to withhold<br>
it.</p>
<p dir="auto">Stepping back, twice.</p>
<p dir="auto">Each of the demands in messages (015387), (015389), (015391),<br>
(015392), (015393), (015398), (015400) and (015402) carries the same<br>
condition: "before adoption" (015387, 015389, 015391), "before<br>
mandatory enforcement" (015393), "before this proceeds" (015398),<br>
"until ... addressed" (015392), "until that is clarified" (015400),<br>
"until ... clearly resolved" (015402).<br>
As Seun reminded the list (015386), this PDP has no conditional<br>
adoption: a proposal cannot pass Last Call subject to future<br>
homework. At day eleven of Last Call, "resolve and test before<br>
advancing" therefore spells "do not adopt". The process has exactly<br>
one instrument for a genuine, fixable concern: proposed text. Jaco<br>
invited it (015390).</p>
<p dir="auto">Let me emphasise the arithmetic: seven distinct technical concerns<br>
in a single day, after eleven days without one - and, section 5's requirements<br>
list aside, still zero proposed amendments. Of the six questions of<br>
23 July (015344), exactly one account engaged them point by point -<br>
Tshepo, in (015348) - and the record should credit those answers.<br>
In short:</p>
<ol>
<li>Two-object case: tooling should bind to an explicitly selected<br>
source or stop and report - the fail-closed behaviour supporters<br>
had proposed; the live case itself stays unresolved either way,<br>
the rule being prospective.</li>
<li>Squatting remedy: none - the victim is left to another<br>
database's dispute or abuse process.</li>
<li>Is it an improvement? "Yes, narrowly."</li>
<li>Evidence bar: a four-part test - whose second criterion, that<br>
the proposal "would have prevented" the incident, excludes by<br>
construction every incident that already exists; a creation-time<br>
rule is prospective by definition.</li>
<li>Impact Assessment: "I do not dispute the findings"; the<br>
objection shifts to what the IA does not cover.</li>
<li>Capacity: individual, representing no organisation or resource<br>
member.</li>
</ol>
<p dir="auto">No other opposing account has answered any of the six. Today the<br>
bar has moved with nearly every message, and a seventh question now<br>
joins the list. My assessment, for the record:<br>
none of today's objections identifies a defect in what the proposal<br>
claims; and their cumulative effect, whatever the intent, has been<br>
to consume the finite attention of this Working Group - a cost<br>
long-standing participants have already described in their own<br>
words (015154, 015179).</p>
<p dir="auto">One further observation, offered for the record and without<br>
attributing it to any individual: this Last Call's objections began<br>
from the principle that the registry "may record... It may not<br>
rule" (015011). Today's objections ask the registry to pre-define<br>
delegation graphs, revocation processes, state machines, permanent<br>
reservations, transition audits and source-selection rules, in<br>
advance (015391, 015392, 015393, 015398, 015400, 015402). Those two<br>
standards pull in opposite directions, and the same seven-clause<br>
creation-time rule cannot be faulted under both at once. Which<br>
standard the Working Group actually holds is exactly what the<br>
Co-Chairs will weigh - against what the proposal actually claims: a<br>
creation-time naming rule, whose every stated boundary today's<br>
objection messages ask it to exceed.</p>
<p dir="auto">The community is entitled to expect Last Call to close on schedule<br>
and to be assessed on the record as it stands.</p>
<p dir="auto">Regards,<br>
Hendrik Visage (AS329532; also AS213481)</p>
</div>
</div>
</body>
</html>