[rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)

[hvisage at hevis.co.za]

Good day Tshepo, Nonjabulo, Phetulo, Taye, Thulisile, colleagues,

 Apologies to the human readers for this voluminous post, but I’d
rather address as much in one email than to flood the mailing list
With even more messages as I’d rather do a digest type response for
all the similar objections at once.

For nearly two weeks we have been asking for technical substance;
today, in the week Last Call closes, technical reasons have at last
been presented. Before I respond to them, let me add a seventh
question to the six of 23 July (015344):

Question 7: could you please provide the technical issues,
difficulties, and real-world examples where implementation of this
draft policy - as three RIRs have already implemented it, and the
fourth is formally proposing - would negatively affect your current
or future operations? We would like to understand those too.
Operational evidence of that kind would genuinely add to the body
of knowledge on this proposal.

Note: numbers like (015344) are message IDs in the RPD archive -
prepend https://lists.afrinic.net/pipermail/rpd/2026/ and append
.html to read any of them.

So let's get to the objections we have been waiting two weeks for:

1)  object lifecycle under changes of ASN control (015387,
    escalated in 015391 and 015400) - answered by Jaco in (015388)
    and (015394)
1b) its delegated-maintainer extension (015398, pressed again in
    015400) - Jaco deferred to the RFC in (015399); the deferral is
    completed in section 1 below
2)  recursive expansion of members: references (015389) - answered
    in (015390)
3)  grandfathered flat objects (015392) - answered in (015395)
4)  multi-source name resolution (015393) - answered in (015396,
    015397)
5)  anchor-ASN eligibility and authentication (015401) - addressed
    in section 5 below
6)  implementation rollout process (015402) - addressed in section 6
    below; its delegation and 7.8.7 points are answered in section 1
    (the delegation question is 015398/015400 returning), and its
    benefit-scope point in the common ground just below

I refer to and endorse Jaco's answers rather than repeat them. It
was asked earlier in this Last Call that objections be addressed as
grouped issues rather than piecemeal, and in that spirit I have
collated the responses in a single email, adding what has not yet
been shared: a precise statement of the authorisation model, the
published data, and the cross-registry record.

First, the common ground, because it is substantial. In today's own
words:
- hierarchical naming "can strengthen creation authorisation" (015393)
- the proposal "secures the first object name" (015389)
- the concerns are "not questions about whether AS-SET membership
  is correct" (015387)
- ASN-anchored naming "can reduce future flat-name collisions"
  (015402)
None of today's messages disputes what the proposal does. Each of
today's objections asks it to also solve an adjacent problem -
 * lifecycle
 * delegation semantics
 * expansion semantics
 * legacy objects
 * mirror copies
 * anchor eligibility
- and every one of those problems exists today, everywhere, with or
without this policy. That is not the discovery of a defect. It is
the discovery that the proposal has a scope, which it states and
which was put on this record weeks ago (015119, 015120, 015123; and
the draft's own sections 7.8.3-7.8.6).

1. The authorisation model, changes of ASN control, and delegation
   (015387, 015391, 015398, 015400, 015402)

Jaco deferred to the RFC on the depth mechanics (015399). Rightly
so - the RFC, followed to the top of the chain, completes his
answer. (015398) states the rule correctly: a first-level object,
AS12345:AS-CUSTOMERS, is created under the authorisation of the
aut-num AS12345 as it stands at that moment - its maintainer chain,
which follows the current registered holder. A deeper object,
AS12345:AS-CUSTOMERS:AS-EU, is created under the authorisation of
the maintainer of its immediate parent. Now ask where that parent
came from: its own creation was authorised by the level above it,
and so on, terminating at the aut-num itself. Every object in the
tree exists because the level above authorised its creation.
Delegation, where it exists, exists because the chain authorised
it. And who controls each level is answerable, level by level, from
the database as it stands - which is what verifiable control looks
like in RPSL.

The emphatic difference at the current state is that a flat name
offers just a maintainer but no chain: no root, and no way to ask
whether the name was ever anyone's to create - beyond that it must
not already exist in THIS one database.

(015400) concludes that because deeper control can be delegated,
the "control model remains unspecified". The opposite is the case:
the control model is fully specified - in the very RFC that
(015398) cited, which is why deferring to it was the right answer.
That deeper authority is delegated, and that delegated authority
does not automatically follow the ASN, is not a gap in the model;
it is the model, working as designed for twenty-seven years, for
every hierarchical object family, at every RPSL-based registry. A
policy does not "leave AFRINIC to interpret" what the RFC and the
production database already define - any more than this proposal
needs to restate what mnt-by means. What deterministically follows
the ASN is the root of every chain: authority over creation and
recreation at the first level of the namespace. That is precisely
- and only - what the proposal's attribution claim covers. The same
depth question returns in (015402); the answer above stands.

These semantics are not invented by this proposal. They are RFC
2622 (1999), operated by RPSL-based registries - AFRINIC's included
- for twenty-seven years. The proposal does not modify them; it
gates which names may come into existence, nothing else. The two
outcomes (015398) poses are therefore both answered by the
semantics already in production: descendants do not move
automatically, so no delegated maintainer is overridden - exactly
as for every delegated object today. And the new holder gains
precisely what the name anchors: authority over creation and
recreation at the first level of its namespace. What the new holder
does not get - control over objects a previous holder's delegates
still maintain - is what nobody has today under flat names, for any
object, ever. A stale delegated descendant is today's universal
condition; the proposal neither creates nor worsens it, and no
registry in those twenty-seven years has defined the demanded
delegation-and-revocation regime for set objects in policy.

How ASN control actually changes in this region is likewise not a
matter for speculation. AFRINIC publishes it:

  https://ftp.afrinic.net/pub/stats/afrinic/transfers/transfers_latest.json

A full read of that file today: 75 ASN-carrying transfer events (91
ASNs) from 2018 through 2026 - about nine such events a year - and
every single one is a merger/acquisition succession, in which the
organisation and its maintainer control pass together, so parent
ASN and child objects move as one unit. That is the published
record behind Jaco's description in (015394), with the frequency
question answered exactly: none open-market, all successions that
preserve the attribution chain by construction. Anyone can verify
this from the file. So the concern of (015391) has been addressed -
with our registry's own data.

The cross-registry record answers the rest. I checked this week,
across the policy, procedural and database-documentation layers of
the other four RIRs. RIPE has required hierarchical names for new
as-sets since December 2022 and operates full ASN transfers,
including inter-RIR; APNIC likewise since July 2023 (prop-151);
LACNIC's IRR has been structurally hierarchical since it launched
in 2020; at ARIN hierarchical naming is available today and a
mandate for new objects is formally proposed (ARIN-prop-342,
pending) - the same direction. All four are silent on child as-set
lifecycle at every layer. Across the deployed implementations that
is roughly three and a half years of exactly the coexistence
(015387) warns about - hierarchical mandates running over live ASN
transfer markets - and I could not find one documented incident of
the failure mode described. In every deployed implementation,
lifecycle lives where it belongs: in standard RPSL authorisation
and registry operations, not in naming-policy text.

On 7.8.7 (015391, 015402): today the namespace has no rule at all -
every creation, by anyone, of any name, is the exception. A closed
default with documented-reason exceptions cannot be less
deterministic than no default whatsoever. And credit where due:
(015402) makes one point that verifies - the staff assessment's
prose cites "7.8.6" for the restoration-of-deleted-objects
exception, where 7.8.6 concerns editing and the exception clause is
in fact 7.8.7. That is a cross-reference slip in the assessment's
commentary, worth an erratum, and it changes nothing in the policy
text: the clauses say what they say, and staff's own recorded
caution about recall loopholes shows the right mechanism was
analysed. As for the demanded exception criteria: 7.8.7 requires
every exception to be documented with its reason - a discipline
stricter than today, where no creation needs any reason at all.

2. Recursive expansion of members: references (015389)

Correct as far as it goes - and it concedes the top level is
secured. What members: may contain is a content question, expressly
outside this proposal's scope, and outside the naming policies of
every registry that already runs this rule: none coupled naming to
expansion semantics, because that coupling is a different and
larger policy. Jaco has already named the constructive path
(015390): a members-qualification rule would be a coherent separate
proposal, and wording was invited. Meanwhile every new hierarchical
set is one fewer ambiguous reference for the next expansion to fear
- the gap this concern describes narrows with adoption and stays
open without it.

3. Grandfathered flat objects and the transition window (015392)

The capability described - register flat names now, populate them
later - exists today, permanently, with or without this proposal.
Anyone may do it this afternoon. The proposal is the only mechanism
before this Working Group that ever closes that window; declining
it preserves the window forever. If gaming of the implementation
gap is the genuine worry, the remedy is a short implementation
period - a staff scheduling matter - not an indefinitely open
namespace. And, respectfully: (015392) describes with precision the
squatting behaviour whose future possibility this policy exists to
end. An objection that demonstrates the attack is an argument for
closing the door.

4. Multi-source resolution (015393)

Jaco's answer (015396, 015397) is complete: an ASN is delegated by
exactly one registry, so a hierarchical name carries its
authoritative source in its own first element. The question "which
source is authoritative for this set?" has a deterministic answer
precisely and only when the name is hierarchical; under a flat name
that answer does not exist anywhere. The working-group draft cited
in (015393) pursues the same determinism through source-qualified
references - the two mechanisms are complements, not conflicts, and
that draft's problem statement describes the flat-name condition
this proposal removes for new AFRINIC sets. What a third-party
mirror carries is today's condition for every object in every IRR
database and is governed by no naming policy at any registry.

5. Anchor-ASN eligibility and authentication (015401)

Taye, this is the kind of message Last Call is for: specific,
technical, and naming the exact requirements it wants. Three
responses.

First, on substance: the properties you list - the leading ASN
globally assigned, an authoritative aut-num present, creation
authenticated against that object's maintainer, private-use and
reserved ranges (RFC 6996) excluded, canonical ASPLAIN form (RFC
5396) - are, I would argue, what the Impact Assessment's own
authorisation claim already entails. An anchor with no holder can
authorise no one; a check that can pass in the absence of the
aut-num it authenticates against would not be the check the
assessment describes. So I read your list not as a new mechanism
but as the strict, and correct, reading of the mechanism the
proposal already claims.

Second, on where it belongs: those are implementation semantics -
the authentication mode of the database software and the eligible
ASN ranges - and I would support AFRINIC staff recording exactly
your list in the implementation guidance for this policy, alongside
the failure behaviour per creation path. That is the normal home of
such requirements at every registry, and section 7.8.7's
documented-exception mechanism gives staff the instrument for any
edge the guidance must handle. It is worth adding: even in the
weakest imaginable configuration, an unattributable
hierarchical-form name is no worse than today, where every name of
any form requires no authorisation from anyone.

Third, on form: yours is the closest any message in this Last Call
has come to proposed text. If you formalise that list as wording -
whether as implementation guidance or as a clarification for a
future revision - I have no doubt this Working Group will engage it
on its merits, exactly as was invited days ago (015390). It is the
constructive instrument the process recognises.

6. Implementation rollout process (015402)

Warning-only phases, test vectors, baselines, rollback plans and
scheduled reviews are implementation artifacts. They are produced
by registry staff during implementation - at every RIR - and they
appear in no naming policy anywhere: RIPE shipped its hierarchical
requirement through the database release process, with release
notes and a release-candidate test environment, on the strength of
a policy text that contains none of those artifacts. Nothing in
this proposal forbids a staged, warning-first deployment; that is
exactly the kind of detail the implementation phase exists to
define, and 7.8.7's documented-exception mechanism gives staff the
instrument for edge handling during it. Taken at face value,
(015402)'s final section is an argument about deployment
scheduling, which follows ratification - not a reason to withhold
it.

Stepping back, twice.

Each of the demands in messages (015387), (015389), (015391),
(015392), (015393), (015398), (015400) and (015402) carries the same
condition: "before adoption" (015387, 015389, 015391), "before
mandatory enforcement" (015393), "before this proceeds" (015398),
"until ... addressed" (015392), "until that is clarified" (015400),
"until ... clearly resolved" (015402).
As Seun reminded the list (015386), this PDP has no conditional
adoption: a proposal cannot pass Last Call subject to future
homework. At day eleven of Last Call, "resolve and test before
advancing" therefore spells "do not adopt". The process has exactly
one instrument for a genuine, fixable concern: proposed text. Jaco
invited it (015390).

Let me emphasise the arithmetic: seven distinct technical concerns
in a single day, after eleven days without one - and, section 5's requirements
list aside, still zero proposed amendments. Of the six questions of
23 July (015344), exactly one account engaged them point by point -
Tshepo, in (015348) - and the record should credit those answers.
In short:

1) Two-object case: tooling should bind to an explicitly selected
   source or stop and report - the fail-closed behaviour supporters
   had proposed; the live case itself stays unresolved either way,
   the rule being prospective.
2) Squatting remedy: none - the victim is left to another
   database's dispute or abuse process.
3) Is it an improvement? "Yes, narrowly."
4) Evidence bar: a four-part test - whose second criterion, that
   the proposal "would have prevented" the incident, excludes by
   construction every incident that already exists; a creation-time
   rule is prospective by definition.
5) Impact Assessment: "I do not dispute the findings"; the
   objection shifts to what the IA does not cover.
6) Capacity: individual, representing no organisation or resource
   member.

No other opposing account has answered any of the six. Today the
bar has moved with nearly every message, and a seventh question now
joins the list. My assessment, for the record:
none of today's objections identifies a defect in what the proposal
claims; and their cumulative effect, whatever the intent, has been
to consume the finite attention of this Working Group - a cost
long-standing participants have already described in their own
words (015154, 015179).

One further observation, offered for the record and without
attributing it to any individual: this Last Call's objections began
from the principle that the registry "may record... It may not
rule" (015011). Today's objections ask the registry to pre-define
delegation graphs, revocation processes, state machines, permanent
reservations, transition audits and source-selection rules, in
advance (015391, 015392, 015393, 015398, 015400, 015402). Those two
standards pull in opposite directions, and the same seven-clause
creation-time rule cannot be faulted under both at once. Which
standard the Working Group actually holds is exactly what the
Co-Chairs will weigh - against what the proposal actually claims: a
creation-time naming rule, whose every stated boundary today's
objection messages ask it to exceed.

The community is entitled to expect Last Call to close on schedule
and to be assessed on the record as it stands.

Regards,
Hendrik Visage (AS329532; also AS213481)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260727/6df469f5/attachment-0001.html>