Hi Dmitry and Tony, This is a 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. Thank you, RFC Editor/mc > On Jan 21, 2025, at 9:16 AM, Madison Church <mchu...@staff.rfc-editor.org> > wrote: > > 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
