Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt

[Andrew Sullivan <[e-mail]>]

Hi,

On Tue, Aug 29, 2017 at 10:17:40PM +0000, Darcy Kevin (FCA) wrote:
> 
> So, as the sole definition in the foundational RFCs, perhaps that's the *only* context in which the term "QNAME" should have meaning. Which is why I suggested coming up with a different term to be used in other contexts, e.g. the resolver algorithm, the auth-server algorithm, negative caching and so forth. That other term could encompass more than just the name which was originally presented by the client as the QNAME; it could include end-of-CNAME-chain.
> 
[…] 
> It's *used* that way, but there is no *definition* in RFC 1034. That's my main point. We have only 2 competing definitions of "QNAME" -- RFC 1035 (with a limited context, as you point out) versus RFC 2308. Thus, we have a choice: to either reconcile the competing definitions via errata (where one "wins" and the other "loses"), or we can bifurcate into different terms. Personally, I prefer the 2-state solution, but it's not a strong preference.
>

Speaking as one of the presumed editors of post-7719 -- one who is,
so-presumed, supposed to sort this problem out -- I hope it's ok to
state _very strongly_ that I appreciate the extensive discussion of
this issue.  I think this is very much one of the kinds of knotty
terminological problems that has created enormous difficulty for
people approaching the DNS for the first time.  Not only are terms
hard to understand; but when you come across them, they seem to be
slippery.

At the same time, and taking off my editor hat for the moment, I am
quite uncomfortable having a terminology document (which is what this
thread is about) make the term not-slippery.  It _is_ slippery in the
reference documents.  I don't think it helps us to try to settle those
disputes.  I think 7719-bis can do two things:

    1.  Document, as clearly as possible, the nature of the ambiguity.
    This thread has helped, but I bet (I haven't checked with my
    co-editors) that a ¶ well-worked-out on the list (not necessarily
    the WG please note) would be welcome.

    2.  Define, as clearly as possible and using new terms, the
    distinctions in question and provide names for them.  These could
    be, of course, names not previously known.

I emphasise again that clarity of definitions is, at least for me, quite important, so ambiguous examples are super valuable.  Thanks!

A

-- 
Andrew Sullivan
[e-mail]