[auth48] Re: RFC-to-be 10003 draft-ietf-lamps-rfc5273bis for your review

[Megan Ferguson <[e-mail]>]

Hi Sean,

We’ve updated according to points 2 and 3.  

With regard to 1, the only way to make this appear as desired is to put that title actually in the <artwork> itself.  We have updated as such, but please note that these titles/figures will not be linkable, might not look appropriately centered across all formats, and appear inside the grayed out <artwork> boxes instead of beneath them in the PDF and HTML outputs.  

The files have been posted here (please refresh):
 https://www.rfc-editor.org/authors/rfc10003.txt
 https://www.rfc-editor.org/authors/rfc10003.pdf
 https://www.rfc-editor.org/authors/rfc10003.html
 https://www.rfc-editor.org/authors/rfc10003.xml

The diff files have been posted here (please refresh):
 https://www.rfc-editor.org/authors/rfc10003-diff.html (comprehensive)
 https://www.rfc-editor.org/authors/rfc10003-rfcdiff.html (side by side)

 https://www.rfc-editor.org/authors/rfc10003-auth48diff.html (AUTH48 only)
 https://www.rfc-editor.org/authors/rfc10003-auth48rfcdiff.html (side by side)

The Final Review page for this document is available here:
  https://queue.rfc-editor.org/final-review/rfc10003/

Thank you.

Megan Ferguson
RFC Production Center

> On May 29, 2026, at 1:56 PM, Sean Turner <[e-mail]> wrote:
> 
> Megan,
> 
> 1) Is there any way we can make the “Figures” examples:
> 
> OLD:
> 
> Figure 1: Example Message 1: Simple PKI Request
> 
> NEW:
> 
> Example Message 1: Simple PKI Request
> 
> 2) Also, it’s my bad, but Example 2 should be: 
> 
> Message 2: Simple PKI Response
> 
> 3) can we indent them by like 2?
> 
> spt
> 
>> On May 29, 2026, at 14:02, Megan Ferguson <[e-mail]> wrote:
>> 
>> Hi Sean and Joe,
>> 
>> Thanks for your replies and guidance.
>> 
>> We have updated as requested. 
>> 
>> NOTE: The change to reference RFC-to-be 9846 may cause an additional hold for this cluster.  You can follow this document’s AUTH48 progress here: https://queue.rfc-editor.org/final-review/rfc9846/. 
>> 
>> The files have been posted here (please refresh):
>>  https://www.rfc-editor.org/authors/rfc10003.txt
>>  https://www.rfc-editor.org/authors/rfc10003.pdf
>>  https://www.rfc-editor.org/authors/rfc10003.html
>>  https://www.rfc-editor.org/authors/rfc10003.xml
>> 
>> The diff files have been posted here (please refresh):
>>  https://www.rfc-editor.org/authors/rfc10003-diff.html (comprehensive)
>>  https://www.rfc-editor.org/authors/rfc10003-rfcdiff.html (side by side)
>> 
>>  https://www.rfc-editor.org/authors/rfc10003-auth48diff.html (AUTH48 only)
>>  https://www.rfc-editor.org/authors/rfc10003-auth48rfcdiff.html (side by side)
>> 
>> The Final Review page for this document is available here:
>>   https://queue.rfc-editor.org/final-review/rfc10003/
>> 
>> Thank you.
>> 
>> Megan Ferguson
>> RFC Production Center
>> 
>>> On May 28, 2026, at 2:50 PM, Sean Turner <[e-mail]> wrote:
>>> 
>>> Sorry a couple of more:
>>> 
>>> 2) s5:
>>> 
>>> OLD:
>>> 
>>> |  The examples that follow are purposely truncated for brevity.
>>> 
>>> NEW (warning or note - whichever is appropriate):
>>> 
>>> |  WARNING: The examples that follow are purposely truncated for brevity.
>>> 
>>> 3) s5: There are four example messages can we put them in some kind of <artwork>, indent them, and call them:
>>> 
>>> Example Message 1: Simple PKI Request
>>> Example Message 2: Simple PKI Request
>>> Example Message 3: Full PKI Request
>>> Example Message 4: Full PKI Response
>>> 
>>> 4) s9: Twice ...
>>> 
>>> OLD:
>>> 
>>> AuthenticatedEnvelopedData
>>> 
>>> NEW:
>>> 
>>> AuthEnvelopedData
>>> 
>>> 
>>> 
>>>> On May 28, 2026, at 16:35, Sean Turner <[e-mail]> wrote:
>>>> 
>>>> nit:
>>>> 
>>>> 1) s6:
>>>> 
>>>> OLD:
>>>> 
>>>> following rules apply.
>>>> 
>>>> NEW:
>>>> 
>>>> following rules apply:
>>>> 
>>>> spt
>>>> 
>>>>> On May 28, 2026, at 13:23, Joe Mandel <[e-mail]> wrote:
>>>>> 
>>>>> Please see our responses below.
>>>>> 
>>>>> Joe and Sean
>>>>> 
>>>>>> On May 22, 2026, at 11:12 AM, [e-mail] wrote:
>>>>>> 
>>>>>> Authors,
>>>>>> 
>>>>>> While reviewing this document during AUTH48, please resolve (as necessary) 
>>>>>> the following questions, which are also in the source file.
>>>>>> 
>>>>>> 1) <!--[rfced] Are both instances of "prior" intended in this text?
>>>>>> 
>>>>>> Original:
>>>>>> In some instances, no prior out-of-band trust will have been
>>>>>> initiated prior to use of this protocol.
>>>>>> 
>>>>>> Perhaps:
>>>>>> In some instances, no out-of-band trust will have been
>>>>>> initiated prior to use of this protocol.
>>>>>> -->
>>>>> 
>>>>> We agree with the suggested text.
>>>>>> 
>>>>>> 
>>>>>> 2) <!-- [rfced] We note that the citation tag [BCP195] is being used for
>>>>>> the reference entry for RFC 9325. Should this reference be
>>>>>> updated to point to RFC 9325 only (with a different citation tag)
>>>>>> or should the reference entry be updated to correctly reference
>>>>>> all of BCP 195?
>>>>>> 
>>>>>> Current:
>>>>>> [BCP195] Sheffer, Y., Saint-Andre, P., and T. Fossati,
>>>>>> "Recommendations for Secure Use of Transport Layer
>>>>>> Security (TLS) and Datagram Transport Layer Security
>>>>>> (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
>>>>>> 2022, <https://www.rfc-editor.org/info/rfc9325>.
>>>>>> 
>>>>>> Suggested A:
>>>>>> [RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for
>>>>>> Secure Use of Transport Layer Security (TLS) and Datagram Transport
>>>>>> Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325,
>>>>>> November 2022, <https://www.rfc-editor.org/info/rfc9325>.
>>>>>> 
>>>>>> Suggested B:
>>>>>> [BCP195] Best Current Practice 195,
>>>>>> <https://www.rfc-editor.org/info/bcp195>.
>>>>>> At the time of writing, this BCP comprises the following:
>>>>>> 
>>>>>> Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
>>>>>> 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
>>>>>> <https://www.rfc-editor.org/info/rfc8996>.
>>>>>> 
>>>>>> Sheffer, Y., Saint-Andre, P., and T. Fossati,
>>>>>> "Recommendations for Secure Use of Transport Layer
>>>>>> Security (TLS) and Datagram Transport Layer Security
>>>>>> (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
>>>>>> 2022, <https://www.rfc-editor.org/info/rfc9325>.
>>>>>> 
>>>>> 
>>>>> We like Suggestion B.
>>>>>> -->
>>>>>> 
>>>>>> 
>>>>>> 3) <!-- [rfced] Informative reference RFC 5246 has been obsoleted by RFC
>>>>>> 8446. We recommend replacing RFC 5246 with RFC 8446. However,
>>>>>> if RFC 5246 must be referenced, we suggest mentioning RFC 8446
>>>>>> (e.g., RFC 5246 has been obsoleted by RFC 8446). See Section
>>>>>> 4.8.6 in the RFC Style Guide (RFC 7322).
>>>>>> -->
>>>>> 
>>>>> We’d like to point to RFC 9846 (-rfc8446bis is in AUTH48).
>>>>>> 
>>>>>> 
>>>>>> 4) <!-- [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 the following should be updated:
>>>>>> 
>>>>>> native
>>>>>> -->
>>>>> 
>>>>> To remove “native”, we suggest changing the first line in Section 5 to: 
>>>>> 
>>>>> "MIME wrapping is defined for those environments that support MIME.”
>>>>>> 
>>>>>> 
>>>>>> Thank you.
>>>>>> 
>>>>>> Megan Ferguson
>>>>>> RFC Production Center
>>>>>> 
>>>>>> 
>>>>>> *****IMPORTANT*****
>>>>>> 
>>>>>> 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
>>>>>> 
>>>>>> *  [e-mail] (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).
>>>>>> 
>>>>>> *  [e-mail], 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,
>>>>>>      [e-mail] 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/rfc10003.xml
>>>>>> https://www.rfc-editor.org/authors/rfc10003.html
>>>>>> https://www.rfc-editor.org/authors/rfc10003.pdf
>>>>>> https://www.rfc-editor.org/authors/rfc10003.txt
>>>>>> 
>>>>>> Diff file of the text:
>>>>>> https://www.rfc-editor.org/authors/rfc10003-diff.html
>>>>>> https://www.rfc-editor.org/authors/rfc10003-rfcdiff.html (side by side)
>>>>>> 
>>>>>> Diff of the XML:
>>>>>> https://www.rfc-editor.org/authors/rfc10003-xmldiff1.html
>>>>>> 
>>>>>> 
>>>>>> Tracking progress
>>>>>> -----------------
>>>>>> 
>>>>>> The details of the AUTH48 status of your document are here:
>>>>>> https://www.rfc-editor.org/auth48/rfc10003
>>>>>> 
>>>>>> Please let us know if you have any questions.
>>>>>> 
>>>>>> Thank you for your cooperation,
>>>>>> 
>>>>>> RFC Editor
>>>>>> 
>>>>>> --------------------------------------
>>>>>> RFC 10003 (draft-ietf-lamps-rfc5273bis)
>>>>>> 
>>>>>> Title            : Certificate Management over CMS (CMC): Transport Protocols
>>>>>> Author(s)        : J. Mandel,
>>>>>>                 S. Turner, Ed.
>>>>>> WG Chair(s)      : Russ Housley, Tim Hollebeek
>>>>>> Area Director(s) : Deb Cooley, Christopher Inacio
>>>>> 
>>>> 
>>> 
>> 
>