Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-02.txt

[Petr Špaček <[e-mail]>]

On 31.3.2017 17:52, Stephane Bortzmeyer wrote:
> On Wed, Mar 29, 2017 at 08:15:45AM -0700,
>  [e-mail] <[e-mail]> 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