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

[Sean Turner <[e-mail]>]

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
>>>> 
>>> 
>> 
>