<div dir="auto">Hi Frank,<div dir="auto"><br></div><div dir="auto">Your examples are useful, but they do not establish the global guarantee you suggest.</div><div dir="auto"><br></div><div dir="auto">On your first question, the answer is not automatically “no.” Current RIPE Database documentation states that anyone may create an aut-num copy for an ASN administered by another RIR. The same documentation says that creation of a hierarchical AS-SET is authorised through the maintainer of the parent object in that local database. This means, at least in principle, that a locally created, non-authoritative copy of an out-of-region aut-num could become the authorisation anchor for the same hierarchical AS-SET name. </div><div dir="auto"><br></div><div dir="auto">This is not an imaginary threshold. A current IETF GROW Internet-Draft expressly states that RFC 2622 hierarchical authorisation works only within a single IRR and does not identify the correct external IRR. The proposal therefore improves local authorisation, but local authorisation should not be presented as global authority. </div><div dir="auto"><br></div><div dir="auto">On whether AS3320:AS-DTAG could be created in AFRINIC, the normative text does not provide a complete answer. It requires an ASN as the first element, but does not expressly require that ASN to be currently administered by AFRINIC and authenticated against an authoritative AFRINIC aut-num.</div><div dir="auto"><br></div><div dir="auto">That requirement should be stated directly, for example:</div><div dir="auto"><br></div><div dir="auto">> The first ASN element MUST be currently administered by AFRINIC and MUST be authenticated against the authoritative AFRINIC aut-num object. A locally copied or otherwise non-authoritative aut-num object MUST NOT satisfy this requirement.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">The proposal should also state precisely what assurance the name provides:</div><div dir="auto"><br></div><div dir="auto">> A compliant hierarchical name proves authorisation to create the object in the AFRINIC authoritative IRR at that time. It does not, by itself, establish the authority of copies in other IRRs or determine how multi-source tools must select an object.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">As for the possibility that suitable tooling may be written later, possibility is not an operational guarantee. A mandatory policy should not be credited today with a security property that software might implement in future. If tools are expected to rely on the hierarchical name as an authority signal, the meaning of that signal and the relevant test cases should be specified first.</div><div dir="auto"><br></div><div dir="auto">I accept that the proposal can improve creation control inside AFRINIC. I do not accept that this proves global uniqueness or deterministic source authority.</div><div dir="auto"><br></div><div dir="auto">Until the authoritative-anchor requirement and the scope of the resulting assurance are made explicit, I remain opposed to the proposal as written.</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Phetulo</div></div>