[DNSOP] Re: New Version Notification for draft-muks-dns-nta-feed-zones-00.txt

[Ondřej Surý]

Aditya, it feels like that your message was both LLM-generated and misread the emails that you are replying to at the same time. While it is OK to use LLMs to polish your language for non-native speakers, you need to remain fully responsible for the content that you are posting to the mailing list - in this case, this would mean reading the proposed draft, reading my response and reading Carsten’s response. If you actually did that, you would see that your response is missing the point I was making, and misunderstanding the substance of the proposed draft. Ondrej -- Ondřej Surý (He/Him) A gentle nudge is always appreciated if I take a little longer to reply. On 28. 7. 2026, at 09:46, Aditya Ghosh <aditya.gh...@iifon.net> wrote:  Hi, I agree with Ondřej's point regarding the architecture here. NTAs are inherently local operational overrides specific to a resolver's policy, rather than a global state that belongs in dedicated feed zones. If the core objective is visibility and discovery into active NTAs rather than building new zone-transfer infrastructure, leveraging RFC 9606 (RESINFO) might be a cleaner alternative. Since NTAs are scoped to the resolver and are meant to be temporary, resolvers could self-announce their currently active NTAs via RESINFO key-value pairs (for instance, an nta-uri attribute pointing to the resolver's active NTA dataset). This keeps the policy discovery explicitly local to the resolver enforcement point and reuses an existing mechanism, avoiding the need to construct and maintain new feed-zone distribution logic. Best regards, Aditya Ghosh (he/him) Research Intern India Internet Foundation aditya.gh...@iifon.net

_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org