<div dir="auto">Dear PDWG,<div dir="auto"><br></div><div dir="auto">Kindly allow me to raise a technical concern on my side that further supports my objection to the proposed policy. </div><div dir="auto"><br></div><div dir="auto">The proposal controls the name of a newly created AS-SET, but not the AS-SET names referenced inside it. RPSL allows the members: attribute of an AS-SET to contain other AS-SET names. Those referenced sets are then included when the object is expanded, with nested inclusion operating recursively. </div><div dir="auto"><br></div><div dir="auto">A new object such as:</div><div dir="auto"><br></div><div dir="auto">AS65000:AS-CUSTOMERS</div><div dir="auto"><br></div><div dir="auto">could therefore still contain:</div><div dir="auto"><br></div><div dir="auto">members: AS-EXAMPLE</div><div dir="auto"><br></div><div dir="auto">If AS-EXAMPLE exists with different contents in multiple IRR sources, the top-level object may be hierarchical while its dependency chain remains ambiguous. The same filter-generation problem can therefore reappear during recursive expansion.</div><div dir="auto"><br></div><div dir="auto">This is not the earlier argument about whether individual members are factually correct. It is a narrower issue of resolution integrity: the proposal secures the first object name but does not secure every referenced name that tooling must resolve.</div><div dir="auto"><br></div><div dir="auto">The Impact Assessment expressly places resolver behaviour outside scope, yet the operational justification depends on the results produced by resolvers and filter-generation tools. That gap needs to be addressed.</div><div dir="auto"><br></div><div dir="auto">Before adoption, the proposal should clarify whether newly created hierarchical AS-SETs may reference grandfathered flat AS-SETs. If they may, the policy should define how ambiguity is detected and handled throughout the dependency chain. If they may not, the operational impact and migration requirements should be assessed and documented.</div><div dir="auto"><br></div><div dir="auto">A creation-time naming restriction should not be credited with protecting filter generation until the complete expansion path has been tested.</div><div dir="auto"><br></div><div dir="auto">For this reason, I object to the proposal as presently written.</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Nonjabulo</div></div>