Re: [DNSOP] Deprecating the status opcode

Ray Bellis <ray@bellis.me.uk> Thu, 16 May 2019 10:50 UTC

Return-Path: <ray@bellis.me.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 BF2F11201BB for <dnsop@ietfa.amsl.com>; Thu, 16 May 2019 03:50:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=portfast.net
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 U0HNRt6995cO for <dnsop@ietfa.amsl.com>; Thu, 16 May 2019 03:50:52 -0700 (PDT)
Received: from mail.portfast.net (mail.portfast.net [IPv6:2a03:9800:20:1::2]) (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 343A8120074 for <dnsop@ietf.org>; Thu, 16 May 2019 03:50:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=portfast.net; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: 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=+C8OSrGmlDkly84gC8Kx4i0JMihjQ2z4o0VEs/E4uUM=; b=XAZMHH2uDXOgp/LejGkj41j00i yHefQ3ZMdyf/MuXKS3r5efdDBovxxB3Ucl/slNlyvAEBwG/kLroCMcT+9H7l5X8iJyZPdV/6PmVoI QnXC5iJpRSod6rqKVb3ZTuC0JNrnxvNihhE/WEptW5Xk2EDCB6Zi3cnD/CwrnRdWGPho=;
Received: from [88.212.170.147] (port=64484 helo=Rays-MacBook-Pro.local) by mail.portfast.net ([188.246.200.9]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1hRDyM-000430-4k (Exim 4.89) for dnsop@ietf.org (return-path <ray@bellis.me.uk>); Thu, 16 May 2019 10:50:50 +0000
To: dnsop@ietf.org
References: <064BA295-F3DD-46E4-86A9-E03CF68EB6BC@sinodun.com> <20190515170020.3F76420141A62A@ary.qy> <CA+nkc8DTfhf7N9Wx0EaRC7kTWJcRMdv2v6P9Z+HH0DzvGbAuhw@mail.gmail.com> <7eca1d5a-bf88-b004-e260-be5eaeaffb05@nic.cz>
From: Ray Bellis <ray@bellis.me.uk>
Message-ID: <e09d29a0-d1fd-d1f9-82c0-5974574bb50d@bellis.me.uk>
Date: Thu, 16 May 2019 11:50:49 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <7eca1d5a-bf88-b004-e260-be5eaeaffb05@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zMvkHzcpxDQnNQo2RyjJsfAp2uI>
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: Thu, 16 May 2019 10:50:55 -0000


On 16/05/2019 11:23, Petr Špaček wrote:

> Personally I think it is not worth the effort, it will just add one more
> RFC to read and does not help the protocol maintenance.
> 
> I would say that it is better to have one "cleanup" RFC instead of
> one-off doc with one useful paragraph in it. With one bigger document we
> could say to newcommers "this is list of things you can ignore when you
> encounter them in pile of DNS RFCs".

Must as I like simple short documents, I'm inclined to agree.

I recently had an interesting debate with someone about the correct use 
of the flag bits for opcodes other than QUERY.

While some later docs do talk about uses of those bits for e.g. UPDATE, 
there's no place I could find that specifically says that header bits 
are opcode specific and MUST NOT be copied into the response without 
explicit (per-opcode) instruction.

Ray