Hi Yuehua, Thank you for your reply! We have marked your approval on the AUTH48 status page (see https://www.rfc-editor.org/auth48/rfc9696).
Once we receive approvals from Dmitry, Pascal, and Tony, we will move this document forward in the publication process. Thank you! RFC Editor/mc > On Dec 19, 2024, at 7:00 PM, wei.yue...@zte.com.cn wrote: > > Hi Madison, > Thank you. > I have reviewed the whole draft and I approve the publication as the editor. > > Best Regards, > Yuehua Wei > > Original > From: MadisonChurch <mchu...@amsl.com> > To: 魏月华00019655;张征00007940;f...@yandex-team.ru > <f...@yandex-team.ru>;pthub...@cisco.com > <pthub...@cisco.com>;p...@juniper.net <p...@juniper.net>; > Cc: RFC Editor <rfc-edi...@rfc-editor.org>;rift-...@ietf.org > <rift-...@ietf.org>;rift-cha...@ietf.org > <rift-cha...@ietf.org>;zzh...@juniper.net <zzh...@juniper.net>;James Guichard > <james.n.guich...@futurewei.com>;auth48archive@rfc-ed > <auth48archive@rfc-editor.org>; > Date: 2024年12月18日 23:33 > Subject: Re: AUTH48: RFC-to-be 9696 <draft-ietf-rift-applicability-17> for > your review > Hi Authors, > > Zheng - We have noted your approval on the AUTH48 status page (please see > https://www.rfc-editor.org/auth48/rfc9696). > > Yuehua - Thank you for your quick reply! We have updated the document to > reflect your proposed change in the updated files below. > > Please review the document carefully to ensure satisfaction as we do not make > changes once it has been published as an RFC. 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. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9696.txt > https://www.rfc-editor.org/authors/rfc9696.pdf > https://www.rfc-editor.org/authors/rfc9696.html > https://www.rfc-editor.org/authors/rfc9696.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9696-diff.html > https://www.rfc-editor.org/authors/rfc9696-rfcdiff.html > https://www.rfc-editor.org/authors/rfc9696-auth48diff.html > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9696 > > Thank you, > RFC Editor/mc > > > On Dec 17, 2024, at 7:35 PM, <wei.yue...@zte.com.cn> > > <wei.yue...@zte.com.cn> wrote: > > > > Hi Madison, > > Thank you very much for such a quick revision. > > Everything looks perfect except one minor flaw: > > > > ORIGINAL: > > 4.2.4. Reachability of Internal Nodes in the Fabric > > Under normal operating conditions this can be easily achieved by > > injecting the node's loopback address into North and South Prefix > > TIEs or other implementation specific mechanisms. > > CURRENT: > > 4.2.4. Reachability of Internal Nodes in the Fabric > > Under normal operating conditions, this can be easily achieved by > > injecting the node's loopback address into North and Prefix South > > TIEs or other implementation-specific mechanisms. > > PROPOSE: > > Under normal operating conditions, this can be easily achieved by > > injecting the node's loopback address into Prefix North TIEs and Prefix > > South > > TIEs or other implementation-specific mechanisms. > > > > Best Regards, > > Yuehua Wei > > M: +86 13851460269 E: wei.yue...@zte.com.cn > > > > Original > > From: MadisonChurch <mchu...@amsl.com> > > To: 魏月华00019655;张征00007940;f...@yandex-team.ru > > <f...@yandex-team.ru>;pthub...@cisco.com > > <pthub...@cisco.com>;p...@juniper.net <p...@juniper.net>; > > Cc: RFC Editor <rfc-edi...@rfc-editor.org>;rift-...@ietf.org > > <rift-...@ietf.org>;rift-cha...@ietf.org > > <rift-cha...@ietf.org>;zzh...@juniper.net <zzh...@juniper.net>;James > > Guichard <james.n.guich...@futurewei.com>;auth48archive@rfc-ed > > <auth48archive@rfc-editor.org>; > > Date: 2024年12月18日 06:27 > > Subject: Re: AUTH48: RFC-to-be 9696 <draft-ietf-rift-applicability-17> for > > your review > > Hi Yuehua, > > > > Thank you for your reply! We have updated the document accordingly and all > > of our questions have been addressed. > > > > Please review the document carefully to ensure satisfaction as we do not > > make changes once it has been published as an RFC. 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. > > > > The files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9696.txt > > https://www.rfc-editor.org/authors/rfc9696.pdf > > https://www.rfc-editor.org/authors/rfc9696.html > > https://www.rfc-editor.org/authors/rfc9696.xml > > > > The relevant diff files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9696-diff.html (comprehensive > > diff) > > https://www.rfc-editor.org/authors/rfc9696-rfcdiff.html (side-by-side > > diff) > > https://www.rfc-editor.org/authors/rfc9696-auth48diff.html (diff showing > > AUTH48 changes) > > > > For the AUTH48 status of this document, please see: > > https://www.rfc-editor.org/auth48/rfc9696 > > > > Thank you! > > RFC Editor/mc > > > > > On Dec 17, 2024, at 1:37 AM, wei.yue...@zte.com.cn wrote: > > > > > > Dear editors, > > > I have resolved all the questions inline with your email starting with > > > "weiyh>>>", I appreciate your further comments. > > > In adition, I believe in "5.10. In-Band Reachability of Nodes", > > > "-- the spine nodes in Figure 9 -- " SHOULD BE "-- the spine nodes in > > > Figure 11 -- " > > > Thank you! > > > Best Regards, > > > Yuehua Wei > > > > > > Original > > > From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> > > > To: 魏月华00019655;张征00007940;f...@yandex-team.ru > > > <f...@yandex-team.ru>;pthub...@cisco.com > > > <pthub...@cisco.com>;p...@juniper.net <p...@juniper.net>; > > > Cc: rfc-edi...@rfc-editor.org > > > <rfc-edi...@rfc-editor.org>;rift-...@ietf.org > > > <rift-...@ietf.org>;rift-cha...@ietf.org > > > <rift-cha...@ietf.org>;zzh...@juniper.net > > > <zzh...@juniper.net>;james.n.guich...@futurewei.com > > > <james.n.guich...@futurewei.com>;auth48archive@rfc-editor.org > > > <auth48archive@rfc-editor.org>; > > > Date: 2024年12月12日 08:21 > > > Subject: Re: AUTH48: RFC-to-be 9696 <draft-ietf-rift-applicability-17> > > > for your review > > > Authors, > > > > > > While reviewing this document during AUTH48, please resolve (as > > > necessary) the following questions, which are also in the XML file. > > > > > > 1) <!-- [rfced] Please note that the title of the document has been > > > updated to > > > expand "RIFT" per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please > > > review. > > > > > > Original: > > > RIFT Applicability and Operational Considerations > > > > > > Current: > > > Routing in Fat Trees (RIFT) Applicability and Operational > > > Considerations > > > --> > > > weiyh>>>Good! > > > > > > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > > > the title) for use on https://www.rfc-editor.org/search. --> > > > weiyh>>>no more keywords. > > > > > > 3) <!-- [rfced] To avoid repetition and make the text more concise, we > > > have > > > updated the following sentences in Section 2. Please let us know any > > > objections. > > > > > > Original: > > > This document uses the terminology of RIFT [RIFT]. The most > > > frequently used terminologies defined in RIFT are listed here. These > > > terms > > > are consistent with definition in RIFT [RIFT] > > > > > > Current: > > > This document uses the terminology defined in [RIFT]. The most > > > frequently used terms and their definitions from that document are > > > listed > > > here. > > > --> > > > weiyh>>>no objections. > > > > > > 4) <!-- [rfced] What is "vice versa" referring to in this sentence? > > > > > > Original: > > > If links in a Clos are considered as either being all directed > > > towards the top or vice versa, each of such two graphs is a DAG. > > > > > > Perhaps: > > > If links in a Clos are considered as either being all directed > > > towards the top or bottom, each of such two graphs is a DAG. > > > --> > > > weiyh>>>no objections. > > > > > > 5) <!-- [rfced] We are unable to verify if the term "homonym" is used > > > correctly in [FATTREE]. May we rephrase the following sentence for > > > accuracy? > > > > > > Original: > > > Clos [CLOS] topologies (called commonly a fat tree/network in modern > > > IP fabric considerations as homonym to the original definition of the > > > term Fat Tree [FATTREE]) have gained prominence in today's > > > networking, primarily as a result of the paradigm shift towards a > > > centralized data-center based architecture that deliver a majority of > > > computation and storage services. > > > > > > Perhaps: > > > Clos [CLOS] topologies (commonly called a Fat Tree/network in modern > > > IP fabric considerations as a similar term for the original definition > > > of the > > > term Fat Tree [FATTREE]) have gained prominence in today's > > > networking, primarily as a result of the paradigm shift towards a > > > centralized data-center-based architecture that delivers a majority of > > > computation and storage services. > > > --> > > > weiyh>>>no objections. > > > > > > 6) <!-- [rfced] May we specify "link-state" and "distance-vector" for > > > clarity in > > > the following instances? > > > > > > Original: > > > RIFT combines the advantage of both link-state and distance-vector... > > > > > > RIFT also eliminates major disadvantages of link-state and > > > distance-vector > > > with... > > > > > > Perhaps: > > > RIFT combines the advantages of both link-state and distance-vector > > > protocols... > > > > > > RIFT also eliminates major disadvantages of link-state and > > > distance-vector > > > protocols... > > > --> > > > weiyh>>>no objections. > > > > > > 7) <!-- [rfced] Some author comments are present in the XML. Please > > > confirm that > > > no updates related to these comments are outstanding. Note that the > > > comments will be deleted prior to publication. > > > --> > > > weiyh>>>confirmed. > > > > > > 8) <!-- [rfced] May we update the following sentence for clarity? > > > Additionally, > > > should "employed" be updated to "deployed"? We note that this is the only > > > instance of "employed" that appears in the document. > > > > > > Original: > > > A full-mesh connectivity between nodes on the same level can be > > > employed and that allows N-SPF to provide for any node losing all its > > > northbound adjacencies (as long as any of the other nodes in the > > > level are northbound connected) to still participate in northbound > > > forwarding. > > > > > > Perhaps: > > > A full-mesh connectivity between nodes on the same level can be > > > deployed, which allows North SPF (N-SPF) to provide for any node > > > losing all its > > > northbound adjacencies (as long as any of the other nodes in the > > > level are northbound connected) and still participate in northbound > > > forwarding. > > > --> > > > weiyh>>>Yes, "deployed" is better. > > > > > > > > > 9) <!-- [rfced] Should "Link State" be specified as "link-state > > > protocols" here? > > > > > > Original: > > > In that case, RIFT operates very much like RPL [RFC6550], but using > > > Link State for southbound routes (downwards in RPL's terms). > > > > > > Perhaps: > > > In that case, RIFT operates very much like RPL [RFC6550], but uses > > > link-state protocols for southbound routes (downwards in RPL's terms). > > > --> > > > weiyh>>>if "link-state" is too brief, maybe say, "but uses > > > link-state information for southbound routes (downwards in RPL's > > > terms)." > > > > > > 10) <!-- [rfced] May we rephrase the following sentence for ease of the > > > reader? > > > > > > Original: > > > RIFT is suited for applying in data center (DC) IP fabrics underlay > > > routing, vast majority of which seem to be currently (and for the > > > foreseeable > > > future) Clos architectures. > > > > > > Perhaps: > > > RIFT is suited for applying underlay routing in data center (DC) IP > > > fabrics, with the vast majority of these IP fabrics being Clos > > > architectures > > > (and will be for the foreseeable future). > > > --> > > > weiyh>>>Good! > > > > > > > > > 11) <!-- [rfced] To match [TR-384], may we update "leaf and spine fabric" > > > to > > > "leaf-spine fabric"? > > > > > > Original: > > > The two I/O modules are interconnected by a leaf and spine fabric > > > [TR-384]. > > > > > > Perhaps: > > > The two I/O modules are interconnected by a leaf-spine fabric [TR-384]. > > > --> > > > weiyh>>>since "spine-and-leaf" is widely used in this rfc, I'd prefer > > > "The two I/O modules are interconnected by a spine-and-leaf fabric > > > [TR-384]." > > > > > > > > > 12) <!-- [rfced] May we rephrase and break up the following sentence to > > > improve readability? > > > > > > Original: > > > * RIFT reduces FIB size towards the bottom of the IP fabric where > > > most nodes reside and allows with that for cheaper hardware on the > > > edges and introduction of modern IP fabric architectures that > > > encompass e.g. server multi-homing. > > > > > > Perhaps: > > > * RIFT reduces FIB size towards the bottom of the IP fabric where > > > most nodes reside. This allows for cheaper hardware on the > > > edges and introduction of modern IP fabric architectures that > > > encompass server multihoming and other mechanisms. > > > --> > > > weiyh>>>Good! > > > > > > 13) <!-- [rfced] We note that the following instances of text are > > > repeated at > > > the end of Sections 5.1 and following Figure 4 in Section 5.2. Should the > > > text > > > in Section 5.2 be removed to avoid repetition? > > > > > > Original (Section 5.1): > > > In an equivalent fashion, as the result of the south > > > reflection between Spine121-Leaf121-Spine122 and > > > Spine121-Leaf122-Spine122, > > > Spine121 and Spine 122 knows each other at level 1. > > > > > > Original (Section 5.2): > > > As shown in Figure 4, as the result of the south > > > reflection between Spine121-Leaf121-Spine122 and > > > Spine121-Leaf122-Spine122, > > > Spine121 and Spine 122 knows each other at level 1. > > > --> > > > weiyh>>>Good catch! I suggest to replace "as the result of the south > > > reflection between Spine121-Leaf121-Spine122 and > > > Spine121-Leaf122-Spine122, Spine121 and Spine 122 know each other at > > > level 1" with "as the result of the south reflection, Spine121 and Spine > > > 122 know each other at level 1". Is it better? > > > > > > > > > 14) <!-- [rfced] We have rephrased the following sentence and split it > > > into two > > > for ease of the reader. Please let us know any objections. > > > > > > Original: > > > Without disaggregation mechanism, when linkSL6 fails, the packet > > > from leaf121 to prefix122 will probably go up through linkSL5 to > > > linkTS3 then > > > ago down through linkTS4 to linkSL8 to Leaf122 or go up through > > > linkSL5 to > > > linkTS6 then go down through linkTS8 and linkSL8 to Leaf122 based on > > > pure > > > default route. > > > > > > Current: > > > Without disaggregation mechanisms, the packet from leaf121 to > > > prefix122 will probably go up through linkSL5 to linkTS3 when linkSL6 > > > fails. Then, the packet will go down through linkTS4 to linkSL8 to > > > Leaf122 or > > > go up through linkSL5 to linkTS6, then go down through linkTS8 and > > > linkSL8 to > > > Leaf122 based on the pure default route. > > > --> > > > weiyh>>>no objections. > > > > > > 15) <!-- [rfced] Is "and when not" referring to ZTP configuring the > > > network? > > > > > > Original: > > > It is recommended to let ZTP configure the network, and when not, it > > > is recommended to configure the level of all the nodes to avoid an > > > undesirable > > > interaction between ZTP and the manual configuration. > > > > > > Perhaps: > > > It is recommended to let ZTP configure the network, and when ZTP does > > > not configure the network, it is recommended to configure the level of > > > all the > > > nodes to avoid an undesirable interaction between ZTP and the manual > > > configuration. > > > --> > > > weiyh>>>Good! > > > > > > 16) <!-- [rfced] We note that Figures 8 and 9 have the same title of > > > "Fallen > > > Spine". Is this intentional? If not, please let us know how we should > > > update to make these figures more distinct. > > > --> > > > weiyh>>>replace "Figure 9: Fallen Spine" with "Additional Cabling > > > Constraint Example" > > > > > > 17) <!--[rfced] To clarify the content found in RFC 8505, may we rephrase > > > the > > > text around its citations as follows? > > > > > > Original: > > > When using IPv6 [RFC8200], RIFT suggests to leverage [RFC8505] as the > > > IPv6 ND interaction between the mobile node and the leaf. > > > ... > > > When using [RFC8505], the parallel registration of an > > > anycast address to multiple leaves is done with the same sequence > > > counter, whereas the sequence counter is incremented when the point > > > of attachment changes. > > > > > > Perhaps: > > > When using IPv6 [RFC8200], RIFT suggests leveraging 6LoWPAN ND > > > [RFC8505] > > > as the IPv6 ND interaction between the mobile node and the leaf. > > > ... > > > When using 6LoWPAN ND [RFC8505], the parallel registration of an > > > anycast address to multiple leaves is done with the same sequence > > > counter, whereas the sequence counter is incremented when the point > > > of attachment changes. > > > --> > > > weiyh>>>Good! > > > > > > 18) <!-- [rfced] We are unable to parse the following sentence > > > (specifically, we > > > are unable to determine what "or the must" means). May we rephrase as > > > follows for clarity and specify "Top-of-Fabric"? > > > > > > Original: > > > It has no configuration (unless it is a Top-of-Fabric at the top of > > > the topology or the must operate in the topology as leaf and/or support > > > leaf-2-leaf procedures) and it will fully configure itself after being > > > attached to the topology. > > > > > > Perhaps: > > > It has no configuration (unless it is a ToF node at the top of the > > > topology or if it must operate in the topology as a leaf and/or support > > > leaf-2-leaf procedures), and it will fully configure itself after being > > > attached to the topology. > > > --> > > > weiyh>>> "or the must" means “the node is a leaf_only node”，the > > > rephrasing is Good! > > > > > > 19) <!-- [rfced] May we rephrase the sentence below as follows (i.e., > > > specify > > > "ToR" and update "start on" to "startup")? > > > > > > Original: > > > Sometimes, people may prefer to disaggregate from ToR to servers > > > from start on, i.e. the servers have couple tens of routes in FIB from > > > start > > > on beside default routes to avoid breakages at rack level. > > > > > > Perhaps: > > > Sometimes people may prefer to disaggregate from ToR nodes to > > > servers from startup, i.e., the servers have multiple routes in the > > > FIB from > > > startup other than default routes to avoid breakages at the rack level. > > > --> > > > weiyh>>>no objections. > > > > > > 20) <!-- [rfced] References > > > > > > a) Please review the following reference. We have added the following URL: > > > https://www.iso.org/standard/30932.html and updated the title to reflect > > > the > > > accurate title of this ISO/IEC standard. Please let us know if you have > > > any > > > objections. > > > > > > Original: > > > [ISO10589-Second-Edition] > > > International Organization for Standardization, > > > "Intermediate system to Intermediate system intra-domain > > > routing information exchange protocol for use in > > > conjunction with the protocol for providing the > > > connectionless-mode Network Service (ISO 8473)", November > > > 2002. > > > > > > Current: > > > [ISO10589-Second-Edition] > > > ISO/IEC, "Information technology - Telecommunications and > > > information exchange between systems - Intermediate System > > > to Intermediate System intra-domain routeing information > > > exchange protocol for use in conjunction with the protocol > > > for providing the connectionless-mode network service (ISO > > > 8473)", ISO/IEC 10589:2002, November 2002, > > > <https://www.iso.org/standard/30932.html>. > > > weiyh>>>no objections. > > > > > > b) Please review the following reference. We found a URL > > > (https://www.broadband-forum.org/pdfs/tr-384-1-0-0.pdf) that matches the > > > information provided in this reference and updated the reference as > > > follows. Please let us know any objections. > > > > > > Original: > > > [TR-384] Broadband Forum Technical Report, "TR-384 Cloud Central > > > Office Reference Architectural Framework", January 2018. > > > > > > Current: > > > [TR-384] Broadband Forum Technical Report, "TR-384: Cloud Central > > > Office Reference Architectural Framework", TR-384, Issue > > > 1, January 2018, > > > <https://www.broadband-forum.org/pdfs/tr-384-1-0-0.pdf>. > > > weiyh>>>no objections. > > > > > > c) Please review the following reference. We found the following URL: > > > https://ieeexplore.ieee.org/document/6012836. We have added this URL to > > > this > > > reference. Please let us know if you have any objections. > > > > > > Original: > > > [CLOS] Yuan, X., "On Nonblocking Folded-Clos Networks in Computer > > > Communication Environments", IEEE International Parallel & > > > > > > Distributed Processing Symposium, 2011. > > > > > > > > > Current: > > > [CLOS] Yuan, X., "On Nonblocking Folded-Clos Networks in Computer > > > Communication Environments", 2011 IEEE International > > > Parallel & Distributed Processing Symposium, > > > DOI 10.1109/IPDPS.2011.27, May 2011, > > > <https://ieeexplore.ieee.org/document/6012836>. > > > weiyh>>>no objections. > > > > > > d) Please review. We found the following URL for this reference: > > > https://ieeexplore.ieee.org/document/6312192. We have added this URL to > > > this > > > reference. Please let us know if you have any objections > > > > > > Original: > > > [FATTREE] Leiserson, C. E., "Fat-Trees: Universal Networks for > > > Hardware-Efficient Supercomputing", 1985. > > > > > > Current: > > > [FATTREE] Leiserson, C. E., "Fat-Trees: Universal Networks for > > > Hardware-Efficient Supercomputing", IEEE Transactions on > > > Computers, vol. C-34, no. 10, pp. 892-901, > > > DOI 10.1109/TC.1985.6312192, October 1985, > > > <https://ieeexplore.ieee.org/document/6312192>. > > > weiyh>>>no objections. > > > > > > e) Please review. We found the following URL for this reference: > > > https://www.broadband-forum.org/download/af-pnni-0055.001.pdf. We have > > > added > > > this URL to this reference. Additionally, please note that the original > > > date > > > for this reference was 2003. We were unable to find a version of this > > > reference with that date. The version we found at the URL has a date of > > > April > > > 2002 and updated the reference as follows for consistency. Please let us > > > know > > > if you have any objections. > > > > > > Original: > > > [PNNI] ATM Forum Technical Committee, "Private Network-Network > > > Interface Specification, Version 1.1 (PNNI 1.1), af-pnni- > > > 0055.002", 2003. > > > > > > Current: > > > [PNNI] The ATM Forum Technical Committee, "Private Network- > > > Network Interface - Specification Version 1.1 - (PNNI > > > 1.1)", af-pnni-0055.001, April 2002, > > > <https://www.broadband-forum.org/download/af-pnni- > > > 0055.001.pdf>. > > > --> > > > weiyh>>>no objections. > > > > > > 21) <!-- [rfced] The following terminology appears to be used > > > inconsistently. > > > Please let us know how we should update for consistency. > > > > > > North Prefix TIE vs. Prefix North TIE > > > South Prefix TIE vs. South North TIE --> > > > Prefix South TIE > > > weiyh>>> replace “South Prefix TIE”with "Prefix South TIE" ，and replace > > > “North Prefix TIE”with "Prefix North TIE" > > > > > > 22) <!-- [rfced] Please review the "Inclusive Language" portion of the > > > online > > > Style Guide > > > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > > > and let us know if any changes are needed. Updates of this nature > > > typically > > > result in more precise language, which is helpful for readers. > > > > > > For example, please consider whether the terms "black" and "natively". > > > > > > In addition, please consider whether "traditional" should be updated for > > > clarity. > > > While the NIST website > > > <https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> > > > > > > indicates that this term is potentially biased, it is also ambiguous. > > > "Tradition" is a subjective term, as it is not the same for everyone. --> > > > > > > weiyh>>>I'd prefer to keep "black" and "natively", and prefer to replace > > > "traditional" with "classical" > > > > > > 23) <!-- [rfced] FYI - We have added expansions for the following > > > abbreviations > > > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > > > expansion in the document carefully to ensure correctness. > > > > > > > > > Bidirectional Forwarding Detection (BFD) > > > Key Management Protocol (KMP) > > > Mobile Ad Hoc Network (MANET) > > > Optimized Link State Routing (OLSR) > > > Private Network-Network Interface (PNNI) > > > Routing Protocol for Low-Power and Lossy Networks (RPL) > > > --> > > > weiyh>>>no objections. > > > > > > Thank you. > > > > > > RFC Editor/mc/ap > > > > > > > > > On Dec 11, 2024, at 4:19 PM, rfc-edi...@rfc-editor.org wrote: > > > > > > *****IMPORTANT***** > > > > > > Updated 2024/12/11 > > > > > > 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 > > > > > > * rfc-edi...@rfc-editor.org (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). > > > > > > * auth48archive@rfc-editor.org, 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, > > > auth48archive@rfc-editor.org 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/rfc9696.xml > > > https://www.rfc-editor.org/authors/rfc9696.html > > > https://www.rfc-editor.org/authors/rfc9696.pdf > > > https://www.rfc-editor.org/authors/rfc9696.txt > > > > > > Diff file of the text: > > > https://www.rfc-editor.org/authors/rfc9696-diff.html > > > https://www.rfc-editor.org/authors/rfc9696-rfcdiff.html (side by side) > > > > > > Diff of the XML: > > > https://www.rfc-editor.org/authors/rfc9696-xmldiff1.html > > > > > > > > > Tracking progress > > > ----------------- > > > > > > The details of the AUTH48 status of your document are here: > > > https://www.rfc-editor.org/auth48/rfc9696 > > > > > > Please let us know if you have any questions. > > > > > > Thank you for your cooperation, > > > > > > RFC Editor > > > > > > -------------------------------------- > > > RFC9696 (draft-ietf-rift-applicability-17) > > > > > > Title : RIFT Applicability and Operational Considerations > > > Author(s) : Y. Wei, Z. Zhang, D. Afanasiev, P. Thubert, T. > > > Przygienda > > > WG Chair(s) : Zhaohui (Jeffrey) Zhang, Jeff Tantsura > > > > > > Area Director(s) : Jim Guichard, John Scudder, Gunter Van de Velde > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
