Hi Roman, Thank you for your approval. We’ve noted it on the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9919
Best regards, Alanna Paloma RFC Production Center > On Jan 23, 2026, at 11:25 AM, Roman Danyliw <[email protected]> wrote: > > Approved. > > -----Original Message----- > From: Alanna Paloma <[email protected]> > Sent: Thursday, January 22, 2026 12:45 PM > To: Deb Cooley <[email protected]>; Sean Turner <[email protected]>; Corey > Bonnell <[email protected]>; Clint Wilson <[email protected]> > Cc: RFC Editor <[email protected]>; [email protected]; > [email protected]; [email protected]; Roman Danyliw <[email protected]>; > Russ Housley <[email protected]>; auth48archive > <[email protected]> > Subject: [AD] Re: AUTH48: RFC-to-be 9919 <draft-ietf-lamps-rfc5019bis-12> for > your review > > Warning: External Sender - do not click links or open attachments unless you > recognize the sender and know the content is safe. > > > Authors and Deb*, > > *Deb - As the AD, please review and approve of the following removed text in > Section 3.2.3: > > As such, this profile extends > the [RFC6960] definition of "unauthorized" as follows: > > The response "unauthorized" is returned in cases where the client is > not authorized to make this query to this responder or the responder > is not capable of responding authoritatively. > > See this diff file: > https://www.rfc-editor.org/authors/rfc9919-auth48diff.html > > > Authors - Thank you for your responses and for confirming those updates. We > have updated the files accordingly. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9919.txt > https://www.rfc-editor.org/authors/rfc9919.pdf > https://www.rfc-editor.org/authors/rfc9919.html > https://www.rfc-editor.org/authors/rfc9919.xml > > The relevant diff files are posted here: > https://www.rfc-editor.org/authors/rfc9919-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9919-auth48diff.html (all AUTH48 > changes) > https://www.rfc-editor.org/authors/rfc9919-lastdiff.html (htmlwdiff diff > between last version and this) > https://www.rfc-editor.org/authors/rfc9919-lastrfcdiff.html (rfcdiff between > last version and this) > > Please review the document carefully as documents do not change once > published as RFCs. > > We will await any further changes you may have and approvals from each author > and *Deb prior to moving forward in the publication process. > > Please see the AUTH48 status page for this document here: > https://www.rfc-editor.org/auth48/rfc9919 > > Thank you, > Alanna Paloma > RFC Production Center > > >> On Jan 22, 2026, at 6:35 AM, Clint Wilson <[email protected]> wrote: >> >> These changes all look great to me (some really nice catches in here too, >> fwiw). Thank you all for working on this draft! >> >>> On Jan 21, 2026, at 8:32 AM, Sean Turner <[email protected]> wrote: >>> >>> Okay on to the detailed review - co-authors please double check: >>> >>> 1) s3.1.1: There is no “RequestList” it’s “requestList” >>> >>> OLD: >>> OCSPRequest.RequestList >>> NEW: >>> OCSPRequest.requestList >>> 2) s3.2.1: bump dash >>> OLD: >>> ... the id- >>> pkix-ocsp-basic OID. >>> NEW: >>> ... the >>> id-pkix-ocsp-basic OID. >>> >>> >>> 3) s3.2.1: use elements instead of SingleResponses >>> OLD: >>> two SingleResponses in a BasicOCSPResponse >>> NEW: >>> two SingleResponse elements in a BasicOCSPResponse >>> OLD: >>> the CertID of one of the SingleResponses uses >>> NEW: >>> the CertID of one of the SingleResponse structures uses >>> 4) s3.2.1: Refer to correct extension structure >>> OLD: >>> The responder MAY include the singleResponse.singleResponse >>> extensions structure. >>> NEW: >>> The responder MAY include the SingleResponse.SingleExtensions >>> extensions structure. >>> 5) s3.2.3: Do we still extend the definition of unauthorized? >>> >>> In 5019, the definition of unauthorized was extended. RFC 6960 was updated >>> to match the definitions in RFC 5019. So can we drop this bit of text: >>> As such, this profile extends >>> the [RFC6960] definition of "unauthorized" as follows: >>> >>> The response "unauthorized" is returned in cases where the client is >>> not authorized to make this query to this responder or the responder >>> is not capable of responding authoritatively. >>> 6) s8.2: rename title >>> >>> OLD: >>> >>> 8.2. Man-in-the-Middle Attacks >>> NEW: >>> 8.2. On-Path Attacks >>> >>> Cheers, >>> spt >>> >>>> On Jan 21, 2026, at 10:48, Alanna Paloma <[email protected]> >>>> wrote: >>>> >>>> Hi Sean and Clint, >>>> >>>> Thank you for confirming those two remaining questions. We have updated >>>> the document accordingly. >>>> >>>> The files have been posted here (please refresh): >>>> https://www.rfc-editor.org/authors/rfc9919.xml >>>> https://www.rfc-editor.org/authors/rfc9919.txt >>>> https://www.rfc-editor.org/authors/rfc9919.html >>>> https://www.rfc-editor.org/authors/rfc9919.pdf >>>> >>>> The relevant diff files have been posted here: >>>> https://www.rfc-editor.org/authors/rfc9919-diff.html (comprehensive >>>> diff) https://www.rfc-editor.org/authors/rfc9919-auth48diff.html >>>> (AUTH48 changes) >>>> https://www.rfc-editor.org/authors/rfc9919-auth48rfcdiff.html >>>> (AUTH48 changes side by side) >>>> >>>> We will await approvals from each author prior to moving this document >>>> forward in the publication process. >>>> >>>> See here for the AUTH48 status page of this document: >>>> https://www.rfc-editor.org/auth48/rfc9919 >>>> >>>> Thank you, >>>> Alanna Paloma >>>> RFC Production Center >>>> >>>>> On Jan 21, 2026, at 5:40 AM, Sean Turner <[email protected]> wrote: >>>>> >>>>> Clint, >>>>> >>>>> Thanks for confirming! >>>>> >>>>> spt >>>>> >>>>>> On Jan 20, 2026, at 17:39, Clint Wilson <[email protected]> wrote: >>>>>> >>>>>> The proposed update for #9 seems correct to me. I don’t think it’s >>>>>> likely for the direct document link to become outdated in the >>>>>> foreseeable future (it appears to have been stable for at least several >>>>>> years). >>>>>> >>>>>> Thank you! >>>>>> -Clint >>>>>> >>>>>>> On Jan 20, 2026, at 1:51 PM, Sean Turner <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Jan 20, 2026, at 14:58, Alanna Paloma >>>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> Hi Sean, >>>>>>>> >>>>>>>> Thank you for your reply. We have updated as requested. >>>>>>>> >>>>>>>> Please note that we are awaiting for these two queries to be confirmed: >>>>>>>> >>>>>>>>>> 9) <!-- [rfced] We were unable to find a document directly >>>>>>>>>> matching the title provided in the original reference. The URL >>>>>>>>>> provided goes to the homepage for the Open Mobile Alliance. We >>>>>>>>>> did find the following URL, which points to the OCSP Mobile Profile: >>>>>>>>>> https://www.openmobilealliance.org/release/OCSP/V1_0-20040127- >>>>>>>>>> C/OMA-WAP-OCSP-V1_0-20040127-C.pdf >>>>>>>>>> >>>>>>>>>> May we update this reference as follows? >>>>>>>>>> >>>>>>>>>> Original: >>>>>>>>>> [OCSPMP] Open Mobile Alliance, "OCSP Mobile Profile V1.0", >>>>>>>>>> www.openmobilealliance.org . >>>>>>>>>> >>>>>>>>>> Perhaps: >>>>>>>>>> [OCSPMP] Open Mobile Alliance, "Online Certificate Status >>>>>>>>>> Protocol Mobile Profile", Candidate Version V1.0, 27 January >>>>>>>>>> 2004, >>>>>>>>>> <https://www.openmobilealliance.org/release/OCSP/V1_0-20040127-C/OMA-WAP-OCSP-V1_0-20040127-C.pdf>. >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> I will defer to my co-authors on this one. >>>>>>>>> >>>>>>>>>> 10) <!-- [rfced] Please review the "type" attribute of each >>>>>>>>>> sourcecode element in the XML file to ensure correctness. If >>>>>>>>>> the current list of preferred values for "type" >>>>>>>>>> (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-ty >>>>>>>>>> pes) does not contain an applicable type, then feel free to >>>>>>>>>> let us know. >>>>>>>>>> Also, it is acceptable to leave the "type" attribute not set. >>>>>>>>>> >>>>>>>>>> In addition, review each artwork element. Specifically, should >>>>>>>>>> any artwork element be tagged as sourcecode or another >>>>>>>>>> element? >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> I will put this on my to do list ;) >>>>>>> >>>>>>> >>>>>>> I was being sooo slow. I pulled the xml and the three ASN.1 code blocks >>>>>>> include the correct tag: >>>>>>> >>>>>>> <sourcecode type="asn.1”> >>>>>>> >>>>>>> I believe then we are awaiting my co-auhors response on #9! >>>>>>> >>>>>>> spt >>>>>>> >>>>>>>> The files have been posted here (please refresh): >>>>>>>> https://www.rfc-editor.org/authors/rfc9919.xml >>>>>>>> https://www.rfc-editor.org/authors/rfc9919.txt >>>>>>>> https://www.rfc-editor.org/authors/rfc9919.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9919.pdf >>>>>>>> >>>>>>>> The relevant diff files have been posted here: >>>>>>>> https://www.rfc-editor.org/authors/rfc9919-diff.html >>>>>>>> (comprehensive diff) >>>>>>>> https://www.rfc-editor.org/authors/rfc9919-auth48diff.html >>>>>>>> (AUTH48 changes) >>>>>>>> https://www.rfc-editor.org/authors/rfc9919-auth48rfcdiff.html >>>>>>>> (AUTH48 changes side by side) >>>>>>>> >>>>>>>> Please review the document carefully and contact us with any further >>>>>>>> updates you may have. Note that we do not make changes once a >>>>>>>> document is published as an RFC. >>>>>>>> >>>>>>>> We will await approvals from each party listed on the AUTH48 status >>>>>>>> page below prior to moving this document forward in the publication >>>>>>>> process. >>>>>>>> >>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>> https://www.rfc-editor.org/auth48/rfc9919 >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Alanna Paloma >>>>>>>> RFC Production Center >>>>>>>> >>>>>>>>> On Jan 20, 2026, at 7:39 AM, Sean Turner <[email protected]> wrote: >>>>>>>>> >>>>>>>>> Hi! >>>>>>>>> >>>>>>>>>> On Jan 16, 2026, at 13:46, [email protected] wrote: >>>>>>>>>> >>>>>>>>>> Authors, >>>>>>>>>> >>>>>>>>>> While reviewing this document during AUTH48, please resolve (as >>>>>>>>>> necessary) the following questions, which are also in the source >>>>>>>>>> file. >>>>>>>>>> >>>>>>>>>> 1) <!--[rfced] Please note the title of the document has been >>>>>>>>>> updated as follows. Abbreviations have been expanded per >>>>>>>>>> Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review. >>>>>>>>>> >>>>>>>>>> Original: >>>>>>>>>> Updates to Lightweight OCSP Profile for High Volume >>>>>>>>>> Environments >>>>>>>>>> >>>>>>>>>> Current: >>>>>>>>>> Updates to the Lightweight Online Certificate Status Protocol >>>>>>>>>> (OCSP) Profile for High Volume Environments >>>>>>>>>> >>>>>>>>>> Because this document will obsolete RFC 5019 (rather than >>>>>>>>>> update it), we suggest changing the title and abbreviated title as >>>>>>>>>> follows. Is this acceptable? >>>>>>>>>> >>>>>>>>>> Original: >>>>>>>>>> Updates to Lightweight OCSP Profile for High Volume >>>>>>>>>> Environments >>>>>>>>>> >>>>>>>>>> Perhaps (same title as RFC 5019): >>>>>>>>>> The Lightweight Online Certificate Status Protocol (OCSP) >>>>>>>>>> Profile for High-Volume Environments >>>>>>>>>> >>>>>>>>>> Similarly, may the abbreviated title (which appears in the >>>>>>>>>> running header of the PDF) be updated as follows? >>>>>>>>>> >>>>>>>>>> Original: >>>>>>>>>> Lightweight OCSP Profile Update >>>>>>>>>> >>>>>>>>>> Perhaps: >>>>>>>>>> Lightweight OCSP Profile >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> Yes, since we’re obsoleting it there’s no need for the “Updates to” / >>>>>>>>> “Update” words. >>>>>>>>> >>>>>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that >>>>>>>>>> appear in the title) for use on >>>>>>>>>> https://www.rfc-editor.org/search. --> >>>>>>>>> >>>>>>>>> Revocation >>>>>>>>> >>>>>>>>>> 3) <!--[rfced] FYI, we changed "RECOMMENDS" to "is RECOMMENDED >>>>>>>>>> by" (2 instances), as "RECOMMENDED" is the defined keyword >>>>>>>>>> from BCP 14. This update allows using the <bcp14> element >>>>>>>>>> without warnings. We realize the original text matches RFC 5019. For >>>>>>>>>> example: >>>>>>>>>> >>>>>>>>>> Original: >>>>>>>>>> Clients SHOULD NOT include the requestExtensions structure. If >>>>>>>>>> a requestExtensions structure is included, this profile >>>>>>>>>> RECOMMENDS that it contain only the nonce extension >>>>>>>>>> (id-pkix-ocsp-nonce). >>>>>>>>>> >>>>>>>>>> Current: >>>>>>>>>> Clients SHOULD NOT include the requestExtensions structure. If >>>>>>>>>> a requestExtensions structure is included, it is RECOMMENDED >>>>>>>>>> by this profile that the structure contain only the nonce >>>>>>>>>> extension (id-pkix- ocsp-nonce). >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> WFM >>>>>>>>> >>>>>>>>>> 4) <!--[rfced] Is this line within the sourcecode in Section >>>>>>>>>> 3.2.1 intended to be a comment within the sourcecode, or >>>>>>>>>> should it be taken out of the sourcecode? (Note: This line >>>>>>>>>> exceeded the 72-character limit so we included a line break >>>>>>>>>> within the sourcecode.) >>>>>>>>>> >>>>>>>>>> Original: >>>>>>>>>> The value for response SHALL be the DER encoding of >>>>>>>>>> BasicOCSPResponse. >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> This sentence should be taken out of the source code, so I guess that >>>>>>>>> means there’s two blocks of source code. >>>>>>>>> >>>>>>>>>> 5) <!--[rfced] May we update this sentence as follows to >>>>>>>>>> clarify that the protocol in [RFC5019] is backward compatible, >>>>>>>>>> rather than the RFC itself? >>>>>>>>>> >>>>>>>>>> Original: >>>>>>>>>> Older responders which provide backward compatibility with >>>>>>>>>> [RFC5019] MAY use the byName field to represent the >>>>>>>>>> ResponderID, but should transition to using the byKey field as soon >>>>>>>>>> as practical. >>>>>>>>>> >>>>>>>>>> Perhaps: >>>>>>>>>> Older responders that provide backward compatibility with the >>>>>>>>>> protocol defined in [RFC5019] MAY use the byName field to >>>>>>>>>> represent the ResponderID but should transition to using the byKey >>>>>>>>>> field as soon as practical. >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> Yes >>>>>>>>> >>>>>>>>>> 6) <!--[rfced] We are having some trouble understanding how >>>>>>>>>> "server name and base64-encoded OCSPRequest structure" fits >>>>>>>>>> into the sentence below. Please review and let us know the sentence >>>>>>>>>> may be updated for clarity. >>>>>>>>>> >>>>>>>>>> Original: >>>>>>>>>> When sending requests that are less than or equal to 255 bytes >>>>>>>>>> in total (after encoding) including the scheme and delimiters >>>>>>>>>> (http://), server name and base64-encoded OCSPRequest >>>>>>>>>> structure, clients MUST use the GET method (to enable OCSP >>>>>>>>>> response caching). >>>>>>>>>> >>>>>>>>>> Perhaps: >>>>>>>>>> When sending requests that are less than or equal to 255 bytes >>>>>>>>>> in total (after encoding), including the scheme and delimiters >>>>>>>>>> (http://), server name, and base64-encoded OCSPRequest >>>>>>>>>> structure, clients MUST use the GET method (to enable OCSP >>>>>>>>>> response caching). >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> I think that’s right. The 255 bytes needs to include everything that >>>>>>>>> is listed there. >>>>>>>>> >>>>>>>>>> 7) <!--[rfced] Should "productedAt" be "producedAt" (no 't')? >>>>>>>>>> Even though RFC 5019 contains one instance of "productedAt", >>>>>>>>>> it contains seven instances of "producedAt". We note that >>>>>>>>>> other RFCs also use "producedAt" (e.g., RFCs 9654, 6960, 5912). >>>>>>>>>> >>>>>>>>>> Original: >>>>>>>>>> productedAt = March 19, 2023 01:00:00 GMT >>>>>>>>>> >>>>>>>>>> Suggested: >>>>>>>>>> producedAt = March 19, 2023 01:00:00 GMT >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> GREAT CATCH! >>>>>>>>> >>>>>>>>> Definitely needs to be “producedAt”! >>>>>>>>> >>>>>>>>>> 8) <!--[rfced] May this sentence be updated as follows to >>>>>>>>>> avoid citing RFC 9846 twice? >>>>>>>>>> >>>>>>>>>> Original: >>>>>>>>>> This functionality has been specified as an extension to the >>>>>>>>>> TLS [I-D.ietf-tls-rfc8446bis] protocol in Section 4.4.2 of >>>>>>>>>> [I-D.ietf-tls-rfc8446bis], but can be applied to any >>>>>>>>>> client-server protocol. >>>>>>>>>> >>>>>>>>>> Current: >>>>>>>>>> This functionality has been specified as an extension to the >>>>>>>>>> TLS protocol [RFC9846] in Section 4.4.2 of [RFC9846] but can >>>>>>>>>> be applied to any client-server protocol. >>>>>>>>>> >>>>>>>>>> Option A: >>>>>>>>>> This functionality has been specified as an extension to the >>>>>>>>>> TLS protocol in Section 4.4.2 of [RFC9846] but can be applied >>>>>>>>>> to any client-server protocol. >>>>>>>>>> >>>>>>>>>> Option B: >>>>>>>>>> In Section 4.4.2 of [RFC9846], this functionality has been >>>>>>>>>> specified as an extension to the TLS protocol, but it can be >>>>>>>>>> applied to any client-server protocol. >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> I prefer option A. >>>>>>>>> >>>>>>>>>> 9) <!-- [rfced] We were unable to find a document directly >>>>>>>>>> matching the title provided in the original reference. The URL >>>>>>>>>> provided goes to the homepage for the Open Mobile Alliance. We >>>>>>>>>> did find the following URL, which points to the OCSP Mobile Profile: >>>>>>>>>> https://www.openmobilealliance.org/release/OCSP/V1_0-20040127- >>>>>>>>>> C/OMA-WAP-OCSP-V1_0-20040127-C.pdf >>>>>>>>>> >>>>>>>>>> May we update this reference as follows? >>>>>>>>>> >>>>>>>>>> Original: >>>>>>>>>> [OCSPMP] Open Mobile Alliance, "OCSP Mobile Profile V1.0", >>>>>>>>>> www.openmobilealliance.org . >>>>>>>>>> >>>>>>>>>> Perhaps: >>>>>>>>>> [OCSPMP] Open Mobile Alliance, "Online Certificate Status >>>>>>>>>> Protocol Mobile Profile", Candidate Version V1.0, 27 January >>>>>>>>>> 2004, >>>>>>>>>> <https://www.openmobilealliance.org/release/OCSP/V1_0-20040127-C/OMA-WAP-OCSP-V1_0-20040127-C.pdf>. >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> I will defer to my co-authors on this one. >>>>>>>>> >>>>>>>>>> 10) <!-- [rfced] Please review the "type" attribute of each >>>>>>>>>> sourcecode element in the XML file to ensure correctness. If >>>>>>>>>> the current list of preferred values for "type" >>>>>>>>>> (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-ty >>>>>>>>>> pes) does not contain an applicable type, then feel free to >>>>>>>>>> let us know. >>>>>>>>>> Also, it is acceptable to leave the "type" attribute not set. >>>>>>>>>> >>>>>>>>>> In addition, review each artwork element. Specifically, should >>>>>>>>>> any artwork element be tagged as sourcecode or another >>>>>>>>>> element? >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> I will put this on my to do list ;) >>>>>>>>> >>>>>>>>>> 11) <!--[rfced] Should instances of "OCSP protocol" be updated >>>>>>>>>> to simply "OCSP" to avoid redundancy (if expanded, "OCSP >>>>>>>>>> protocol" would read "Online Certificate Status Protocol >>>>>>>>>> protocol")? Please review and let us know if any updates are needed. >>>>>>>>>> >>>>>>>>>> Original: >>>>>>>>>> Future versions of the OCSP protocol may provide a way for the >>>>>>>>>> client to know whether the responder supports nonces or does >>>>>>>>>> not support nonces. >>>>>>>>>> ... >>>>>>>>>> The authors of this version of the document wish to thank Alex >>>>>>>>>> Deacon and Ryan Hurst for their work to produce the original >>>>>>>>>> version of the lightweight profile for the OCSP protocol. >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> Yes please drop the extra “protocol” where appropriate. >>>>>>>>> >>>>>>>>>> 12) <!--[rfced] Abbreviations >>>>>>>>>> >>>>>>>>>> a) Both the expansion and the acronym for the following term >>>>>>>>>> are used throughout the document. Would you like to update to >>>>>>>>>> using the expansion upon first usage and the acronym for the rest of >>>>>>>>>> the document? >>>>>>>>>> >>>>>>>>>> certification authority (CA) >>>>>>>>> >>>>>>>>> I am happy with that. >>>>>>>>> >>>>>>>>>> b) We note that "AIA" has been expanded two different ways in the >>>>>>>>>> document. >>>>>>>>>> Please review and let us know which version should be used for >>>>>>>>>> consistency. >>>>>>>>>> >>>>>>>>>> authorityInfoAccess (AIA) vs. authorityInformationAccess (AIA) >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> So this is a bit weird maybe: >>>>>>>>> >>>>>>>>> s3.2.2: >>>>>>>>> >>>>>>>>> OLD: >>>>>>>>> >>>>>>>>> authorityInfoAccess >>>>>>>>> (AIA) extension nor cRLDistributionPoints (CRLDP) extension >>>>>>>>> >>>>>>>>> NEW: >>>>>>>>> >>>>>>>>> Authority Information Access >>>>>>>>> (AIA) extension nor CRL Distribution Points (CRLDP) extension >>>>>>>>> >>>>>>>>> S4.1: >>>>>>>>> >>>>>>>>> OLD: >>>>>>>>> >>>>>>>>> authorityInfoAccess extension >>>>>>>>> >>>>>>>>> NEW: >>>>>>>>> >>>>>>>>> AIA extension >>>>>>>>> >>>>>>>>> OLD: >>>>>>>>> >>>>>>>>> authorityInformationAccess (AIA) extension >>>>>>>>> cRLDistributionPoints extension >>>>>>>>> >>>>>>>>> NEW: >>>>>>>>> >>>>>>>>> AIA extension >>>>>>>>> CRLDP extension >>>>>>>>> >>>>>>>>> >>>>>>>>>> 13) <!-- [rfced] Please review the "Inclusive Language" >>>>>>>>>> portion of the online Style Guide >>>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_langua >>>>>>>>>> ge> and let us know if any changes are needed. Updates of >>>>>>>>>> this nature typically result in more precise language, which >>>>>>>>>> is helpful for readers. >>>>>>>>>> >>>>>>>>>> For example, please consider whether "man-in-the-middle" should be >>>>>>>>>> updated. >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> I am fine with changing it to on-path if my co-authors are. >>>>>>>>> >>>>>>>>> spt >>>>>>>>> >>>>>>>>>> Thank you. >>>>>>>>>> >>>>>>>>>> Alanna Paloma and Alice Russo >>>>>>>>>> RFC Production Center >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Jan 16, 2026, at 10:45 AM, [email protected] wrote: >>>>>>>>>> >>>>>>>>>> *****IMPORTANT***** >>>>>>>>>> >>>>>>>>>> Updated 2026/01/16 >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> * [email protected] (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). >>>>>>>>>> >>>>>>>>>> * [email protected], 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-4 >>>>>>>>>> Q9l2USxIAe6P8O4Zc >>>>>>>>>> >>>>>>>>>> * 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, >>>>>>>>>> [email protected] 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/rfc9919.xml >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9919.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9919.pdf >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9919.txt >>>>>>>>>> >>>>>>>>>> Diff file of the text: >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9919-diff.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9919-rfcdiff.html (side >>>>>>>>>> by side) >>>>>>>>>> >>>>>>>>>> Diff of the XML: >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9919-xmldiff1.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Tracking progress >>>>>>>>>> ----------------- >>>>>>>>>> >>>>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9919 >>>>>>>>>> >>>>>>>>>> Please let us know if you have any questions. >>>>>>>>>> >>>>>>>>>> Thank you for your cooperation, >>>>>>>>>> >>>>>>>>>> RFC Editor >>>>>>>>>> >>>>>>>>>> -------------------------------------- >>>>>>>>>> RFC9919 (draft-ietf-lamps-rfc5019bis-12) >>>>>>>>>> >>>>>>>>>> Title : Updates to Lightweight OCSP Profile for High >>>>>>>>>> Volume Environments >>>>>>>>>> Author(s) : T. Ito, C. Wilson, C. Bonnell, S. Turner >>>>>>>>>> WG Chair(s) : Russ Housley, Tim Hollebeek >>>>>>>>>> Area Director(s) : Deb Cooley, Paul Wouters >>>>>> >>>>>> >>>>> >>>> >>> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
