Re: [DNSOP] Deprecating the status opcode

Chris Thompson <cet1@cam.ac.uk> Wed, 15 May 2019 16:36 UTC

Return-Path: <cet1@hermes.cam.ac.uk>
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 3A11C120182 for <dnsop@ietfa.amsl.com>; Wed, 15 May 2019 09:36:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cam.ac.uk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51xSlIkIvOqY for <dnsop@ietfa.amsl.com>; Wed, 15 May 2019 09:36:36 -0700 (PDT)
Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2267120178 for <dnsop@ietf.org>; Wed, 15 May 2019 09:36:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cam.ac.uk; s=20180806.ppsw; h=Sender:Content-Type:Mime-Version:References:In-Reply-To: Message-ID:Subject:Reply-To:To:From:Date:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=wMUpvQzrV0K4HwgrtxYA5lgjQ2Qjl0azGpti5skB4k8=; b=u3GsQ86U309547Q3Xqfqh1x0p6 iwlQNed9HrH4czbwoZAq/v4RSaWGgjXPfs9yd3WjeX55DRqK51YznaL+F6lbs9zc3/I7N7xpPIbiw xvtlJ+u7SVQRNixgHeGZ4vV4fUMdNTGQlOEO95XgrF0CLMtfzwTh1wf4CH1KG+RW6e+w=;
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:58092) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:cet1) id 1hQwtM-000BgO-iJ (Exim 4.91) for dnsop@ietf.org (return-path <cet1@hermes.cam.ac.uk>); Wed, 15 May 2019 17:36:32 +0100
Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1hQwtM-0008Lq-NW (Exim 4.91) for dnsop@ietf.org (return-path <cet1@hermes.cam.ac.uk>); Wed, 15 May 2019 17:36:32 +0100
Received: from [128.232.253.131] by old-webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 15 May 2019 17:36:32 +0100
Date: 15 May 2019 17:36:32 +0100
From: Chris Thompson <cet1@cam.ac.uk>
To: dnsop@ietf.org
Reply-To: cet1@cam.ac.uk
Message-ID: <Prayer.1.3.5.1905151736320.23780@hermes-2.csi.cam.ac.uk>
In-Reply-To: <8C30EFAB-6D28-4B71-83FC-A038BA82F8B3@rfc1035.com>
References: <064BA295-F3DD-46E4-86A9-E03CF68EB6BC@sinodun.com> <ecf35601-a2e6-df28-352c-427b39d892c0@time-travellers.org> <8C30EFAB-6D28-4B71-83FC-A038BA82F8B3@rfc1035.com>
X-Mailer: Prayer v1.3.5
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Sender: Chris Thompson <cet1@hermes.cam.ac.uk>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/InlJ_CkojGWJgoPjy6cFl1uE98I>
Subject: Re: [DNSOP] Deprecating the status opcode
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 May 2019 16:36:39 -0000

On May 15 2019, Jim Reid wrote:

>> On 15 May 2019, at 12:55, Shane Kerr <shane@time-travellers.org>; wrote:
>> 
>> This seems like the most non-controversial document ever in the history
>> of documents.
>
>A non-controversial DNS doc at the IETF? That'll be a first. :-)

Well, I am sure some nit-picking can be organised. As well as RFC 1035,
surely the admirably concise definition of a status query in section 3.8
of RFC 1034 deserves to be mentioned?

There is pre-history as well, of course. In RFC 883 the opcodes 2 and 3
were assigned to "completion queries" CQUERYM and CQUERYU. Or rather, they
would have been except for an obvious typo which actually assigns 2 to
both of them [top of page 27]. It's quite shocking that no-one ever seems
to have filed an official erratum against RFC 883 about this!

RFC 1996 assigned opcode 4 to NOTIFY without any explanation as to why 3
might be, in some sense, already reserved.

-- 
Chris Thompson
Email: cet1@cam.ac.uk