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

From: Mark Andrews <[email-masked]>
Date: Wed, 05 Apr 2017 04:35:25 +1000

In message <[email-masked]>, Stephane Bortzmeyer writes:
> On Mon, Mar 13, 2017 at 08:59:32AM -0700,
>  [email-masked] <[email-masked]> wrote 
>  a message of 45 lines which said:
> 
> >         Title           : DNS Terminology
> >         Authors         : Paul Hoffman
> >                           Andrew Sullivan
> >                           Kazunori Fujiwara
> > 	Filename        : draft-ietf-dnsop-terminology-bis-05.txt
> 
> 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.

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.

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

Mark

> I filed an errata against RFC 2308
> <https://www.rfc-editor.org/errata_search.php?eid=4983>
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Peter van Dijk" <[email-masked]>
Date: Wed, 05 Apr 2017 08:57:18 +0200

Hello Stephane,

> <https://www.rfc-editor.org/errata_search.php?eid=4983>

Notwithstanding your stubborn redefinition in 8020, the text in 2308 is 
correct and this erratum is wrong.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 07 Apr 2017 10:55:52 -0700

>> which seems used only by this RFC. IMHO, we should keep only the RFC

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.

> 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."

> 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

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 07 Apr 2017 10:57:57 -0700

On 4 Apr 2017, at 23:57, Peter van Dijk wrote:

> Notwithstanding your stubborn redefinition in 8020, the text in 2308 
> is correct and this erratum is wrong.

That "stubborn redefinition" has modern WG and IETF consensus.

--Paul Hoffman

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 07 Apr 2017 11:39:53 -0700

(I'm surprised our philosophy-minded folks didn't answer this. I'll take 
a stab, acknowledging that I'm only a philosophy tourist.)

On 30 Mar 2017, at 13:41, Andrew McConachie wrote:

> If a domain name is made up of labels, and labels are made up of 
> octets, then can there be non-digital representations of domain names?

Yes. The octets in the labels can be encoded into writing systems, and 
there can be a commonly-recognized display format for the representation 
of a group of labels.

> For example, if I spray paint 'www.example' on the side of a bus, is 
> it not a domain name because it is made up of paint instead of octets?

It is a rendering (in paint, on a bus) a domain name in a 
commonly-accepted display format. Neither the paint nor the bus is the 
domain name.

Some history related to representation versus essence: 
https://essenceofbuddhism.wordpress.com/2016/04/19/what-the-finger-pointing-to-the-moon-analogy-really-means-from-zen-buddhism-the-buddha-in-the-shurangama-sutra/

> I don't see anything in this document restricting the terms to 'on the 
> wire' definitions. So I assume that the scope of 'domain name' 
> includes non-digital instantiations. Perhaps what's needed isn't so 
> much a new definition for label, but clarification on the scope of 
> these terms and their definitions.

I'm not sure that us going into the ontology of domain names would help 
someone reading the document.

--Paul Hoffman

---

From: Paul Vixie <[email-masked]>
Date: Fri, 07 Apr 2017 11:44:39 -0700

> That "stubborn redefinition" has modern WG and IETF consensus.

well, yes, but, it's still wrong.

-- 
P Vixie

---

From: Andrew McConachie <[email-masked]>
Date: Sat, 8 Apr 2017 15:23:50 +0200

On 4/7/17 20:39, Paul Hoffman wrote:
> (I'm surprised our philosophy-minded folks didn't answer this. I'll 
> take a stab, acknowledging that I'm only a philosophy tourist.)
>
> there can be a commonly-recognized display format for the 
> representation of a group of labels.
>
/Ceci n'est pas une pipe./

If I understand correctly this definition of domain name incorporates 
actual pipes and explicitly not paintings of pipes. Since the draft says 
a domain name is essentially octets, and only octets, any representation 
of domain names not composed of octets is just a representation, not an 
actual domain name.

I don't believe that's how the term is used in common parlance, but I 
can see how that definition works for this document. Thanks for the 
clarification!

--Andrew

---

From: "Peter van Dijk" <[email-masked]>
Date: Sat, 08 Apr 2017 15:38:07 +0200

> is correct and this erratum is wrong.

And to clarify, regardless of whether we agree on what the -right- 
definition of QNAME is, your erratum breaks 2308. After the sentence you 
replace, more sentences follow, and they no longer make sense after the 
replacement. Furthermore, 2308 relies on the definition of QNAME as it 
stands in 2308 today, so if you want to ‘fix’ the definition of 
QNAME in 2308, you need to make a lot more edits to it. (which given the 
terrible readability of 2308 is not the worst idea).

Kind regards,

---

From: "Peter van Dijk" <[email-masked]>
Date: Sat, 08 Apr 2017 15:50:54 +0200

> <https://www.rfc-editor.org/errata_search.php?eid=4983>

A question unrelated to the content of this erratum: if you had not 
posted here to mention your erratum, how would people have been able to 
find out? I can find various IETF lists that receive errata for more 
recent RFCs, but https://datatracker.ietf.org/doc/rfc2308/email/ does 
not list any addresses that I could subscribe to.

Kind regards,