All, Thank you for confirming. We’ve 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) And Tadahiko’s approval has been noted. We have now received all necessary approvals and consider AUTH48 complete: https://www.rfc-editor.org/auth48/rfc9919 As this document is part of Cluster C496, you may track the progress of all documents in this cluster through AUTH48 at: https://www.rfc-editor.org/auth48/C496 Note: This document normatively references RFC-to-be 9846, so it will be published at the same time as or after that document. Please let us know if you have any questions. Thank you, Alanna Paloma RFC Production Center > On Feb 3, 2026, at 11:54 AM, Sean Turner <[email protected]> wrote: > > I believe it is in the last paragraph of s3.2.1. I suggested this change: > s/singleResponse.singleResponse/SingleResponse.SingleExtension > but it should have been: > s/singleResponse.singleResponse/SingleResponse.singleExtensions > > spt > >> On Feb 3, 2026, at 14:37, Alanna Paloma <[email protected]> wrote: >> >> Hi Tadahiko, >> >>> Could you fix this? >>> I am not sure if we need extra process but I approve with condition of the >>> following change. >>> >>> Old: >>> SingleResponse.SingleExtensions >>> >>> New: >>> SingleResponse.singleExtensions >> >> >> Can you please confirm where in the document this update should be made? We >> are not finding any instances of “SingleResponse.SingleExtensions” in the >> document. “singleExtensions” is used in Section 3.2.1, but that instance >> uses a lowercase “s”. >> >> Thank you, >> Alanna Paloma >> RFC Production Center >> >> >>> On Feb 3, 2026, at 10:23 AM, Tadahiko Ito <[email protected]> >>> wrote: >>> >>> Hi Alanna >>> >>> Could you fix this? >>> I am not sure if we need extra process but I approve with condition of the >>> following change. >>> >>> Old: >>> SingleResponse.SingleExtensions >>> >>> New: >>> SingleResponse.singleExtensions >>> >>> Regards Tadahiko >>> >>> 2026年2月4日(水) 2:56 Sean Turner <[email protected]>: >>> Yes! I believe it is! >>> >>> spt >>> >>>> On Feb 3, 2026, at 12:45, Tadahiko Ito <[email protected]> >>>> wrote: >>>> >>>> Hi all, and thank you very much for great catches, and sorry to replay >>>> late. >>>> I was almost approved, but let me confirm that. >>>> >>>>> SingleResponse.SingleExtensions >>>> >>>> isn't it "SingleResponse.singleExtensions" (lowercase letter s)? >>>> >>>> Regards Tadahiko Ito >>>> >>>> 2026年2月3日(火) 9:45 Alanna Paloma <[email protected]>: >>>> Hi Clint, >>>> >>>> Your approval has been noted: >>>> https://www.rfc-editor.org/auth48/rfc9919 >>>> >>>> Once we’ve received Tadahiko’s approval, we will move this document >>>> forward in the publication process. >>>> >>>> Thank you, >>>> Alanna Paloma >>>> RFC Production Center >>>> >>>>> On Feb 2, 2026, at 12:38 PM, Clint Wilson <[email protected]> wrote: >>>>> >>>>> Hi Alanna, >>>>> >>>>> I have reviewed and approve this latest version of the document. >>>>> >>>>> Thank you! >>>>> -Clint >>>>> >>>>>> On Jan 30, 2026, at 2:39 PM, Alanna Paloma >>>>>> <[email protected]> wrote: >>>>>> >>>>>> Hi Authors, >>>>>> >>>>>> This is a friendly reminder that we await your reviews and approvals of >>>>>> the updated files prior to moving this document forward in the >>>>>> publication process. See the files below. >>>>>> >>>>>> 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 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 23, 2026, at 11:34 AM, Alanna Paloma >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> 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]
