Adam Roach has entered the following ballot position for draft-ietf-dnsop-attrleaf-13: Discuss
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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Related to the topic in my DISCUSS, 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. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
