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 Center > > > > On 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]
