Re: [DNSOP] Status of draft-ietf-dnsop-terminology-bis
Matthijs Mekking <matthijs@pletterpet.nl> Mon, 19 March 2018 12:21 UTC
Return-Path: <matthijs@pletterpet.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 3842E1270AE for <dnsop@ietfa.amsl.com>; Mon, 19 Mar 2018 05:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 tMmWUh1g75cl for <dnsop@ietfa.amsl.com>; Mon, 19 Mar 2018 05:21:17 -0700 (PDT)
Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 32AF2124B17 for <dnsop@ietf.org>; Mon, 19 Mar 2018 05:21:16 -0700 (PDT)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2JCCxhY101931 for <dnsop@ietf.org>; Mon, 19 Mar 2018 12:21:16 GMT
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2gtd0vg14h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <dnsop@ietf.org>; Mon, 19 Mar 2018 12:21:16 +0000
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w2JCLE8U020684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <dnsop@ietf.org>; Mon, 19 Mar 2018 12:21:15 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w2JCLDR4016223 for <dnsop@ietf.org>; Mon, 19 Mar 2018 12:21:14 GMT
Received: from [172.19.129.102] (/216.146.45.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Mar 2018 05:21:13 -0700
To: dnsop@ietf.org
References: <7C873271-A784-4594-91A3-48C697EEC613@vpnc.org>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <22fe4a5c-fcd5-50fd-71da-d714d8f31fe5@pletterpet.nl>
Date: Mon, 19 Mar 2018 13:21:11 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <7C873271-A784-4594-91A3-48C697EEC613@vpnc.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8836 signatures=668693
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=12 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803190007
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/lpZ-5UNAbCGuMuq23zVMDe7gPnc>
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: Mon, 19 Mar 2018 12:21:19 -0000
Hi, While I was not waiting for WG last call, it is a while ago since I have read this draft. Positive is that I read it without it leading to a lot of confusion or outrage. I have some small comments though. 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? 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]. 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? Thanks, best regards, Matthijs On 05-03-18 17:14, Paul Hoffman wrote: > Greetings. As you can see, draft-ietf-dnsop-terminology-bis-09.txt is > out. Reading the diff might be a bit difficult because of the > reorganization of some sections that y'all asked for, but I think the > result is worth the extra effort. > > We're still not done yet. I took a hiatus from finishing the list of > definitions that people wanted more scrutiny on, but will start that > again soon. I hope we'll be done with that list by mid-April and then be > ready for WG last call. > > As a side note, some of the changes in this version came from people > reading the document fresh. I encourage folks who were maybe waiting for > WG Last Call to do a first deep reading of the document to instead do so > now. The work that everyone is doing on this document will go a long way > to making the final RFC more valuable for lots of folks entering the field. > > --Paul Hoffman > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
- [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