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

From: Petr Špaček <[email-masked]>
Date: Fri, 7 Apr 2017 16:21:21 +0200

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

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Apr 2017 06:29:51 -0700

> policies. draft-leiba-cotton-iana-5226bis, currently in the RFC editor

Thanks.  I hadn't registered that issue...

> standards organization" by "specification required (RFC 5226bis,

Hmm. The IANA draft's 'Specification Required' (Section 4.6) imposes a 
requirement both for a designated expert AND the existence of a publicly 
published spec.

My original thought was that this registry should have a concern for 
stability of the reference using it, but not impose much of a barrier in 
terms of quality.  (I figured that the other document's standards 
criteria would suffice for that.)

While some registries do need careful quality control for each entry, 
this doesn't seem like it should be one of them.  The namespace is 
essentially infinite, so we don't have to worry about exhaustion, and I 
don't see much downside in letting the market decide whether the entry 
is useful.

So on reflection, I'm starting to wonder about instead going to the 
lesser First Come First Served (Section 4.4 of the IANA draft).  This 
should encourage early (pre-standards) registration.

It also should cover established practice that doesn't provide the level 
of documentation one would wish for.  Which fact you've nicely 
documented next...

Thoughts?

> Also, the proposed initial registry includes:
> 
>   SPF        | _spf         | "TXT" | [RFC7372]
> 
> RFC 7372 contains *nothing* about that, and SPF (RFC 7208) does not
> use undesrscore names.

(Yeah.  RFC 7372 is wrong.  It should be RFC 7208.  However...)

1. RFC 7208 notes the TXT ambiguity problem

    3.  SPF Records
    ...
    Since TXT records have multiple uses, beware of other TXT records
    published there for other purposes.  They might cause problems with
    size limits (see Section 3.4), and care has to be taken to ensure
    that only SPF records are used for SPF processing.

2. It requires use of TXT

    3.1.  DNS Resource Records

    SPF records MUST be published as a DNS TXT

4.  All of the examples that explicit show the TXT RR show domain names 
that do NOT use a _spf node name.  (sigh)

5.  However the document also is littered with examples of using ._spf. 
(sigh)

6.  And finally, industry documentation for SPF is loaded with 
directions for use of ._spf.  E.g.,

      http://www.openspf.org/FAQ/Common_mistakes

      Sometimes an ISP will create a special SPF record that customers
      can include with their record, such as _spf.example.com.

So we have extensive, established practice, though one could wish for a 
(much) better specification.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 10 Apr 2017 15:23:00 -0000

>should encourage early (pre-standards) registration.

I agree FCFS makes sense.  As you note the supply of names is
effectively unlimited, so squatting isn't a big deal.

>of documentation one would wish for.  Which fact you've nicely 

Right, we can add _spf and the enumservice names with hand waves about
the places they're sorta but not very well described.

R's,
John