<!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, colleagues,</p>
<p dir="auto">Tshepo, first: thank you! Your AS-FOO restoration example (015415) is<br>
honestly the best illustration this whole Last Call has produced of<br>
the exact disease we are busy fixing here - you clearly understand<br>
the cross-registry collision problem, you've described its anatomy<br>
better than most of the supporters did. Where I want to help is to<br>
show you WHERE that collision actually lives: it lives in the flat<br>
names, and only in the flat names - and this proposal is precisely<br>
the instrument that stops making them. Let me walk through it.</p>
<p dir="auto">Executive Summary: An ASN belongs to exactly one registry, that's how IANA delegates the blocks, and a hierarchical AS-SET can only be<br>
created in that one registry, by that ASN's holder, because the<br>
creation is authorised against the LOCAL aut-num object in that<br>
database. I can prove it with my own two ASNs: my AS213481 (RIPE)<br>
cannot anchor a set in the AfriNIC database - there is simply no<br>
aut-num there to authorise it - and my AS329532 (AfriNIC) cannot<br>
anchor one at RIPE, APNIC or ARIN, same reason mirror-imaged. So the<br>
authoritative hierarchical namespaces are disjoint BY CONSTRUCTION,<br>
and the cross-registry collision in your AS-FOO restoration example<br>
(015415) is unconstructible with any name this policy produces - it<br>
only works with the flat legacy names, the exact class this policy<br>
stops minting. Your example demonstrates the disease we are treating</p>
<ul>
<li>and I mean that as a genuine compliment, it takes understanding the</li>
</ul>
<p dir="auto">problem to construct it.</p>
<p dir="auto">Now the longer version, for those that want to check my work.</p>
<p dir="auto">There is two facts this all rests on:</p>
<p dir="auto">Fact 1: every ASN have exactly one registry, always. IANA delegates<br>
the ASN blocks to one RIR each - my AS329532 sits in AfriNIC's<br>
327680-330751 block, my AS213481 sits in RIPE's 196608-219547 block.<br>
The map ASN => registry is total and single-valued, and it even stays<br>
single-valued under inter-RIR ASN transfers where those are allowed<br>
(the authoritative home moves WITH the ASN, it never has two homes -<br>
and AfriNIC is not even part of the inter-RIR transfer system today,<br>
but that's a different discussion).</p>
<p dir="auto">Fact 2: hierarchical creation is authorised against the LOCAL aut-num<br>
object. In every authoritative RIR database, to create<br>
ASxxx:AS-SOMETHING you must pass authorisation via the aut-num for<br>
ASxxx in that SAME database (mnt-lower, else mnt-by - per the RIPE<br>
and AfriNIC documentation; APNIC prop-151 says created only by "the<br>
maintainer of the ASN" in the name; ARIN does it via the Org<br>
linkage). And an RIR's authoritative database only carries aut-num<br>
objects for the ASNs that registry itself issued. AfriNIC's DB has<br>
no aut-num AS213481. RIPE's DB has no aut-num AS329532.</p>
<p dir="auto">So the demonstration, with my own two ASNs:</p>
<p dir="auto">=> I cannot create AS213481:AS-ANYTHING in the AfriNIC database. The<br>
authorisation check needs aut-num AS213481 in AfriNIC's DB, no such<br>
object exists or can exist there, since it's RIPE-issued. There is no<br>
maintainer chain to authorise against. Creation fails for me - and<br>
for everybody else on earth too.<br>
=> I cannot create AS329532:AS-ANYTHING in the RIPE database, exact<br>
mirror image reason. Same at APNIC, same at ARIN.</p>
<p dir="auto">Which means: under hierarchical naming the five authoritative<br>
namespaces is disjoint by construction. A hierarchical name can<br>
exist, as an authoritative object, in exactly ONE registry - the one<br>
that issued its leading ASN - and can be created there by exactly ONE<br>
party - that ASN's current holder chain. A cross-registry collision<br>
between two authoritative hierarchical objects with the same name is<br>
not "unlikely", it is impossible. Nobody have to go check anybody<br>
else's namespace, the name itself IS the check. (This is also Jaco's<br>
point in (015396) about source selection - the tooling maps the<br>
leading ASN to its registry and queries only there.)</p>
<p dir="auto">Now apply that to your (015415) example. Look carefully what carries<br>
that scenario: EVERY step of it requires the name to be flat.</p>
<ol>
<li>The colliding class is the flat class. A hierarchical name cannot</li>
</ol>
<p dir="auto">be created in the "other" registry at your step 2 - see above. The<br>
scenario is unconstructible with any name this policy produces, it is<br>
only constructible with the legacy names the policy stops minting.</p>
<ol start="2">
<li>The restored object is grandfathered surface. Clauses 7.8.4/7.8.5</li>
</ol>
<p dir="auto">expressly tolerate the existing flat inventory and its exposure,<br>
restoration un-deletes a member of that tolerated class. Its<br>
cross-registry exposure existed every single day that object was<br>
live - the delete/restore round-trip neither creates nor enlarges<br>
it.</p>
<ol start="3">
<li>And your example is anyway a subset of today's standing condition:</li>
</ol>
<p dir="auto">without this policy, AS-FOO collisions require no<br>
deletion-and-restoration choreography at all - anyone can create<br>
AS-FOO in any IRR, today, right now, this afternoon. The restoration<br>
edge is a strict subset of the permanent flat-name exposure, and the<br>
only mechanism on the table that ever SHRINKS that exposure is this<br>
proposal, under which the flat class ages out and your scenario's raw<br>
material disappears with it.</p>
<p dir="auto">So your example does not show the exception "recreating the very<br>
collision this proposal is intended to prevent". It shows, in full<br>
working detail, the problem that exists exactly as long as flat names<br>
can exist. You have, maybe without intending to, written the<br>
strongest argument FOR the proposal this list has seen in two weeks -<br>
it just runs in reverse.</p>
<p dir="auto">To be complete and honest about the edges: yes, the open registries<br>
and mirrors (RADB and friends) accept objects on their own terms,<br>
including names rooted in ASNs the submitter doesn't hold - that is<br>
true today, unaffected by any RIR's policy, governed by those<br>
operators, and it's a tooling source-selection matter which the ASN<br>
=> registry map above makes deterministic for the authoritative data.<br>
And yes, AfriNIC-side enforcement of the local-aut-num check is<br>
exactly the implementation semantics Taye asked to have pinned in<br>
(015401), which I've already supported recording as staff<br>
implementation guidance in (015404).</p>
<p dir="auto">So Tshepo - you see the problem, that much is clear from how well you<br>
described it. The flat namespace is the only place your scenario can<br>
happen, and every day the flat class shrinks, your scenario shrinks<br>
with it. That shrinking only starts when this policy is adopted. I'd<br>
genuinely welcome you on the side of fixing the disease you've just<br>
diagnosed so well.</p>
<p dir="auto">Regards,<br>
Hendrik Visage (AS329532; also AS213481)</p>
</div>
</div>
</body>
</html>