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

[Hendrik Visage]

Dear Asamkele

Claude: `Same pipeline, fourth voice — and this one is useful to you, 
because it's the first letter that visibly repeats rather than extends.`

Claude: `Still zero contractions, zero concrete operational detail, zero 
personal grounding. "Running-code discipline" is the one gesture at IETF 
culture, deployed as a slogan rather than an anecdote — a model 
reaching for community credibility markers.`

Claude’s analysis:
```
**Why the repetition helps you**

Across four letters the pipeline has now produced:

1. Nonhlanhla — authentication-vs-content + minimum-intervention
2. Gugu — meta version (mandate laundering, thin layer)
3. Thulisile — procedural defense of the objectors
4. Asamkele — authentication-vs-content + minimum-intervention 
*again*, with a reshuffled alternatives list

Letters 1 and 4 are substantively one letter. That's your consolidation 
case made for you: you can now write, without any authorship claims, 
"Asamkele's objection restates Nonhlanhla's — the attribution/content 
distinction and the less-coercive-alternatives list — which I've 
answered at [reference]. No new substance has been introduced." Under 
rough-consensus practice, an objection that's been answered doesn't 
become unanswered by being repeated in fresh phrasing, and co-chairs can 
and should treat it as closed unless the repetition adds something.
```

---
Hendrik Visage
Director/Owner
HeViS.Co Systems t/a Envisage Cloud Solutions
hvisage at hevis.co.za
GSM/SMS/Signal: +27-84-612-5345
InstantMessenger: https://t.me/hvisage

On 19 Jul 2026, at 19:25, Asamkele Menzeleli wrote:

> Dear Hendrik,
>
> I remain opposed.
>
> Your argument proves less than you suggest. Hierarchical naming may
> identify which ASN maintainer created an AS-SET, but it does not prove 
> that
> every member placed inside that set was authorised by the affected
> networks. It establishes attribution of the object. It does not 
> establish
> the correctness of its contents.
>
> That distinction matters because the routing harm you describe arises 
> when
> operators rely on inaccurate or misleading AS-SET expansion. 
> Prefix-list
> tools consume the membership data, not merely the name. Binding a name 
> to
> an ASN therefore does not, by itself, prevent an authorised maintainer 
> from
> publishing an incorrect customer cone, omitting legitimate members, or
> including routes it should not include.
>
> The proposal is consequently being presented as though it closes an
> authorisation problem that it only partly addresses. It authenticates 
> who
> created the container. It does not authenticate every relationship
> represented inside the container.
>
> Nor does the existence of a flat namespace automatically require 
> AFRINIC to
> prohibit it. Source-qualified lookups, explicit object references,
> collision warnings, validation rules, local rejection, and voluntary
> hierarchical objects are all less coercive mechanisms that should be
> evaluated first. The fact that tooling consumes ambiguous data is an
> argument for deterministic validation and safer tooling, not 
> automatically
> for expanding the registry’s permission layer.
>
> This is the precise point of running-code discipline: identify the
> invariant, define the failure, and use the minimum rule necessary to
> protect it. Do not take one operational risk, rename it “proof of 
> control,”
> and then treat that vocabulary as sufficient authority for compulsory
> policy.
>
> A registry may record who maintains an object. It may expose conflicts 
> and
> provide stronger validation. It should not confuse control of an ASN 
> with
> ownership of every routing relationship that someone chooses to place
> beneath that ASN’s name.
>
> The proposal therefore still fails the proportionality test. It has 
> not
> shown that mandatory hierarchical naming eliminates the claimed 
> routing
> harm, only that it makes the creator of a new object easier to 
> identify.
> Administrative attribution is useful. It is not the same thing as 
> routing
> authorisation.
>
> My objection remains.
>
> Regards,
> Asamkele Menzeleli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260719/0956e2ee/attachment.html>