Subject: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-terminology-bis-13: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 27 Aug 2018 15:59:15 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnsop-terminology-bis-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

First off, thank you all for the effort that went into this document -- it's
quite helpful to have a central resource to refer to.

I agree with Mirja about further clarity for the 2308 updates being nice, and
about the "primary master" definition's clarification.  (The latter seems like
it would meet a DISCUSS criterion, as internal inconsistency makes it difficult
to have a clear specification.  But it would be absurd to apply it here when
the fix is clear.)

I appreciate that "privacy of names" and "privacy of data associated with
names" are called out as potential facets of a naming system to consider, but I
would like to understand better why they are not given more treatment in this
document.  The surrounding text seems to imply that they are not needed to
describe the DNS and that a pure lexicon need not explore the privacy
considerations of the terms being defined; is this correct, and was there much
discussion on this question?

In a similar vein, it was a little surprising to only see the facets be
expounded upon for the global DNS and not the other related naming systems,
though it's unclear that there would be much non-overlap for the other systems
considered.

In Section 6:

I'm a little confused about the interaction between "stealth server"
and "hidden master" -- if a hidden master is a stealth server, it is "like
a slave" and would thus be expected to get its configuration from yet
another master?  But this doesn't jibe with being listed as the MNAME.
I accept that DNS terminology is a complicated area and there may not
be a right answer, of course.

The "privacy-enabling DNS server" definition seems too narrowly scoped to
particular existing technologies as opposed to describing the properties
provided (or mentioning the possibility for future protocols to be
included).  Is a DNS-over-HTTP server "privacy-enabling"?  How about
DNS-over-QUIC?

Section 8

Interesting to see the term "Opt-Out zone" used but not defined in this
document.  (No action needed, and I do see the definition of "Opt-Out".)

Finally, I am somewhat sympathetic to the indications that this document may
(also) be appropriate as Informational; I look forward to seeing how that
discussion unfolds.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Aug 2018 18:17:12 +0000

> to have a clear specification.  But it would be absurd to apply it here when

We'll fix it based on what Warren tells us comes out of the telechat. This is edge-case-y enough where we need more specific input from the IESG. 

> discussion on this question?

There was no discussion of this at all. The description you are referring to was added in the -04 draft in January 2017, and was unchanged since. 

> though it's unclear that there would be much non-overlap for the other systems

The document is about definitions that apply mostly to the global DNS. The facet list was added in hopes that other documents that describe other naming systems can use the facets (or maybe additional ones) to help compare those naming systems with the global DNS.

> be a right answer, of course.

There might not be *one* right answer. Note that this definition appeared in an RFC very late in the development of the DNS, even though the functionality had been widely used for over a decade.

> included).  

It is a quote from an existing RFC, and we tried to rely on such quotes over our own definitions.

> Is a DNS-over-HTTP server "privacy-enabling"?

Assuming you mean DNS-over-HTTPS, it probably will be in the future.

>  How about

Some of us are hoping that that will not exist other than as DNS-over-HTTPS-over-QUIC (DoHQ).

> document.  (No action needed, and I do see the definition of "Opt-Out".)

RFC 5155 does define it as "Opt-Out zone:  a zone with at least one Opt-Out NSEC3 RR.", but the term is not commonly used.

> (also) be appropriate as Informational; I look forward to seeing how that

So are the authors. :-)

--Paul Hoffman