Hi Authors, This is a friendly reminder that we have yet to hear back from some of you regarding this document’s readiness for publication. We await approvals from Dmitry, Pascal, and Tony.
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 20, 2024, at 10:12 AM, Madison Church <mchu...@amsl.com> wrote: > > 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
