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

From: [email-masked]
Date: Wed, 28 Mar 2018 08:30:47 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : DNS Scoped Data Through '_Underscore' Naming of Attribute Leaves
        Author          : Dave Crocker
	Filename        : draft-ietf-dnsop-attrleaf-06.txt
	Pages           : 9
	Date            : 2018-03-28

Abstract:
   Formally, any DNS resource record may occur for any domain name.
   However some services have defined an operational convention, which
   applies to DNS leaf nodes that are under a DNS branch having one or
   more reserved node names, each beginning with an underscore.  The
   underscore naming construct defines a semantic scope for DNS records
   that are associated with the parent domain, above the underscored
   branch.  This specification explores the nature of this DNS usage and
   defines the "DNS Global Underscore Scoped Entry 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 services.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-06
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Paul Vixie <[email-masked]>
Date: Wed, 28 Mar 2018 11:41:23 -0700

dave, HEREIS. --paul

[email-masked] wrote:
> ...
> ...

in: 1. Introduction

s/resource records/resource record types/ (two occurrences)

in: 1.1. _Underscore Scoping

s/existing resource record/existing resource record type/
s/specific resource records/specific resource record sets/
s/[RFC1035]/[RFC952]/ (first occurrence)
s/above the underscore/above the underscored/

in: 1.2. Scaling Benefits for TXT, SRV, and URI Resource Records

s/SRV,//; S/"SRV",//
OR s/Some resource records are generic and support a variety of uses.//;
    s/Their use can scale poorly.*different uses\.//;
    s/increasingly-popular//; s/approach,/approach/

s/records/record types/
s/RR/RRset/ (note, leave "RR"s alone)
s/RRs/RRsets/

in: 2. DNS Underscore Scoped Entry Registries Function

s/specific resource records/specific resource record types/
s/one or more RR records/an RRset/
s/such records/such RRsets/
s/other resource records/other RRsets/
s/applications/applications using the same resource record type/
s/listed resource record/listed resource record type/
s/RR,/RR type/
s/table of names/table of RR types and names/
(table needs to be fixed to add an RR Type column)
/name space/name space, just as every RR type owns a distinct, 
subordinate name space./

in: 2.1. DNS Underscore Global Scoped Entry Registry Definition

s/RR:/RR Type:/
s/the RR/the RR type/
s/References/References:/
s/Each RR/Each RR type/

in: 3.1. DNS Underscore Global Scoped Entry Registry

s/first/right-most/
s/(RR)/(RR Type)/
s/RR/RR Type/ (in table)

in: 3.2. Guidance for Expert Review

s/resource record/resource record type/ (three occurrences)

-- 
P Vixie

---

From: Dave Crocker <[email-masked]>
Date: Thu, 29 Mar 2018 08:24:01 -0700

> dave, HEREIS. --paul

Cool.  Thanks!

(Sorry for the sloppy vocabulary usage.  By way of an empathy signal cf, 
common use of 'header' in email when it should be 'header field'...)

I've gone through the entire document and reviewed all occurrences RR 
and resource record strings.  The results don't exactly the match the 
set of changes you specify, but did produce quite a few changes.

The RFC 2181 definition resource record set is a set of records of the 
/same/ type.  In some cases, that isn't what's meant, so I didn't change 
the text. In some cases, the text's intent is to to cover RRs of 
/different/ types populating the same leaf.  As I read the definition, 
that's not covered by RRset.

Inline questions/comments/concerns...

...
> s/specific resource records/specific resource record sets/

Current text:

      "That scope is a leaf node, within which the uses of specific 
resource records can be formally defined and constrained."

I often find that there is wording danger in using plurals, that can be 
avoided with the singular.  I think the issue here can be simplified by 
changing the text to:

      "That scope is a leaf node, within which the uses of a specific 
resource record type can be formally defined and constrained."

> s/[RFC1035]/[RFC952]/ (first occurrence)

hmmm. I suggest listing both, since RFC1035 both cites the precedence of 
RFC952 as well as supplying an (apparently redundant) formal syntax 
specification for host name.

>     s/increasingly-popular//; s/approach,/approach/

Sorry, not understanding the issue(s). Please clarify.

Here's my guess at the concern:

      SRV is viewed as not generic and/or doesn't have scaling problems?

There is a type of variability to the use of some RR types that 
effectively means they have variation in their role, not just their 
payload.  TXT is the extreme example of this.  SRV is more interesting, 
because it was designed for that variability.  Glad to use a term other 
than generic, but I don't have an obvious alternative that suits.

The variability of such types can make it problematic to aggregate all 
occurrences of them into the same node, even though they are associated 
with that node. The underscore naming approach separates these subsets. 
Again, SRV is interesting because it was designed with that naming as 
part of its original design.  However the fact that it was designed with 
the solution from the start doesn't relieve it of needing that solution. 
  The text, here, is attempting to characterize a motivating issue, 
namely a scaling challenge that occurs due to the variability of use for 
some RR types.

> s/RR/RRset/ (note, leave "RR"s alone)

The substitution command seems to be at odds with the comment.  Please 
explain.

...
> /name space/name space, just as every RR type owns a distinct, 

An RR type owns a name space?  I don't understand what that means or how 
it is correct.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 29 Mar 2018 11:45:55 -0400

A bit of context here, this is probably a document you have seen before and
it is one of those cleanup documents that tends to languish.

The reason I asked Dave to restart work on this draft is that I was
reviewing another draft (SMTPRPT) that clearly needs to register a new
prefix and indeed really needs a new prefix registry.

This this draft is about to become critical path for another draft which
means that it is much more likely that it will actually make it to RFC this
time which means that if you have an opinion on it, now is the time to
speak or forever hold your peace.

On Wed, Mar 28, 2018 at 11:30 AM, <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Paul Vixie <[email-masked]>
Date: Thu, 29 Mar 2018 09:31:15 -0700

> specification for host name.

the reference to 952 in 1035 is only in the bibliography, and does not 
specifically discuss its relationship to A RR owner names or to MX RR 
targets. if you can show me the part of 1035 you think is relevant to 
the definition of a host name, i'd like to see it.

when i chose _ it was right after the great \n PTR vuln in sendmail, and 
so i was darn sure where the definition of host name was that did not 
include _ as a valid character, having just wrestled those 'gators.

> SRV is viewed as not generic and/or doesn't have scaling problems?

it's not increasingly popular, it doesn't scale poorly, and it's not 
generic. so you can either remove those descriptions of SRV, or you can 
remove SRV as the object of your description, or you can finesse it.

> The text, here, is attempting to characterize a motivating issue, namely
> a scaling challenge that occurs due to the variability of use for some
> RR types.

your words, "needing that solution", have no subject here. the problems 
you are describing for TXT will apply to NULL, and to JSON if we restart 
that effort, and possibly to URI (i didn't check that), but they do not 
occur with SRV, nor might they, ever.

other than the need to document _UDP and _TCP in the registry for the 
SRV type, there is nothing in your effort that touches or is motivated 
by SRV. having an _ doesn't make it "like TXT". there is an RRset for 
SRV where it is used, and that RRset is selected by its attrleaf. it 
passes like ships in the night with any other type of RRset at any child 
of the same domain name.

> The substitution command seems to be at odds with the comment. Please

i don't want you to change the quoted RR ("RR") only the unquoted RR (RR).

> An RR type owns a name space? I don't understand what that means or how

the children of some node (www.example.com) that are of some type (SRV) 
are in a different namespace, with respect to an application's ability 
to fetch them discretely (_SMTP._TCP.www.example.com SRV) and also with 
respect to conflicts with the same node being used by some other type 
(_TCP.www.example.com TXT).

perhaps after "subordinate name space" i ought to have added "for the 
purpose of allowing applications to fetch only the data they desire and 
without also hearing unrelated data used by other services and apps."

-- 
P Vixie

---

From: Dave Crocker <[email-masked]>
Date: Thu, 29 Mar 2018 10:06:43 -0700

Paul,

The text in RFC 1035 I have in mind is:

 > 2.3.1. Preferred name syntax
...
> When creating a new host name,
> the old rules for HOSTS.TXT should be followed.  This avoids problems
> when old software is converted to use domain names.
> 
> The following syntax will result in fewer problems with many
> 
> applications that use domain names (e.g., mail, TELNET).
> 
> <domain> ::= <subdomain> | " "
> 
> <subdomain> ::= <label> | <subdomain> "." <label>
> 
> <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]

So, no, it doesn't explicitly cite the RFC number, but I read it as 
citing the substance.

> remove SRV as the object of your description, or you can finesse it.

Trying to eliminate the issue entirely, is this sufficient:

  <section title="Scaling Benefits">

    <t>Some resource record types are used in a fashion that can create
       scaling problems, if an entire RRset associated with a domain
       name is aggregated in the leaf node for that name. An
       increasingly-popular approach, with excellent scaling properties,
       places the RR under a node having an underscore-based name, at a
       defined place in the DNS tree under the 'parent' name. This
       constrains the use of particular <spanx style="verb">RR</spanx>
       types associated with that parent name. A direct lookup to the
       subordinate leaf node produces only the desired record types, at
       no greater cost than a typical DNS lookup.</t>

    <t>The definition of a underscore global registry, provided in this
       specification, primarily attends to the top-most names used for
       coping an RR type; that is the _underscore "global" names. </t>

    </section>

>> An RR type owns a name space? I don't understand what that means or how

While I think I see a computer science basis for saying that an RR type 
has a namespace, I'm continuing to find the point more confusing than 
helpful, and fear that other readers will, too.

At the least, can you point me to official documents that explain that 
view?  I've looked around a bit an haven't found such a specification or 
discussion.

Note, for example, that RFC 1034 says:

 > 2.4. Elements of the DNS
...
>      The DOMAIN NAME SPACE and RESOURCE RECORDS, which are
>      specifications for a tree structured name space and data
>      associated with the names.  Conceptually, each node and leaf
>      of the domain name space tree names a set of information, and
>      query operations are attempts to extract specific types of
>      information from a particular set.

which is not language that lends itself towards saying that an RR type 
has its own namespace.  I don't see anything in RFC 1035 that works for 
that view, either.

d/

---

From: Paul Vixie <[email-masked]>
Date: Thu, 29 Mar 2018 10:30:18 -0700

...
> So, no, it doesn't explicitly cite the RFC number, but I read it as

i think it's non-normative and should not be referenced in your 
document. this text:

> However, when assigning a domain name for an object, the prudent user
> will select a name which satisfies both the rules of the domain system
> and any existing rules for the object, whether these rules are published
> or implied by existing programs.

...does not require or prohibit. and in your example:

> the old rules for HOSTS.TXT should be followed.

...is not using a modern SHOULD, it's general advice only.

bizarrely, we are then greeted by this text:

> The labels must follow the rules for ARPANET host names.  They must
> start with a letter, end with a letter or digit, and have as interior
> characters only letters, digits, and hyphen.  There are also some
> restrictions on the length.  Labels must be 63 characters or less.

it says "must", and if this is to be seen as a modern MUST, then it is 
true of all labels, and SRV updated 1035. also, the famous example of 
3com.com required a change to the SRI-NIC policies of its era, but was 
never backported to 1035. so, this text is clearly archaic.

whereas, in 952 we have the following. (more commentary below the break.)

> GRAMMATICAL HOST TABLE SPECIFICATION
>
>    A. Parsing grammar
>
>       <entry> ::= <keyword> ":" <addresses> ":" <names> [":" [<cputype>]
>          [":" [<opsys>]  [":" [<protocol list>] ]]] ":"
>       <addresses> ::= <address> *["," <address>]
>       <address> ::= <octet> "." <octet> "." <octet> "." <octet>
>       <octet> ::= <0 to 255 decimal>
>       <names> ::= <netname> | <gatename> | <domainname> *[","
>          <nicknames>]
>          | <official hostname> *["," <nicknames>]
>       <netname>  ::= <name>
>       <gatename> ::= <hname>
>       <domainname> ::= <hname>
>       <official hostname> ::= <hname>
>       <nickname> ::= <hname>
>       <protocol list> ::= <protocol spec> *["," <protocol spec>]
>       <protocol spec> ::= <transport name> "/" <service name>
>          | <raw protocol name>
>
>    B. Lexical grammar
>
>       <entry-field> ::= <entry-text> [<cr><lf> <blank> <entry-field>]
>       <entry-text>  ::= <print-char> *<text>
>       <blank> ::= <space-or-tab> [<blank>]
>       <keyword> ::= NET | GATEWAY | HOST | DOMAIN
>       <hname> ::= <name>*["."<name>]
>       <name>  ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]
>       <cputype> ::= PDP-11/70 | DEC-1080 | C/30 | CDC-6400...etc.
>       <opsys>   ::= ITS | MULTICS | TOPS20 | UNIX...etc.
>       <transport name> ::= TCP | NCP | UDP | IP...etc.
>       <service name> ::= TELNET | FTP | SMTP | MTP...etc.
>       <raw protocol name> ::= <name>
>       <comment> ::= ";" <text><cr><lf>
>       <text>    ::= *[<print-char> | <blank>]
>       <print-char>  ::= <any printing char (not space or tab)>

since the _ was chosen as nonconflicting, and since you desire to 
explain what it is we aren't conflicting with, and since the RFC 1035 
language is both non-normative and archaic by inspection, i really think 
that 952 is the correct, and only correct, reference to use.

as a side node, RFC 952 permits host names of only 24 characters or 
less, including those which have interior periods for RFC 921 purposes. 
therefore, a protocol lawyer could say that any name longer than 24 
characters, or beginning with a number, was by definition 
non-conflicting with RFC 952, and needs no underscore to achieve same. i 
do not harbor this view, and i believe that the LEXICAL GRAMMAR section 
is more definitional than the ASSUMPTIONS section of RFC 952.

...
>> generic. so you can either remove those descriptions of SRV, or you
>> can remove SRV as the object of your description, or you can finesse it.
>
> scaling problems, if an entire RRset associated with a domain name is
> aggregated in the leaf node for that name. An increasingly-popular
> approach, with excellent scaling properties, places the RR under a
> node having an underscore-based name, at a defined place in the DNS
> tree under the 'parent' name. This constrains the use of particular
> <spanx style="verb">RR</spanx> types associated with that parent
> name. A direct lookup to the subordinate leaf node produces only the
> desired record types, at no greater cost than a typical DNS
> lookup.</t>
>

it's almost 100% of the way there. but, you should say "places the 
RRset" since an RR never travels singly except in zone files, and all 
underscore-using applications i know of will accept more than one RR 
having the same name, class, and type -- thus, they process RRsets, 
which travel as RRsets on the wire, and the fact that an RRset contains 
RRs is unimportant in and of itself -- and describing it this way is 
confusing. an RRset with one RR may seem to be a degenerate case, but 
it's essential (respects law of least astonishment) to think of it that way.

> view? I've looked around a bit an haven't found such a specification or

it only contains a namespace for the purposes of your underscore 
registry. no use of _TCP by any other RR type will conflict with the use 
of _TCP by SRV, for example. thus, each RR type effectively has its own 
registry, whose names need only be unique within that registry. you may 
prefer to call it a dictionary rather than a namespace in order to avoid 
confusion around what other DNS RFC's call a "namespace".

-- 
P Vixie

---

From: Dave Crocker <[email-masked]>
Date: Thu, 29 Mar 2018 14:44:35 -0700

> that 952 is the correct, and only correct, reference to use.

Thanks for the detailed explication.  I think it's odd to have a DNS 
naming-related discussion that does not cite either of the seminal 
standards documents for domain naming, but I suppose there's isn't much 
downside at this place in the document, to cite only RFC 952.

> is more definitional than the ASSUMPTIONS section of RFC 952.

To me, that's an example of the problem with citing only that document: 
It is not definitive on 'host name'.  That RFC 1035 isn't, really, 
either was my reason for wanting to cite both.  But anyhow, the next 
version will have only 952.

> RRset"

oops.  quite correct.

> confusion around what other DNS RFC's call a "namespace".

Oh.  Alas, I'm still not seeing how this is helpful pedagogy for the 
average reader.  Let's suspend this until the next version and see how 
the doc sits with folks.

d/