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

[Benjamin Kaduk <[e-mail]>]

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.