Hi Dmitry and Tony, This is a friendly reminder that we have yet to hear back from you regarding this document’s readiness for publication.
Please review the AUTH48 status page (https://www.rfc-editor.org/auth48/rfc9696) for further information and the previous messages in this thread for pertinent communication. Thank you, RFC Editor/mc > On Jan 13, 2025, at 11:12 AM, Pascal Thubert <pascal.thub...@gmail.com> wrote: > > Dear editor > > I’m no more with Cisco. Would you mind updating the author information to > echo what is done in rfc to be 9692 (rift)? > > Many thanks ! > > >> Le 13 janv. 2025 à 16:58, Madison Church <mchu...@staff.rfc-editor.org> a >> écrit : >> >> Hi *Pascal and Yuehua, >> >> Thank you both for your replies! We have updated the document as requested >> and updated files have been posted below. We now await approvals from Dmitry >> and Tony. >> >> *Pascal - We were notified that your email address has changed. Would you >> like for us to update the Authors’ Addresses section with your current email >> address (pascal.thub...@gmail.com)? If yes, please review your contact >> information in the updated files and let us know if any additional changes >> are needed. >> >> 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 (AUTH48 changes >> only) >> >> For the AUTH48 status of this document, please see: >> https://www.rfc-editor.org/auth48/rfc9696 >> >> Thank you, >> RFC Editor/mc >> >>> On Jan 13, 2025, at 4:23 AM, <wei.yue...@zte.com.cn> >>> <wei.yue...@zte.com.cn> wrote: >>> >>> Hi Pascal, >>> Yes, you are right. >>> >>> >>> Best Regards, >>> 魏月华 Yuehua Wei >>> 承载网标准预研-总工/Chief Engineer of Bearer Network Standards Development >>> 标准团队/有线规划部/有线产品经营部/Standardization Team/Wireline Product Planning >>> Dept/Wireline Product Operation >>> ZTE Corporation南京市软件大道50号/No.50, Software Avenue, Nanjing, 210012, P. R. >>> China >>> M: +86 13851460269 E: wei.yue...@zte.com.cn >>> >>> >>> Original >>> From: PascalThubert <pascal.thub...@gmail.com> >>> To: 魏月华00019655; >>> Cc: mchu...@staff.rfc-editor.org >>> <mchu...@staff.rfc-editor.org>;张征00007940;f...@yandex-team.ru >>> <f...@yandex-team.ru>;pthub...@cisco.com >>> <pthub...@cisco.com>;p...@juniper.net >>> <p...@juniper.net>;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: 2025年01月13日 17:00 >>> Subject: Re: AUTH48: RFC-to-be 9696 <draft-ietf-rift-applicability-17> for >>> your reviewHello Yuehua >>> >>> you're right they will know through both. Meaning that “via both Leaf121 >>> and Leaf 122”is probably what you want? >>> >>> all the best, >>> >>> Pascal >>> >>> Le lun. 13 janv. 2025 à 07:57, <wei.yue...@zte.com.cn> a écrit : >>> Hi Pascal, >>> Do you mean I should add “via Leaf121 or Leaf 122” to this paragraph: >>> Original: >>> "As shown in Figure 4, as the result of the south reflection, Spine121 and >>> Spine 122 know each other at level 1." >>> New： >>> "As shown in Figure 4, as the result of the south reflection, Spine121 and >>> Spine 122 know each other via Leaf121 or Leaf 122 at level 1." >>> >>> Thank you！ >>> Best Regards, >>> Yuehua Wei >>> M: +86 13851460269 E: wei.yue...@zte.com.cn >>> >>> >>> Original >>> From: PascalThubert <pascal.thub...@gmail.com> >>> To: 魏月华00019655; >>> Cc: mchu...@staff.rfc-editor.org >>> <mchu...@staff.rfc-editor.org>;张征00007940;f...@yandex-team.ru >>> <f...@yandex-team.ru>;pthub...@cisco.com >>> <pthub...@cisco.com>;p...@juniper.net >>> <p...@juniper.net>;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: 2025年01月12日 22:58 >>> Subject: Re: AUTH48: RFC-to-be 9696 <draft-ietf-rift-applicability-17> for >>> your review >>> Dear editor >>> I reviewed the changes and I approve the publication. >>> Nit: in the change under fig 4, I'd add "via leaf 122" to clarify how the >>> reflection happens. >>> Many thanks >>> Pascal >>> >>> Le dim. 12 janv. 2025, 07:01, <wei.yue...@zte.com.cn> a écrit : >>> Hi Madison and Pascal, >>> Pascal's email changed, so I forward this email to pascal.thub...@gmail.com. >>> Thank you! >>> >>> Best Regards, >>> Yuehua Wei >>> M: +86 13851460269 E: wei.yue...@zte.com.cn >>> Original >>> From: MadisonChurch <mchu...@staff.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 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>;Madison Church >>> <mchu...@staff.rfc-editor.org>; >>> Date: 2025年01月10日 03:58 >>> Subject: Re: AUTH48: RFC-to-be 9696 <draft-ietf-rift-applicability-17> for >>> your review Hi Dmitry, Pascal, and Tony, >>> >>> [Note that this email is coming to you from a new email address on our end.] >>> >>> This is another friendly reminder that we have yet to hear back from of you >>> regarding this document’s readiness for publication. >>> >>> 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 Jan 2, 2025, at 9:03 AM, Madison Church <mchu...@amsl.com> wrote: >>>> >>>> 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
