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

[Paul Hoffman <[e-mail]>]

On Aug 27, 2018, at 3:59 PM, Benjamin Kaduk <[e-mail]> wrote:
> 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.)

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. 

> 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?

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. 

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

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.

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

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.

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

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
> DNS-over-QUIC?

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

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

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.

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

So are the authors. :-)

--Paul Hoffman