[DNSOP] Re: Comments from IETF Last Call about draft-ietf-dnsop-structured-dns-error

[Petr Špaček <[e-mail]>]

On 5/5/25 17:27, tirumal reddy wrote:
> On Mon, 5 May 2025 at 20:32, Petr Špaček <[e-mail] 
> <mailto:[e-mail]>> 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