[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-attrleaf-13: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnsop-attrleaf-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.