[DNSOP] Re: Wallet is not implementable.

Joe Abley <jabley@strandkip.nl> Mon, 24 June 2024 09:12 UTC

Return-Path: <jabley@strandkip.nl>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE1AC14CF18 for <dnsop@ietfa.amsl.com>; Mon, 24 Jun 2024 02:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strandkip.nl
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3X0tUp3mW7J for <dnsop@ietfa.amsl.com>; Mon, 24 Jun 2024 02:12:24 -0700 (PDT)
Received: from st43p00im-ztdg10063201.me.com (st43p00im-ztdg10063201.me.com [17.58.63.182]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A4FC14F6AF for <dnsop@ietf.org>; Mon, 24 Jun 2024 02:12:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=strandkip.nl; s=sig1; t=1719220343; bh=7dwKsaz06uJmDQdP0FpTS9Pxv60zwDBdjMBZaPi0i1c=; h=Content-Type:From:Mime-Version:Subject:Date:Message-Id:To; b=V0rK3rCfXLP3hGqzGlbvBd3hM+NJerN1lOooxffyqc205CazxXLFuZ0wbqplUle+6 HN4suf50hGOQknpP/J5MYMKrKdcD7MdkgPvOE06Jn3fMhlsRTPuMEzcwKY4sKacZsm sxFKe6BH2gFODnSH3bUfJDq8XWaM6ay4GcjseV1E3QP7bdnqq/B5JxI8/fB79bevFW VHjkxoG7aOngJHEAPdPl2SXkH+fxsfEK8GpmMtgzqhAlCrs0xg8du0yTS8Hju2HNoH q03Lov1gBRyLsN1vfK/A08F/6JF5V5k66vY3PjHHrEszxsfiUkfZboWbxhN2VzR5YV gw2FEmaLlnGbA==
Received: from smtpclient.apple (st43p00im-dlb-asmtp-mailmevip.me.com [17.42.251.41]) by st43p00im-ztdg10063201.me.com (Postfix) with ESMTPSA id CAE299809D6; Mon, 24 Jun 2024 09:12:22 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail-8D76A1DC-BC0C-4425-91D0-DB89C4E3BD53"
Content-Transfer-Encoding: 7bit
From: Joe Abley <jabley@strandkip.nl>
Mime-Version: 1.0 (1.0)
Date: Mon, 24 Jun 2024 11:11:48 +0200
Message-Id: <9C0A36BC-41D9-4DDC-9C77-27EB2C40F8DC@strandkip.nl>
References: <F8802827-EEE4-4309-9821-B7E2C5C82F10@isc.org>
In-Reply-To: <F8802827-EEE4-4309-9821-B7E2C5C82F10@isc.org>
To: Mark Andrews <marka@isc.org>
X-Mailer: iPad Mail (21F90)
X-Proofpoint-ORIG-GUID: SarqsNBAejRgS-CkrmjDnGWEKWr0rkav
X-Proofpoint-GUID: SarqsNBAejRgS-CkrmjDnGWEKWr0rkav
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-06-24_08,2024-06-21_01,2024-05-17_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 adultscore=0 bulkscore=0 mlxscore=0 clxscore=1030 malwarescore=0 phishscore=0 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2406240074
Message-ID-Hash: UVHGCPAZLUKJBDI7WPZ3M4E5V5EV7CEX
X-Message-ID-Hash: UVHGCPAZLUKJBDI7WPZ3M4E5V5EV7CEX
X-MailFrom: jabley@strandkip.nl
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 <dnsop@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: Wallet is not implementable.
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/z5tNRYKeQ7hKX7l2EaTUcP0jt1s>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

On 23 Jun 2024, at 04:58, Mark Andrews <marka@isc.org> wrote:

> Turning off escape processing prevents turning off multi line processing.

https://www.iana.org/assignments/dns-parameters/WALLET/wallet-completed-template

Our expert review guidelines are explicitly lenient so I suppose I'm not surprised this was accepted. However, it does seem like there is an actual cost to accepting things like this. Using WALLET as an example, the constrained RDATA format provides an implementation cost to parse and check the syntax of the resource record in DNS servers that is presumably going to be duplicated in the systems that consume this data from the DNS, as they apparently already do with TXT RRs. If, in fact, this new RRType had RDATA defined as "exactly like TXT" it would be a lot cheaper to implement in nameservers. Since some people think new RRTYPEs are hard to deploy specifically because they take a long time to be supported, perhaps this would be a win in more ways than one.

It seems like we could do three things about this:

(a) do nothing, this is fine, Mark enjoys this stuff and he'd be bored if he didn't have more of it

(b) change the expert review guidelines to push back on this kind of thing and say "no, use exactly TXT with underscore labels, you are not as special as you think"

(c) write some guidance for future applications of the form "basically TXT but with a different RRTYPE" to make things as cookie-cutter as possible for implementers, and add a question to the application template of the form "explain why you can't just use the cookie-cutter approach described in RFCxxx" with some guidance for expert reviewers in assessing the answer.

Personally I think underscore labels are a better and cheaper solution for a lot of applications, which makes me like (b). But I appreciate other people think differently and perhaps are already OMG NO PLEASE NOT AGAIN about the idea of restarting that conversation.

If anybody has any appetite for (c) then I could write something up.

It seems like it would be nice to be able to implement future new RRTypes like WALLET simply by adding an RRType to an array of RRTypes that are all implemented the same way, rather than writing new parsers for every one of them. It would also make applicants' lives easier since they could say "I want cookie-cutter WALLET" and not have to think about the consequences of how they define their RDATA. Of course there's some XKCD-927 risk in this approach.


Joe