<div dir="auto"><div dir="auto">Dear Jaco,</div><div dir="auto"><br></div><div dir="auto">As I have been following the discussions very closely, thank you for taking the time to explain your position. I accept that hierarchical naming can strengthen creation authorisation within the AFRINIC database.</div><div dir="auto"><br></div><div dir="auto">I have a different concern, however. The proposal binds an AS-SET name to an ASN, but it does not bind that name to a particular IRR source.</div><div dir="auto"><br></div><div dir="auto">For example, AS12345:AS-CUSTOMERS identifies the ASN namespace, but it does not tell a resolver whether the intended object is from AFRINIC, RADB, RIPE, or another source. IRR software already recognises that sets with the same primary key may exist in different sources and may return them separately. </div><div dir="auto"><br></div><div dir="auto">This is not merely hypothetical architecture. An active IETF GROW working-group draft, still a work in progress, states that object primary keys are not guaranteed to be unique among IRR registries and proposes registry-scoped references precisely because multi-source resolution remains ambiguous. </div><div dir="auto"><br></div><div dir="auto">That creates a gap in the proposal’s central claim. It is presented as protection against inter-RIR collisions, yet the Impact Assessment expressly places mirroring and resolver behaviour outside scope. If the source is not part of the object’s identity, a hierarchical name may be properly authorised in AFRINIC while an identically named object remains visible through another source.</div><div dir="auto"><br></div><div dir="auto">Before mandatory enforcement is introduced, the design should specify how the authoritative source is selected, what tooling must do when the same hierarchical primary key appears in multiple sources, and whether source-qualified references or an equivalent deterministic rule are required.</div><div dir="auto"><br></div><div dir="auto">Otherwise, the policy gives operators a stronger-looking name without providing a complete answer to the multi-source lookup problem it is meant to address.</div><div dir="auto"><br></div><div dir="auto">This concern is fixable, but it should be resolved and tested before the proposal advances. I therefore remain opposed to the policy as presently written.</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Phetulo</div></div>