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

From: [email-masked]
Date: Thu, 22 Mar 2018 13:31:17 -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-04.txt
	Pages           : 9
	Date            : 2018-03-22

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-04
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-04

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

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: Ray Bellis <[email-masked]>
Date: Thu, 22 Mar 2018 21:41:43 +0000

Dave,

I think this is much improved :)

A few nits:

> Each globally-registered underscore name owns a distinct, subordinate
> name space.

except when it doesn't (i.e. the SRV transports all share the *same*
subordinate name space).

- on that note, _sctp and _dccp are missing from the global table.

- the table formatting is pretty poor, do we really need any more
  than just "NAME", "RR" and "REFERENCE"?   The ID field just seems
  to be an alternate mnemonic for the (already unique) underscore
  label itself

- the IANA considerations still refer to the now non-existent common
  second-level table

- it's still only been five years, although it *does* feel like 12 :p

Not a nit:

- is there a reference for IANA "First Come First Served" rules, and
  should we perhaps also mandate "specification required" as a
  pre-condition for registration?   We don't want that table filled
  with any old junk without a stable specification.

Ray

---

From: Dave Crocker <[email-masked]>
Date: Thu, 22 Mar 2018 16:23:24 -0700

> except when it doesn't (i.e. the SRV transports all share the *same*

Well, ummm, I think this demonstrates the difference between theory and 
practice.  In theoretical terms -- as far as the global registration 
scheme goes -- they /do/ have their own name spaces.  In practical 
terms, they adhere to some additional conventions that choose to use the 
same subordinate one.

I suppose some sort of language that notes this possibility -- since 
it's a popular choice -- is worth adding, to moderate the tone of 
independence in the current draft.

> - on that note, _sctp and _dccp are missing from the global table.

ack.

>    to be an alternate mnemonic for the (already unique) underscore

I added control because the message header field registration work has 
it and it occurred to me it's worth marking.

> - the IANA considerations still refer to the now non-existent common

darn.  thought i'd expunged them all.

the word 'second' appears to now be fully absent from the next version 
of the draft...

>    with any old junk without a stable specification.

What is the downside of leaving the requirement out?

I'm a minimalist in terms of the role of a registry.  To the extent 
possible, I think that it only has to do registration with 
accountability.  There are cases where more stringent requirements make 
sense, but I don't see this as one of them: there not any danger I can 
see in a useless registration entry and there's lots of namespace.

Thoughts?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Thu, 22 Mar 2018 17:55:20 -0700

>    to be an alternate mnemonic for the (already unique) underscore

I've looked over the latest version of the table with the above in mind.

Wrestled a bit, and finally landed on 'yes', but want to record the 
thoughts justifying removing fields:

    ID: the _Node Name field really does serve that purpose well enough

    Purpose: The text that was there for most of the entries was 
mechanically redundant with information in other fields for the entry.

    Control: I've added overall text in a bulleted list before the 
table, that handles the 'authority' issue for each entry.

d/