Re: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-05.txt

"Paul Hoffman" <paul.hoffman@vpnc.org> Fri, 07 April 2017 17:55 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 267D312957B for <dnsop@ietfa.amsl.com>; Fri, 7 Apr 2017 10:55:53 -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 lJc0sCHaULUp for <dnsop@ietfa.amsl.com>; Fri, 7 Apr 2017 10:55:51 -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 D746312956A for <dnsop@ietf.org>; Fri, 7 Apr 2017 10:55:48 -0700 (PDT)
Received: from [10.32.60.173] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v37HtW5g058433 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Apr 2017 10:55:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.173]
From: "Paul Hoffman" <paul.hoffman@vpnc.org>
To: "Mark Andrews" <marka@isc.org>
Cc: "Stephane Bortzmeyer" <bortzmeyer@nic.fr>, dnsop@ietf.org
Date: Fri, 07 Apr 2017 10:55:52 -0700
Message-ID: <02133DF7-5EE0-4064-9739-C7313B3E8F5B@vpnc.org>
In-Reply-To: <20170404183525.2B15A6A8A07B@rock.dv.isc.org>
References: <148942077219.17007.342057944218385620@ietfa.amsl.com> <20170328143352.GA12923@laperouse.bortzmeyer.org> <20170404183525.2B15A6A8A07B@rock.dv.isc.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.6r5347)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/d1mJLtc5hcAXDCiJk5_4sIkOwsE>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-05.txt
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: Fri, 07 Apr 2017 17:55:53 -0000

On 4 Apr 2017, at 11:35, Mark Andrews wrote:

> In message <20170328143352.GA12923@laperouse.bortzmeyer.org>rg>, Stephane 
> Bortzmeyer writes:
>> The new definition of QNAME describes as equivalent two conflicting
>> definitions, the original one, in RFC 1034, and the one of RFC 2308,
>> which seems used only by this RFC. IMHO, we should keep only the RFC
>> 1034 definition.

As noted in the current draft, RFC 1034 says:

A standard query specifies a target domain name (QNAME), query type
(QTYPE), and query class (QCLASS) and asks for RRs which match.

To me, the use of appositives for QNAME, QTYPE, and QCLASS gives them 
definitions.

RFC 1034 also says:

The query contains a QTYPE, QCLASS,
and QNAME, which describe the types and classes of desired information
and the name of interest.


> RFC 1034
>
>             If the data at the node is a CNAME, and QTYPE doesn't
>             match CNAME, copy the CNAME RR into the answer section
>             of the response, change QNAME to the canonical name in
>             the CNAME RR, and go back to step 1.
>
> Note "QNAME" refers the the name *after* CNAME substituion when you
> are following the process as described in 4.3.2. Algorithm.

This is indeed the definition of the algorithm, not of the terms. But 
RFC 1034 says that the algorithm is not definitive: "The actual 
algorithm used by the name server will depend on the local OS and data 
structures used to store RRs."

> There is no confict between 1034 and 2308.  Only a failure to
> examine all uses of QNAME in 1034.

We disagree here. RFC 2038 defines QNAME as: "...the name in the query 
section of an answer, or where this resolves to a CNAME, or CNAME chain, 
the data field of the last CNAME." That definition is derived from the 
optional algorithm.

--Paul Hoffman