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

From: [email-masked]
Date: Sat, 03 Nov 2018 13:22:45 -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-15.txt
	Pages           : 14
	Date            : 2018-11-03

Abstract:
   Formally, any DNS resource record may occur under any domain name.
   However some services use an operational convention for defining
   specific interpretations of an RRset, by locating the records in a
   DNS branch, under the parent domain to which the RRset actually
   applies.  The top of this subordinate branch is defined by a naming
   convention that uses a reserved node name, which begins with an
   _underscore.  The underscored naming construct defines a semantic
   scope for DNS record types 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-15
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-15

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

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: Warren Kumari <[email-masked]>
Date: Sun, 4 Nov 2018 06:55:58 +0700

Nit:
Section 1.5:
"For "TXT" records, there is no consistent, internal syntax that to permits
distinguishing among the different uses."
Spurious 'that' or 'to'.

I'm also somewhat confused by the quoting in:
"In the case of the "SRV" "RR" and "URI" "RR", distinguishing among
different types"  (and in "defining "RR"s that might" ) - I'm not sure if
it is intentional, but it doesn't align with much of the rest of the
formatting, and is (IMO) confusing around the first part.)

Probably nit: Section 2:
"Only global underscored names are registered in the IANA Underscore
Only the global underscored names "_service1", "_service2", Global
table.  (From the example, that would mean registering "_service3",
"_service4", and "_authority" are registered in the IANA _service1,
_service2, _service3, _service 4, and _authority.)"

First sentence repeats.

Nit:
7.2.  References -\- Informative

Also nit (I think):
Adam Roach, Petr &#352;pa&#269;ek, Ond&#345;ej Sury

Otherwise I think this one looks cooked.
W

On Sun, Nov 4, 2018 at 3:23 AM <[email-masked]> wrote:

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

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: "John R. Levine" <[email-masked]>
Date: 4 Nov 2018 11:54:09 +0700

> formatting, and is (IMO) confusing around the first part.)

That's xml2rfc being helpful.  The xml says those are verbatim strings and 
it added the quotes.  I presume the editors can fix this.

> _service2, _service3, _service 4, and _authority.)"

In xml it is clear that two lines of old text weren't deleted.

I stared at the table of names and I think it's right, but it's the meat 
of the document and more people looking at it would be good.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Bjørn Mork <[email-masked]>
Date: Sun, 04 Nov 2018 15:10:55 +0100

Section 4.3 claims RFC7671 reserves "_dane":

"             +------------+------------------+------------+
              | RR Type    | _NODE NAME       | REFERENCE  |
              +------------+------------------+------------+
..
              | TLSA       | _dane            | [RFC7671]  |
"

I can't see any support of this in RFC7671.

I assume the misunderstanding comes from a couple of examples using a
"_dane" label. But this is an arbitrary choice, and not an attempt to
reserve a name.  For example from RFC7671 section 5.2:

"  Some domains may prefer to avoid the operational complexity of
   publishing unique TLSA RRs for each TLS service.  If the domain
   employs a common issuing CA to create certificates for multiple TLS
   services, it may be simpler to publish the issuing authority as a TA
   for the certificate chains of all relevant services.  The TLSA query
   domain (TLSA base domain with port and protocol prefix labels) for
   each service issued by the same TA may then be set to a CNAME alias
   that points to a common TLSA RRset that matches the TA.  For example:

   ; Two servers, each with its own certificate, that share
   ; a common issuer (TA).
   ;
   www1.example.com.            IN A 192.0.2.1
   www2.example.com.            IN A 192.0.2.2
   _443._tcp.www1.example.com.  IN CNAME tlsa._dane.example.com.
   _443._tcp.www2.example.com.  IN CNAME tlsa._dane.example.com.
   tlsa._dane.example.com.      IN TLSA 2 0 1 e3b0c44298fc1c14...
"

It is obvious from this that "tlsa._dane.example.com." is a placeholder
alias, and not reserving "tlsa" or "_dane" labels.

The consistent choice of "tlsa._dane" in the RFC7671 examples might have
contributed to this confusion.  Something to keep in mind for future DNS
label examples.  Use your fantasy :-)

Bjørn

---

From: Dave Crocker <[email-masked]>
Date: Sun, 4 Nov 2018 06:17:39 -0800

On 11/3/2018 4:55 PM, Warren Kumari wrote:
> different types"  (and in "defining "RR"s that might" ) - I'm not sure 
> if it is intentional, but it doesn't align with much of the rest of the 

I used spanx too liberally, because it looked nice in the html version 
on my machine, and I didn't realize what it did for the text version. My 
use matched what I'm seeing in some bibxml entries, but you are right 
that it doesn't look right in some of the sequences here.

So I've removed most spanx occurrences in the source.

> Adam Roach, Petr &#352;pa&#269;ek, Ond&#345;ej Sury

This is a dilemma. The characters produce appropriate text in html, to 
show his actual name.  The xml2rfc text rendering engine produces this 
silliness and I'm inclined to class it as a bug in the engine.

If there is an established practice for working around that bug, to 
produce the proper characters in html and an 'acceptable' alternative in 
text, please let me know and I'll fix it.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Erik Kline <[email-masked]>
Date: Mon, 5 Nov 2018 09:28:20 +0700

Dave (others),

One thing I missed earlier (and please forgive me if this was already
discussed), was whether or not _example* should be reserved in the
table in draft-ietf-dnsop-attrleaf-15#section-4.3.

Basically, is there any value in reserving _example* for future RFCs
to use (ones that don't care about the specific _foo label but apply
to all such labels in some way).

Sorry for the last-minute distraction,
-Erik

---

From: Dave Crocker <[email-masked]>
Date: Sun, 4 Nov 2018 18:56:43 -0800

> to all such labels in some way).

Clever suggestion.  Seems like obvious benefit with no obvious detriment.

So I immediately went to add it and then realized that doing this 
cleanly will take an entry for each RR...

Not so sure we want to do that?

d/

---

From: Erik Kline <[email-masked]>
Date: Mon, 5 Nov 2018 10:07:20 +0700

> Not so sure we want to do that?

Perhaps doable via a {see section #X.Y} e.g.:

              | *       | _example* {see #X.Y} | [this doc]  |

X.Y Reserved _example* label
    For use in RFC documentation describing behaviour applicable to
any label associate with any RR type. More awesome text also goes
here.

I'm not sure about the strictness requirements for this kind of table for IANA.

Also, this doesn't address whether it's an actually useful suggestion. :-)

---

From: Ray Bellis <[email-masked]>
Date: Mon, 5 Nov 2018 10:08:24 +0700

> cleanly will take an entry for each RR...

Why not this?

| *          | _example         | [TBD]      |

Ray

---

From: Dave Crocker <[email-masked]>
Date: Sun, 4 Nov 2018 19:22:36 -0800

>> cleanly will take an entry for each RR...

Well, that's two of you making close to the same suggestion (though the 
version Erik suggested seems a bit more complete.

Absent objections, I'll add that.

d/