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