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
