Hi Aaron, Just a friendly reminder that we await your confirmation of our changes and approval prior to moving this document forward in the publication process.
Thank you. RFC Editor/mf > > Begin forwarded message: > > From: Megan Ferguson <mfergu...@staff.rfc-editor.org> > Subject: Re: AUTH48: RFC-to-be 9773 <draft-ietf-acme-ari-08> for your review > Date: May 13, 2025 at 9:31:58 PM MDT > To: Aaron Gable <aa...@letsencrypt.org> > Cc: RFC Editor <rfc-edi...@rfc-editor.org>, acme-...@ietf.org, > acme-cha...@ietf.org, ynir.i...@gmail.com, Deb Cooley <debcool...@gmail.com>, > auth48archive@rfc-editor.org > > Hi Aaron, > > Thank you for sending along these changes in the XML file. We have adopted > the changes and reposted. > > Please review the files carefully as we do not make changes after > publication. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9773.txt > https://www.rfc-editor.org/authors/rfc9773.pdf > https://www.rfc-editor.org/authors/rfc9773.html > https://www.rfc-editor.org/authors/rfc9773.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9773-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9773-auth48diff.html (AUTH48 changes > only) > https://www.rfc-editor.org/authors/rfc9773-lastdiff.html (last to current > version only) > https://www.rfc-editor.org/authors/rfc9773-lastrfcdiff.html (last to > current version side by side) > > Please contact us with any further updates/questions/comments you may have or > with your approval of the document in its current form. Once we have your > approval, we will send along any necessary updates to IANA prior to > publication. > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9773 > > Thank you. > > RFC Editor/mf > On May 13, 2025, at 5:29 PM, Aaron Gable <aa...@letsencrypt.org> wrote: > > I have two final minor edits that I would like to incorporate: > > - In Section 4.2, replace "set of names on the order" with "set of > identifiers on the order". > - In Section 5, replace "GET requests described above" with "GET requests > described in Section 4.1", with an internal cross-link to that section. > > I have attached an XML file that I believe implements these two edits and no > other changes; please make sure I haven't accidentally broken anything! > > Thanks again, > Aaron > > On Wed, May 7, 2025 at 6:18 PM Megan Ferguson > <mfergu...@staff.rfc-editor.org> wrote: > Hi Aaron, > > Just a friendly reminder that the updates to this document await your review. > > Please contact us at your earliest convenience with any further changes you > may have or your approval of the document in its current form. > > Thank you. > > RFC Editor/mf > > > > On Apr 29, 2025, at 1:53 PM, Megan Ferguson > > <mfergu...@staff.rfc-editor.org> wrote: > > > > Hi Aaron, > > > > Thank you for your reply and the updated XML file. > > We have adopted your version (see below) and added the keywords suggested > > to our database. > > > > Please review the files carefully as we do not make changes after > > publication. > > > > The files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9773.txt > > https://www.rfc-editor.org/authors/rfc9773.pdf > > https://www.rfc-editor.org/authors/rfc9773.html > > https://www.rfc-editor.org/authors/rfc9773.xml > > > > The relevant diff files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9773-diff.html (comprehensive diff) > > https://www.rfc-editor.org/authors/rfc9773-auth48diff.html (AUTH48 > > changes only) > > https://www.rfc-editor.org/authors/rfc9773-lastdiff.html (last to current > > version only) > > > > Please contact us with any further updates/questions/comments you may have. > > > > > > We will await approvals from each of the parties listed on the AUTH48 > > status page prior to moving forward to publication. > > > > The AUTH48 status page for this document is available here: > > > > https://www.rfc-editor.org/auth48/rfc9773 > > > > Thank you. > > > > RFC Editor/mf > > > >> On Apr 25, 2025, at 4:17 PM, Aaron Gable > >> <aaron=40letsencrypt....@dmarc.ietf.org> wrote: > >> > >> Hello editors, > >> > >> Thank you for the edits and improvements to this document! My responses to > >> your specific questions are inline below, and the updated XML file is > >> attached. > >> > >> Thanks again, > >> Aaron > >> > >> On Wed, Apr 23, 2025 at 1:51 PM <rfc-edi...@rfc-editor.org> wrote: > >> 1) <!-- [rfced] Please note that the title of the document has been > >> updated as follows: > >> > >> We have moved the expansion of ACME from the document title to its first > >> use in the Abstract as generally we do not expand abbreviations within > >> abbreviations. > >> > >> Original: > >> Automated Certificate Management Environment (ACME) Renewal > >> Information (ARI) Extension > >> > >> Current: > >> ACME Renewal Information (ARI) Extension > >> > >> --> > >> > >> Thank you, the improved title is great. > >> > >> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > >> the title) for use on > >> https://www.rfc-editancestorDomainancestorDomainor.org/search. --> > >> > >> I have added the following keywords: > >> - certificate > >> - CA > >> - x509 > >> - pki > >> - webpki > >> - renew > >> - replace > >> > >> I'm not sure how best to see the keywords attached to other ACME documents > >> all in one place; please feel free to add or remove keywords to bring this > >> list in line with best practices. > >> > >> 3) <!--[rfced] Please review our update to "a literal period" to make it > >> match similar handling of the "=" character later in the paragraph and > >> uses in the RFC Series and let us know any objections. > >> > >> Original: > >> > >> The unique identifier is constructed by concatenating the > >> base64url-encoding [RFC4648] of the keyIdentifier field of the > >> certificate's Authority Key Identifier (AKI) [RFC5280] extension, a > >> literal period, and the base64url-encoding of the DER-encoded Serial > >> Number field (without the tag and length bytes). > >> > >> Current: > >> > >> The unique identifier is constructed by concatenating the > >> base64url-encoding [RFC4648] of the keyIdentifier field of the > >> certificate's Authority Key Identifier (AKI) [RFC5280] extension, the > >> period character ".", and the base64url-encoding of the DER-encoded Serial > >> Number field (without the tag and length bytes). > >> > >> --> > >> > >> This update looks great to me. > >> > >> 4) <!--[rfced] We had the following questions related to the IANA > >> Considerations section: > >> > >> a) Section 7.1: In the Resource Type column of Table 2, please review if > >> "Renewal info", "Renewal Information", or "renewalInfo" or something else > >> should be used instead of "Renewal Info" as this is the only occurrence in > >> the document of this form (other than Table 1, which also uses "Renewal > >> info"). > >> > >> Original: > >> Renewal Info object > >> > >> Thank you for catching this. I have settled on the following convention: > >> - `renewalInfo` (always in <tt>, always starting lowercase) refers to the > >> new entry added to the Directory object. > >> - RenewalInfo (always in plaintext, always starting uppercase) refers to > >> the newly-introduced resource/object. > >> > >> I've also eliminated all use of the shortened form "info", except as part > >> of those two compound words. I have attempted to update the whole document > >> to abide by this convention, but may have missed a spot. Please let me > >> know if I have! > >> > >> b) Section 7.2: FYI - we have added a citation to RFC 8126 in the > >> description of the Registration Procedure and a corresponding entry in > >> the Informative References section. Please let us know any concerns. > >> > >> c) FYI- we will communicate any nits/edits to IANA upon the completion > >> of AUTH48. > >> > >> > >> --> > >> > >> Thanks for the heads-up! > >> > >> 5) <!--[rfced] Please review the following questions related to > >> terminology use throughout the document. > >> > >> a) We see mixed marking of the following terms throughout the document. > >> Please let us know if/how these may be made uniform: > >> > >> "renewalInfo" resource vs. renewalInfo resource > >> > >> See above, I believe I have standardized this now. > >> > >> New Order request vs. new-order request > >> > >> Interestingly, neither of these is correct! I have updated all instances > >> to "newOrder request", to match RFC 8555 and other ACME documents. > >> > >> Server vs. server > >> > >> Standardized on the lowercase form, to match RFC 8555 > >> > >> base64url-encoding vs. base64url encoding > >> > >> Standardized on the form without a hyphen, to match RFC 8555. > >> > >> b) There are instances of simply RenewalInfo. Should a label follow > >> (e.g., object, resource, etc.) for the ease of the reader? > >> > >> I have added either "object" or "resource" after all instances of > >> RenewalInfo except those of the form "the certificate's RenewalInfo", > >> which I think are already sufficiently clear. > >> > >> > >> --> > >> > >> > >> 6) <!--[rfced] We note the use of the <tt> element to mark text in this > >> document. See the list of marked terms below. > >> > >> a) We recommend authors review the output of this element in all > >> output formats (text, pdf, html, etc.) to ensure it appears as > >> expected across formats. > >> > >> b) Please review for consistent use throughout the document (as we see > >> some occurrences that are not marked with <tt>) and either update the > >> edited XML file directly or let the RPC know if/how we may update > >> . > >> > >> 00:87:65:43:21 > >> 0x87 > >> 69:88:5B:6B:87:46:40:41:E1:B3:7B:84:7B:A0:AE:2C:DE:01:C8:D4 > >> AIdlQyE= > >> aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE > >> aYhba4dGQEHhs3uEe6CuLN4ByNQ= > >> cron > >> end > >> explanationURL > >> keyIdentifier > >> renewalInfo > >> replaces > >> Retry-After > >> start > >> suggestedWindow > >> = > >> || > >> > >> I believe I have standardized the use of <tt> so that now it is used in > >> only the following circumstances: > >> - around JSON object field names, such as renewalInfo, suggestedWindow, > >> explanationURL, start, end, and replaces > >> - around literal byte sequences, such as the period, equals, pipes, and > >> various hex and base64 values > >> > >> I have removed it from Retry-After, keyIdentifier, and cron. > >> > >> --> > >> > >> > >> 7) <!-- [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 for this reference; I believe this document abides by all of its > >> suggestions. All people mentioned in the acknowledgements have given their > >> permission and preferred name. > >> > >> > >> > >> Thank you. > >> > >> RFC Editor/mf > >> > >> *****IMPORTANT***** > >> > >> Updated 2025/04/23 > >> > >> RFC Author(s): > >> -------------- > >> > >> Instructions for Completing AUTH48 > >> > >> Your document has now entered 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 > >> available as listed in the FAQ (https://www.rfc-editor.org/faq/). > >> > >> 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. > >> > >> I believe all questions have been addressed above. > >> > >> > >> * 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. > >> > >> No coauthors have submitted any parallel changes. > >> > >> > >> * 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 > >> > >> All the content appears correct to my eye, though I've now stared at it > >> for so long that I'm sure I'm blind to any remaining typos. > >> > >> > >> * 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). > >> > >> Reviewed. > >> > >> > >> * 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>. > >> > >> All semantic markup (largely just sourcecode and tt in this document) > >> looks good to me. > >> > >> > >> * 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. > >> > >> Formatting looks good. Thank you so much for getting the text version to > >> have nice indentation when defining new object fields (e.g. Section 5); I > >> couldn't figure out how to get my markdown-to-rfc tooling to do that at > >> all. > >> > >> 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 > >> > >> * rfc-edi...@rfc-editor.org (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). > >> > >> * auth48archive@rfc-editor.org, which is a new archival mailing list > >> to preserve AUTH48 conversations; 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, > >> auth48archive@rfc-editor.org 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/rfc9773.xml > >> https://www.rfc-editor.org/authors/rfc9773.html > >> https://www.rfc-editor.org/authors/rfc9773.pdf > >> https://www.rfc-editor.org/authors/rfc9773.txt > >> > >> Diff file of the text: > >> https://www.rfc-editor.org/authors/rfc9773-diff.html > >> https://www.rfc-editor.org/authors/rfc9773-rfcdiff.html (side by side) > >> > >> Diff of the XML: > >> https://www.rfc-editor.org/authors/rfc9773-xmldiff1.html > >> > >> > >> Tracking progress > >> ----------------- > >> > >> The details of the AUTH48 status of your document are here: > >> https://www.rfc-editor.org/auth48/rfc9773 > >> > >> Please let us know if you have any questions. > >> > >> Thank you for your cooperation, > >> > >> RFC Editor > >> > >> -------------------------------------- > >> RFC9773 (draft-ietf-acme-ari-08) > >> > >> Title : Automated Certificate Management Environment (ACME) > >> Renewal Information (ARI) Extension > >> Author(s) : A. Gable > >> WG Chair(s) : Yoav Nir, Tomofumi Okubo > >> > >> Area Director(s) : Deb Cooley, Paul Wouters > >> > >> > >> <rfc9773.xml> > > > > > > > > <rfc9773.xml> -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
