Hi Scott, Thank you for your reply. We have updated as requested.
The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9874.xml https://www.rfc-editor.org/authors/rfc9874.txt https://www.rfc-editor.org/authors/rfc9874.html https://www.rfc-editor.org/authors/rfc9874.pdf The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc9874-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9874-auth48diff.html (AUTH48 changes) https://www.rfc-editor.org/authors/rfc9874-auth48rfcdiff.html (AUTH48 changes side by side) Please review the document carefully and contact us with any further updates you may have. Note that we do not make changes once a document is published as an RFC. We will await approvals from each party listed on the AUTH48 status page below prior to moving this document forward in the publication process. For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9874 Thank you, Alanna Paloma RFC Production Center > On Sep 23, 2025, at 9:27 AM, Hollenbeck, Scott > <[email protected]> wrote: > >> -----Original Message----- >> From: [email protected] <[email protected]> >> Sent: Tuesday, September 23, 2025 1:26 AM >> To: Hollenbeck, Scott <[email protected]>; Carroll, William >> <[email protected]>; [email protected] >> Cc: [email protected]; [email protected]; [email protected]; >> [email protected]; [email protected]; [email protected] >> Subject: [EXTERNAL] Re: AUTH48: RFC-to-be 9874 >> <draft-ietf-regext-epp-delete- >> bcp-10> for your review >> >> Caution: This email originated from outside the organization. Do not click >> links >> or open attachments unless you recognize the sender and know the content is >> safe. >> >> Authors, >> >> While reviewing this document during AUTH48, please resolve (as necessary) >> the following questions, which are also in the source file. > > [SAH] We've noted our responses below. In addition, we've found one term > that's used in the text that requires an additional sentence for > clarification. We've already discussed the topic with Orie (cc'd here), and > he's approved our approach to adding a clarification to the text in Section 5. > > OLD > Notably, the scope of any practice discussed here is the EPP server that > adopts the practice and the domains managed by it. > > NEW > Notably, the scope of any practice discussed here is the EPP server that > adopts the practice, the domains managed by it, and the associated host > objects where "associated" is described in RFCs 5731 [RFC5731] and 5732 > [RFC5732]. > >> 1) <!--[rfced] This document has been assigned a new BCP number. >> Please let us know if this is not correct (i.e., it should be part of an >> existing >> BCP). >> >> See the complete list of BCPs here: >> https://secure-web.cisco.com/1ronHlStzrkPTBidwHiueJ0APXes- >> JyLb_dBGHiEBdouxvSEF3wsn6jC3V4DvPr1VhLhhmMtJ3PrSfqL4D1UWipGqCuX7I >> 39p4_j44l207oCjAyU89hiCwVaFSc0p240fujlWKdNUEvGwVfq_ajLa7iv1seDnOQ6e >> qr_JXbQbRGq2tgVkIbPQ7UOk0E_ahr9cbqPEundX3WkSEMpW_kBkjtB17xI35eaE >> uQwK25lRO5DfaaLfj4EzXud5tFWHUBHdfa- >> R0oCzlVaYWhRVjnLJ1blksuw72gt0t2LF1VqTKfk/https%3A%2F%2Fwww.rfc- >> editor.org%2Fbcps >> --> > > [SAH] This is correct. A new BCP number should be assigned. > >> 2) <!--[rfced] We note that Scott Hollenbeck and William Carroll have the >> same >> authors' address listed. However, Scott's organization is listed as >> "Verisign Labs", >> while William's is "Verisign". Should these be made consistent in the >> following >> and the document header? >> >> Scott Hollenbeck >> Verisign Labs >> 12061 Bluemont Way >> Reston, VA 20190 >> United States of America >> Email: [email protected] >> URI: https://secure- >> web.cisco.com/1lym9v5MxG01dIeXO4nDizhfNw4aZYvxr5Yh2KEWudPWvPviy- >> F4S2kDdzwSRDDnORgAAeCwsE- >> HYoDEj3QkF6YU91pIOMAkWxJdkQMKXvTmiUfhx67ZQTrYEpO_4ss9XK4n7RaybL >> T8diXMcVmImU8u6x5qFtiZSb5Zl6wwsPsLN5bGezyF5zimFvxjZA5xtWKzxS2Fekf- >> wFq2dqWbVh1OEkMpeKIohu6M4VRAcxy80ZRXFPIDFVQd17bFfkc00R6qA2j1CKd >> L5wS-i8SeJjvtWRA-wbKTAm_SSnLyjPENwvT_l2hH7iY9ueBE3c46- >> /https%3A%2F%2Fwww.verisignlabs.com%2F >> >> >> William Carroll >> Verisign >> 12061 Bluemont Way >> Reston, VA 20190 >> United States of America >> Phone: +1 703 948-3200 >> Email: [email protected] >> URI: https://verisign.com >> --> > > [SAH] Yes, please use Verisign Labs for both. > >> 3) <!--[rfced] For clarity, may we add citations to [RFC5731] and [RFC5732] >> in >> this sentence? >> >> Original: >> This document describes the rationale for the "SHOULD NOT be deleted" >> text and the risk associated with host object renaming. >> >> Perhaps: >> This document describes the rationale for the "SHOULD NOT be deleted" >> text in [RFC5731] and [RFC5732] as well as the risk associated with >> host object renaming. >> --> > > [SAH] Sure, that's fine. > >> 4) <!-- [rfced] FYI - Some sentences cite RFCs 5731 and 5732 but did not >> include >> cite tags. We have added cite tags to these citations. For example: >> >> Original: >> The text in RFCs 5731 and 5732 was written to >> encourage clients to take singular, discrete steps to delete objects >> in a way that avoids breaking DNS resolution functionality. >> >> Current: >> The text in [RFC5731] and [RFC5732] was written to >> encourage clients to take singular, discrete steps to delete objects >> in a way that avoids breaking DNS resolution functionality. >> --> > > [SAH] That's fine. > >> 5) <!--[rfced] To improve readability, may we update "as can" to "which can" >> below? >> >> Original: >> Implementations of EPP can have dependencies on the hierarchical >> domain object/host object relationship, as can exist in a relational >> database. >> >> Perhaps: >> Implementations of EPP can have dependencies on the hierarchical >> domain object/host object relationship, which can exist in a relational >> database. >> --> > > [SAH] That's fine. > >> 6) <!-- [rfced] We note that [RFC7535] uses "EMPTY.AS112.ARPA" rather than >> "empty.as112.arpa". Should this be updated to match [RFC7535]? >> >> Current: >> "empty.as112.arpa" is designed to be used with DNAME aliasing, not >> as a parent domain for sacrificial name servers (see Section 3 of >> [RFC7535]). >> --> > > [SAH] Yes, please use uppercase characters. > >> 7) <!--[rfced] Does "removed from the zone" apply to both "domains with no >> remaining name servers" and "domains with only one remaining name server"? >> If yes, may we update this sentence as follows? Note that this sentence >> occurs >> in Sections 5.2.1.1.2 and 5.2.2.1.2. >> >> Original: >> This could result in domains with no remaining name servers being >> removed from the zone or domains with only one remaining name server. >> >> Perhaps: >> This could result in domains with no remaining name servers or >> with only one remaining name server being removed from the zone. >> --> > > [SAH] We'd prefer something like this: > > "This could result in domains with no name servers being removed from the > zone > or domains with only one name server remaining in the zone." > >> 8) <!-- [rfced] Informative reference RFC 8499 has been obsoleted by RFC >> 9499. >> May we update the reference to point to RFC 9499? We note that "NXDOMAIN" >> is mentioned in RFC 9499. >> >> RFC 8499 is cited in the text as follows: >> Requests to the root for this domain would result >> in NXDOMAIN response [RFC8499]. >> --> > > [SAH] Yes, that's fine. > >> 9) <!--[rfced] FYI - We have alphabetized the names listed in the >> Acknowledgments section. We believe that was the intent as only one was out >> of order. Let us know if you prefer the original order. >> --> > > [SAH] That change is fine. > >> 10) <!--[rfced] FYI - As both "nameserver" and "name server" were used >> throughout the document. We have updated all instances to "name server" >> for consistency. Please review and let us know of any objections. >> --> > > [SAH] That's fine. > >> 11) <!--[rfced] FYI - We have added an expansion for the following >> abbreviation per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review >> each expansion in the document carefully to ensure correctness. >> >> Top-Level Domain (TLD) >> --> > > [SAH] That's fine. > >> 12) <!-- [rfced] Please review the "Inclusive Language" portion of the >> online Style Guide <https://secure- >> web.cisco.com/1SkvcGcLm7rHlDGJeQZxcpRT54XiBPIq-Oqx5h7- >> qRg4O9nPsnGqiyMqmH- >> rKQBq4nIXXFLxhvTkvkkZLe540tVqQB4p7wC3MFE7v31khFUWS9Oer5ejV9N- >> 8LRYEtciO2SjvDf9O40-9QMUe_T- >> 2KFhOVFL5FS_mCXnLAyO8ubttjPUlzYQKrQ_s3VZsbKwtTWqKzSSRhgJLmko7ipCX0 >> CZ5Ipol7QzPLs9hXdCsoTvRgGOPFMynO70OSH5HPy- >> EMj8muo7qdjpJ3dPb3VbgWmUJGvJqCZF7JRBa2nq4ocE/https%3A%2F%2Fwww. >> rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_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. >> --> > > All good - thanks! > > Scott -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
