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-types) >>>>>>>> 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-types) >>>>>>>> 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_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. >>>>>>>> >>>>>>>> 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-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, >>>>>>>> [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 >>>> >>>> >>> >> >
smime.p7s
Description: S/MIME cryptographic signature
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
