DNS is well outside my area of expertise.  I found this draft to be clearly written and easy to read.

I have one easy comment: 

Section 1.2.1, second paragraph: The 'may' here is difficult to interpret since literally all the values under this paragraph are 'MUST' or 'MUST NOT'.  I'd suggest 'elements have the following optional attributes'.

I found this a nice read and a interesting introduction in the (to me) mystical world of DNS and delegation records. Thank you for this document

I support Murray’s DISCUSS position re the SHOULD in Section 3.1, although possibly for a slightly different motivation. I saw the reply to his DISCUSS to the effect that you’re saying the operator really had better configure a policy. As written that’s not clear from the text of the spec:

“Servers SHOULD restrict the supported DNS record types in accordance with their own policy.”

What I took away from that sentence, reading it without benefit of looking at the list discussion, was “a server should respect configured policy, unless it doesn’t feel like it, in which case whatever”. Evidently that’s not what you mean (good!). Perhaps something like,

“Operators SHOULD configure server policy to restrict the supported DNS record types, in accordance with their own requirements.”

Thanks to Takahiro Nemoto for their ARTART review.

I support Eric's DISCUSS position.

For the SHOULDs in Section 3.2, what are the implications of deviating from this advice?  Is there ever a legitimate reason to do so?

Thank you for including Section 9.

Thank you to Ines Robles for the GENART review.

** Section 1.2.1
   2.  If the value of the "for" attribute is "custom", then the
       <ttl:ttl> element MUST also have a "custom" attribute containing
       a DNS record type conforming with the regular expression in
       Section 3.1 of [RFC6895].  Additionally, the record type MUST be
       registered with IANA.

Does this “must be registered with IANA” mean that it has a code point in https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml?  It would be helpful to be explicit in the text.

“Private Use” values would not be acceptable?

** Section 1.2.1.2
   To facilitate forward compatibility with future changes to the DNS
   protocol, this document does not enumerate or restrict the DNS record
   types that can be included in the "custom" attribute of the <ttl:ttl>
   element.

Does this mean no restriction beyond requiring their registration?

** Section 3.1
   Servers SHOULD restrict the supported DNS record types in accordance
   with their own policy.  For example, a server MAY allow clients to
   specify TTL values for DS records only.

This “SHOULD” statement is confusing.  When would servers NOT restrict things according to their own policy.  It reads like it isn’t mandatory for them to follow their own policy.

Thanks for this specification. I agree with Eric that describing or defining the frames would be helpful here.

Thanks for addressing the previous DISCUSS (and most of my COMMENTS) in the -18 and for the e-mail exchanges.

See https://mailarchive.ietf.org/arch/msg/regext/URDkHLYZCbWNbDD3e-avb6dG160/ for the previous ballot.

Regards

-éric

## COMMENTS (non-blocking)

### Section 1.2.1.2

It is mostly a DISCUSS point, but why using a "custom" attribute rather a IANA approved RRTYPE ? It adds complexity in the parsing for little value IMHO.

### Section 7

Strongly suggest to add the IANA registry URI as a reference to avoid any ambiguity.

## NITS (non-blocking / cosmetic)

### Section 2.1.1.1

Like written by Erik Kline, please use canonical IPv6 address format, i.e., s/2001:DB8::8:800:200C:417A/2001:db8::8:800:200c:417a/ (this issue appears at least twice in the document).