On Mon, 5 May 2025 at 21:23, Petr Špaček <pspa...@isc.org> wrote: > On 5/5/25 17:27, tirumal reddy wrote: > > On Mon, 5 May 2025 at 20:32, Petr Špaček <pspa...@isc.org > > <mailto: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/ <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 > > Could you please point me to the the decision, please? > > I did not find this being discussed on the mailing list. IETF 115 dnsop > minutes for this draft say only this: > ----- > https://datatracker.ietf.org/doc/minutes-115-dnsop/ > > Structured Data for Filtered DNS > draft-wing-dnsop-structured-dns-error-page, Tirumal Reddy > Lots of industry interest > **Chairs Action: CfA** > ----- > > To refresh my mind I went to IETF 115 dnsop recording here > > https://meetecho-player.ietf.org/playout/?session=IETF115-DNSOP-20221108-0930 > and listened to block starting at 1:52:00. What I hear is call for > adoption a minute or two before the session ended and everyone went > home, not a technical discussion. > > Did I miss some other place where it was discussed? It's been a long > time so I might have missed something, obviously. >
It has been a long time, and I recall discussing this with resolver providers who did not see any issues with implementing it. For instance, it is already implemented by AdGuard’s DNS SDE extension <https://github.com/AdguardTeam/dns-sde-extension> and by Akamai (see DNS Errors <https://datatracker.ietf.org/meeting/116/materials/slides-116-dnsop-dns-errors-implementation-proposal-slides-116-dnsop-update-on-dns-errors-implementation-00> ). -Tiru > > > > 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. > Just to be clear: I'm fine with using an option in both directions. What > I object to is overloading meaning of an existing EDE option for > different purpose. Specifically EDE spec in RFC 8914 section 2 says: > > > The Extended DNS Error (EDE) option can be included in any response > (SERVFAIL, NXDOMAIN, REFUSED, even NOERROR, etc.) to a query that > includes an OPT pseudo-RR [RFC6891]. > > It does not say anything about use in queries. I can't see a technical > reason for this overloading, and as resolver implementer I don't want to > deal with complicated spec and resulting code if it can be made simpler. > > Hopefully I explained myself clearly now. > > -- > Petr Špaček > Internet Systems Consortium >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
