IETF Logo Mail Archive

Re: [DNSOP] About draft-ietf-dnsop-extended-error

Paul Vixie <paul@redbarn.org> Tue, 14 November 2017 09:06 UTC

Return-Path: <paul@redbarn.org>
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 188EF124205 for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 01:06:48 -0800 (PST)
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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 EJIhnyD2sIag for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 01:06:47 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E72612008A for <dnsop@ietf.org>; Tue, 14 Nov 2017 01:06:47 -0800 (PST)
Received: from [IPv6:2001:559:8000:c9:2c81:6cd7:5872:4e2f] (unknown [IPv6:2001:559:8000:c9:2c81:6cd7:5872:4e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 00ECA61FA2; Tue, 14 Nov 2017 09:06:46 +0000 (UTC)
Message-ID: <5A0AB226.9040105@redbarn.org>
Date: Tue, 14 Nov 2017 01:06:46 -0800
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.20 (Windows/20171012)
MIME-Version: 1.0
To: Joe Abley <jabley@hopcount.ca>
CC: dnsop@ietf.org
References: <20171112012835.GA16257@laperouse.bortzmeyer.org> <alpine.DEB.2.11.1711131236140.14243@grey.csi.cam.ac.uk> <yblmv3psjmk.fsf@wu.hardakers.net> <20171114073227.GO3322@mournblade.imrryr.org> <3b429f8e-1046-e70d-ab9f-0ac4ba735232@time-travellers.org> <20171114084725.GP3322@mournblade.imrryr.org> <7043569809190448225@unknownmsgid>
In-Reply-To: <7043569809190448225@unknownmsgid>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/m_ZPd6wqRuhY_dmtp1yxMkALpaI>
Subject: Re: [DNSOP] About draft-ietf-dnsop-extended-error
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 14 Nov 2017 09:06:48 -0000


Joe Abley wrote:
> ...
>
> I don't think it's sensible to say absolutely that there will never be a
> need to disambiguate NXDOMAIN or NOERROR since never is an awfully long
> time, and who knows or dares to dream?

that outcome depends on scope. if you imagine a protocol speaker 
behaving differently based on fine-grained differences in cause that 
relate in small ways to the larger NXDOMAIN/NOERROR status code, then i 
think we should not allow for that -- it would be madness, even compared 
to the present day.

if you believe that it will appear in "dig" output and syslogs and 
dnstap traces, so as to help diagnosticians and academicians decide the 
whichness of what, after the fact, then i agree, we should not prohibit 
the fine detail just because we think the gross details are obvious.

-- 
P Vixie

v2.23.0 | Report a Bug | By Email