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

["Paul Hoffman" <[e-mail]>]

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

> In message <[e-mail]>, 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