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