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 ( > http://www.rfc-editor.org/auth48/rfc9719) 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://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 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://wiki.ietf.org/group/ops/yang-security-guidelines). 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://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. 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://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/rfc9719.xml > >>> https://www.rfc-editor.org/authors/rfc9719.html > >>> https://www.rfc-editor.org/authors/rfc9719.pdf > >>> https://www.rfc-editor.org/authors/rfc9719.txt > >>> > >>> Diff file of the text: > >>> https://www.rfc-editor.org/authors/rfc9719-diff.html > >>> https://www.rfc-editor.org/authors/rfc9719-rfcdiff.html (side by side) > >>> > >>> Diff of the XML: > >>> https://www.rfc-editor.org/authors/rfc9719-xmldiff1.html > >>> > >>> > >>> Tracking progress > >>> ----------------- > >>> > >>> The details of the AUTH48 status of your document are here: > >>> https://www.rfc-editor.org/auth48/rfc9719 > >>> > >>> 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
