Hi Karen, sorry to keep you waiting. I've just returned from summer vacation and am still catching up. I'll attend to this shortly.
G. On Tue, 25 Aug 2026, at 23:13, Karen Moore wrote: > Hello Gavin, > > We do not believe we have heard from you regarding this document's > readiness for publication. Please review our questions (see thread > below) and files and let us know if any updates are needed. > > The files are available here: > https://www.rfc-editor.org/authors/rfc10037.xml > https://www.rfc-editor.org/authors/rfc10037.html > https://www.rfc-editor.org/authors/rfc10037.pdf > https://www.rfc-editor.org/authors/rfc10037.txt > > Diff files of the text: > https://www.rfc-editor.org/authors/rfc10037-diff.html > https://www.rfc-editor.org/authors/rfc10037-rfcdiff.html (side by side) > > Details on the status of your Final Review are here: > https://queue.rfc-editor.org/final-review/rfc10037/ > > Best regards, > > Karen Moore > RFC Production Center > >> On Aug 14, 2026, at 3:04 PM, [email protected] wrote: >> >> Gavin, >> >> While reviewing this document during Final Review, please resolve (as >> necessary) the following questions, which are also in the source file. >> >> 1) <!--[rfced] Please note that the title has been updated as >> follows. Abbreviations have been expanded per Section 3.6 of RFC >> 7322 ("RFC Style Guide"). We also made "To" lowercase (which >> matches the title of RFC 9803). >> >> Original: >> RDAP Extension for DNS Time-To-Live (TTL Values) >> >> Current: >> Registration Data Access Protocol (RDAP) Extension >> for DNS Time-to-Live (TTL) Values >> --> >> >> >> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in >> the title) for use on https://www.rfc-editor.org/search. >> --> >> >> >> 3) <!--[rfced] This document uses four different terms for the >> "ttl0_data" JSON object and its "values"/"remarks" sub-parts: >> "property" (used most frequently), "member", "element", and >> "attribute". For consistency, please let us know which term >> should be used throughout. (We note that RFC 9083 consistently >> uses "member" for JSON name/value pairs.) >> >> Use of "property" (Section 3): >> Servers that support this extension MAY include a "ttl0_data" >> property in any domain... >> >> Use of "member" (Section 3): >> ...clients that do not implement this specification SHOULD >> ignore the "ttl0_data" member. >> >> Uses of "element" (Section 4.2): >> ...should explicitly carve out the "values" property of >> "ttl0_data" elements. >> >> Since the list of record types appearing in "ttl0_data" elements >> may change with time... >> >> Uses of "attribute" (Section 3): >> An example domain object with a valid "ttl0_data" attribute is >> provided below. >> >> An example nameserver object with a valid "ttl0_data" attribute >> is provided below. >> --> >> >> >> 4) <!--[rfced] We note that the use of quotation marks around terms >> tagged with <tt> is inconsistent. In most instances, the term is >> set off with quotation marks in addition to the <tt> tags (e.g., >> "<tt>ttl0_data</tt>"), but in the instances below, the quotation >> marks are omitted. For consistency, please let us know if >> quotation marks should be added in these instances or removed >> from the other instances throughout the document. >> >> Note: In the last example, "ttl0" has quotation marks but >> "rdapConformance" does not. >> >> Current: >> Section 3: >> The <tt>ttl0_data</tt> property is an object that has the >> following properties: >> >> Section 3.1: >> The DNS record type mnemonics that appear as the property >> names in <tt>values</tt> objects MUST be in all capitals... >> >> Section 3.2: >> Servers returning responses containing TTL values MUST include >> the string "<tt>ttl0</tt>" in the <tt>rdapConformance</tt> >> array. >> --> >> >> >> 5) <!--[rfced] Sourcecode examples in Section 3 >> >> a) In the first sourcecode example, we note an extra space before >> "registry". Is this intentional, or should "registry" be moved >> over one space to the left? And should a period be added after >> "https://domain.example"; for consistency? >> >> Current: >> "description": [ >> "For more information about the .example", >> " registry policy relating to DS record TTL changes,", >> "see https://domain.example"; >> >> Perhaps: >> "description": [ >> "For more information about the .example", >> "registry policy relating to DS record TTL changes,", >> "see https://domain.example."; >> >> b) In the second sourcecode example, we note a space after >> "TTL" - is that intentional, or should the extra space be >> deleted? >> >> Current: >> "description": [ >> "The .example registry does not permit TTL ", >> "values for nameservers to be changed." >> >> Perhaps: >> "description": [ >> "The .example registry does not permit TTL", >> "values for nameservers to be changed." >> --> >> >> >> 6) <!--[rfced] Is the intention to cite the names of the RFCs (option A) >> or the protocol and extension names (option B)? Additionally, >> please confirm if our updates to the latter half of the sentence >> correctly reflect that it is the EPP TTL extension (RFC 9803) >> that does not need to be implemented. Note that we also made >> "server" plural. >> >> Original: >> This specification is complementary to the Extensible Provisioning >> Protocol [RFC5730] (EPP) Mapping for DNS Time-to-Live (TTL) >> Values [RFC9803], but registry operators do not need to implement >> that extension in their EPP server in order to implement this RDAP >> extension. >> >> Perhaps A (document titles): >> This specification is complementary to "Extensible Provisioning >> Protocol (EPP)" [RFC5730] and "Extensible Provisioning Protocol >> (EPP) Mapping for DNS Time-to-Live (TTL) Values" [RFC9803], but >> registry operators do not need to implement the EPP extension >> described in [RFC9803] in their EPP servers in order to implement >> this RDAP extension. >> >> or >> Perhaps B (protocol/extension names): >> This specification is complementary to the Extensible Provisioning >> Protocol (EPP) [RFC5730] and the EPP Mapping for DNS Time-to-Live >> (TTL) Values extension [RFC9803], but registry operators do not >> need to implement that EPP extension in their EPP servers in order >> to implement this RDAP extension. >> --> >> >> >> 7) <!--[rfced] In the Acknowledgements section, note that we removed >> "Sarah Tarrant" as we don't normally include RPC staff names in >> this section, especially since multiple editors help to process >> the document. >> --> >> >> >> 8) <!--[rfced] FYI: We have added an expansion for the following >> abbreviation per Section 3.6 of RFC 7322 ("RFC Style Guide"). >> Please review this and each expansion in the document >> carefully to ensure correctness. >> >> Delegation Signer (DS) >> --> >> >> >> 9) <!--[rfced] Please review the "Inclusive Language" portion of the online >> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >> and let us know if any changes are needed. Updates of this nature typically >> result in more precise language, which is helpful for readers. >> >> Note that our script did not flag any words in particular, but this should >> still be reviewed as a best practice. >> --> >> >> >> Thank you. >> >> Karen Moore >> RFC Production Center >> >> >> On Aug 14, 2026, at 3:02 PM, [email protected] wrote: >> >> *****IMPORTANT***** >> >> RFC Author(s): >> -------------- >> >> Final Review for RFC-to-be 10037 <draft-ietf-regext-rdap-ttl-extension> >> >> Your document is now available for Final Review (previously AUTH48). Once it >> has been >> reviewed and approved by you and all coauthors, it will be published as an >> RFC. >> If an author is no longer available, there are several remedies; >> see the Unavailable Authors section >> (https://authors.ietf.org/rfc-publication-process#unavailable-authors). >> >> You and you coauthors are responsible for engaging other parties >> (e.g., Contributors or Working Group) as necessary before providing >> your approval. >> >> Planning your review >> --------------------- >> >> Please review the following aspects of your document: >> >> * RFC Editor questions >> >> Please review and resolve any questions raised by the RFC Editor >> that have been included in the XML file as comments marked as >> follows: >> >> <!-- [rfced] ... --> >> >> These questions will also be sent in a subsequent email. >> >> * Changes submitted by coauthors >> >> Please ensure that you review any changes submitted by your >> coauthors. We assume that if you do not speak up that you >> agree to changes submitted by your coauthors. >> >> * Content >> >> Please review the full content of the document, as this cannot >> change once the RFC is published. Please pay particular attention to: >> - IANA considerations updates (if applicable) >> - contact information >> - references >> >> * Copyright notices and legends >> >> Please review the copyright notice and legends as defined in >> RFC 5378 and the Trust Legal Provisions >> (TLP – https://trustee.ietf.org/license-info). >> >> * Semantic markup >> >> Please review the markup in the XML file to ensure that elements of >> content are correctly tagged. For example, ensure that <sourcecode> >> and <artwork> are set correctly. See details at >> <https://authors.ietf.org/rfcxml-vocabulary>. >> >> * Formatted output >> >> Please review the PDF, HTML, and TXT files to ensure that the >> formatted output, as generated from the markup in the XML file, is >> reasonable. Please note that the TXT will have formatting >> limitations compared to the PDF and HTML. >> >> >> Submitting changes >> ------------------ >> >> To submit changes, please reply to this email using 'REPLY ALL' as all >> the parties CCed on this message need to see your changes. The parties >> include: >> >> * your coauthors >> >> * [email protected] (the RPC team) >> >> * other document participants, depending on the stream (e.g., >> IETF Stream participants are your working group chairs, the >> responsible ADs, and the document shepherd). >> >> * [email protected], which is an archival mailing list >> to preserve discussion about the document while in the RPC editorial >> queue; it is not an active discussion list: >> >> * More info: >> >> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >> >> * The archive itself: >> https://mailarchive.ietf.org/arch/browse/auth48archive/ >> >> * Note: If only absolutely necessary, you may temporarily opt out >> of the archiving of messages (e.g., to discuss a sensitive matter). >> If needed, please add a note at the top of the message that you >> have dropped the address. When the discussion is concluded, >> [email protected] will be re-added to the CC list and >> its addition will be noted at the top of the message. >> >> You may submit your changes in one of two ways: >> >> An update to the provided XML file >> — OR — >> An explicit list of changes in this format >> >> Section # (or indicate Global) >> >> OLD: >> old text >> >> NEW: >> new text >> >> You do not need to reply with both an updated XML file and an explicit >> list of changes, as either form is sufficient. >> >> We will ask a stream manager to review and approve any changes that seem >> beyond editorial in nature, e.g., addition of new text, deletion of text, >> and technical changes. Information about stream managers can be found in >> the FAQ. Editorial changes do not require approval from a stream manager. >> >> >> Approving for publication >> -------------------------- >> >> To approve your RFC for publication, please reply to this email stating >> that you approve this RFC for publication. Please use 'REPLY ALL', >> as all the parties CCed on this message need to see your approval. >> >> >> Files >> ----- >> >> The files are available here: >> https://www.rfc-editor.org/authors/rfc10037.xml >> https://www.rfc-editor.org/authors/rfc10037.html >> https://www.rfc-editor.org/authors/rfc10037.pdf >> https://www.rfc-editor.org/authors/rfc10037.txt >> >> Diff file of the text: >> https://www.rfc-editor.org/authors/rfc10037-diff.html >> https://www.rfc-editor.org/authors/rfc10037-rfcdiff.html (side by side) >> >> Diff of the XML: >> https://www.rfc-editor.org/authors/rfc10037-xmldiff1.html >> >> >> Tracking progress >> ----------------- >> >> Details on the status of your Final Review are here: >> https://queue.rfc-editor.org/final-review/rfc10037/ >> >> Please let us know if you have any questions. >> >> Thank you for your cooperation, >> >> RFC Editor >> >> -------------------------------------- >> RFC 10037 (draft-ietf-regext-rdap-ttl-extension) >> >> Title : RDAP Extension for DNS Time-To-Live (TTL Values) >> Author(s) : Gavin Brown >> WG Chair(s) : James Galvin, Antoin Verschuren, Jorge Cano >> Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani >> -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
