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

From: [email-masked]
Date: Sat, 21 Jul 2018 09:11:29 -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-12.txt
	Pages           : 13
	Date            : 2018-07-21

Abstract:
   Formally, any DNS resource record may occur under 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
   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-12
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-12

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

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: Bob Harold <[email-masked]>
Date: Mon, 23 Jul 2018 16:21:19 -0400

> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-12

 The table on page 6 includes:

"._protoB._service2"

Why the dot at the beginning?  None of the other lines have that.

-- 

Bob Harold

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 23 Jul 2018 17:22:15 -0400

Bob

Looks like a typo.  That has been there for a bit.

Tim

On Mon, Jul 23, 2018 at 4:21 PM, Bob Harold <[email-masked]> wrote:

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

---

From: Mats Dufberg <[email-masked]>
Date: Tue, 24 Jul 2018 09:13:49 +0000

In table 2 on page 9, the draft refers to RFC 2782 for _dccp and _sctp (SRV), but those “_node names” are not even mentioned in the RFC. Are they defined elsewhere?

In the same table, the draft refers to RFC 7553 for a number URI _node names, but the references are quite indirect. Could references to relevant IANA registries be added?

Mats

---
Mats Dufberg
DNS Specialist, IIS
Mobile: +46 73 065 3899
https://www.iis.se/en/

From: DNSOP <[email-masked]> on behalf of Bob Harold <[email-masked]>
Date: Monday, 23 July 2018 at 22:22
To: IETF DNSOP WG <[email-masked]>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt

On Sat, Jul 21, 2018 at 12:11 PM <[email-masked]<mailto:[email-masked]>> wrote:

Abstract:

---

From: "John Levine" <[email-masked]>
Date: 24 Jul 2018 10:58:44 -0400

In article <[email-masked]> you write:
>-=-=-=-=-=-
>In table 2 on page 9, the draft refers to RFC 2782 for _dccp and _sctp (SRV), but those “_node names”
>are not even mentioned in the RFC. Are they defined elsewhere?

RFC 2782 says that SRV's are named with _proto where proto is is a
protocol name.  RFCs 3588 and 6733 say to do _sctp SRV lookups, but
don't further define them, and only have 2782 as an informative
reference.  No RFC mentions _dccp.  

It seems to me that 2782 is the right reference for _sctp.  For _dccp
we've had arguments about whether 2782 says that a SRV can be named by
any protocol so maybe we should put in every protocol in the IANA
registry.  That's a lot of dead protocols.  A reasonable compromise
would be to start the registry with the names that have some evidence
of being used somewhere, so we could drop _dccp

>In the same table, the draft refers to RFC 7553 for a number of URI _node names, but the references are quite
>indirect. Could references to relevant IANA registries be added?

Since RFC 7553 is the place that says that the enumservice names turn
into _node names, I think that's the right reference.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 24 Jul 2018 12:00:57 -0400

I did some greppage through the RFCs and found some more names to go
in the attrleaf table.

               +------------+-----------------+------------+
               | RR Type    | _NODE NAME      | REFERENCE  |
               +------------+-----------------+------------+
               | TLSA       | _dane           | [RFC7671]  |
               | SRV        | _ipv6           | [RFC5026]  |
               | SRV        | _sip            | [RFC5509]  |
               | SRV        | _xmpp           | [RFC3921]  |
               | SRV        | _tls            | [RFC6733]  |
               +------------+-----------------+------------+

For _sip and _xmpp, also see the Instant Messaging SRV Protocol Label
Registry and the Presence SRV Protocol Label Registry.

The _tls is in an example, and it's probably wrong, but it's there so
I figure we should list it.

R's,
John

---

From: Tony Finch <[email-masked]>
Date: Tue, 24 Jul 2018 17:18:59 +0100

> I figure we should list it.

_tls in the protocol field is used by non-standard proprietary
technologies including Microsoft Lync / Skype for Business and Cisco
Jabber / Collaboration Edge. Maybe others?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
harness technological change to human advantage

---

From: Dave Crocker <[email-masked]>
Date: Tue, 24 Jul 2018 12:10:02 -0700

On 7/23/2018 2:22 PM, Tim Wicinski wrote:
> ooks like a typo.  That has been there for a bit.
> 
...
>       The table on page 6 includes:

Given that it's the only one like that, yes, it should be changed.

Just to bikeshed the issue, note that it's not 'wrong' to have the dot 
there, given the nature of this registration activity and therefore the 
context that the examples are going to get used in.

But certainly things need to be consistent and that one isn't.

Thanks for catching it, Bob.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Mats Dufberg <[email-masked]>
Date: Wed, 25 Jul 2018 09:32:40 +0000

RFC 8145 defines the _ta-XXXX node name:

   A Key Tag query consists of a standard DNS query of type NULL and of
   class IN [RFC1035].

   The first component of the query name is the string "_ta-" followed
   by a sorted, hyphen-separated list of hexadecimal-encoded Key Tag
   values.  The zone name corresponding to the trust anchor is appended
   to this first component.

   (RFC 8145, page 8)

_ta-XXXX should go into table 2 on page 9 of draft-ietf-dnsop-attrleaf.

Mats

---
Mats Dufberg
DNS Specialist, IIS
Mobile: +46 73 065 3899
https://www.iis.se/en/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 25 Jul 2018 06:23:20 -0700

For completeness:

      Absent further discussion and agreement in the wg, I taking this 
exchange as producing /no/ changes to the spec.

d/

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 25 Jul 2018 09:25:57 -0400

/no/ changes to the spec, except to correct the typo Bob Harold spotted.
Correct?

---

From: Dave Crocker <[email-masked]>
Date: Wed, 25 Jul 2018 06:28:31 -0700

> /no/ changes to the spec, except to correct the typo Bob Harold spotted. 

darn.  i was trying to be clear that the note referred only to that 
specific exchange.

the . typo is fixed.

I'm also adding the other underscored names folks have been citing.

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 25 Jul 2018 10:50:03 -0700

> _ta-XXXX should go into table 2 on page 9 of draft-ietf-dnsop-attrleaf.

Wow. This is a unique case, since it reserves essentially all of an 
even-more-subordinate namespace -- everything to the right of that dash.

Theoretically it isn't that inclusive but in practical terms, unless we 
want complex pattern-matching for sub-strings at run-time, it is.

I'm inclined to have the notation be:

     _ta-.*

to draw from regex, with an explicit reference to that, unless folks 
agree on something else.  (Yes, that's 'pattern matching' but it's in 
the specification document, not the operational code.)

Thoughts?

d/

---

From: Bob Harold <[email-masked]>
Date: Wed, 25 Jul 2018 13:59:41 -0400

> the specification document, not the operational code.)

Dot "." has special meaning in DNS, so I would prefer:

   _ta-*

Not regex, but a common wildcard usage.

-- 
Bob Harold

---

From: Dave Crocker <[email-masked]>
Date: Wed, 25 Jul 2018 11:06:30 -0700

> Not regex, but a common wildcard usage.

wfm.

anyone else care to chime in?

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 25 Jul 2018 11:06:38 -0700

wfm.

d/

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 25 Jul 2018 14:20:39 -0400

I like Bob's suggestion.

---

From: "John Levine" <[email-masked]>
Date: 25 Jul 2018 19:57:46 -0000

In article <[email-masked]>,
>> Not regex, but a common wildcard usage.

I suppose.  A plausible actual regex would be

   _ta(-[0-9a-z]{4}){1,12}

which might be a bit dense.  That's not quite right because the
numbers in the label have to be sorted, but there's no way to say that
in a regex other than enumerating them which would be bulky.

Whatever you do, please put include some text reminding people that it's
a conceptual glob stype wildcard, not a DNS wildcard.

R's,
John
-- 
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: Mats Dufberg <[email-masked]>
Date: Thu, 26 Jul 2018 08:45:37 +0000

I prefer a regex and I think that Dave's "_ta-.*" makes most sense. An explanation that it is a regex and that the exact format of the name is found in RFC 8145 is needed.

Mats

---
Mats Dufberg
DNS Specialist, IIS
Mobile: +46 73 065 3899
https://www.iis.se/en/

On 2018-07-25, 21:58, "DNSOP on behalf of John Levine" <[email-masked] on behalf of [email-masked]> wrote:

    In article <[email-masked]>,
    Dave Crocker  <[email-masked]> wrote:
    >>  Â Â  _ta-*

       _ta(-[0-9a-z]{4}){1,12}

    
    R's,
    John