[DNSOP] Re: Conclusion and request for action after AD review of draft-ietf-dnsop-structured-dns-error-20

["Eric Vyncke (evyncke)" <[e-mail]>]

Warren, Vladimir, and DNSOP,

As the IETF Last Call has just completed now, let me chime in again on this topic.

Warren, you are 100% correct about the a.cc "counter-example", this also means that "short domain names" should be removed from `as short as possible: short domain names,  concise text in the values for the "j" and "o" names, and minified JSON` because then the modified sentence can have a "MUST" 😉

Regards

-éric




From: Warren Kumari <[e-mail]>
Date: Monday, 15 June 2026 at 22:09
To: Vladimír Čunát <vladimir.cunat=[e-mail]>
Cc: [e-mail] WG <[e-mail]>
Subject: [DNSOP] Re: Conclusion and request for action after AD review of draft-ietf-dnsop-structured-dns-error-20





On Mon, Jun 15, 2026 at 5:02 AM, Vladimír Čunát <vladimir.cunat=[e-mail]<mailto:vladimir.cunat=[e-mail]>> wrote:
On 09/06/2026 10.10, Eric Vyncke (evyncke) wrote:
Per [1], why not a MUST (my preference but up to you) or providing the required guidance for the "SHOULD" in:
  To avoid exceeding the maximum EDNS0 size [RFC9715] the generated JSON values *SHOULD* be as short as possible: [...]

In my eyes, "as short as possible" and the following text have a fairly fuzzy meaning, except the JSON-minifcation part, so I'm not sure if MUST vs. SHOULD makes a practical difference when formulated this way.

I agree with Vladimir here.

The context is:
" To avoid exceeding the maximum EDNS0 size [RFC9715] the generated
   JSON values SHOULD be as short as possible: short domain names,
   concise text in the values for the "j" and "o" names, and minified
   JSON (that is, without spaces or line breaks between JSON elements).
   Otherwise, there is a risk that the response will get fragmented."

Making this MUST would mean that the domain name has to be something like a.cc<http://a.cc/>, the reason would be something like "because" and the org would have to rename itself from "Acme Security" to X.

I personally still think that shoving any sort of JSON into an EDE or EDNS0 answer, and expecting it to be shown to a human is a bad idea, but if we've decided to do that, we might as well make it useable, and so SHOULD seems fine to me.
But, obviously, I don't have to defend this in front of the IESG, and so if Eric still thinks it needs to be a MUST to pass, he's probably right…
W



Also note that the server producing this structured error does know limitations on the overall size of that particular DNS message.  (if it's going over plain UDP, they've already "negotiated" the limit size)  Though it might be impractical/complicated to make such a decision dynamically.


_______________________________________________
DNSOP mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>