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