[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-terminology-bis-13: (with COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Mon, 27 August 2018 22:59 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3430D130E17; Mon, 27 Aug 2018 15:59:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dnsop-terminology-bis@ietf.org, Suzanne Woolf <suzworldwide@gmail.com>, dnsop-chairs@ietf.org, suzworldwide@gmail.com, dnsop@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153541075520.29995.11362089145955536527.idtracker@ietfa.amsl.com>
Date: Mon, 27 Aug 2018 15:59:15 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Khe6pt-ueA5LGEciV79_-eHmKGg>
Subject: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-terminology-bis-13: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Aug 2018 22:59:15 -0000
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.
- [DNSOP] Benjamin Kaduk's No Objection on draft-ie… Benjamin Kaduk
- Re: [DNSOP] [Ext] Benjamin Kaduk's No Objection o… Paul Hoffman