<div dir="auto">Dear Hendrik,<div dir="auto"><br></div><div dir="auto">If I have misstated the current RIPE Database behaviour, then I have no objection to correcting that point. My argument does not depend on that particular example.</div><div dir="auto"><br></div><div dir="auto">Likewise, I cited the GROW Internet-Draft because it discusses operational considerations around hierarchical authorisation across IRRs, not because an Internet-Draft has normative status. Whether or not that draft was ultimately adopted does not, on its own, determine whether the underlying technical observation is valid.</div><div dir="auto"><br></div><div dir="auto">The central issue remains unchanged.</div><div dir="auto"><br></div><div dir="auto">The proposal establishes naming and authorisation within the AFRINIC IRR. What it does not explicitly define is the scope of the assurance that follows from that naming convention. If the proposal's intent is limited to AFRINIC object creation, then I believe the policy should say so explicitly. If broader operational benefits are being relied upon in support of the proposal, then those benefits should also be demonstrated explicitly.</div><div dir="auto"><br></div><div dir="auto">My concern has never been whether hierarchical naming is useful within AFRINIC. It is whether the policy clearly defines what assurance it provides and, equally importantly, what assurance it does not provide. Clear policy language reduces differing interpretations and avoids attributing properties to the proposal that are outside its stated scope.</div><div dir="auto"><br></div><div dir="auto">For that reason, I continue to believe that clarifying the proposal's guarantees would strengthen it, regardless of the examples used during this discussion.</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto"><br></div><div dir="auto">Phetulo</div></div>