Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves
draft-ietf-dnsop-attrleaf-16

[Note that my initial issue below was originally a DISCUSS. I am leaving it
in as a comment, as I believe it remains a significant problem with the
registry established by this document; but given that it was explicitly
discussed by the Working Group and that reasonable people can disagree
on the degree of harm here, I'm not going to stand in the way of
publication.]

I'm glad to see this registry finally being set up, and want to thank everyone
who helped get the document ready. I understand that this has been a large
archaeological undertaking, and that the relatively small size of the document
belies the large amount of actual work that went into it.

I have one top-level concern about the registry, a handful of proposed
corrections to the initial table, and some very minor editorial nits. I present
the following feedback in that order.

---------------------------------------------------------------------------

I have some very strong concerns about the handling for the "URI" RRTYPE.
As far as I can tell, the entries in the initial table were formed by starting
with the entries in
https://www.iana.org/assignments/enum-services/enum-services.xhtml, adding the
most popular entries from
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml,
("dccp", "sctp", "tcp", and "udp") and removing "web".

Please note that it is entirely possible that I've missed an important detail
here, and am merely confused.

My top-line concern is that, while the table established by this document
appears to intend to be a strict superset of the Enumservices table, there are
no instructions of any kind to the IANA that would result in these tables
remaining in sync -- that is, when a new service is added to the "Enumservice
Registrations" table, one might presume that it needs to also appear in the
new registry established by this document.

I would imagine this could be handled either by asking the IANA to add
instructions to the "Enumservice Registrations" table indicating that a
corresponding entry must be added to this one; or simply by including the
contents of that table by reference rather than by value into this one. I'm
pretty agnostic about which approach is taken.

---------------------------------------------------------------------------

Related to the topic above, I have three very closely related comments:

Comment 1: Was the removal of "web" intentional?

Comment 2: These initial entries misspell "xmpp" as "xmp"

Comment 3: Is it envisioned that all future URI entries in this table will
reference RFC 7533? That doesn't quite seem right. My instinct is that it would
serve the users of this registry better if:

 - _iax refers to RFC 6315
 - _acct refers to RFC 7566
 - All other enumservice-based URI entries in the current table refer to
   RFC 6118
 - RFC 7533 is mentioned elsewhere in the document as the reason enumservices
   appear in the table.

---------------------------------------------------------------------------

RFC 6763 §6 says:

   Every DNS-SD service MUST have a TXT record in addition to its SRV
   record, with the same name, even if the service has no additional
   data to store and the TXT record contains no more than a single zero
   byte.

It's worth noting that RFC 6763 limits its use strictly to the use of "_tcp" and
"_udp" -- all non-TCP transports are coded as "_udp". So I believe the following
entries need to be added:

              | TXT        | _tcp             | [RFC6763]  |
              | TXT        | _udp             | [RFC6763]  |

---------------------------------------------------------------------------

RFC 4386 §2 defines Global SRV records for _ldap, _http, and _ocsp. So:

              | SRV        | _ldap            | [RFC4386]  |
              | SRV        | _http            | [RFC4386]  |
              | SRV        | _ocsp            | [RFC4386]  |

---------------------------------------------------------------------------

Regarding the existing entry:

              | SRV        | _tls             | [RFC6733]  |

RFC 6733 uses this name non-normatively in an example, as an intermediate
target while resolving an NAPTR record, and it is clearly a site-local
decision rather than a protocol element. I do not believe this should be
construed as reserving the name; its use in this context is clearly, in the
words of this document's introduction, "a matter of operational convention,
rather than defined protocol semantics."

---------------------------------------------------------------------------

§1.1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].

Minor nit: please consider using the boilerplate from RFC 8174.

---------------------------------------------------------------------------

§4.1:

>  o  The table is to be maintained with entries sorted by the first
>     column (RR Type) and, within that, the second column (_Node Name).

Minor nit: I suggest that this document would be improved by sorting the table
in §4.3 in this order as well.

I agree with Alexey. It seems like the expert is being asked to do the review that IANA would typically do itself.

Please address  the Gen-ART review nits.

Just a nit:

This document creates the new registry, but draft-ietf-dnsop-attrleaf-fix updates the existing specifications.  It would be nice to add an Informative reference (to draft-ietf-dnsop-attrleaf-fix) in order to make the connection clear from both sides.

Adam captured all of my comments in considerably more detail than in my notes, so I will follow the discussion resulting from his ballot.

I'm happy to see this registry created and populated; I would be balloting
YES except that I do not think I have time to follow all the references
for the initial registry contents.

That said, I do share Adam's concern about IANA being more reliable than 
authors of future enum-services documents at remembering to (check whether
to) update a second table, but the subsequent discussion about not all
enum-services necessarily being used in URI records seems to support the
current scheme.

I also have some section-by-section comments.

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.  [...]

nit: just "underscore" or "_", I think -- "_underscore" is not a well
recognized character.

Section 1.4
   
   Conversely, a wildcard such as *.example.com can match any name
   including an underscored name.  So, a wildcard might match an
   underscored name, returning a record that is the type controlled by
   the underscored name but is not intended to be used in the
   underscored context and does not conform to its rules.

This could perhaps benefit from greater clarity on which entity's
perspective the "not intended" applies to.  I assume the entity making the
wild query does not intend to interpret the response in an underscore
context, but the language is a bit hard to follow.

Section 3

   This section provides a basic template that can be used to register
   new entries in the IANA DNS Underscore Global Scoped Entry Registry,
   if the global underscored name above the RRTYPE is not already
   registered. [...]

I'm not sure how to parse "name above the RRTYPE", since (1) the RRTYPE
record can have the owner name that is the global underscored name, and (2)
the RRTYPE is, well, a record type and not a name.

Section 4.1

I would consider adding another 8126 citation for "Expert Review"
procedures.

Section 4.3

There are some URI usages with node names _kerberos, _kpasswd, and
_kerberos-adm listed in draft-ietf-kitten-krb-service-discovery (and
implemented, per
http://web.mit.edu/kerberos/krb5-latest/doc/admin/realm_config.html#kdc-discovery).
It's unclear whether they meet the WG's criteria for inclusion in the
initial registry contents, especially at such a late stage of the document's lifecycle.

Section 5

   For the purposes of this Expert Review, other matters of the
   specification's technical quality, adequacy or the like are outside
   of scope.

I have mixed feelings about wanting to keep registration open to avoid
squatting, but also about wanting to allow the experts to reject requests
that do not provide a clear and interoperable description of what the
RRTYPE+name is used for.  I do think that the first bullet point
("sufficeintly clear, precise and complete") allows the experts some leeway
in this regard, but when limited by this statement I'm not sure it provides
the experts enough leeway.

Section 6

One could perhaps argue that by creating a global registry this document
reduces the likelihood of inadvertent collision, and that such collision
could have security consequences.  But it would be a bit of a stretch.

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5596



COMMENTS

>      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

This text is a bit hard to parse for the layman. Here's my attempted
rewrite, which captures what I think this means.

Conventionally, this construct associates data with the parent domain,
with the underscored label instead denoting the type of the data.

I'm not sure if that helps, but perhaps something along these lines?


S 1.1.
>   
>   1.1.  Underscore Scoping
>   
>      As an alternative to defining a new RR type, some DNS service
>      enhancements call for using an existing resource record type, but
>      specify a restricted scope for its occurrence.  Scope is meant as a

I think I get why you are saying "scope" here, but it's kind of not
that good fit with the programming concepts of scope as I am familiar
with.

It seems like there are two benefits to this convention (1) indicating
the type of the data (2) the ability to do a selective query.

Perhaps it would be clearer to introduce the convention first with the
typing benefit and then explain that this also gives you the ability
to do a selective query.




S 2.
>                         +----------------------------+
>   
>                          Examples of Underscored Names
>   
>      Only global underscored names are registered in the IANA Underscore
>      Global table.

so just for clarify, in the examples above, only _service[1-4] and
_authority would need to be registered?

This is a DNS specification that is fairly clear to people who know a little about DNS, but not a lot. You win.

This text

   DNS data semantics have been
   limited to the specification of particular resource record types, on
   the expectation that new ones would be added as needed.

would have been clearer for me, if it said "new resource record types would be added as needed".  "new ones" was vague enough to break my train of thought.