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-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

Reply via email to