Hi Authors, Xufeng - Thank you for your reply! We have added your approval to the AUTH48 status page (see https://www.rfc-editor.org/auth48/rfc9719).
All - We have received all necessary approvals and consider AUTH48 complete. Thank you for your time and attention during the AUTH48 process! We will move forward with publication shortly. Best, RFC Editor/mc > On Mar 23, 2025, at 10:19 AM, Xufeng Liu <xufeng.liu.i...@gmail.com> wrote: > > Hi Madison, > > Thanks for the update. It looks good to me. I'd like to approve this document. > > I appreciate your efforts, help, and support. > Best, > - Xufeng > > On Fri, Mar 21, 2025 at 11:16 AM Madison Church > <mchu...@staff.rfc-editor.org> wrote: > Hi Xufeng, > > Thank you for your reply (and thank you for your patience throughout this > process). We have updated your affiliation to "Individual". Please review the > document (specifically the document header and Authors’ Addresses section) > and let us know if you approve this document for publication. Once we hear > back from you, we will move this document forward in the publication process. > > Updated files: > https://www.rfc-editor.org/authors/rfc9719.txt > https://www.rfc-editor.org/authors/rfc9719.pdf > https://www.rfc-editor.org/authors/rfc9719.html > https://www.rfc-editor.org/authors/rfc9719.xml > > Diff files: > https://www.rfc-editor.org/authors/rfc9719-diff.html > https://www.rfc-editor.org/authors/rfc9719-rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9719-auth48diff.html > https://www.rfc-editor.org/authors/rfc9719-auth48rfcdiff.html (side by > side) > > AUTH48 status page: > https://www.rfc-editor.org/auth48/rfc9719 > > Thank you! > RFC Editor/mc > > > On Mar 19, 2025, at 1:30 PM, Xufeng Liu <xufeng.liu.i...@gmail.com> wrote: > > > > Hi Madison, > > > > I have checked my company after receiving Jim's email. They have accepted > > what Jim suggested. So, can you please list me with no affiliation? Doing > > so allows us to avoid these company statements. > > > > Thanks, > > - Xufeng > > > > On Mon, Mar 17, 2025 at 9:14 PM Xufeng Liu <xufeng.liu.i...@gmail.com> > > wrote: > > Hi Madison, > > > > Thanks for your email. Yes, I have read James' email, so I'm checking again > > with the company. > > Thanks, > > - Xufeng > > > > On Thu, Mar 13, 2025 at 1:19 PM Madison Church > > <mchu...@staff.rfc-editor.org> wrote: > > Hi Xufeng, > > > > We have updated your affiliation to "The MITRE Corporation" as requested. > > Please also see mail sent from James Guichard (Responsible AD for RFC 9719) > > on March 4th. We will await your response before moving forward. > > > > Thank you, > > RFC Editor/mc > > > > > On Mar 4, 2025, at 11:12 AM, James Guichard > > > <james.n.guich...@futurewei.com> wrote: > > > > > > Hi all, > > > As the responsible AD for this WG I am not comfortable with this > > > solution for a variety of reasons. I would prefer that the author be > > > listed with no affiliation. Is this acceptable Xufeng? > > > Jim > > > From: Xufeng Liu <xufeng.liu.i...@gmail.com> > > > Date: Tuesday, March 4, 2025 at 11:31 AM > > > To: Madison Church <mchu...@staff.rfc-editor.org> > > > Cc: ShaoWen Ma <mashao...@gmail.com>, ext-zhang.zh...@zte.com.cn > > > <zhang.zh...@zte.com.cn>, Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>, > > > Bruno Rijsman <brunorijs...@gmail.com>, wei.yue...@zte.com.cn > > > <wei.yue...@zte.com.cn>, Jordan Head <jh...@juniper.net>, RFC Editor > > > <rfc-edi...@rfc-editor.org>, rift-...@ietf.org <rift-...@ietf.org>, > > > rift-cha...@ietf.org <rift-cha...@ietf.org>, James Guichard > > > <james.n.guich...@futurewei.com>, auth48archive@rfc-ed > > > <auth48archive@rfc-editor.org> > > > Subject: Re: AUTH48: RFC-to-be 9719 <draft-ietf-rift-yang-17> for your > > > review > > > Hi Madison, > > > My affiliated company is ok with the document now, but requests to add > > > the following statement in the Acknowledgement section: > > > > > > OLD: > > > 6. Acknowledgement > > > The authors would like to thank Tony Przygienda, Jordan Head, Benchong Xu > > > (xu.bench...@zte.com.cn), Tom Petch for their review, valuable comments > > > and suggestions. > > > > > > NEW: > > > 6. Acknowledgement > > > The authors would like to thank Tony Przygienda, Jordan Head, Benchong Xu > > > (xu.bench...@zte.com.cn), Tom Petch for their review, valuable comments > > > and suggestions. > > > > > > Author affiliation with The MITRE Corporation is provided for > > > identification purposes only and is not intended to convey or imply > > > MITRE's concurrence with, or support for, the positions, opinions, or > > > viewpoints expressed by the author. (c)2025 The MITRE Corporation. All > > > Rights Reserved. MITRE has approved this document for Public Release, > > > Distribution Unlimited, with Public Release Case Number 25-0633. > > > END > > > Also, can you please update my affiliation as follows? > > > The MITRE Corporation > > > > > > Sorry for holding this for so long, and thanks a lot, > > > - Xufeng > > > On Sun, Mar 2, 2025 at 11:21 AM Xufeng Liu <xufeng.liu.i...@gmail.com> > > > wrote: > > > Hi Madison, > > > > > > Thanks for the update. I think that I am getting closer. > > > Thanks, > > > - Xufeng > > > On Fri, Feb 28, 2025 at 9:58 AM Madison Church > > > <mchu...@staff.rfc-editor.org> wrote: > > > Hi Shaowen and *Xufeng, > > > > > > Shaowen - Thank you for your reply! We have noted your approval on the > > > AUTH48 status page for this document [1]. > > > > > > *Xufeng - If more time is needed on your end for approval or if there are > > > any additional updates/changes regarding your situation, please let us > > > know. Also note that RFC-to-be-9692 (a normative reference for this > > > document in Cluster 513) is still in AUTH48 [2], which will allow for > > > more time to obtain your approval if needed. Once we receive your > > > approval and RFC-to-be-9692 completes AUTH48, we will move this document > > > forward in the publication process. > > > > > > [1] https://www.rfc-editor.org/auth48/rfc9719 > > > [2] https://www.rfc-editor.org/auth48/C513 > > > > > > Thank you! > > > RFC Editor/mc > > > > > > > On Feb 27, 2025, at 10:18 PM, ShaoWen Ma <mashao...@gmail.com> wrote: > > > > > > > > Hi All, > > > > > > > > I approve the publication as one of the co-authors. > > > > > > > > Best Regards > > > > Shaowen Ma > > > > > > > > On Wed, Feb 19, 2025 at 6:50 AM Madison Church > > > > <mchu...@staff.rfc-editor.org> wrote: > > > > Hi Xufeng and Sandy, > > > > > > > > Thank you both for the updates! We will make note of the situation and > > > > wait to hear back from you. > > > > > > > > Thank you! > > > > RFC Editor/mc > > > > > > > > > On Feb 16, 2025, at 8:10 PM, <zhang.zh...@zte.com.cn> > > > > > <zhang.zh...@zte.com.cn> wrote: > > > > > > > > > > Hi Jeffrey, Xufeng, Madison and Shaowen, > > > > > I sent a message to Shaowen before and he is waiting for the > > > > > company's approval. Seems like it also take a long time for his > > > > > company to approve. > > > > > So maybe we can wait a little longer. > > > > > Best regards, > > > > > Sandy > > > > > > > > > > > > > > > Original > > > > > From: XufengLiu <xufeng.liu.i...@gmail.com> > > > > > To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; > > > > > Cc: Madison Church <mchu...@staff.rfc-editor.org>;Bruno Rijsman > > > > > <brunorijs...@gmail.com>;魏月华00019655;张征00007940;mashao...@gmail.com > > > > > <mashao...@gmail.com>;RFC Editor > > > > > <rfc-edi...@rfc-editor.org>;rift-...@ietf.org > > > > > <rift-...@ietf.org>;rift-cha...@ietf.org > > > > > <rift-cha...@ietf.org>;Jordan Head <jh...@juniper.net>;James Guichard > > > > > <james.n.guich...@futurewei.com>;auth48archive@rfc-ed > > > > > <auth48archive@rfc-editor.org>; > > > > > Date: 2025年02月16日 22:57 > > > > > Subject: Re: AUTH48: RFC-to-be 9719 <draft-ietf-rift-yang-17> for > > > > > your reviewHi Jeffrey, Sandy, and Madison, > > > > > > > > > > Thanks for all the suggestions. My issue is mostly the timing and the > > > > > slow process on my side. If we have some more time, I may be able to > > > > > do any of these. At this moment, I still don't have the result. To > > > > > unblock the publication immediately, the safest way is simply to > > > > > remove. As Madison mentioned, if we are still waiting for Shaowen, I > > > > > may have more time. I'll give the update. > > > > > > > > > > Thanks, > > > > > - Xufeng > > > > > > > > > > On Wed, Feb 5, 2025 at 10:52 PM Jeffrey (Zhaohui) Zhang > > > > > <zzh...@juniper.net> wrote: > > > > > Hi Xufeng, > > > > > > > > > > Is it that your current employer does not want an affiliation with > > > > > this (or any) IETF documents? > > > > > One solution could be that you're listed as an individual co-author > > > > > (no company affiliation). > > > > > > > > > > Jeffrey > > > > > > > > > > > > > > > Juniper Business Use Only > > > > > -----Original Message----- > > > > > From: Madison Church <mchu...@staff.rfc-editor.org> > > > > > Sent: Wednesday, February 5, 2025 2:46 PM > > > > > To: Xufeng Liu <xufeng.liu.i...@gmail.com>; Bruno Rijsman > > > > > <brunorijs...@gmail.com>; wei.yue...@zte.com.cn; > > > > > ext-zhang.zh...@zte.com.cn > > > > > <zhang.zh...@zte.com.cn>;mashao...@gmail.com > > > > > Cc: RFC Editor <rfc-edi...@rfc-editor.org>; rift-...@ietf.org; > > > > > rift-cha...@ietf.org; Jordan Head <jh...@juniper.net>; James Guichard > > > > > <james.n.guich...@futurewei.com>; auth48archive@rfc-ed > > > > > <auth48archive@rfc-editor.org> > > > > > Subject: Re: AUTH48: RFC-to-be 9719 <draft-ietf-rift-yang-17> for > > > > > your review > > > > > > > > > > [External Email. Be cautious of content] > > > > > > > > > > > > > > > Hi Xufeng, > > > > > > > > > > Thank you for informing us of the situation. If removing your name as > > > > > an author is needed, would you like to be listed as a contributor (it > > > > > would mean adding a Contributors section) or mentioned in the > > > > > Acknowledgements section? > > > > > > > > > > Please note that we are currently waiting on approval from Shaowen Ma > > > > > as well. We can check in with you to see how the process is going > > > > > once we hear from Shaowen. > > > > > > > > > > Thank you, > > > > > RFC Editor/mc > > > > > > > > > > > On Feb 4, 2025, at 7:51 PM, Xufeng Liu <xufeng.liu.i...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > Hi Madison, > > > > > > > > > > > > Sorry for the delay. I recently changed my employment, and the new > > > > > > employer has different policies. I am still trying to go through > > > > > > the process, but it is slow. To unblock the publication process, > > > > > > I'd like to remove myself from the author list. Sorry for the > > > > > > inconvenience. > > > > > > > > > > > > Thanks, > > > > > > - Xufeng > > > > > > > > > > > > On Tue, Jan 28, 2025 at 10:29 AM Madison Church > > > > > > <mchu...@staff.rfc-editor.org> wrote: > > > > > > Hi Shaowen and Xufeng, > > > > > > > > > > > > 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://urldefense.com/v3/__http://www.rfc-editor.org/auth48/rfc9719__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vpma7-KiRG71YH5mVZ6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5vLI3PIEg$ > > > > > > ) for further information and the previous messages in this thread. > > > > > > > > > > > > Thank you, > > > > > > RFC Editor/mc > > > > > > > > > > > > > On Jan 21, 2025, at 11:44 AM, Madison Church > > > > > > > <mchu...@staff.rfc-editor.org> wrote: > > > > > > > > > > > > > > Hi Yuehua and Bruno, > > > > > > > > > > > > > > Thank you both for your replies. We have noted your approval and > > > > > > > incorporated our edits into the updated files below per Bruno’s > > > > > > > guidance. In addition to our updates, note that we also added > > > > > > > <em> tags to italicize term "ThreeWay" for consistency with RFCs > > > > > > > 9692 and 9696. > > > > > > > > > > > > > > The updated files have been posted here (please refresh): > > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9719.txt__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vpma7-KiRG71YH5mVZ6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5sG1irukA$ > > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9719.pdf__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vpma7-KiRG71YH5mVZ6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5vX_l0l4g$ > > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9719.html__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vpma7-KiRG71YH5mVZ6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5tGe1X-Ng$ > > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 > > > > > > > 19.xml__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vpma7-KiRG71YH5mV > > > > > > > Z6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5shGew8YA$ > > > > > > > > > > > > > > The updated diffs have been posted here: > > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9719-diff.html__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vpma7-KiRG71YH5mVZ6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5vJjrFaUQ$ > > > > > > > (comprehensive diff) > > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9719-rfcdiff.html__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vpma7-KiRG71YH5mVZ6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5sX8aD9tA$ > > > > > > > (side by side) > > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9719-auth48diff.html__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vpma7-KiRG71YH5mVZ6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5u_hrHeog$ > > > > > > > (AUTH48 changes only) > > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 > > > > > > > 19-auth48rfcdiff.html__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vp > > > > > > > ma7-KiRG71YH5mVZ6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5ulV7CH4g$ > > > > > > > (side > > > > > > > by side) > > > > > > > > > > > > > > The details of the AUTH48 status of your document are here: > > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc971 > > > > > > > 9__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vpma7-KiRG71YH5mVZ6sp5 > > > > > > > c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5u8aKH7yQ$ > > > > > > > > > > > > > > Once we receive approvals from Shaowen and Xufeng, we will move > > > > > > > this document forward in the publication process. > > > > > > > > > > > > > > Thank you! > > > > > > > RFC Editor/mc > > > > > > > > > > > > > >> On Jan 16, 2025, at 11:04 PM, Bruno Rijsman > > > > > > >> <brunorijs...@gmail.com> wrote: > > > > > > >> > > > > > > >> Dear RFC editors, > > > > > > >> > > > > > > >> Thank you very much for your careful review and final edits. > > > > > > >> > > > > > > >> I have carefully reviewed all the changes in the diff, and I > > > > > > >> agree with them. > > > > > > >> > > > > > > >> I also agree with your suggested changes to fix the comments in > > > > > > >> items #1 through #11 below, and I have read the style guide > > > > > > >> mentioned in #12. > > > > > > >> > > > > > > >> I approve this RFC for publication. > > > > > > >> > > > > > > >> Also my sincere thanks to the co-authors for their work on this > > > > > > >> document. > > > > > > >> > > > > > > >> — Bruno Rijsman > > > > > > >> > > > > > > >>> On Jan 16, 2025, at 3:14 AM, rfc-editor@rfc-editor.orgwrote: > > > > > > >>> > > > > > > >>> Authors, > > > > > > >>> > > > > > > >>> While reviewing this document during AUTH48, please resolve (as > > > > > > >>> necessary) the following questions, which are also in the XML > > > > > > >>> file. > > > > > > >>> > > > > > > >>> 1) <!-- [rfced] We have updated the abbreviated title (which > > > > > > >>> appears in the running header of the PDF) as follows. Please > > > > > > >>> let us know if you prefer otherwise. > > > > > > >>> > > > > > > >>> Original: > > > > > > >>> RIFT YANG Model > > > > > > >>> > > > > > > >>> Current: > > > > > > >>> RIFT YANG Data Model > > > > > > >>> --> > > > > > > >>> > > > > > > >>> > > > > > > >>> 2) <!-- [rfced] The Terminology section (Section 3.1) states > > > > > > >>> that > > > > > > >>> terms and their definitions are copied from RFC 9692. However, > > > > > > >>> we > > > > > > >>> note that definitions in this section contain a mix of sentences > > > > > > >>> directly from RFC 9692, paraphrased sentences from RFC 9692, as > > > > > > >>> well as mirrored definitions missing words throughout. If there > > > > > > >>> are no objections, we will revise the Terminology section in > > > > > > >>> this > > > > > > >>> document to accurately reflect the definitions that appear in > > > > > > >>> RFC 9692. Please let us know any concerns. > > > > > > >>> > > > > > > >>> For example: > > > > > > >>> > > > > > > >>> "TIE" in RFC 9692 (Original): > > > > > > >>> This is an acronym for a "Topology Information Element". TIEs > > > > > > >>> are > > > > > > >>> exchanged between RIFT nodes to describe parts of a network such > > > > > > >>> as links and address prefixes. A TIE has always a direction and > > > > > > >>> a > > > > > > >>> type. North TIEs (sometimes abbreviated as N-TIEs) are used when > > > > > > >>> dealing with TIEs in the northbound representation and > > > > > > >>> South-TIEs > > > > > > >>> (sometimes abbreviated as S-TIEs) for the southbound > > > > > > >>> equivalent. TIEs have different types such as node and prefix > > > > > > >>> TIEs. > > > > > > >>> > > > > > > >>> "TIE" in this document (Original): > > > > > > >>> "Topology Information Element" are exchanged between RIFT nodes > > > > > > >>> to > > > > > > >>> describe parts of a network such as links and address prefixes. > > > > > > >>> A > > > > > > >>> TIE has always a direction and a type. North TIEs (sometimes > > > > > > >>> abbreviated as N-TIEs) are used when dealing with TIEs in the > > > > > > >>> northbound representation and South-TIEs (sometimes abbreviated > > > > > > >>> as > > > > > > >>> S-TIEs) for the southbound equivalent. TIEs have different > > > > > > >>> types such as node and prefix TIEs. > > > > > > >>> --> > > > > > > >>> > > > > > > >>> > > > > > > >>> 3) <!--[rfced] We note that the following paragraph appears in > > > > > > >>> Sections 2.1 and 2.3. To avoid repetition, may we remove the > > > > > > >>> duplicate text from one section or the other? > > > > > > >>> > > > > > > >>> Original (Sections 2.1 and 2.3): > > > > > > >>> The RIFT YANG module augments the > > > > > > >>> /routing/control-plane-protocols/ control-plane-protocol path > > > > > > >>> defined in the ietf-routing module. This model augments the > > > > > > >>> routing module to add RIFT as a control plane protocol. It then > > > > > > >>> offers the ability to create a list of instances, which it does > > > > > > >>> by > > > > > > >>> declaring 'list rift'. Multiple instances of the protocol are > > > > > > >>> supported by the module by giving each instance a unique name. > > > > > > >>> --> > > > > > > >>> > > > > > > >>> > > > > > > >>> 4) <!--[rfced] FYI, we corrected 'sourth' to 'south' (3 > > > > > > >>> instances). > > > > > > >>> > > > > > > >>> From the original: > > > > > > >>> 465: | | +-ro total-num-routes-sourth? > > > > > > >>> 2418: leaf total-num-routes-sourth { > > > > > > >>> 2422: "The total number of sourth routes."; > > > > > > >>> --> > > > > > > >>> > > > > > > >>> > > > > > > >>> 5) <!-- [rfced] We note that Section 6.3.9 of RFC 9692 is titled > > > > > > >>> "Northbound TIE Flooding Reduction". May we rephrase as follows? > > > > > > >>> > > > > > > >>> Original: > > > > > > >>> Some features can be used to enhance protocol, such as BFD > > > > > > >>> [RFC5881], flooding-reducing section 6.3.9 [I-D.ietf-rift-rift]. > > > > > > >>> > > > > > > >>> Perhaps: > > > > > > >>> Some features can be used to enhance protocols, such as BFD > > > > > > >>> [RFC5881], with flooding reduction (Section 6.3.9 of [RFC9692]). > > > > > > >>> --> > > > > > > >>> > > > > > > >>> > > > > > > >>> 6) <!--[rfced] May we rephrase this sentence as follows for > > > > > > >>> clarity? > > > > > > >>> > > > > > > >>> Original: > > > > > > >>> Unexpected TIE and neighbor's layer error should be notified. > > > > > > >>> > > > > > > >>> Perhaps: > > > > > > >>> Unexpected TIE and neighbor layer errors should be notified. > > > > > > >>> --> > > > > > > >>> > > > > > > >>> > > > > > > >>> 7) <!--[rfced] We have received guidance from Benoit Claise and > > > > > > >>> the YANG Doctors that "YANG module" and "YANG data model" are > > > > > > >>> preferred. > > > > > > >>> We have updated the title of Section 3 accordingly. Please > > > > > > >>> review > > > > > > >>> usage of "YANG model" within this document. > > > > > > >>> --> > > > > > > >>> > > > > > > >>> > > > > > > >>> 8) <!--[rfced] In the YANG module, please clarify "system id > > > > > > >>> using pattern" > > > > > > >>> in the description of system-id. (In text as "System ID" to > > > > > > >>> match > > > > > > >>> RFC-to-be 9692.) > > > > > > >>> > > > > > > >>> Original: > > > > > > >>> description > > > > > > >>> "This type defines RIFT system id using pattern, > > > > > > >>> the system id looks like: 0021.2FFF.FEB5.6E10"; > > > > > > >>> > > > > > > >>> Perhaps: > > > > > > >>> description > > > > > > >>> "This type defines the pattern for RIFT System IDs. > > > > > > >>> An example of a System ID is 0021.2FFF.FEB5.6E10."; > > > > > > >>> --> > > > > > > >>> > > > > > > >>> > > > > > > >>> 9) <!--[rfced] Please note that the YANG module has been updated > > > > > > >>> per the formatting option of pyang. Please let us know any > > > > > > >>> concerns. > > > > > > >>> --> > > > > > > >>> > > > > > > >>> > > > > > > >>> 10) <!--[rfced] Section 4. The text has been updated to exactly > > > > > > >>> match the template for YANG module security considerations > > > > > > >>> (https://urldefense.com/v3/__https://wiki.ietf.org/group/ops/yang-security-guidelines__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vpma7-KiRG71YH5mVZ6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5v8aiXi-w$ > > > > > > >>> ). Please review. > > > > > > >>> If additional changes are needed, please let us know. > > > > > > >>> Specifically, the following text was updated. > > > > > > >>> > > > > > > >>> Original (paragraph 3): > > > > > > >>> Writable data node represent configuration of each instance, > > > > > > >>> node, > > > > > > >>> interface, etc. These correspond to the following schema node: > > > > > > >>> > > > > > > >>> Current: > > > > > > >>> These are the subtrees and data nodes and their sensitivity/ > > > > > > >>> vulnerability: > > > > > > >>> > > > > > > >>> However, should it be updated to singular because one item is > > > > > > >>> listed? > > > > > > >>> Perhaps: > > > > > > >>> This is the schema node and its sensitivity/vulnerability: > > > > > > >>> > > > > > > >>> > > > > > > >>> Original (paragraph 11): > > > > > > >>> Specifically, the > > > > > > >>> following operations have particular sensitivities/ > > > > > > >>> vulnerabilities: > > > > > > >>> > > > > > > >>> Current: > > > > > > >>> These are the subtrees and data nodes and their sensitivity/ > > > > > > >>> vulnerability: > > > > > > >>> --> > > > > > > >>> > > > > > > >>> > > > > > > >>> 11) <!--[rfced] Please clarify this sentence; the original does > > > > > > >>> not parse. > > > > > > >>> > > > > > > >>> Original: > > > > > > >>> The incorrect modification of authentication, except for the > > > > > > >>> neighbor connection broken, will lead to the permanent > > > > > > >>> connection > > > > > > >>> broken. > > > > > > >>> > > > > > > >>> Perhaps: > > > > > > >>> The incorrect modification of authentication, except for the > > > > > > >>> broken neighbor connection, will break the connection > > > > > > >>> permanently. > > > > > > >>> --> > > > > > > >>> > > > > > > >>> > > > > > > >>> 12) <!-- [rfced] Please review the "Inclusive Language" portion > > > > > > >>> of > > > > > > >>> the online Style Guide > > > > > > >>> <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide > > > > > > >>> /part2/*inclusive_language__;Iw!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZ > > > > > > >>> dGaw_s3Vpma7-KiRG71YH5mVZ6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5vIPOf > > > > > > >>> lCg$ > and let us know if any changes are needed. Updates of > > > > > > >>> this > > > > > > >>> nature typically result in more precise language, which is > > > > > > >>> helpful > > > > > > >>> for readers. Note that our script did not flag any words in > > > > > > >>> particular, but this should still be reviewed as a best > > > > > > >>> practice. > > > > > > >>> --> > > > > > > >>> > > > > > > >>> > > > > > > >>> Thank you. > > > > > > >>> > > > > > > >>> RFC Editor/mc/ar > > > > > > >>> > > > > > > >>> > > > > > > >>> On Jan 15, 2025, rfc-edi...@rfc-editor.org wrote: > > > > > > >>> > > > > > > >>> *****IMPORTANT***** > > > > > > >>> > > > > > > >>> Updated 2025/01/15 > > > > > > >>> > > > > > > >>> 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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vpma7-KiRG71YH5mVZ6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5uo5Yt7oA$ > > > > > > >>> ). > > > > > > >>> > > > > > > >>> 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://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vpma7-KiRG71YH5mVZ6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5u3x1YHMw$ > > > > > > >>> ). > > > > > > >>> > > > > > > >>> * 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://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vpma7-KiRG71YH5mVZ6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5v5AixMsQ$ > > > > > > >>> >. > > > > > > >>> > > > > > > >>> * 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ > > > > > > >>> ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-gk!BYLSY0QM > > > > > > >>> aMmHmCqNoQkWZdGaw_s3Vpma7-KiRG71YH5mVZ6sp5c4hCkv6hmHhC0CwPshI2iOMw > > > > > > >>> l9gFgmP5t2stZVIQ$ > > > > > > >>> > > > > > > >>> * The archive itself: > > > > > > >>> > > > > > > >>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/brow > > > > > > >>> se/auth48archive/__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vpma > > > > > > >>> 7-KiRG71YH5mVZ6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5sa9xeU7A$ > > > > > > >>> > > > > > > >>> * 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc > > > > > > >>> 9719.xml__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vpma7-KiRG71Y > > > > > > >>> H5mVZ6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5shGew8YA$ > > > > > > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc > > > > > > >>> 9719.html__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vpma7-KiRG71 > > > > > > >>> YH5mVZ6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5tGe1X-Ng$ > > > > > > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc > > > > > > >>> 9719.pdf__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vpma7-KiRG71Y > > > > > > >>> H5mVZ6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5vX_l0l4g$ > > > > > > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc > > > > > > >>> 9719.txt__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vpma7-KiRG71Y > > > > > > >>> H5mVZ6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5sG1irukA$ > > > > > > >>> > > > > > > >>> Diff file of the text: > > > > > > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc > > > > > > >>> 9719-diff.html__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vpma7-K > > > > > > >>> iRG71YH5mVZ6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5vJjrFaUQ$ > > > > > > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc > > > > > > >>> 9719-rfcdiff.html__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vpma > > > > > > >>> 7-KiRG71YH5mVZ6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5sX8aD9tA$ > > > > > > >>> (side > > > > > > >>> by side) > > > > > > >>> > > > > > > >>> Diff of the XML: > > > > > > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc > > > > > > >>> 9719-xmldiff1.html__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vpm > > > > > > >>> a7-KiRG71YH5mVZ6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5v9WZhdQA$ > > > > > > >>> > > > > > > >>> > > > > > > >>> Tracking progress > > > > > > >>> ----------------- > > > > > > >>> > > > > > > >>> The details of the AUTH48 status of your document are here: > > > > > > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9 > > > > > > >>> 719__;!!NEt6yMaO-gk!BYLSY0QMaMmHmCqNoQkWZdGaw_s3Vpma7-KiRG71YH5mVZ > > > > > > >>> 6sp5c4hCkv6hmHhC0CwPshI2iOMwl9gFgmP5u8aKH7yQ$ > > > > > > >>> > > > > > > >>> Please let us know if you have any questions. > > > > > > >>> > > > > > > >>> Thank you for your cooperation, > > > > > > >>> > > > > > > >>> RFC Editor > > > > > > >>> > > > > > > >>> -------------------------------------- > > > > > > >>> RFC9719 (draft-ietf-rift-yang-17) > > > > > > >>> > > > > > > >>> Title : YANG Data Model for Routing in Fat Trees > > > > > > >>> (RIFT) > > > > > > >>> Author(s) : Z. Zhang, Y. Wei, S. Ma, X. Liu, B. Rijsman > > > > > > >>> 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
