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

Reply via email to