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

"Paul Hoffman" <paul.hoffman@vpnc.org> Fri, 31 August 2018 22:31 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B72E130DFA; Fri, 31 Aug 2018 15:31:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVMZflq8LRxq; Fri, 31 Aug 2018 15:31:39 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768B812785F; Fri, 31 Aug 2018 15:31:39 -0700 (PDT)
Received: from [10.32.60.65] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w7VMV7Ju058808 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 31 Aug 2018 15:31:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.65]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Adam Roach <adam@nostrum.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dnsop-terminology-bis@ietf.org, suzworldwide@gmail.com, dnsop-chairs@ietf.org, dnsop@ietf.org
Date: Fri, 31 Aug 2018 15:31:34 -0700
X-Mailer: MailMate (1.11.3r5509)
Message-ID: <FA26D5F9-CF28-44A4-870D-954B7157DAEF@vpnc.org>
In-Reply-To: <7fc7565f-c798-9ec5-d20c-bd001bac700d@nostrum.com>
References: <153561293370.3144.18070168241164270027.idtracker@ietfa.amsl.com> <5EC914D6-EB2F-439E-9DE4-29853DE3B6F6@icann.org> <7fc7565f-c798-9ec5-d20c-bd001bac700d@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/T1DGQvBnmTUPGVW0UUnO7d_5Jng>
Subject: Re: [DNSOP] [Ext] Adam Roach's No Objection on draft-ietf-dnsop-terminology-bis-13: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
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: Fri, 31 Aug 2018 22:31:41 -0000

On 31 Aug 2018, at 14:47, Adam Roach wrote:

>>> §5:
>>>> Owner:  The domain name where a RR is found ([RFC1034], Section 
>>>> 3.6).
>>> Nit: "...an RR..." (see RFC 7322 §1, CMOS 10.9)
>> There too.
>
>
> In that case, this definition appears to be missing quotation marks.

Good point. Added.

>>> ---------------------------------------------------------------------------
>>>
>>> §6:
>>>
>>>> Privacy-enabling DNS server:  "A DNS server that implements DNS 
>>>> over
>>>>     TLS [RFC7858] and may optionally implement DNS over DTLS
>>>>     [RFC8094]."  (Quoted from [RFC8310], Section 2)
>>> This definition seems incomplete in light of the mechanism defined 
>>> in
>>> draft-ietf-doh-dns-over-https.
>> Agree, but it is what we have as a quotation.
>
>
> Other definitions consist of quotations plus additional information 
> (frequently in the form of another quotation). If the notion here is 
> that you don't want to perform any synthesis, I'm sympathetic to that 
> (although other definitions do contain substantial synthesis, so it 
> doesn't seem like a hard-and-fast rule). If that's not the rationale, 
> consider adding explanatory text pointing to DoH. I'm not really 
> bothered either way, though. As Spencer is fond of saying: do the 
> right thing.

Another good point. Added as well.

--Paul Hoffman