Re: [DNSOP] Status of draft-ietf-dnsop-terminology-bis
"Paul Hoffman" <paul.hoffman@vpnc.org> Sun, 22 April 2018 20:00 UTC
Return-Path: <paul.hoffman@vpnc.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 B24D6126D3F for <dnsop@ietfa.amsl.com>; Sun, 22 Apr 2018 13:00:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 NOV6hsUCQSD0 for <dnsop@ietfa.amsl.com>; Sun, 22 Apr 2018 13:00:36 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 15FA6126CC7 for <dnsop@ietf.org>; Sun, 22 Apr 2018 13:00:36 -0700 (PDT)
Received: from [10.32.60.37] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w3MJxnWO041889 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 22 Apr 2018 12:59:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.37]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Matthijs Mekking <matthijs@pletterpet.nl>
Cc: dnsop@ietf.org
Date: Sun, 22 Apr 2018 13:00:33 -0700
X-Mailer: MailMate (1.11.1r5471)
Message-ID: <224D06C2-F9EC-42C6-A656-BCB50AAE7C97@vpnc.org>
In-Reply-To: <22fe4a5c-fcd5-50fd-71da-d714d8f31fe5@pletterpet.nl>
References: <7C873271-A784-4594-91A3-48C697EEC613@vpnc.org> <22fe4a5c-fcd5-50fd-71da-d714d8f31fe5@pletterpet.nl>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/VllfxgMVcju5_E_1zIExiTOe6oU>
Subject: Re: [DNSOP] Status of draft-ietf-dnsop-terminology-bis
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: Sun, 22 Apr 2018 20:00:37 -0000
On 19 Mar 2018, at 5:21, Matthijs Mekking wrote: > Negative response: > > I and some others have been using the term 'Negative response' to > indicate that the response does not contain any records in the Answer > section. Current definition seems to imply that this is only the case > if the RCODE is NXDOMAIN, NOERROR, SERVFAIL or if there was a timeout > (unreachable). The definition I have been using includes responses > with other RCODEs too, for example FORMERR or REFUSED. > > I wonder if this is just me and my bubble or if others also a slightly > different meaning of 'Negative response' as it is defined now. If > there are others, is it worth spending a line or two about this here? Some implementations put things in the Answer section even when it seems like they are saying negative things. This does not appear to be prohibited by RFC 1035 or updates, but I could be wrong. > RRsets: > > Raised by a discussion I had at the Hackathon, I think it would be > useful to add some clarification about RRSIGs and their role with > respect to RRsets. Perhaps a quote from RFC4035 will do: > > An RRset MAY have multiple RRSIG RRs associated with it. Note that > as RRSIG RRs are closely tied to the RRsets whose signatures they > contain, RRSIG RRs, unlike all other DNS RR types, do not form > RRsets. In particular, the TTL values among RRSIG RRs with a > common > owner name do not follow the RRset rules described in [RFC2181]. Great suggestion. I only remember that last bit some of the time when I (incorrectly) say "all records in an RRset have the same TTL". > Last, I don't fully understand the meaning of the cryptic comment > about QTYPE=ANY that is under the RRset definition: > > (This definition is definitely not the same as "the > response one gets to a query for QTYPE=ANY", which is an > unfortunate misunderstanding.) > > Can you explain why this comment is here? Um, no. :-( I'll remove it. --Paul Hoffman
- [DNSOP] Status of draft-ietf-dnsop-terminology-bis Paul Hoffman
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Matthijs Mekking
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Matthew Pounsett
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Paul Vixie
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Matthijs Mekking
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Stuart Cheshire
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… John Dickinson
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Paul Hoffman
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Paul Hoffman
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Paul Hoffman
- [DNSOP] Lameness terminology (was: Status of draf… Shane Kerr
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Edward Lewis
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Amreesh Phokeer
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… David Huberman
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Mark Andrews
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… David Huberman
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Bill Woodcock
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Frederico A C Neves
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Mark Andrews
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… David Huberman
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Mark Andrews
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… David Huberman
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Mark Andrews
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Bill Woodcock
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Bill Woodcock
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Bill Woodcock
- Re: [DNSOP] Fixing lame delegations Paul Hoffman
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Mark Andrews
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Mark Andrews
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… John Kristoff
- Re: [DNSOP] [Ext] Lameness terminology Paul Vixie
- Re: [DNSOP] [Ext] Lameness terminology Shane Kerr
- Re: [DNSOP] [Ext] Lameness terminology Shane Kerr
- Re: [DNSOP] [Ext] Lameness terminology Matthew Pounsett
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Edward Lewis
- Re: [DNSOP] [Ext] Lameness terminology Joe Abley
- Re: [DNSOP] [Ext] Lameness terminology Joe Abley
- Re: [DNSOP] [Ext] Lameness terminology Edward Lewis
- Re: [DNSOP] [Ext] Lameness terminology Paul Hoffman
- Re: [DNSOP] [Ext] Lameness terminology Edward Lewis