David, Thank you for the updates.
We will move this document forward in the publication process at this time. RFC Editor/mf > On Jun 12, 2025, at 2:58 PM, David Dong via RT <iana-mat...@iana.org> wrote: > > Hi Megan, > > Apologies; the contents of the ACME RenewalInfo Object Fields registry are > displayed again: > > Field Name Field Type Reference > suggestedWindow object [RFC-ietf-acme-ari-08] > explanationURL string [RFC-ietf-acme-ari-08] > > Registry: > https://www.iana.org/assignments/acme/ > > Best regards, > > David Dong > IANA Services Sr. Specialist > > On Thu Jun 12 20:08:57 2025, mfergu...@staff.rfc-editor.org wrote: >> Hi David, >> >> Looking at https://www.iana.org/assignments/acme/acme.xhtml#acme- >> renewalinfo-object-fields, I believe there should be initial contents: >> >> From Section 7.2 of the document (see https://www.rfc- >> editor.org/authors/rfc9773.txt): >> >> Initial contents: >> +=================+============+===============+ >> | Field Name | Field Type | Reference | >> +=================+============+===============+ >> | suggestedWindow | object | This document | >> +-----------------+------------+---------------+ >> | explanationURL | string | This document | >> +-----------------+------------+---------------+ >> >> Table 3 >> >> Thank you. >> >> RFC Editor/mf >> >>> On Jun 11, 2025, at 4:54 PM, David Dong via RT <iana-mat...@iana.org> >>> wrote: >>> >>> Hi Megan, >>> >>> This has been completed: >>> >>> 1) renewalInfo RenewalInfo object [RFC-ietf-acme-ari-08] >>> 2) ACME RenewalInfo Object Fields >>> 3) alreadyReplaced The request specified a predecessor certificate >>> that has already been marked as replaced [RFC-ietf-acme-ari- >>> 08] >>> >>> Registry: >>> https://www.iana.org/assignments/acme/ >>> >>> Thank you. >>> >>> Best regards, >>> >>> David Dong >>> IANA Services Sr. Specialist >>> >>> On Mon Jun 09 17:07:33 2025, mfergu...@staff.rfc-editor.org wrote: >>>> IANA, >>>> >>>> This document has completed AUTH48 and needs a few updates to the >>>> following to match. You may view the related diff (Section 7) for >>>> your convenience at: >>>> https://www.rfc-editor.org/authors/rfc9773-diff.html >>>> >>>> 1) At https://www.iana.org/assignments/acme/acme.xhtml#acme- >>>> resource- >>>> types, please remove the space between Renewal and Info: >>>> >>>> Original: >>>> renewalInfo Renewal Info object [RFC-ietf-acme-ari-08] >>>> >>>> Current: >>>> renewalInfo RenewalInfo object [RFC-ietf-acme-ari-08] >>>> >>>> 2) The new sub registry at >>>> https://www.iana.org/assignments/acme/acme.xhtml#acme-renewal-info- >>>> object-fields needs a similar title update: >>>> >>>> Original: >>>> ACME Renewal Info Object Fields >>>> >>>> Current: >>>> ACME RenewalInfo Object Fields >>>> >>>> 3) At https://www.iana.org/assignments/acme/acme.xhtml#acme-error- >>>> types, in the Description, please change “which” to “that”: >>>> >>>> Original: >>>> …predecessor certificate which has… >>>> >>>> Current: >>>> …predecessor certificate that has… >>>> >>>> Once these updates have been completed, this document will be ready >>>> to >>>> move forward in the publication process. >>>> >>>> Thank you. >>>> >>>> RFC Editor/mf >>>> >>>> >>>>> On Jun 6, 2025, at 5:55 PM, Aaron Gable <aa...@letsencrypt.org> >>>>> wrote: >>>>> >>>>> Hi Megan, >>>>> >>>>> Apologies for the delay. After extensive review with all of my >>>>> coworkers, we have found one last typo: >>>>> >>>>> Section 6 >>>>> >>>>> OLD: >>>>> (or do no implement ARI at all) >>>>> >>>>> NEW: >>>>> (or do not implement ARI at all) >>>>> >>>>> Thanks, >>>>> Aaron >>>>> >>>>> On Thu, Jun 5, 2025 at 10:47 AM Megan Ferguson >>>>> <mfergu...@staff.rfc- >>>>> editor.org> wrote: >>>>> 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
