I also believe this document is ready for publication.
Thanks for the work! Am 18.06.2026 um 20:59 schrieb Karen Moore:
Hi Ned, Thank you for your reply. We have noted your approval at https://www.rfc-editor.org/auth48/rfc9999. We now await approval from Hannes prior to moving forward with publication. Best regards, Karen Moore RFC Production CenterOn Jun 17, 2026, at 5:09 PM, Ned Smith IETF <[email protected]> wrote: Karen, I believe it is ready for publication. Thanks, Ned From: Karen Moore <[email protected]> Sent: Wednesday, 17 June 2026 15:04:57 To: Henk Birkholz <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; Thomas Fossati <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; Deb Cooley <[email protected]> Subject: Re: Final Review: RFC-to-be 9999 (draft-ietf-rats-msg-wrap) for your review Hi Henk, Thank you for your reply. We have noted your approval (see https://www.rfc-editor.org/auth48/rfc9999). We now await approvals from Hannes and Ned. Best regards, Karen Moore RPC Production CenterOn Jun 17, 2026, at 12:58 PM, Henk Birkholz <[email protected]> wrote: Karen, thank you for the nudge! Yes, of course. Thomas is our shining example of not dropping the ball here. This document is ready for publication. Viele Grüße, Henk On 17.06.2026 21:08, Karen Moore wrote:Dear Hannes, Henk, and Ned, We do not believe we have heard from you regarding this document's readiness for publication. Please review the files below and let us know if any further updates are needed or if the document is ready for publication. https://www.rfc-editor.org/authors/rfc9999.xml https://www.rfc-editor.org/authors/rfc9999.txt https://www.rfc-editor.org/authors/rfc9999.html https://www.rfc-editor.org/authors/rfc9999.pdf https://www.rfc-editor.org/authors/rfc9999-diff.html https://www.rfc-editor.org/authors/rfc9999-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9999-auth48diff.html https://www.rfc-editor.org/authors/rfc9999-auth48rfcdiff.html (side by side) For the status of this document, please see: https://www.rfc-editor.org/auth48/rfc9999 We will wait to hear from you before continuing with the publication process. Thank you. Karen Moore RFC Production CenterOn Jun 11, 2026, at 10:59 AM, Karen Moore <[email protected]> wrote: Hi Deb, Thank you for the review. We have noted your approval at <https://www.rfc-editor.org/auth48/rfc9999>. We now await approval of the document from Hannes, Henk, and Ned prior to moving forward with publication. Best regards, Karen Moore RPC Production CenterOn Jun 11, 2026, at 3:19 AM, Deb Cooley <[email protected]> wrote: I approve. I'm sorry that Dionna Glaze had to be moved to the ack section, it is too bad they can't be an author as an 'individual', ie. w/out work affiliation. Deb On Wed, Jun 10, 2026 at 6:16 PM Karen Moore <[email protected]> wrote: Hi Deb (AD), Please review the updates in Sections 3.1.1, 5.4, and 9.6.2 and let us know if you approve. The updates are outlined below for ease and can be viewed here: https://www.rfc-editor.org/authors/rfc9999-auth48diff.html. 1) Section 3.1.1 Original: As such, it indicates which bits are allowed to be set in the ind byte string. Current: As such, it indicates which bits are allowed to be set in the ind byte bitmap. ... 2) In the second figure in Section 5.4, the following line was updated: Original: d28440a044d901f5a040 # "҄@\xA0D\xD9\u0001\xF5\xA0\@" Current: d28440a044d901f5a040 # serialized CM value Rationale: [TF] The annotations are automatically generated by Carsten's cbor2pretty.rb tool. In this case, we don't think there's any reason to attempt a string conversion, as the encoded message is just a series of random bytes. If this is a problem, we suggest replacing the string in the comment with an ellipsis, as no information would really be lost. After some more discussion, we believe that it's worth annotating it with something more meaningful like "serialized CM value” ... 3) Section 9.6.2 (Table 4) Original: Tag Number Tag Content 1668547091 bytes .cbor cbor-cmw 1668547092 bytes-wrapped json-cmw 1668547093 bytes .cbor signed-cbor-cmw 1668547094 bytes-wrapped signed-json-cmw Current: Tag Number Tag Content 1668547091 bytes .cbor cbor-collection 1668547092 bytes .cbor signed-cbor-cmw 1668547093 bytes-wrapped json-collection 1668547094 bytes-wrapped signed-json-cmw ... 4) Dionna Glaze was removed from the author list and added to the Acknowledgements section.[DG] Apple still hasn’t approved my contributions to ietf, so you might as well remove me from authors—Files (please refresh)— Note: We will await approvals from Hannes, Henk, and Ned prior to moving forward with publication. Updated XML file: https://www.rfc-editor.org/authors/rfc9999.xml Updated output files: https://www.rfc-editor.org/authors/rfc9999.txt https://www.rfc-editor.org/authors/rfc9999.pdf https://www.rfc-editor.org/authors/rfc9999.html Diff files showing all changes made during Final Review (formally AUTH48): https://www.rfc-editor.org/authors/rfc9999-auth48diff.html https://www.rfc-editor.org/authors/rfc9999-auth48rfcdiff.html (side by side) Diff files showing only changes made during the last editing round: https://www.rfc-editor.org/authors/rfc9999-lastdiff.html https://www.rfc-editor.org/authors/rfc9999-lastrfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9999-diff.html https://www.rfc-editor.org/authors/rfc9999-rfcdiff.html (side by side) For the status of this document, please see: https://www.rfc-editor.org/auth48/rfc9999 Best regards, Karen Moore RFC Production CenterOn Jun 10, 2026, at 10:35 AM, Thomas Fossati <[email protected]> wrote: Hi Karen, On Wed, 10 Jun 2026 at 19:22, Karen Moore <[email protected]> wrote:Hi Thomas, Thank you for the nice comment. Note that we have updated Hannes’ affiliation and marked your approval.Thanks!In terms of removing "this example uses line wrapping per [RFC8792]” within the figure in Section 5.4, note that other RFCs typically contain this text within the figure as well as in the running text (we add it to the running text if not present in order to cite RFC 8792). Please see RFCs 9644, 9834, and 9950 as examples. Given this, we have left the text as is.OK, as usual, I'll leave it to your superior judgement :-)Another option would be to remove "(this example uses line wrapping per [RFC8792])” from Section 5.4 and instead state the following in Section 2: Perhaps: The example in Section 5.4 uses line wrapping per [RFC8792]. Please review and let us know your preference.I'm fine with leaving it as it is. cheers!—Files (please refresh)— Updated XML file: https://www.rfc-editor.org/authors/rfc9999.xml Updated output files: https://www.rfc-editor.org/authors/rfc9999.txt https://www.rfc-editor.org/authors/rfc9999.pdf https://www.rfc-editor.org/authors/rfc9999.html Diff files showing all changes made during Final Review (formally AUTH48): https://www.rfc-editor.org/authors/rfc9999-auth48diff.html https://www.rfc-editor.org/authors/rfc9999-auth48rfcdiff.html (side by side) Diff files showing only changes made during the last editing round: https://www.rfc-editor.org/authors/rfc9999-lastdiff.html https://www.rfc-editor.org/authors/rfc9999-lastrfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9999-diff.html https://www.rfc-editor.org/authors/rfc9999-rfcdiff.html (side by side) For the status of this document, please see: https://www.rfc-editor.org/auth48/rfc9999 Best regards, Karen Moore RFC Production CenterOn Jun 9, 2026, at 10:41 PM, Thomas Fossati <[email protected]> wrote: Hi Karen, thanks for the update. (nearly) Everything looks very good. On doing another scan, I noticed a couple of minor issues: 1. Hannes' affiliation is still reported as H-BRS in the header, but it should be "UniBw M." 2. In §5.4, since the prose now says "this example uses line wrapping per [RFC8792]", we could remove the similar text from the example just below. Once these two items are fixed, I approve publication of the document. Thank you very much for the great work! cheers, t On Tue, 9 Jun 2026 at 22:50, Karen Moore <[email protected]> wrote:Hi Thomas, We have updated our files accordingly. Please let us know if you approve the document in its current form or if any further updates are needed. We will await approvals from each author prior to moving forward with publication. 1) Note that for Figures 1 and 2, we made “topology” uppercase (rather than making “Conceptual Messages” lowercase). Thanks for pointing that out. —Files (please refresh)— Updated XML file: https://www.rfc-editor.org/authors/rfc9999.xml Updated output files: https://www.rfc-editor.org/authors/rfc9999.txt https://www.rfc-editor.org/authors/rfc9999.pdf https://www.rfc-editor.org/authors/rfc9999.html Diff files showing all changes made during Final Review (formally AUTH48): https://www.rfc-editor.org/authors/rfc9999-auth48diff.html https://www.rfc-editor.org/authors/rfc9999-auth48rfcdiff.html (side by side) Diff files showing only changes made during the last editing round: https://www.rfc-editor.org/authors/rfc9999-lastdiff.html https://www.rfc-editor.org/authors/rfc9999-lastrfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9999-diff.html https://www.rfc-editor.org/authors/rfc9999-rfcdiff.html (side by side) For the status of this document, please see: https://www.rfc-editor.org/auth48/rfc9999 Best regards, Karen Moore RFC Production CenterOn Jun 9, 2026, at 7:35 AM, Thomas Fossati <[email protected]> wrote: Hi Karen, Thanks very much for your changes. Please find some more comments below. cheers! On Fri, 5 Jun 2026 at 22:46, Karen Moore wrote:Hi Thomas, Thank you for your reply! We have updated our files accordingly. We have a few additional questions: 1) We note that “Collection CMW” is preferred. Please let us know if/how you would like this sentence to be updated. Current: CMW Records, Tags, and Collections alone do not offer authenticity, integrity protection, or confidentiality. Perhaps: Record, Tag, and Collection CMWs alone do not offer authenticity, integrity protection, or confidentiality.The "Perhaps" looks better.2) In Section 5.4, we replaced "҄@\xA0D\xD9\u0001\xF5\xA0\@" with "…". Please review and let us know if any further changes are needed.After some more discussion, we believe that it's worth annotating it with something more meaningful like "serialized CM value"3) We moved Dionna Glaze to the Acknowledgements section. If she should be listed as a contributor instead, please let us know.Dionna told us that her employer has not yet approved her contributions to the IETF. Therefore, I don't think it would be appropriate to list her as a contributor.—Files— Note that it may be necessary for you to refresh your browser to view the most recent version. Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. Please contact us with any further updates or with your approval of the document in its current form. We will await approvals from each author prior to moving forward in the publication process.After reviewing the whole document we have the following comments: 1. Abstract and Introduction (two instances): "[...] conveyed between RATS roles during RATS." sounds like the sentence was cut short. We'd like to propose: "[...] conveyed between RATS roles during RATS interactions." 2. The new caption of Figure 2 has a couple of typos: a. missing "of" after "Conveyance" b. extra '"' at the end Also, these captions are the only place where "Conceptual Messages" is capitalised like this. Should they be "conceptual messages" instead? 3. Hannes's affiliation is not current and should be updated to: Hannes Tschofenig University of the Bundeswehr Munich Institute of Distributed Intelligent Systems Werner-Heisenberg-Weg 39 85577 Neubiberg Germany Email: [email protected] 4. The [TLS-DTLS] reference is no longer active. It has been replaced by I-D.fossati-seat-early-attestation. We should update it and display it as [RA-TLS-EARLY]. 5. In the abstract: "[...] evolves message serialization formats without breaking compatibility" suggests the wrong idea that CMW itself drives the evolution of message serialisation formats, whereas the concept here is that CMW enables the smooth evolution of serialisation formats. We'd like to propose: "[...] enables the evolution of message serialization formats without breaking compatibility" 6. In the abstract, the following statement contains a couple of inaccuracies: "[...] this document defines a media type and a CoAP Content-Format to transport CMWs over protocols" The "to transport" part makes it sound as though the Content-Format is transporting the CMW. Besides, we define more than one media type and one C-F. Therefore, we'd like to propose the following: "[...] this document defines media types and CoAP Content-Formats which may be used to identify CMWs when transported over protocols". 7. In Section 3.1.1: we say "the ind byte string" but it should be "the ind bitmap" instead. 8. We have also just noticed that some incorrect information has been introduced: "IANA has allocated CBOR tag numbers and the corresponding data items, as shown in Table 4." However, in this case, IANA hasn't done any allocation; the carve-out has been in place since RFC9277. To fix the two problems above we propose: OLD 9.6.2. CBOR Tags per RFC 9277 Registering the CoAP Content-Formats listed in Table 3 automatically allocates CBOR tags in the range [1668546817, 1668612095] using the TN() transform defined in Appendix B of [RFC9277]. IANA has allocated CBOR tag numbers and the corresponding data items as shown in Table 4. +============+===============================+ | Tag Number | Tag Content | +============+===============================+ | 1668547091 | bytes .cbor cbor-cmw | +------------+-------------------------------+ | 1668547092 | bytes .cbor signed-cbor-cmw | +------------+-------------------------------+ | 1668547093 | bytes-wrapped json-cmw | +------------+-------------------------------+ | 1668547094 | bytes-wrapped signed-json-cmw | +------------+-------------------------------+ Table 4: TN-Derived CBOR Tags Figure 7 extends the $cbor-tag socket defined in Section 3.2 to add the definitions of the associated Tag CMWs. Note that CMWs in Tag and Record form are excluded from the productions. This is because they can already be represented as a CMW, so the extra wrapping would be redundant. $cbor-tag /= tag-cm-cbor<1668547091, cbor-collection> $cbor-tag /= tag-cm-cbor<1668547092, signed-cbor-cmw> $cbor-tag /= tag-cm-data<1668547093> ; bytes(cmw+json collection) $cbor-tag /= tag-cm-data<1668547094> ; bytes(cmw+jws) Figure 7: Tag CMW Definitions NEW 9.6.2. CBOR Tags per RFC 9277 Registering the CoAP Content-Formats listed in Table 3 automatically allocates CBOR tags in the range [1668546817, 1668612095] using the TN() transform defined in Appendix B of [RFC9277]. The allocated CBOR tag numbers and the corresponding data items are shown in Table 4. Note that CMWs in Tag and Record form are excluded. This is because they can already be represented as a CMW, so the extra wrapping would be redundant. +============+===============================+ | Tag Number | Tag Content | +============+===============================+ | 1668547091 | bytes .cbor cbor-collection | +------------+-------------------------------+ | 1668547092 | bytes .cbor signed-cbor-cmw | +------------+-------------------------------+ | 1668547093 | bytes-wrapped json-collection | +------------+-------------------------------+ | 1668547094 | bytes-wrapped signed-json-cmw | +------------+-------------------------------+ Table 4: TN-Derived CBOR Tags Figure 7 extends the $cbor-tag socket defined in Section 3.2 to add the definitions of the associated Tag CMWs. $cbor-tag /= tag-cm-cbor<1668547091, cbor-collection> $cbor-tag /= tag-cm-cbor<1668547092, signed-cbor-cmw> $cbor-tag /= tag-cm-data<1668547093> ; bytes(cmw+json collection) $cbor-tag /= tag-cm-data<1668547094> ; bytes(cmw+jws) Figure 7: Tag CMW Definitions—Files— Note that it may be necessary for you to refresh your browser to view the most recent version. Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. Please contact us with any further updates or with your approval of the document in its current form. We will await approvals from each author prior to moving forward in the publication process. Updated XML file: https://www.rfc-editor.org/authors/rfc9999.xml Updated output files: https://www.rfc-editor.org/authors/rfc9999.txt https://www.rfc-editor.org/authors/rfc9999.pdf https://www.rfc-editor.org/authors/rfc9999.html Diff files showing all changes made during Final Review (formally AUTH48): https://www.rfc-editor.org/authors/rfc9999-auth48diff.html https://www.rfc-editor.org/authors/rfc9999-auth48rfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9999-diff.html https://www.rfc-editor.org/authors/rfc9999-rfcdiff.html (side by side) For the status of this document, please see: https://www.rfc-editor.org/auth48/rfc9999 Best regards, Karen Moore RFC Production Center
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
