On Mon, Oct 8, 2018 at 10:15 PM Adam Roach <a...@nostrum.com> wrote: > 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. > > > I will be on a plane during this telechat (actually, I hope to have landed before the telechat, but no guarantees, etc.)
I'm OK with either of the above solutions (and hope that Dave is as well). W > ---------------------------------------------------------------------- > 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. > > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
