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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
