Hi Megan, These changes are complete:
https://www.iana.org/assignments/acme Thanks, Sabrina On Tue Jun 17 14:31:25 2025, mfergu...@staff.rfc-editor.org wrote: > IANA, > > Please make the following updates to > https://www.iana.org/assignments/acme/acme.xhtml#acme-error-types to > match the document. > > Original: > The CA only supports checking CAA for hidden services in-band, but the > client has not provided an in-band CAA > > New (add “the” and cap Hidden Services): > The CA only supports checking the CAA for Hidden Services in-band, but > the client has not provided an in-band CAA > > Once these updates have been confirmed, this document will be ready to > move forward to publication. > > Thank you. > > RFC Editor/mf > > > > > On Jun 6, 2025, at 4:51 PM, Q Misell <q...@as207960.net> wrote: > > > > That looks good to me. Happy for this to move to TI. > > Any statements contained in this email are personal to the author and > > are not necessarily the statements of the company unless specifically > > stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y- > > lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is > > a company registered in Wales under № 12417574, LEI > > 875500FXNCJPAPF3PD10. ICO register №: ZA782876. UK VAT №: > > GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South > > Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered > > office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, > > 46001, trading as Glauca Digital, is a company registered in Estonia > > under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the > > Glauca logo are registered trademarks in the UK, under № > > UK00003718474 and № UK00003718468, respectively. > > > > > > > > Ar Gwen, 6 Meh 2025 am 18:26 Megan Ferguson <mfergu...@staff.rfc- > > editor.org> ysgrifennodd: > > Hi Q, > > > > Thank you for the prompt reply. We have updated the redundant text > > (with a few punctuation tweaks pulled back in from our previous > > edits). Please review and approve. > > > > We have also noted your request to wait for tooling to handle the > > name issue at the AUTH48 status page for this document. Once we > > receive your approval of the last update, we will move this document > > to TI state (Tooling Issue) to await resolution. > > > > 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/rfc9799.txt > > https://www.rfc-editor.org/authors/rfc9799.pdf > > https://www.rfc-editor.org/authors/rfc9799.html > > https://www.rfc-editor.org/authors/rfc9799.xml > > > > The relevant diff files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9799-diff.html (comprehensive > > diff) > > https://www.rfc-editor.org/authors/rfc9799-auth48diff.html (AUTH48 > > changes only) > > https://www.rfc-editor.org/authors/rfc9799-lastdiff.html (last > > version to this) > > > > Please contact us with any further updates/questions/comments you may > > have. > > > > The AUTH48 status page for this document is available here: > > > > https://www.rfc-editor.org/auth48/rfc9799 > > > > Thank you. > > > > RFC Editor/mf > > > > > On Jun 6, 2025, at 4:54 AM, Q Misell <q...@as207960.net> wrote: > > > > > > Hi Megan, > > > > > > I'd rather wait a bit longer for the discussion on pull #1246 to > > > conclude. I don't mind if this RFC takes a little longer to > > > publish, but with my name shown correctly. > > > > > > In re the redundant text, indeed I did get confused with other > > > questions. You are right, it is redundant. I propose the following > > > text instead: > > > > > > Tor directory servers are inherently untrusted entities, and as > > > such there is no difference in the security model for accepting CAA > > > records directly from the ACME client or fetching them over Tor; > > > the CAA records are verified using the same hidden service key in > > > either case. > > > > > > Q > > > Any statements contained in this email are personal to the author > > > and are not necessarily the statements of the company unless > > > specifically stated. AS207960 Cyfyngedig, having a registered > > > office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading > > > as Glauca Digital, is a company registered in Wales under № > > > 12417574, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876. UK > > > VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: > > > 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, > > > having a registered office at Lääne-Viru maakond, Tapa vald, > > > Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a > > > company registered in Estonia under № 16755226. Estonian VAT №: > > > EE102625532. Glauca Digital and the Glauca logo are registered > > > trademarks in the UK, under № UK00003718474 and № UK00003718468, > > > respectively. > > > > > > > > > > > > Ar Iau, 5 Meh 2025 am 21:39 Megan Ferguson <mfergu...@staff.rfc- > > > editor.org> ysgrifennodd: > > > Hi Q, > > > > > > Thanks for the prompt reply and the updated XML file. > > > We have adopted this version and posted to the links below. > > > > > > A few follow-up comments/questions: > > > > > > 1) Looks like the issue about your initial is still being discussed > > > (see https://github.com/ietf-tools/xml2rfc/pull/1246). > > > > > > 2) We may have confused you with Question 14 with side edits > > > (sorry!). Please review the following for redundancy and let us > > > know if you’d like to make any changes: > > > > > > Original: > > > > > > Tor directory servers are inherently untrusted entities, and as > > > such > > > there is no difference in the security model for accepting CAA > > > records directly from the ACME client or fetching them over Tor. > > > There is no difference in the security model between accepting CAA > > > records directly from the ACME client and fetching them over Tor; > > > the > > > CAA records are verified using the same hidden service key in > > > either > > > case. > > > > > > 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/rfc9799.txt > > > https://www.rfc-editor.org/authors/rfc9799.pdf > > > https://www.rfc-editor.org/authors/rfc9799.html > > > https://www.rfc-editor.org/authors/rfc9799.xml > > > > > > The relevant diff files have been posted here (please refresh): > > > https://www.rfc-editor.org/authors/rfc9799-diff.html > > > (comprehensive diff) > > > https://www.rfc-editor.org/authors/rfc9799-auth48diff.html > > > (AUTH48 changes 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/rfc9799 > > > > > > Thank you. > > > > > > RFC Editor/mf > > > > > > > On Jun 4, 2025, at 7:26 AM, Q Misell > > > > <q=40as207960....@dmarc.ietf.org> wrote: > > > > > > > > > > > > Thank you for your copy editing; as always, much appreciated! > > > > > > > > Attached is my edited XML source, incorporating changes relating > > > > to your comments. Below are my responses to all comments. > > > > > > > > > The short title that appears in the running header of the pdf > > > > > output has been updated to use double quotes around ".onion" to > > > > > match the use in the full title. > > > > > > > > LGTM. > > > > > > > > > Q - currently our tooling does not support the request to > > > > > remove the period from following your first name. > > > > > > > > I have made a PR to xml2rfc (https://github.com/ietf- > > > > tools/xml2rfc/pull/1246) to fix this to my liking. > > > > I would appreciate that merged before publication. > > > > > > > > > Please insert any keywords > > > > > > > > Done. > > > > > > > > > Please review our edits to the following text to ensure we have > > > > > maintained your intent. > > > > > The ACME server SHOULD follow redirects. Note that these MAY > > > > > be redirects to services that are not ".onion" and that the > > > > > server SHOULD honor these. > > > > > > > > LGTM. > > > > > > > > > Please review our updates to this text carefully and let us > > > > > know any objections. > > > > > An "onion-csr-01" challenge MUST NOT be used to issue > > > > > certificates for Special-Use Domain Names that are not > > > > > ".onion". > > > > > > > > LGTM. > > > > > > > > > Please note that sourcecode elements in this document exceed > > > > > our character limit > > > > > > > > XML edited accordingly. > > > > > > > > > Please note that we have updated to use "flags" (plural) to > > > > > match the use in Section 4.1.1 of RFC 8659. > > > > > > > > No objection. > > > > > > > > > In the following instances, please review the use of the BCP 14 > > > > > keyword with the surrounding text > > > > > > > > Fixed in HTML. > > > > > > > > > We have deleted the "it" before the comma in this sentence. > > > > > > > > LGTM. > > > > > > > > > Please note that we believe Section 9.7.8 should actually read > > > > > 9.7.4 in the following. > > > > > > > > That is correct. > > > > > > > > > We believe "ACME Directory Metadata Fields" registry is defined > > > > > in Section 9.7.6 of [RFC8555], not Section 9.7.8. > > > > > > > > That is correct. > > > > > > > > > Please review our update to this text to expand MAC and avoid > > > > > using an abbreviation as a verb. > > > > > > > > LGTM > > > > > > > > > These sentences seem redundant. Please review. > > > > > > > > Edits LGTM > > > > > > > > > Please note that we have changed the URL of the [spoiled- > > > > > onions] reference to point use the DOI rather than the original > > > > > URL, which took the reader to a preview page that they couldn't > > > > > back out of. > > > > > > > > LGTM > > > > > > > > > Please review. We found an open-access version of [spoiled- > > > > > onions] on arXiv. The information appears to match the current > > > > > reference; however, some author names are missing. Would you > > > > > prefer to use this open-access version of this reference? > > > > > > > > The version I worked from whilst writing this RFC was the one > > > > published by Springer. The version on the arXiv appears to be a > > > > draft before the paper underwent peer-review, and as such I would > > > > rather not use it. > > > > > > > > > We assume ".onion" is pronounced as "dot onion" and have thus > > > > > left instances of "a ".onion" as they were. > > > > > > > > That is correct. > > > > > > > > > We see the following similar terms used. Please let us know if > > > > > these should be made uniform or if they should remain distinct > > > > > terms. > > > > > > > > They are all equivalent, I have edited the XML accordingly. > > > > > > > > > We note that <tt> tags were used to enclose the following terms > > > > > in this document. > > > > > > > > XML edited accordingly. > > > > > > > > > Please note we have expanded these abbreviations as follows > > > > > > > > LGTM > > > > > > > > > We note that the original xml file submitted used <eref> to > > > > > point to specific sections in the [tor-spec]. Please review if > > > > > these links should remain with the following in mind. Please > > > > > let us know how you would like to proceed. > > > > > > > > As, even during the course of drafting this RFC, the links became > > > > outdated, I have opted to remove any <eref>s to Tor spec > > > > documents. > > > > > > > > > Please consider whether the “type" attribute of any sourcecode > > > > > element should be set and/or has been set correctly. > > > > > > > > I'm happy with the type attributes as they are. > > > > > > > > > Please note that CSR (the abbreviation at least) is not used in > > > > > either Appendix B.2.b of [cabf-br] or [RFC2986]. Please review > > > > > the citations in this document and let us know if any updates > > > > > are necessary/desirable. > > > > > > > > I've expanded the abbreviation to Certificate Request where > > > > appropriate in the XML. > > > > Any statements contained in this email are personal to the author > > > > and are not necessarily the statements of the company unless > > > > specifically stated. AS207960 Cyfyngedig, having a registered > > > > office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, > > > > trading as Glauca Digital, is a company registered in Wales under > > > > № 12417574, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876. > > > > UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: > > > > 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, > > > > having a registered office at Lääne-Viru maakond, Tapa vald, > > > > Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a > > > > company registered in Estonia under № 16755226. Estonian VAT №: > > > > EE102625532. Glauca Digital and the Glauca logo are registered > > > > trademarks in the UK, under № UK00003718474 and № UK00003718468, > > > > respectively. > > > > > > > > > > > > > > > > Ar Llun, 2 Meh 2025 am 22:53 <rfc-edi...@rfc-editor.org> > > > > ysgrifennodd: > > > > Q, > > > > > > > > While reviewing this document during AUTH48, please resolve (as > > > > necessary) the following questions, which are also in the XML > > > > file. > > > > > > > > 1) <!-- [rfced] Please note that the title of the document has > > > > been > > > > updated as follows: > > > > > > > > The short title that appears in the running header of the pdf > > > > output has been updated to use double quotes around ".onion" to > > > > match the use in the full title. > > > > > > > > Original: > > > > > > > > ACME for .onion > > > > Current: > > > > ACME for ".onion" > > > > --> > > > > > > > > > > > > 2) <!--[rfced] Q - currently our tooling does not support the > > > > request to > > > > remove the period from following your first name. Please > > > > see > > > > https://github.com/ietf-tools/xml2rfc/issues/1204. We have > > > > commented on this issue to raise awareness that you document > > > > is > > > > now in AUTH48 and publication is nearing. > > > > > > > > > > > > --> > > > > > > > > > > > > 3) <!-- [rfced] Please insert any keywords (beyond those that > > > > appear in > > > > the title) for use on https://www.rfc-editor.org/search. --> > > > > > > > > > > > > 4) <!--[rfced] Please review our edits to the following text to > > > > ensure we > > > > have maintained your intent. > > > > > > > > Original: > > > > The ACME server SHOULD follow redirects; note that these MAY > > > > be > > > > redirects to non-".onion" services, and the server SHOULD > > > > honour > > > > these. > > > > > > > > Current: > > > > The ACME server SHOULD follow redirects. Note that these MAY > > > > be > > > > redirects to services that are not ".onion" and that the > > > > server > > > > SHOULD honor these. > > > > > > > > --> > > > > > > > > > > > > 5) <!--[rfced] Please review our updates to this text carefully > > > > and let > > > > us know any objections. > > > > > > > > Original: > > > > > > > > An "onion-csr-01" MUST NOT be used to issue certificates for non > > > > ".onion" Special-Use Domain Names. > > > > > > > > Current: > > > > An "onion-csr-01" challenge MUST NOT be used to issue > > > > certificates for > > > > Special-Use Domain Names that are not ".onion". > > > > --> > > > > > > > > > > > > 6) <!--[rfced] Please note that sourcecode elements in this > > > > document > > > > exceed our character limit (see > > > > https://authors.ietf.org/en/drafting-in-plaintext for the 69 > > > > character limit on sourcecode elements). Please review > > > > throughout the document and let us know how these may be > > > > changed > > > > (or feel free to update/replace in the edited XML file > > > > yourself > > > > if this is more convenient).--> > > > > > > > > > > > > 7) <!--[rfced] Please note that we have updated to use "flags" > > > > (plural) > > > > to match the use in Section 4.1.1 of RFC 8659. Please let > > > > us > > > > know any objections. > > > > > > > > > > > > Original: > > > > The contents of "flag", "tag", and "value" are as per Section > > > > 4.1.1 > > > > of [RFC8659]. > > > > > > > > Current: > > > > The contents of "flags", "tag", and "value" are as per Section > > > > 4.1.1 > > > > of [RFC8659]. > > > > > > > > --> > > > > > > > > > > > > 8) <!--[rfced] In the following instances, please review the use > > > > of the > > > > BCP 14 keyword with the surrounding text (i.e., also and > > > > always > > > > specifically). > > > > > > > > > > > > Original: > > > > > > > > A hidden service operator MAY also not wish to publish a CAA > > > > record > > > > set in its service descriptor to avoid revealing information > > > > about the > > > > service operator. > > > > > > > > Perhaps: > > > > Also, a hidden service operator MAY not wish to publish a CAA > > > > record > > > > set in its service descriptor to avoid revealing information > > > > about the > > > > service operator. > > > > > > > > > > > > > > > > Original: > > > > In any case, the server always MAY fetch the record set from the > > > > service descriptor. > > > > > > > > Perhaps: > > > > In any case, the server MAY fetch the record set from the > > > > service descriptor. > > > > > > > > --> > > > > > > > > > > > > 9) <!--[rfced] We have deleted the "it" before the comma in this > > > > sentence. Please let us know if some other rephrase was > > > > intended. > > > > > > > > Original: > > > > If an ACME server does not support fetching a service's CAA > > > > record > > > > set from its service descriptor it, and the ACME client does > > > > not > > > > provide an "onionCAA" object in its finalize request the ACME > > > > server > > > > MUST respond with an "onionCAARequired" error to indicate > > > > this. > > > > > > > > Current: > > > > If an ACME server does not support fetching a service's CAA > > > > record > > > > set from its service descriptor, and the ACME client does not > > > > provide an "onionCAA" object in its finalize request, the ACME > > > > server > > > > MUST respond with an "onionCAARequired" error to indicate > > > > this. > > > > > > > > --> > > > > > > > > > > > > 10) <!--[rfced] Please note that any changes affecting IANA > > > > registries > > > > will be communicated to IANA by the RPC once AUTH48 > > > > completes.--> > > > > > > > > > > > > 11) <!-- [rfced] Please note that we believe Section 9.7.8 should > > > > actually > > > > read 9.8.4 in the following. Please review and confirm our > > > > update. > > > > > > > > Original: > > > > Per this document, one new entry has been added to the "ACME > > > > Validation Methods" registry defined in Section 9.7.8 of > > > > [RFC8555]... > > > > > > > > Current: > > > > Per this document, one new entry has been added to the "ACME > > > > Validation Methods" registry defined in Section 9.7.4 of > > > > [RFC8555]... > > > > > > > > --> > > > > > > > > > > > > 12) <!-- [rfced] We believe "ACME Directory Metadata Fields" > > > > registry is > > > > defined in Section 9.7.6 of [RFC8555], not Section 9.7.8. > > > > Please > > > > confirm our update. > > > > --> > > > > > > > > > > > > 13) <!--[rfced] Please review our update to this text to expand > > > > MAC and > > > > avoid using an abbreviation as a verb (see > > > > https://www.rfc- > > > > editor.org/styleguide/part2/#abbrev_as_verb). If > > > > this does not correctly capture your intent, please let us > > > > know > > > > how we may rephrase. > > > > > > > > Original: > > > > The second layer descriptor is signed, encrypted and MACed in > > > > a way > > > > that only a party with access to the secret key of the hidden > > > > service > > > > could manipulate what is published there. > > > > > > > > Current: > > > > The second layer descriptor is signed, encrypted, and encoded > > > > using > > > > Message Authentication Code (MAC) in a way that only a party > > > > with > > > > access to the secret key of the hidden service could > > > > manipulate > > > > what is published there. > > > > > > > > > > > > --> > > > > > > > > > > > > 14) <!--[rfced] These sentences seem redundant. Please review. > > > > > > > > Original: > > > > > > > > Tor directory servers are inherently untrusted entities, and as > > > > such > > > > there is no difference in the security model for accepting CAA > > > > records directly from the ACME client or fetching them over Tor. > > > > There is no difference in the security model between accepting > > > > CAA > > > > records directly from the ACME client and fetching them over Tor; > > > > the > > > > CAA records are verified using the same hidden service key in > > > > either > > > > case. > > > > --> > > > > > > > > > > > > 15) <!-- [rfced] Please note that we have changed the URL of the > > > > [spoiled-onions] reference to point use the DOI rather than > > > > the > > > > original URL, which took the reader to a preview page that > > > > they > > > > couldn't back out of. Please review. > > > > > > > > Original: > > > > https://rdcu.be/d1ZRp > > > > > > > > Current: > > > > https://doi.org/10.1007/978-3-319-08506-7_16 > > > > > > > > --> > > > > > > > > > > > > 16) <!-- [rfced] Please review. We found an open-access version > > > > of > > > > [spoiled-onions] on arXiv. The information appears to match the > > > > current reference; however, some author names are missing. Would > > > > you > > > > prefer to use this open-access version of this reference? --> > > > > > > > > > > > > 17) <!--[rfced] We have the following questions related to > > > > terminology > > > > used throughout the document: > > > > > > > > a) We assume ".onion" is pronounced as "dot onion" and have thus > > > > left > > > > instances of "a ".onion" as they were. If this is incorrect, > > > > please > > > > let us know and we can update to "an ".onion"" as necessary. > > > > > > > > b) We see the following similar terms used. Please let us know > > > > if these should be made uniform or if they s > > > > hould remain distinct terms: > > > > > > > > first layer hidden service descriptor vs. first layer descriptor > > > > second layer hidden service descriptor vs. second layer > > > > descriptor > > > > Hidden Service vs. hidden service > > > > ".onion" service vs. "Onion Services" > > > > http-01 vs. "http-01" > > > > tls-alpn-01 vs. "tls-alpn-01" > > > > > > > > c) We note that <tt> tags were used to enclose the following > > > > terms in > > > > this document. Please review use for consistency as we note they > > > > were > > > > not used on every occurrence. Please also review the output of > > > > the > > > > <tt> tags in all formats (html, pdf, text) to ensure > > > > satisfaction. > > > > > > > > <tt>applicantSigningNonce</tt> > > > > <tt>auth-client</tt> > > > > <tt>caSigningNonce</tt> > > > > <tt>"onion-csr-01".</tt> > > > > --> > > > > > > > > > > > > 18) <!--[rfced] Please review the following questions/comments > > > > regarding > > > > abbreviation use in this document: > > > > > > > > a) Please note we have expanded these abbreviations as follows > > > > (per > > > > the reference in parentheses when applicable). Please review and > > > > let > > > > us know any objections/corrections: > > > > > > > > > > > > CSR - Certificate Signing Request (RFC 8555) > > > > PEM - Privacy Enhanced Mail (RFC 4648) > > > > TLD - Top-Level Domain > > > > ECH - Encrypted ClientHello (draft-ietf-tls-esni-24) > > > > > > > > b) Please note that CSR (the abbreviation at least) is not used > > > > in > > > > either Appendix B.2.b of [cabf-br] or [RFC2986]. Please review > > > > the > > > > citations in this document and let us know if any updates are > > > > necessary/desirable. > > > > > > > > --> > > > > > > > > > > > > 19) <!--[rfced] We note that the original xml file submitted used > > > > <eref> > > > > to point to specific sections in the [tor-spec]. Please > > > > review > > > > if these links should remain with the following in mind: > > > > > > > > a) These links make a difference in the output formats as > > > > follows: > > > > > > > > html (where the section names are linked): > > > > To this end, an additional field in the challenge object is > > > > defined to allow the ACME server to advertise th > > > > e Ed25519 public key it will use (as per the "Authentication > > > > during the introduction phase" section of [tor- > > > > spec]) to authenticate itself when retrieving the hidden service > > > > descriptor. > > > > > > > > txt (where the link appears in-line): > > > > To this end, a new field is added to the second layer hidden > > > > service > > > > descriptor, as defined in the "Second layer plaintext format" > > > > (https://spec.torproject.org/rend-spec/hsdesc- > > > > encrypt.html#second- > > > > layer-plaintext) section of [tor-spec] with the following format > > > > (defined using the notation from the "netdoc document meta- > > > > format" > > > > (https://spec.torproject.org/dir-spec/netdoc.html) section of > > > > [tor-spec]): > > > > > > > > b) These links may become stale quickly as [tor-spec] mentions an > > > > upcoming reorganization and that it is a living document. > > > > > > > > An alternative would be to remove the links but include the > > > > section > > > > names in the text itself (i.e., not use <eref>) and allow the > > > > reader > > > > to simply navigate to the section from the main [tor-spec] link. > > > > This > > > > would allow the html and text versions to be the same. > > > > > > > > Please let us know how you would like to proceed. > > > > --> > > > > > > > > > > > > 20) <!-- [rfced] Please consider whether the “type" attribute of > > > > any > > > > sourcecode element should be set and/or has been set > > > > correctly. > > > > > > > > The current list of preferred values for "type" is available at > > > > <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode- > > > > types>. > > > > If the current list does not contain an applicable type, feel > > > > free to > > > > suggest additions for consideration. Note that it is also > > > > acceptable > > > > to leave the "type" attribute not set. > > > > --> > > > > > > > > > > > > 21) <!-- [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. > > > > > > > > RFC Editor/mf > > > > > > > > *****IMPORTANT***** > > > > > > > > Updated 2025/06/02 > > > > > > > > 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. > > > > > > > > * 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 > > > > > > > > * 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/rfc9799.xml > > > > https://www.rfc-editor.org/authors/rfc9799.html > > > > https://www.rfc-editor.org/authors/rfc9799.pdf > > > > https://www.rfc-editor.org/authors/rfc9799.txt > > > > > > > > Diff file of the text: > > > > https://www.rfc-editor.org/authors/rfc9799-diff.html > > > > https://www.rfc-editor.org/authors/rfc9799-rfcdiff.html (side > > > > by side) > > > > > > > > Diff of the XML: > > > > https://www.rfc-editor.org/authors/rfc9799-xmldiff1.html > > > > > > > > > > > > Tracking progress > > > > ----------------- > > > > > > > > The details of the AUTH48 status of your document are here: > > > > https://www.rfc-editor.org/auth48/rfc9799 > > > > > > > > Please let us know if you have any questions. > > > > > > > > Thank you for your cooperation, > > > > > > > > RFC Editor > > > > > > > > -------------------------------------- > > > > RFC9799 (draft-ietf-acme-onion-07) > > > > > > > > Title : Automated Certificate Management Environment > > > > (ACME) Extensions for ".onion" Special-Use Domain Names > > > > Author(s) : Q. Misell > > > > WG Chair(s) : Yoav Nir, Tomofumi Okubo > > > > > > > > Area Director(s) : Deb Cooley, Paul Wouters > > > > > > > > > > > > <rfc9799.xml> > > > > > > > > > > > > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
