<div dir="auto">Dear Jaco,<div dir="auto"><br></div><div dir="auto">Thank you for engaging with the concern. Your reply brings up a different problem that the Impact Assessment does not address.</div><div dir="auto"><br></div><div dir="auto">The policy has a future implementation date, while every flat AS-SET created before that date will remain valid and editable. This creates a race-to-grandfather risk. A database user could register desirable or confusing flat names during the transition, leave them empty or harmless, and populate or alter them after enforcement begins.</div><div dir="auto"><br></div><div dir="auto">The registry would then reject new flat names, but those pre-positioned objects would remain active indefinitely. In other words, the proposal does not necessarily stop new harmful cases going forward. It stops only one method of creating them after the cut-off date. New risk could still be introduced through later changes to grandfathered objects.</div><div dir="auto"><br></div><div dir="auto">The source-qualified membership restriction you suggest is not part of this proposal. A possible future policy cannot be counted as protection delivered by the current text.</div><div dir="auto"><br></div><div dir="auto">At minimum, the proposal would need an immediate reservation or cut-off mechanism, an audit of flat objects created during the implementation period, and clear rules governing material changes to grandfathered objects. The operational impact of those measures has not been assessed.</div><div dir="auto"><br></div><div dir="auto">Grandfathered does not mean frozen. Until the active legacy surface and the transition-period incentive are addressed, I do not believe the claim that the policy prevents new problem cases has been established.</div><div dir="auto"><br></div><div dir="auto">I therefore remain opposed to the proposal as written.</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Nonjabulo</div></div>