Many thanks Kaelin, looks good to me. A bientôt;
Pascal > Le 2 mars 2026 à 22:17, Kaelin Foody <[email protected]> a écrit : > > Hi Pascal, > > We have made a small additional update to this document. > > We have updated a few citation tags for consistency with similar citation > tags in the RFC Series and RFC-to-be 9914. You may view these updates in the > diff here: > https://www.rfc-editor.org/authors/rfc9912-lastrfcdiff.html. > > RFC-to-be 9914 moved to AUTH48 last week; once it completes AUTH48, the rest > of the documents in this cluster (RFC 9912 and 9913) will be published as > well. > > Please let us know if you have any questions in the meantime. > > All the best, > > Kaelin Foody > RFC Production Center > >> On Feb 19, 2026, at 12:59 PM, Kaelin Foody <[email protected]> >> wrote: >> >> Hi Pascal, >> >> Thank you for your review and approval of RFC 9912. >> >> We have now received all necessary approvals and are ready to move this >> document forward in the publication process at this time. >> >> Please note that this document is part of Cluster 538. As such, it will be >> published alongside RFCs-to-be 9913 (draft-ietf-raw-architecture-30) and >> 9914 (draft-ietf-roll-dao-projection-40). >> >> The AUTH48 status page of this document is available here: >> http://www.rfc-editor.org/auth48/rfc9912. >> >> The status of all documents in Cluster 538 is available here: >> https://www.rfc-editor.org/cluster_info.php?cid=C538 >> >> >> In addition, we have updated this text in Section 3 per Janos’s request, as >> follows: >> >>> What about: >>> "RAW inherits and augments IETF recovery mechanisms such as the ones >>> provided in DetNet [DetNet-ARCHI], and in Traffic Engineering, e.g., RFC >>> 4090.” >> >> >> We have also updated RFC 9913 to reflect your request below: >> >>> Reading RFC 9913 iI found a nit to be fixed in 5.2.1 >>> >>> BEFORE >>> "The RAW Track described in the RAW architecture [RFC9912] inherits >>> directly from that model. " >>> >>> AFTER >>> "The RAW recovery graph described in the RAW architecture [RFC9912] >>> inherits directly from that model. “ >> >> >> — FILES (please refresh): — >> >> The updated files have been posted here: >> https://www.rfc-editor.org/authors/rfc9912.txt >> https://www.rfc-editor.org/authors/rfc9912.pdf >> https://www.rfc-editor.org/authors/rfc9912.html >> https://www.rfc-editor.org/authors/rfc9912.xml >> >> Diff files showing changes between the last and current version: >> https://www.rfc-editor.org/authors/rfc9912-lastdiff.html >> https://www.rfc-editor.org/authors/rfc9912-lastrfcdiff.html (side by side) >> >> Diff files showing changes made during AUTH48: >> https://www.rfc-editor.org/authors/rfc9912-auth48diff.html (AUTH48 changes >> only) >> https://www.rfc-editor.org/authors/rfc9912-auth48rfcdiff.html (AUTH48 >> changes side by side) >> >> Diff files showing all changes: >> https://www.rfc-editor.org/authors/rfc9912-diff.html (all changes) >> https://www.rfc-editor.org/authors/rfc9912-rfcdiff.html (all changes side by >> side) >> >> >> Thank you for your time and attention during AUTH48! >> >> All the best, >> >> Kaelin Foody >> RFC Production Center >> >> >> >>>> On Feb 19, 2026, at 3:39 AM, Pascal Thubert <[email protected]> >>>> wrote: >>> >>> Dear editor >>> >>> Reading RFC 9913 iI found a nit to be fixed in 5.2.1 >>> >>> BEFORE >>> "The RAW Track described in the RAW architecture [RFC9912] inherits >>> directly from that model. " >>> >>> AFTER >>> "The RAW recovery graph described in the RAW architecture [RFC9912] >>> inherits directly from that model. " >>> >>> Many thanks! >>> >>> Pascal >>> >>>> Le jeu. 19 févr. 2026 à 09:14, Pascal Thubert <[email protected]> a >>>> écrit : >>> Dear Editor: >>> >>> I reviewed this RFC and approve it for publication. >>> >>> Many thanks for the hard work! >>> >>> Pascal >>> >>>> Le mar. 10 févr. 2026 à 06:46, <[email protected]> a écrit : >>> *****IMPORTANT***** >>> >>> Updated 2026/02/09 >>> >>> RFC Author(s): >>> -------------- >>> >>> Instructions for Completing AUTH48 >>> >>> Your document has now entered AUTH48. Once it has been reviewed and >>> approved by you and all coauthors, it will be published as an RFC. >>> If an author is no longer available, there are several remedies >>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>> >>> You and you coauthors are responsible for engaging other parties >>> (e.g., Contributors or Working Group) as necessary before providing >>> your approval. >>> >>> Planning your review >>> --------------------- >>> >>> Please review the following aspects of your document: >>> >>> * RFC Editor questions >>> >>> Please review and resolve any questions raised by the RFC Editor >>> that have been included in the XML file as comments marked as >>> follows: >>> >>> <!-- [rfced] ... --> >>> >>> These questions will also be sent in a subsequent email. >>> >>> * Changes submitted by coauthors >>> >>> Please ensure that you review any changes submitted by your >>> coauthors. We assume that if you do not speak up that you >>> agree to changes submitted by your coauthors. >>> >>> * Content >>> >>> Please review the full content of the document, as this cannot >>> change once the RFC is published. Please pay particular attention to: >>> - IANA considerations updates (if applicable) >>> - contact information >>> - references >>> >>> * Copyright notices and legends >>> >>> Please review the copyright notice and legends as defined in >>> RFC 5378 and the Trust Legal Provisions >>> (TLP – https://trustee.ietf.org/license-info). >>> >>> * Semantic markup >>> >>> Please review the markup in the XML file to ensure that elements of >>> content are correctly tagged. For example, ensure that <sourcecode> >>> and <artwork> are set correctly. See details at >>> <https://authors.ietf.org/rfcxml-vocabulary>. >>> >>> * Formatted output >>> >>> Please review the PDF, HTML, and TXT files to ensure that the >>> formatted output, as generated from the markup in the XML file, is >>> reasonable. Please note that the TXT will have formatting >>> limitations compared to the PDF and HTML. >>> >>> >>> Submitting changes >>> ------------------ >>> >>> To submit changes, please reply to this email using ‘REPLY ALL’ as all >>> the parties CCed on this message need to see your changes. The parties >>> include: >>> >>> * your coauthors >>> >>> * [email protected] (the RPC team) >>> >>> * other document participants, depending on the stream (e.g., >>> IETF Stream participants are your working group chairs, the >>> responsible ADs, and the document shepherd). >>> >>> * [email protected], which is a new archival mailing list >>> to preserve AUTH48 conversations; it is not an active discussion >>> list: >>> >>> * More info: >>> >>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>> >>> * The archive itself: >>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>> >>> * Note: If only absolutely necessary, you may temporarily opt out >>> of the archiving of messages (e.g., to discuss a sensitive matter). >>> If needed, please add a note at the top of the message that you >>> have dropped the address. When the discussion is concluded, >>> [email protected] will be re-added to the CC list and >>> its addition will be noted at the top of the message. >>> >>> You may submit your changes in one of two ways: >>> >>> An update to the provided XML file >>> — OR — >>> An explicit list of changes in this format >>> >>> Section # (or indicate Global) >>> >>> OLD: >>> old text >>> >>> NEW: >>> new text >>> >>> You do not need to reply with both an updated XML file and an explicit >>> list of changes, as either form is sufficient. >>> >>> We will ask a stream manager to review and approve any changes that seem >>> beyond editorial in nature, e.g., addition of new text, deletion of text, >>> and technical changes. Information about stream managers can be found in >>> the FAQ. Editorial changes do not require approval from a stream manager. >>> >>> >>> Approving for publication >>> -------------------------- >>> >>> To approve your RFC for publication, please reply to this email stating >>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>> as all the parties CCed on this message need to see your approval. >>> >>> >>> Files >>> ----- >>> >>> The files are available here: >>> https://www.rfc-editor.org/authors/rfc9912.xml >>> https://www.rfc-editor.org/authors/rfc9912.html >>> https://www.rfc-editor.org/authors/rfc9912.pdf >>> https://www.rfc-editor.org/authors/rfc9912.txt >>> >>> Diff file of the text: >>> https://www.rfc-editor.org/authors/rfc9912-diff.html >>> https://www.rfc-editor.org/authors/rfc9912-rfcdiff.html (side by side) >>> >>> Alt-diff of the text (allows you to more easily view changes >>> where text has been deleted or moved): >>> https://www.rfc-editor.org/authors/rfc9912-alt-diff.html >>> >>> Diff of the XML: >>> https://www.rfc-editor.org/authors/rfc9912-xmldiff1.html >>> >>> >>> Tracking progress >>> ----------------- >>> >>> The details of the AUTH48 status of your document are here: >>> https://www.rfc-editor.org/auth48/rfc9912 >>> >>> Please let us know if you have any questions. >>> >>> Thank you for your cooperation, >>> >>> RFC Editor >>> >>> -------------------------------------- >>> RFC9912 (draft-ietf-raw-architecture-30) >>> >>> Title : Reliable and Available Wireless Architecture >>> Author(s) : P. Thubert >>> WG Chair(s) : Lou Berger, János Farkas >>> >>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde >>> >>> >>> >>> >>> -- >>> Pascal >>> >>> >>> -- >>> Pascal >> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
