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]
