Hi Shaowen and Xufeng, Shaowen - This is a friendly reminder that we have yet to hear back from you regarding this document’s readiness for publication. Please review the previous messages in this thread for details.
Xufeng - Feel free to let us know if either suggestion (being listed as a contributor or an independent co-author) is acceptable regarding your affiliation as an author for this document. The updated files have been posted here (please refresh): 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 The updated diffs have been posted here: https://www.rfc-editor.org/authors/rfc9719-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9719-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9719-auth48diff.html (AUTH48 changes only) https://www.rfc-editor.org/authors/rfc9719-auth48rfcdiff.html (side by side) The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9719 Once we receive all approvals listed on the AUTH48 status page, we will move this document forward in the publication process. Thank you! RFC Editor/mc > On Feb 5, 2025, at 9: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-edi...@rfc-editor.org wrote: >>>>> >>>>> 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
