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]
