Hi Jim, thanks for your feedback. My comments are below. > On 22 Nov 2023, at 19:43, Gould, James <jgo...@verisign.com> wrote: > > Gavin, > Thank you for posting draft-ietf-regext-epp-ttl-03. Below is my review > feedback: > > • Section 1.2 “Extension elements” > • Nit – I would change “It has a single REQUIRED attribute, for, > which specifies the DNS record type to which the TTL value pertains” to “It > has a single REQUIRED “for” attribute, which specifies the DNS record type to > which the TTL value pertains”.
This will be fixed in the next version. > • Section 1.2.2 “Supported DNS record types” > • Nit – Put the “for” attribute in double quotes, such as “that can > be included in the “for” attribute. As above. > • How would setting the A and AAAA TTLs be implemented for servers > that implement the host objects model of RFC 5732? I believe this is adequately addressed in the draft, but the structure of the document does not clearly signpost it. So the next version will have a specific section on glue records which will combine the last bullet point in the list in section 1.2.2 with the paragraph that immediately follows it. The subsequent two paragraphs will be moved to a new subsection in Section 5. > • Section 3.2 “Use of TTL values for IDN variants” > • I believe this section needs to be removed, since it implies a > specific form of IDN variant relationship that should be defined outside of > the TTL extension. The sharing of attributes across a parent domain and the > variants, including TTL settings, should be covered by the IDN variant > specification and not the TTL extension itself. Agreed, this section has been removed. > • Section 5.2 “When TTL values should be changed” > • What does the convention of the use of the underbars in “_before_” > indicate? My recommendation is to remove the underbars or describe the > convention in section 1.1 “Conventions used in this document”. You're looking at the plaintext rendering, but in the HTML rendering, "before" is shown with emphasis, that is, italics. This is to emphasise that the TTL value must be changed before the RDATA value if the operator wants the shorter TTL to be in effect before the RDATA is changed. > • General considerations > • Inclusion of the server default TTL in the info response would be > helpful. > i. Could be included in a policy response based on inclusion of a > policy option in the command. > • Inclusion of the server min and max TTL in the info response would > be helpful > i. Could be included in a policy response based on inclusion of a > policy option in the command. So I think I would approach this by adding three attributes to <ttl>: * min - the minimum value * default - the default value * max - the maximum value Servers would then include these in responses to <info> commands, .e.g: <ttl:infData> <ttl:ttl for="NS" min="3600" default="86400" max="172800"/> <ttl:ttl for="DS" min="60" default="3600" max="172800"/> </ttl:infData> I'd appreciate the WG's feedback on this before I commit pen to paper. For example, should these attributes be optional, or mandatory in server responses? I am minded to make them mandatory, but would appreciate feedback from server operators. > • The known set of RRecs could be enumerated with support for > extensibility, like what was done with the use of the "custom" enumerated > value and the custom string value in RFC 8334[datatracker.ietf.org] for the > launch phases and "custom" command enumerated value with the "customName" > attribute in RFC 8748 [datatracker.ietf.org]. > i. Providing a predefined enumeration list supports XML parser > validation by default and supports extensibility for new values for the > future. This makes sense to me so I will implement it in the next version. Thanks, G. -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
