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