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
