On Mon, 5 May 2025 at 20:32, Petr Špaček <pspa...@isc.org> wrote: > On 5/5/25 14:49, Eric Vyncke (evyncke) wrote: > > Dear authors and WG, > > > > There have been substantive IETF Last Call comments once extending the > > review outside of DNSOP. On my own read of the comments, there are two > > critical ones: > > > > * Are full-text explanations better or worse from UX or security point > > of view ? > > * Should the draft merge/include/... with draft-nottingham-public- > > resolver-errors ? > > Shameless plug: There is also a technical objection in > > https://mailarchive.ietf.org/arch/msg/last-call/dsouS0lgD8UK36rWgqBkq8LKSWo/ > > under "Issue #1". > > The current text breaks assumptions about EDE Option usage defined in > RFC 8914 and does not state a good reason for it. >
This topic was discussed within the WG, and there was consensus to reuse the EDE Option in the request as a signal of client interest in structured data, please see slide 4 in https://datatracker.ietf.org/meeting/115/materials/slides-115-dnsop-structured-data-for-filtered-dns-01. The same EDNS(0) option is permitted in both requests and responses, for example, RFC7828 (edns-tcp-keepalive) specifies the use of the option in both request/response. It also maintains symmetry between signaling support for this feature and delivering structured error information using the same option. -Tiru > > -- > Petr Špaček > Internet Systems Consortium > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
