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 >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
