[DNSOP] Review of draft-ietf-dnsop-attrleaf

["Murray S. Kucherawy" <[e-mail]>]

I've reviewed this document and I think it's in pretty good shape, and is
just about ready to be sent up for publication.  I have some editorial
comments that are mostly minor in nature, as follows:

Section 1.1:

OLD:

   The scoping feature is particularly useful when generalized resource
   record types are used -- notably "TXT", "SRV", and "URI" [RFC1035
<https://tools.ietf.org/html/rfc1035>],
   [RFC2782 <https://tools.ietf.org/html/rfc2782>], [RFC6335
<https://tools.ietf.org/html/rfc6335>], [RFC7553
<https://tools.ietf.org/html/rfc7553>].

NEW (formatting):

   The scoping feature is particularly useful when generalized resource
   record types are used -- notably "TXT", "SRV", and "URI" (see
[RFC1035 <https://tools.ietf.org/html/rfc1035>],
   [RFC2782 <https://tools.ietf.org/html/rfc2782>], [RFC6335
<https://tools.ietf.org/html/rfc6335>], and [RFC7553
<https://tools.ietf.org/html/rfc7553>]).

OLD:

   when they are the underscored name closest to the DNS root; they are
   considered 'global'.  Underscore-based names that are farther down
   the hierarchy are handled within the scope of the global underscore
   name.

NEW (consistent quoting; this is the first of several instances):

   when they are the underscored name closest to the DNS root; they are
   considered "global".  Underscore-based names that are farther down
   the hierarchy are handled within the scope of the global underscore
   name.

Section 1.3:

OLD:

   presentation convention described in Section 3.1
<https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-11#section-3.1>
or [RFC1034 <https://tools.ietf.org/html/rfc1034>] this is

NEW (typo, comma):

   presentation convention described in Section 3.1
<https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-11#section-3.1>
of [RFC1034 <https://tools.ietf.org/html/rfc1034>], this is

Section 2:

COMMENT:

   o  If a public specification calls for use of an underscore-prefixed
      domain node name, the 'global' underscored name -- the underscored
      name that is closest to the DNS root -- MUST be entered into this
      registry.


Use of "MUST" in the RFC2119 sense needs the RFC2119 boilerplate,
which isn't included in the document. This also appears in several
spots in Section 4.

I'm also not sure it applies here; there's no obvious threat to
interoperability if someone does this but doesn't register it.

(More generally, I've frequently been told that MUSTard in IANA
Considerations is a no-no.)


OLD:

   An underscored name define scope of use for specific resource record


NEW:

   An underscored name defines the scope of use for specific resource record

Section 4.1:

OLD:

   The DNS Global Underscore Scoped Entry Registry is any DNS node name
   that begin with the underscore character (_) and is the underscored

NEW (include the ASCII value):

   The DNS Global Underscore Scoped Entry Registry is any DNS node name
   that begin with the underscore character ("_", ASCII 0x5F) and is
the underscored

OLD:

   o  The required Reference for an entry MUST have a stable resolution
      to the organization controlling that registry entry


NEW (missing trailing period):

   o  The required Reference for an entry MUST have a stable resolution
      to the organization controlling that registry entry.

COMMENT:

The DNS is case-insensitive so this is a minor point, but would there
be any benefit to specifying that the registry only records the
all-lowercase version of an underscore name?

COMMENT:

The text specifically calls for a stable reference.  Do we have
guidance about what constitutes such a thing?  I believe IANA has its
own guidelines to that end; are they available to the Designated
Expert?

Section 6:

COMMENT:

I have doubts that SECDIR would accept this one-sentence comment.  I
suggest saying something more specific, like:

"This document establishes a registry, and encourages a slight
reorganization of attributes stored in the DNS.  It establishes no new
security issues."

Section 6.1:

COMMENT:

This seems to me to be content that belongs in its own section outside
of Section 6 since it doesn't seem to me to be a security issue, but
it's worth saying.  Maybe give it its own section between what's now
Sections 3 and 4?

-MSK