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

Adam Roach <adam@nostrum.com> Tue, 09 October 2018 19:39 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B761C130DCF; Tue, 9 Oct 2018 12:39:02 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach <adam@nostrum.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-dnsop-attrleaf@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, Benno Overeinder <benno@NLnetLabs.nl>, dnsop-chairs@ietf.org, benno@NLnetLabs.nl, dnsop@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.86.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153911394274.10609.17949228643661419023.idtracker@ietfa.amsl.com>
Date: Tue, 09 Oct 2018 12:39:02 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/tYDfZYUr38M8XdsEblNOyVlnpcg>
Subject: [DNSOP] Adam Roach's No Objection on draft-ietf-dnsop-attrleaf-13: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Oct 2018 19:39:11 -0000

Adam Roach 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:
----------------------------------------------------------------------

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