Return-Path: X-Original-To: dnsop@mail2.ietf.org Delivered-To: dnsop@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 148F0101B5AC5 for ; Mon, 15 Jun 2026 13:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1781554095; bh=U3hR93YErn6+/L57Nw58fEXGggJikV/GZJMXI1rtojc=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=Z98UglgWCwsQ/c1vuoyH59D8RR7ql7Jv7px9G6/7tf+uDyGDGfDeK5lWlnh/9Qald JeGYRnVlamaF+ywqoQOE/NBJPmAq6NRKYD+6U/zQrPXW0pdZxQq2FFOVgi50pMFrCn MwSgQQZkfp3F61JXDly9+wNHlebrOOHldh7qmT1k= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.net Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLgLuwCyDNu1 for ; Mon, 15 Jun 2026 13:08:14 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 919CB101B587B for ; Mon, 15 Jun 2026 13:05:20 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-691c5776f35so6076925a12.3 for ; Mon, 15 Jun 2026 13:05:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781553919; cv=none; d=google.com; s=arc-20240605; b=hSmzfO070aGlT2pm2T5igTII240ATIPW08nUQyeloWxQPJ3nZqAUzGoGObg4bdrTp0 WFu+0TygzY3S2bnTXR5zoYrhm1gxTw2QNdcIatno8OFzur/LA9wMXDF/JdJL2HAkmLSA HFSWa3U2yqLaab1kajFOaZp6RkrAkyyohzHmPNxGLM3BkuXnPMddSZw/1sOzFvXlZT/N PDYk9GPGI8t36rQPVubi/8foKCZ3y+r8a5UYby8nERVZSb1hS5bqCHpBmIRK3OsC15oL WBaIRBdYA0IrTfYCb08ZLHeC8ofPD/BTzWevXu4EvcBb6jqQ/Q0ZcF43BD3+Sz9qU7JD Gzcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=u+HivJpCC2/8eQmbnEYW5dRCXcizbFiAqJV942tkCXo=; fh=sMqyKa7dtnla0ccdmKGkKAAVUKOvxsPUe/UzW6AwVgY=; b=RQZT+0osv78r8A4q2PJ6MLPlzegyy2PxvVGZpO1yI1aJo2QRgQG+LWNDybTCkjLwoL 7MsG6XBVFfWDrDCdNEMgOU+FmFN4LbJgBPmCrloWxzm1JOk/rQHxoIWVknEdRoEoQYJU uSjcCOdzE03usFsUwRk0bTvDxfd8MejMJmKUQ+TZDuC+yuaHU3KcQoZ7PnC9h5uhFeM/ UwnGNhDNQdRI8Dx6SHBXuxmb5FQ41mvzMIa5sFQTa7KplWrEMisH6hHE5lutFkKKR6Qz fo5dwjWCdp1P4hZb4kf/l5zN+azwvoxopl1TfYazN/qYGCDA8plsyiNx1olTiFTlnpxT f8GA==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; t=1781553919; x=1782158719; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=u+HivJpCC2/8eQmbnEYW5dRCXcizbFiAqJV942tkCXo=; b=IENZVehyZzZE6iabZeSMUOy6+jzWfrzS/CiC1YOr5HuSERI5SK9HwvXMSrokyKIe8Q hIL25z5sFg2fI68xb7tXuOoPVHviRcrX/tvlSTvprqBh46USADBCPyvcAl62Nq5RPZHL iocCCiNXAVkFLBIfFJb8kCjI0cV7c4RbKILKU0lBk79h6KCjVaxKL4SROVw22oGprxXJ auPMnvfdmzF8uL39IIBNCHaXpeBqFcp3vLhornxy+kK0O7F3sJW+f1gxuk0qiBmQVbLa ArnXL6sgr3nSivF9f1NNBCZLFJPFckM2khx3z01It6n95pBPgn7Q4H6nRmiqq4UR2Nko lVzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781553919; x=1782158719; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=u+HivJpCC2/8eQmbnEYW5dRCXcizbFiAqJV942tkCXo=; b=iDddBJ1l6Y3naJxQcy3+jX/fzB4sswYveJt8dRADY+iJX66HV2i9p9+uHmNZCwNRWG a3GUgRbcvLuF7VZ3yYRBCDMgawSbnKnVDWTuyxaoXNB+CdqCiRV4DGPDFaPYAYaAdzEu 7NJ3h6I+wpWajfUAbucmEV4vZK93mm5hnlSNt2MpDrefGfm25YZNWLR35O5W1mmjpTlI LWRZvYqgArKNWccnPYM5Njp5s1XaGASnUA9W17wMQGJNAVhG4daRIDAr5u4r45KQmPaX Q65wCB8OOGxl7Qlz6TUQgrTlWprjsNdLQoTF702dLvjaTn7XCb+7qhLGfHQwB09QTk5F bNpw== X-Gm-Message-State: AOJu0Yz43xm1lBB/3gPSTMSHU5ZfOyV1e8PqUwnO9oY8pbyj0D6F6pm9 vGD91ZOYFk9mwEJA8jgQM6KW0Qt/tsiSZqvdpCp0wS5NUz0PzuI0Zj/9LMut5PSF69wXWixOJ7A KqT++VhQYrFLAsYlgQq7gNBLmn9ThvhyQcFS747YoFA== X-Gm-Gg: Acq92OGq1U+jrAnXAXc0HB7u2SChZjfP2zVageOWlD6phcQiC0kgi+8yda8YEv/OLwj RnIfTmwUD3bW49iIkKar2f0FRcQmUtcF7MGIR0JuomO3ZzkTkbSN5JHEeNL3RRNLma2stJll1Re jlmZsKdnmprYOSXRFZbX5lkQnBDRdD3XVAomk0oCk6a3UdhnNGl9yFcJwrqTf6z7OP0Kvj4TvFK Qyl+R0AcfFKRW9z5NgwAE+u8P8S98Q9vyqhz4F2GjS6bzvC01rxaofQ31Ot9mbY4qIp64BuKThn xTMfJTMtKyZ5UeOogvKHRoh66an02bo= X-Received: by 2002:a05:6402:35d2:b0:68a:ac22:ccc4 with SMTP id 4fb4d7f45d1cf-693c6b9fb34mr5144465a12.14.1781553919507; Mon, 15 Jun 2026 13:05:19 -0700 (PDT) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Mon, 15 Jun 2026 15:05:18 -0500 Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Mon, 15 Jun 2026 15:05:18 -0500 Mime-Version: 1.0 X-Superhuman-ID: mqfn6x2u.3b682c0f-c7e3-4bf7-b288-ab5772e013f3 X-Superhuman-Draft-ID: draft0031b8d9ffd2c1cc References: X-Mailer: Superhuman Desktop (2026-06-15T19:06:10Z) In-Reply-To: From: Warren Kumari Date: Mon, 15 Jun 2026 15:05:18 -0500 X-Gm-Features: AVVi8CfdcYvcMsJ0ti9iYhgNFI7Zzllfbc5kmju_QaeXjBHvNR6kaZqnEPZxoy0 Message-ID: To: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Content-Type: multipart/alternative; boundary="0000000000008550e60654505879" Message-ID-Hash: 2VKGE2EDFAFUVXPK3AKWHDLCMHKKNGSX X-Message-ID-Hash: 2VKGE2EDFAFUVXPK3AKWHDLCMHKKNGSX X-MailFrom: warren@kumari.net X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "dnsop@ietf.org WG" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BDNSOP=5D_Re=3A_Conclusion_and_request_for_action_after_AD_revie?= =?utf-8?q?w_of_draft-ietf-dnsop-structured-dns-error-20?= List-Id: IETF DNSOP WG mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000008550e60654505879 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 15, 2026 at 5:02 AM, Vladim=C3=ADr =C4=8Cun=C3=A1t < vladimir.cunat=3D40nic.cz@dmarc.ietf.org> 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, 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=E2=80= =A6 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) Thoug= h > it might be impractical/complicated to make such a decision dynamically. > > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-leave@ietf.org > --0000000000008550e60654505879 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable




On Mon, Jun 15, 2026= at 5:02 AM, Vladim=C3=ADr =C4=8Cun=C3=A1t <= ;vladimir.cunat=3D40nic.cz@dmarc.ietf.org> wrot= e:
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:
=C2=A0=C2=A0To 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 foll= owing text have a fairly fuzzy meaning, except the JSON-minifcation part, so I'm no= t sure if MUST vs. SHOULD makes a practical difference when formulated this way.


I agree w= ith Vladimir here.=C2=A0

The context is:
" To avoid exceeding the max= imum EDNS0 size [RFC9715] the generated
=C2=A0=C2=A0 JS= ON values SHOULD be as short as possible: short domain names,
=C2=A0=C2=A0 concise text in the values for the "j" and "o&= quot; names, and minified
=C2=A0=C2=A0 JSON (that is, without= spaces or line breaks between JSON elements).
=C2=A0=C2=A0 O= therwise, there is a risk that the response will get fragmented."
<= /div>

Making this MUST would mean that the domain name h= as to be something=C2=A0like a.cc, the reason = would be something like "because" and the org would have to renam= e 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&#= 39;ve decided=C2=A0to do that, we might as well make it useable, and so SHO= ULD seems fine to me.=C2=A0
But, obviously, I don't have = to defend this in front of the=C2=A0IESG, and so if Eric still thinks it ne= eds to be a MUST to pass, he's probably right=E2=80=A6
W<= /div>


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


=20

_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-leave@ietf= .org


--0000000000008550e60654505879--