AS-SETs Hierarchical Names

Hierarchical-name syntax · The newer proposal explicitly requires the first element to be an ASN prefixed by AS and gives examples. The earlier text requires the second element to be an AS-SET name; the newer proposal instead says further elements may be ASNs or AS-SET names and separately defines the AS- prefix for AS-SET names. This is a wording change with a possible validation consequence. The staff assessment still describes a required AS-SET second element and proposes wording to that effect, so the documents do not establish that this ambiguity was finally resolved.

Exceptions for restoring existing names · Both texts protect existing non-hierarchical AS-SETs from forced renaming when edited. The newer proposal adds mandatory case-by-case exceptions, illustrated by restoring an accidentally deleted flat name. That introduces a discretionary operational path alongside the creation-time naming requirement. The staff assessment questions whether restoration could create a loophole and suggests documenting exceptions; those staff comments are not evidence that the proposal adopted the suggested wording or that exceptions were granted.

Treatment of other set types · The earlier proposal expressly excludes other set types such as route sets. That standalone exclusion does not appear in the newer proposal's operative list, but the new staff assessment expressly interprets other set types as excluded and includes an exclusion in suggested replacement wording. This is a difference between the retained proposal texts, not sufficient evidence that the intended policy scope expanded to route sets.

Staff assessment and implementation planning · The earlier page says the staff assessment will be available soon. The newer page supplies an assessment covering authorization, WHOIS and MyAFRINIC changes, preservation of existing objects and exception risks. Its implementation plan ties prioritization to the expected completion of MyAFRINIC v2. These are assessment and planning statements, not proof that the policy was ratified, deployed or completed by the projected date.

Conflicting dates and revision labels in the source pages · The older archive page gives a 2020 submission date but its revision history says the first draft was posted on 15 May 2026. The newer page identifies DRAFT02, dates submission to June 2026 and records Version 2 on 8 June, while its details still say Version 1.0. The comparison therefore follows the explicit DRAFT01/DRAFT02 relationship and revision-history statements, while retaining the conflicting metadata. It does not establish a six-year policy-development interval, and the newer page's Last call and Under Discussion labels do not establish final adoption.

Staff impact assessment: RDAP · The staff assessment changes from its initial draft to version 1.1. Its RDAP row changes from reflecting WHOIS changes for AS-SET queries to no impact. The proposal retains version 1.0 and its AS-SET naming requirement; this is an assessment correction rather than a change to that requirement. Added tab labels and spacing carry no separate policy change.

Procedural status; unchanged AS-SET requirement · The later page changes last call to consensus awaiting Board ratification. The proposal text and staff assessment wording are otherwise unchanged in this pair. This does not show Board ratification or implementation and does not create a new substantive proposal version.

Policy ratification status · The page-level status changes from consensus awaiting Board ratification to ratified, with 25 September 2026 recorded as the AFRINIC Board ratification date. The remainder of the captured document is unchanged. An embedded 'Under Discussion' label remains in that unchanged text; this comparison does not resolve that inconsistency.