Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-02.txt
Petr Špaček <petr.spacek@nic.cz> Fri, 07 April 2017 14:21 UTC
Return-Path: <petr.spacek@nic.cz>
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 BE5EB120227 for <dnsop@ietfa.amsl.com>; Fri, 7 Apr 2017 07:21:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 0kP_FXOsAAAB for <dnsop@ietfa.amsl.com>; Fri, 7 Apr 2017 07:21:23 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2244A1243F3 for <dnsop@ietf.org>; Fri, 7 Apr 2017 07:21:23 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:6c65:5aff:fea1:4735] (unknown [IPv6:2001:1488:fffe:6:6c65:5aff:fea1:4735]) by mail.nic.cz (Postfix) with ESMTPSA id 9E48B60A9C for <dnsop@ietf.org>; Fri, 7 Apr 2017 16:21:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1491574881; bh=ItrMKXyf0/NorWtoBjy69kM+RI8j81kZXIENPZl4OjA=; h=To:From:Date; b=n8R1qTcy4FFnVtKq8CHmGi1aDtlvhHd7xo7kO5c6pJkOD0zinrmCa78ZNavVU8Lcb mP9uHiGVwHBpdhw2GqHN0mIjYCYoAam6X0SCld/6ehzIQ16WPa8S3ON3Pw8mhMEP12 du2dTeiZt6X1GJzVuBsK6E5FzRjvIBWnbPQjLAt8=
To: dnsop@ietf.org
References: <149080054550.26806.17675916795295413492@ietfa.amsl.com> <20170331155217.GA19647@laperouse.bortzmeyer.org>
From: Petr Špaček <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <a6241649-9023-e40b-2416-3fdde00770bb@nic.cz>
Date: Fri, 07 Apr 2017 16:21:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170331155217.GA19647@laperouse.bortzmeyer.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Lu7xfGJB42NXNyQF7UCvN_AlXnw>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-02.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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, 07 Apr 2017 14:21:27 -0000
On 31.3.2017 17:52, Stephane Bortzmeyer wrote: > On Wed, Mar 29, 2017 at 08:15:45AM -0700, > internet-drafts@ietf.org <internet-drafts@ietf.org> wrote > a message of 43 lines which said: > >> Title : DNS Scoped Data Through Global '_Underscore' Naming of Attribute Leaves >> Author : Dave Crocker >> Filename : draft-ietf-dnsop-attrleaf-02.txt Before I dive into it, let me state that I definitely support this work and I will be happy to re-review is as necessary. Here is my first review of the draft so it can be hopefully taken as "would it be understandable to a causal developer?" view: For me, the text is hard to follow. It took me some time to find a path through the text which explains what problem is the draft solving and how. Particular comments are divided by section. Abstract -------- To make it obvious what the draft is about, I propose following extension of the Abstract (it merely borrows one sentence from Section 3): Formally, any DNS "RR" may occur for any domain name. However some services have defined an operational convention that applies to DNS leaf nodes that have a reserved node name, beginning with an underscore. The underscore construct is used to define a semantic scope for DNS records that are associated with the parent domain. This specification explores the nature of this DNS usage and defines the "DNS Global Underscore Scoped Entry Registry" registry with IANA. The purpose of the Underscore registry is to avoid collisions resulting from the use of the same underscore-based name, for different applications. The text could probably use some more editing but I will leave this for people with a better sense of proper English :-) 1. Introduction ---------------- The introduction is all good except, in my eyes, the last paragraph: This specification discusses the underscore "attribute" enhancement, provides an explicit definition of it, and establishes an IANA registry for the highest-level reserved names that begin with _underscore; underscore-based names that are farther down the hierarchy is handled within the scope of the highest-level _underscore name. It updates the many existing specifications that have defined underscore names, in order to aggregate the references to a single IANA table. To me it seems too dense for a first-time reader who is not familiar with the concept (yet). Please let me propose an alternative: This document formally defines how underscore labels act as "attribute" enhancements for their parent domain names. E.g. domain name "_domainkey.example." acts as attribute of parent domain name "example." To avoid collisions resulting from the use of the same underscore-based labels for different applications, this document establishes DNS Global Underscore Scoped Entry IANA Registry and proposes to replace some other registries. As a result this document updates the many existing specifications that have defined underscore names, in order to aggregate the references to a single IANA registry. The main problem which remains is that the term "attribute" is not used anywhere past Section 1. Let me comment on that later. Beyond this, I think that term "RR" (including the quotes!) needs to be formally defined. Right now it is undefined and thus vague and prone to misunderstanding. See below. 2. Scaling Benefits and TXT and SRV Resource Records ----------------------------------------------------- It seems to me that this section would be easier to follow if it was split into two: 2. Explanation of the generic ambiguity of TXT records, 3. Two-level structure of SRV names as an attempt to solve it. Also, the SRV section could use an example to make it easier to follow. Right now I had to re-read it couple times to make sure I understood references to "local scope" and "global scope" etc. 3. DNS Global Underscore Scoped Entry Registry Function -------------------------------------------------------- The table in here is nice but the text in section 3 is not using values from the table "Example of Underscore Names" as commented examples. It would IMHO really help to make the text easier to follow. Here it would be beneficial to again use the notion of "attribute" which was introduced in section 1 to describe the function of the registry. 4. DNS Global Underscore Scoped Entry Registry Definition ---------------------------------------------------------- - Name: The the first glance, the "Name" field/column is really confusing as the text talks about DNS but this is not a DNS name not its part. It gets even worse when "Constraints" reference "name" because it again forces me to think twice "Is this a compound DNS name? Or just this entry in the table? If it is about row in the table, why reference to name??" To avoid all this confusion I propose to rename field "Name" to "ID" (or "Mnemonic"). IMHO it avoids the confusion. The definition of "Constraints" then needs to be updated. - RR(s): Here I refer to the previous question about RR definition. Here it is even without quotes but I believe that intended meaning is "RR type(s)". We either have to define what "RR" is or use RR types. - Purpose: Again, this refers to the undefined "RR". - DNS label: Here the term label describes what is technically label but semantically the attribute. IMHO it should be good to make this clear by referring to both on a prominent place, possibly in the column header "DNS label (attribute)". > Section 5 "IANA considerations" does not use the names of standard > policies. draft-leiba-cotton-iana-5226bis, currently in the RFC editor > queue, says "It is not strictly required that documents use these > terms [the standard policies]; the actual requirement is that the > instructions to IANA be clear and unambiguous. However, use of these > terms is strongly recommended because their meanings are widely > understood." > > Therefore, I suggest to replace "have been specified in any published > RFC, or are documented by a specification published by another > standards organization" by "specification required (RFC 5226bis, > section 4.6). I support use of "specification required (RFC 5226bis, section 4.6)." Besides other things, kitten WG is going to add couple more underscore names in this draft: https://tools.ietf.org/html/draft-ietf-kitten-krb-service-discovery-00 Ideally the Section 5 "IANA considerations" should give an example text which can be re-used in new RFCs to add new underscore labels to the registry. The kitten WG could use it right away. Hopefully this will help to make the draft easier to understand for people who do not watch dnsop. I will be happy to contribute, just let me know! -- Petr Špaček @ CZ.NIC
- [DNSOP] Registration requirement (Was: Re: I-D Ac… Dave Crocker
- Re: [DNSOP] Registration requirement (Was: Re: I-… John Levine
- [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-02.… internet-drafts
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf… Bob Harold
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf… Stephane Bortzmeyer
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf… Petr Špaček