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.
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
