Re: [auth48] [IANA #1288525] [IANA] Re: AUTH48: RFC-to-be 9403 <draft-ietf-rtgwg-yang-rib-extend-24> (was -22) for your review

[Lynne Bartholomew <[e-mail]>]

Hi, Amanda.  Great; thank you for the quick turnaround!

RFC Editor/lb

> On Nov 15, 2023, at 4:14 PM, Amanda Baber via RT <[e-mail]> wrote:
> 
> Hi all,
> 
> This change is complete:
> 
> https://www.iana.org/assignments/xml-registry/ns/yang/ietf-rib-extension.txt
> 
> Best regards,
> 
> Amanda Baber
> IANA Operations Manager
> 
> On Wed Nov 15 16:55:42 2023, [e-mail] wrote:
>> Dear IANA,
>> 
>> We are preparing this document for publication.
>> 
>> Please make the following update on
>> <https://www.iana.org/assignments/xml-registry/ns/yang/ietf-rib-
>> extension.txt>:
>> 
>> OLD:
>> XML: N/A, the requested URI is an XML namespace.
>> 
>> NEW (please change the comma to a semicolon, to fix the run-on
>> sentence):
>> XML: N/A; the requested URI is an XML namespace.
>> 
>> Thank you!
>> 
>> RFC Editor/lb
>> 
>> 
>>> On Nov 15, 2023, at 8:49 AM, Lynne Bartholomew
>>> <[e-mail]> wrote:
>>> 
>>> Hi, Yingzhen and Acee.
>>> 
>>> We have updated your contact information per your notes below.
>>> 
>>> The latest files are posted here.  Please refresh your browser:
>>> 
>>> https://www.rfc-editor.org/authors/rfc9403.txt
>>> https://www.rfc-editor.org/authors/rfc9403.pdf
>>> https://www.rfc-editor.org/authors/rfc9403.html
>>> https://www.rfc-editor.org/authors/rfc9403.xml
>>> https://www.rfc-editor.org/authors/rfc9403-diff.html
>>> https://www.rfc-editor.org/authors/rfc9403-rfcdiff.html
>>> https://www.rfc-editor.org/authors/rfc9403-auth48diff.html
>>> https://www.rfc-editor.org/authors/rfc9403-lastdiff.html
>>> https://www.rfc-editor.org/authors/rfc9403-lastrfcdiff.html
>>> 
>>> https://www.rfc-editor.org/authors/rfc9403-xmldiff1.html
>>> https://www.rfc-editor.org/authors/rfc9403-xmldiff2.html
>>> 
>>> Yingzhen, we have noted your approval on the AUTH48 status page:
>>> 
>>> https://www.rfc-editor.org/auth48/rfc9403
>>> 
>>> We will ask IANA to make a quick punctuation update and will then
>>> move this document forward for publication.
>>> 
>>> Thank you!
>>> 
>>> RFC Editor/lb
>>> 
>>> 
>>>> On Nov 14, 2023, at 1:12 PM, Yingzhen Qu <[e-mail]>
>>>> wrote:
>>>> 
>>>> Hi Lynne,
>>>> 
>>>> Please update my affiliation from "Futurewei" to "Futurewei
>>>> Technologies".
>>>> 
>>>> Thanks,
>>>> Yingzhen
>>> 
>>> 
>>>> On Nov 14, 2023, at 12:56 PM, Acee Lindem <[e-mail]>
>>>> wrote:
>>>> 
>>>> HI Lynne,
>>>> 
>>>> I agree with these changes as well. I noticed that my contact
>>>> information has “LabN Consulting LLC” rather than “LabN Consulting,
>>>> L.L.C.” can you update it to be consistent with other LabN
>>>> Consulting authors (e.g., RFC 9179 and RFC 8819).
>>>> 
>>>> Acee-Lindems-iMac-2:Downloads acee$ diff -c rfc9403.txt.orig
>>>> rfc9403.txt
>>>> *** rfc9403.txt.orig Tue Nov 14 15:51:14 2023
>>>> --- rfc9403.txt Tue Nov 14 15:52:02 2023
>>>> ***************
>>>> *** 3,9 ****
>>>> 
>>>> 
>>>> Internet Engineering Task Force (IETF)                         A.
>>>> Lindem
>>>> ! Request for Comments: 9403                           LabN
>>>> Consulting LLC
>>>> Category: Standards Track
>>>> Y. Qu
>>>> ISSN: 2070-1721
>>>> Futurewei
>>>>                                                           November
>>>> 2023
>>>> --- 3,9 ----
>>>> 
>>>> 
>>>> Internet Engineering Task Force (IETF)                         A.
>>>> Lindem
>>>> ! Request for Comments: 9403                       LabN Consulting,
>>>> L.L.C.
>>>> Category: Standards Track
>>>> Y. Qu
>>>> ISSN: 2070-1721
>>>> Futurewei
>>>>                                                           November
>>>> 2023
>>>> ***************
>>>> *** 1195,1201 ****
>>>> Authors' Addresses
>>>> 
>>>> Acee Lindem
>>>> !    LabN Consulting LLC
>>>> 301 Midenhall Way
>>>> Cary, NC 27513
>>>> United States of America
>>>> --- 1195,1201 ----
>>>> Authors' Addresses
>>>> 
>>>> Acee Lindem
>>>> !    LabN Consulting, L.L.C.
>>>> 301 Midenhall Way
>>>> Cary, NC 27513
>>>> United States of America
>>>> 
>>>> 
>>>> Thanks,
>>>> Acee
>>>> 
>>> 
>>>> On Nov 14, 2023, at 12:40 PM, Yingzhen Qu <[e-mail]>
>>>> wrote:
>>>> 
>>>> Hi Lynne,
>>>> 
>>>> The changes look good to me.
>>>> 
>>>> For the last paragraph in Section 1, I agree with your suggestion to
>>>> keep it as plural.
>>>> 
>>>> I approve this version of the draft.
>>>> 
>>>> Thanks,
>>>> Yingzhen
>>>> 
>>>> On Tue, Nov 14, 2023 at 10:51 AM Lynne Bartholomew
>>>> <[e-mail]> wrote:
>>>> Hi, Yingzhen.
>>>> 
>>>> We have made further updates to this document per your notes below.
>>>> 
>>>> Regarding your question about the plural "YANG modules" in the last
>>>> paragraph of Section 1, which says "The YANG modules defined and
>>>> discussed in this document":
>>>> 
>>>> If the "and discussed" here does not refer to the other YANG modules
>>>> mentioned in this document (e.g., we see "The YANG module defined in
>>>> this document augments the ietf-routing, ietf-ipv4-unicast-routing,
>>>> and ietf-ipv6-unicast-routing YANG modules defined in [RFC8349]" in
>>>> Section 3), then yes, it should be the singular "module".  Please
>>>> advise.
>>>> 
>>>> = = = = =
>>>> 
>>>> Regarding the inconsistent quoting of prefix entries:  Thank you for
>>>> spotting that!
>>>> 
>>>> We found that post-8916 YANG RFCs do not quote the prefix entries,
>>>> so we removed the quotes around "ospf" and "isis".
>>>> For example, RFC 9129 has
>>>>  prefix ospf;
>>>> and RFC 9130 has
>>>>  prefix isis;
>>>> 
>>>> The latest files are posted here.  Please refresh your browser:
>>>> 
>>>> https://www.rfc-editor.org/authors/rfc9403.txt
>>>> https://www.rfc-editor.org/authors/rfc9403.pdf
>>>> https://www.rfc-editor.org/authors/rfc9403.html
>>>> https://www.rfc-editor.org/authors/rfc9403.xml
>>>> https://www.rfc-editor.org/authors/rfc9403-diff.html
>>>> https://www.rfc-editor.org/authors/rfc9403-rfcdiff.html
>>>> https://www.rfc-editor.org/authors/rfc9403-auth48diff.html
>>>> https://www.rfc-editor.org/authors/rfc9403-lastdiff.html
>>>> https://www.rfc-editor.org/authors/rfc9403-lastrfcdiff.html
>>>> 
>>>> https://www.rfc-editor.org/authors/rfc9403-xmldiff1.html
>>>> https://www.rfc-editor.org/authors/rfc9403-xmldiff2.html
>>>> 
>>>> Thanks again for your help and your good catch!
>>>> 
>>>> RFC Editor/lb
>>>> 
>>>> 
>>>>> On Nov 13, 2023, at 12:11 PM, Yingzhen Qu <[e-mail]>
>>>>> wrote:
>>>>> 
>>>>> Hi Lynne,
>>>>> 
>>>>> There are a few more places that need changes.
>>>>> 
>>>>> In Appendix B (2 instances for each change):
>>>>> original:
>>>>> <route-preference>110</route-preference>
>>>>> <source-protocol xmlns:ospf="urn:ietf:params:xml:ns:yang:\
>>>>> ietf-ospf">ospf:ospf</source-protocol>
>>>>> 
>>>>> Change to:
>>>>> <route-preference>120</route-preference>
>>>>> <source-protocol xmlns:rip="urn:ietf:params:xml:ns:yang:\
>>>>> ietf-rip">rip:rip</source-protocol>
>>>>> Original:
>>>>> "route-preference": 110,
>>>>> "source-protocol": "ietf-ospf:ospf",
>>>>> Change to:
>>>>> "route-preference": 120,
>>>>> "source-protocol": "ietf-rip:rip",
>>>>> 
>>>>> 
>>>>> Please let me know if you have any questions.
>>>>> 
>>>>> 
>>>>> Thanks,
>>>>> Yingzhen
>>>>> 
>>>> 
>>>>> On Nov 12, 2023, at 2:01 PM, Yingzhen Qu <[e-mail]>
>>>>> wrote:
>>>>> 
>>>>> Hi Lynne,
>>>>> 
>>>>> Thank you for the changes.
>>>>> 
>>>>> I found the following nits that need to be fixed:
>>>>>    •
>>>>> This document includes only one module, so should the last
>>>>> paragraph in section 1 change to "The YANG module"?
>>>>>   • section 5 inside the module, when importing ietf-ospf and
>>>>> ietf-isis modules, the prefixes have " ", while the imports above
>>>>> don't.
>>>>>   • In grouping repair-path, the description of metric:
>>>>> 
>>>>> Current:
>>>>>             The metric for the repair path. While the IPFR
>>>>>             reroute repair is local and the metric is
>>>>> notSuggestion:
>>>>>           The metric for the repair path. While the
>>>>>           reroute repair is local and the metric is not
>>>>> 
>>>>> Thanks,
>>>>> Yingzhen
>>>>> 
>>>>> 
>>>>> On Thu, Nov 2, 2023 at 1:49 PM Lynne Bartholomew
>>>>> <[e-mail]> wrote:
>>>>> Hi, Acee, Yingzhen, and Jim.
>>>>> 
>>>>> Thank you for the emails.
>>>>> 
>>>>> Jim, we have noted your approval on the AUTH48 status page; thank
>>>>> you!
>>>>> 
>>>>> https://www.rfc-editor.org/auth48/rfc9403
>>>>> 
>>>>> Acee and Yingzhen, we have updated this document per your notes
>>>>> below.
>>>>> 
>>>>> Yingzhen, regarding your reply to our question 3):  Because there
>>>>> are four YANG modules in RFC 8349 and you specified three of them,
>>>>> we specified the three modules in the text as well, to eliminate
>>>>> any question regarding the fourth module in RFC 8349.  Please let
>>>>> us know any concerns.
>>>>> 
>>>>> = = = = =
>>>>> 
>>>>> We found that your replies to our question 5) differ somewhat.
>>>>> Please review the update to Section 3.1, Paragraph 2, and let us
>>>>> know any concerns.
>>>>> 
>>>>> = = = = =
>>>>> 
>>>>> Regarding your replies to our question 7):  Apologies; we corrected
>>>>> this term and used "Equal-Cost Multipath" per <https://www.rfc-
>>>>> editor.org/materials/abbrev.expansion.txt> (also per more frequent
>>>>> usage in post-6000 published RFCs).
>>>>> 
>>>>> = = = = =
>>>>> 
>>>>> Regarding our question 11) (using the <aside> element) and your
>>>>> replies:  As Yingzhen pointed out, this technique has not been
>>>>> consistently applied in recently published RFCs.  Please review,
>>>>> and let us know whether you want to keep or remove the <aside> in
>>>>> Appendix B.
>>>>> 
>>>>> = = = = =
>>>>> 
>>>>> Yingzhen, regarding inclusive language:  No changes are needed;
>>>>> even if we don't find any words that might be of concern, we still
>>>>> ask the authors to also review, as a best practice.
>>>>> 
>>>>> = = = = =
>>>>> 
>>>>> Regarding our question 14) (...extensions.yang vs.
>>>>> ...extension.yang) and your replies:  We updated two instances in
>>>>> Section 6 and one in Appendix A.  Please review, and let us know
>>>>> any concerns.
>>>>> 
>>>>> = = = = =
>>>>> 
>>>>> The latest files are posted here (please refresh your browser):
>>>>> 
>>>>> https://www.rfc-editor.org/authors/rfc9403.txt
>>>>> https://www.rfc-editor.org/authors/rfc9403.pdf
>>>>> https://www.rfc-editor.org/authors/rfc9403.html
>>>>> https://www.rfc-editor.org/authors/rfc9403.xml
>>>>> https://www.rfc-editor.org/authors/rfc9403-diff.html
>>>>> https://www.rfc-editor.org/authors/rfc9403-rfcdiff.html
>>>>> https://www.rfc-editor.org/authors/rfc9403-auth48diff.html
>>>>> https://www.rfc-editor.org/authors/rfc9403-lastdiff.html
>>>>> https://www.rfc-editor.org/authors/rfc9403-lastrfcdiff.html
>>>>> 
>>>>> https://www.rfc-editor.org/authors/rfc9403-xmldiff1.html
>>>>> https://www.rfc-editor.org/authors/rfc9403-xmldiff2.html
>>>>> 
>>>>> Thanks again!
>>>>> 
>>>>> RFC Editor/lb
>>>>> 
>>>>> 
>>>>>> On Nov 2, 2023, at 5:36 AM, James Guichard
>>>>>> <[e-mail]> wrote:
>>>>>> 
>>>>>> Hi Lynne,
>>>>>> 
>>>>>> For the questions marked [AD] I approve and agree with the authors
>>>>>> comments.
>>>>>> 
>>>>>> Jim
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Nov 1, 2023, at 2:26 PM, Yingzhen Qu
>>>>>> <[e-mail]> wrote:
>>>>>> 
>>>>>> Hi Lynne,
>>>>>> 
>>>>>> Thanks for the work. Please see my answers inline below.
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Yingzhen
>>>>>> 
>>>>>> From: Lynne Bartholomew <[e-mail]>
>>>>>> Date: Wednesday, November 1, 2023 at 11:07 AM
>>>>>> To: Acee Lindem <[e-mail]>, Yingzhen Qu
>>>>>> <[e-mail]>, James Guichard
>>>>>> <[e-mail]>
>>>>>> Cc: [e-mail] <[e-mail]>, [e-mail]
>>>>>> <[e-mail]>, Jeff Tantsura <[e-mail]>,
>>>>>> auth48archive <[e-mail]>, rfc-editor@rfc-
>>>>>> editor.org <[e-mail]>
>>>>>> Subject: *[AD] Re: AUTH48: RFC-to-be 9403 <draft-ietf-rtgwg-yang-
>>>>>> rib-extend-24> (was -22) for your review
>>>>>> Dear authors and *AD (Jim),
>>>>>> 
>>>>>> We have updated the edited (AUTH48) copy of this document per the
>>>>>> updates from version -22 to version -24
>>>>>> (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-
>>>>>> tools.ietf.org%2Fiddiff%3Furl1%3Ddraft-ietf-rtgwg-yang-rib-extend-
>>>>>> 22%26url2%3Ddraft-ietf-rtgwg-yang-rib-extend-24%26difftype%3D--
>>>>>> html&data=05%7C01%7Cyingzhen.qu%40futurewei.com%7C389e9f5c54e34f5a889e08dbdb055716%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638344588233146700%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=o5G50zcl3AbU8gkXwutsGTBmIyrrbzqCxHc%2Bt3G0yhQ%3D&reserved=0)
>>>>>> and made a few editorial updates as needed.
>>>>>> 
>>>>>> Please review our updates carefully, and let us know if anything
>>>>>> (particularly in the YANG module) is incorrect.
>>>>>> 
>>>>>> * Jim, there are four questions below for you, marked "*[AD]".
>>>>>> Please review, and let us know if you approve.
>>>>>> 
>>>>>> Our updated list of questions is as follows.  Please review, and
>>>>>> let us know how this document should be further updated:
>>>>>> 
>>>>>> 1) <!-- [rfced] Would you like the style of the document title to
>>>>>> more
>>>>>> closely match that of other YANG RFCs?
>>>>>> 
>>>>>> Please note that for now we updated the title for this document,
>>>>>> as
>>>>>> listed in Section 5, to match the current first-page document
>>>>>> title.
>>>>>> 
>>>>>> Original title:
>>>>>> RIB Extension YANG Data Model
>>>>>> 
>>>>>> Original from the module in Section 5:         reference
>>>>>>        "RFC XXXX: A YANG Data Model for RIB Extensions.";
>>>>>> 
>>>>>> Suggested (as originally cited in Section 5; we would revert the
>>>>>> change in Section 5 to match)):
>>>>>> A YANG Data Model for RIB Extensions -->
>>>>>> 
>>>>>> [Yingzhen]: “A YANG Data Model for RIB Extensions” is good.
>>>>>> 
>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that
>>>>>> appear in the
>>>>>> title) for use on
>>>>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-
>>>>>> editor.org%2Fsearch&data=05%7C01%7Cyingzhen.qu%40futurewei.com%7C389e9f5c54e34f5a889e08dbdb055716%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638344588233146700%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hwO5XHAwCWytrp0eiiYyFm6AiepIFNlSBk16%2BJt3lPs%3D&reserved=0>.
>>>>>> -->
>>>>>> 
>>>>>> [Yingzhen]:  RFC8349 has the following keywords: configuration,
>>>>>> IPv6 Router Advertisements, NETCONF, RESTCONF
>>>>>> For this document, I’d suggest to use “YANG, Routing,  RIB”.
>>>>>> 
>>>>>> 3) <!-- [rfced] Section 3:  Because only one ietf-routing YANG
>>>>>> module is
>>>>>> defined in [RFC8349], we changed "modules" to "module" in this
>>>>>> sentence, per "the ietf-routing YANG module [RFC8349]" in Section
>>>>>> 1.
>>>>>> If this is incorrect, please provide clarifying text (e.g.,
>>>>>> perhaps
>>>>>> all three relevant modules from RFC 8349 should be listed here and
>>>>>> in
>>>>>> Section 1?)
>>>>>> Original:
>>>>>> The YANG module defined in this document augments the ietf-routing
>>>>>> YANG modules defined in [RFC8349], which provide a basis for
>>>>>> routing
>>>>>> system data model development.
>>>>>> 
>>>>>> Currently:
>>>>>> The YANG module defined in this document augments the ietf-routing
>>>>>> YANG module defined in [RFC8349], which provides a basis for
>>>>>> routing
>>>>>> system data model development. -->
>>>>>> 
>>>>>> [Yingzhen]: we are actually augmenting ietf-ipv4-unicast and ietf-
>>>>>> ipv6-unicast-routing modules as well. So how about the following:
>>>>>> The YANG module defined in this document augments the
>>>>>> YANG modules defined in [RFC8349], which provide a basis for
>>>>>> routing
>>>>>> system data model development.
>>>>>> 
>>>>>> 4) <!-- [rfced] Sections 3 and 5:  We have received guidance from
>>>>>> Benoit Claise and the YANG Doctors that "YANG module" and "YANG
>>>>>> data model" are preferred.  We have updated the text to use these
>>>>>> forms.  Please review, and let us know any concerns.
>>>>>> 
>>>>>> Original:
>>>>>> Together with YANG modules defined in
>>>>>> [RFC8349], a generic RIB YANG model is defined to implement and
>>>>>> monitor a RIB.
>>>>>> ...
>>>>>> 5.  RIB Extension YANG Model
>>>>>> ...
>>>>>> description
>>>>>>   "This augmentation is only valid for routes whose
>>>>>>    source protocol is not OSPF or IS-IS since their YANG
>>>>>>    models already include a 'metric' augmentation for
>>>>>>    routes.";
>>>>>> ...
>>>>>> description
>>>>>>  "This augmentation is only valid for routes whose
>>>>>>   source protocol is not OSPF or IS-IS since their YANG
>>>>>>   models already include a 'tag' augmentation for
>>>>>>   routes.";
>>>>>> 
>>>>>> Currently:
>>>>>> Together with the ietf-routing YANG
>>>>>> module and other YANG modules defined in [RFC8349], a generic RIB
>>>>>> YANG data model is defined herein to implement and monitor a RIB.
>>>>>> ...
>>>>>> 5.  RIB Extension YANG Module
>>>>>> ...
>>>>>> description
>>>>>>  "This augmentation is only valid for routes whose
>>>>>>   source protocol is not OSPF or IS-IS, since their YANG
>>>>>>   data models already include a 'metric' augmentation for
>>>>>>   routes.";
>>>>>> ...
>>>>>> description
>>>>>>  "This augmentation is only valid for routes whose
>>>>>>   source protocol is not OSPF or IS-IS, since their YANG
>>>>>>   data models already include a 'tag' augmentation for
>>>>>>   routes."; -->
>>>>>> 
>>>>>> [Yingzhen]: Agreed with Acee’s suggestion.
>>>>>> 
>>>>>> 5) <!-- [rfced] Section 3.1:  We could not parse this sentence.
>>>>>> If the suggested text is not correct, please provide clarifying
>>>>>> text.
>>>>>> 
>>>>>> Original:
>>>>>> The following tree snapshot shows tag and preference which augment
>>>>>> static IPv4 unicast routes and IPv6 unicast routes next-hop.
>>>>>> 
>>>>>> Suggested:
>>>>>> The following tree snapshot shows tag and preference entries that
>>>>>> augment static IPv4 unicast route and IPv6 unicast route next
>>>>>> hops. -->
>>>>>> 
>>>>>> [Yingzhen]: OK.
>>>>>> 
>>>>>> 6) <!-- [rfced] Section 5:  Per common practice in YANG documents,
>>>>>> we
>>>>>> added the following introductory paragraph just prior to the YANG
>>>>>> module.
>>>>>> 
>>>>>> This also accounts for the addition of RFCs 9129 and 9130 as
>>>>>> references in the latest version of this document.
>>>>>> 
>>>>>> Please let us know any objections.
>>>>>> 
>>>>>> Original:
>>>>>> 5. RIB Extension YANG Model
>>>>>> 
>>>>>> <CODE BEGINS> file "[e-mail]"
>>>>>> 
>>>>>> Currently:
>>>>>> 5.  RIB Extension YANG Module
>>>>>> 
>>>>>> This YANG module references [RFC6991], [RFC8343], [RFC8349],
>>>>>> [RFC9129], [RFC9130], and [RFC5714].
>>>>>> 
>>>>>> <CODE BEGINS> file "[e-mail]" -->
>>>>>> 
>>>>>> [Yingzhen]: this looks good.
>>>>>> 
>>>>>> 
>>>>>> 7) <!-- [rfced] Section 5:  As it appears that a lower preference
>>>>>> value
>>>>>> is preferable, we updated this sentence (4 instances) as follows.
>>>>>> If this is not correct, please provide clarifying text.
>>>>>> 
>>>>>> Original:
>>>>>> Routes with a lower preference next-hop are
>>>>>> preferred and equal preference routes result in
>>>>>> Equal-Cost-Multi-Path (ECMP) static routes.
>>>>>> 
>>>>>> Currently (first instance; "ECMP" used thereafter):
>>>>>> Routes with a lower next-hop preference value
>>>>>> are preferred, and equal-preference routes result in
>>>>>> Equal-Cost Multi-Path (ECMP) static routes. -->
>>>>>> 
>>>>>> [Yingzhen]: I did some search online, and I see both “Equal-Cost
>>>>>> Multi-Path” and “Equal Cost Multi-Path”. Whichever is IETF
>>>>>> tradition is fine.
>>>>>> 
>>>>>> 8) <!-- [rfced] Authors and *[AD]:  Section 6:  We see "RPC
>>>>>> (Remote
>>>>>> Procedure Call) operation" in Section 2 but do not see any other
>>>>>> mention of RPC operations in this document.  Please confirm that
>>>>>> the "Some of the RPC operations" paragraph as listed on
>>>>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.ietf.org%2Fgroup%2Fops%2Fyang-
>>>>>> security-
>>>>>> guidelines&data=05%7C01%7Cyingzhen.qu%40futurewei.com%7C389e9f5c54e34f5a889e08dbdb055716%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638344588233146700%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lKGtfdFubM9xxjiFC2HOWg2D0eoSf9YyZSPzitfhTes%3D&reserved=0>
>>>>>> is not
>>>>>> applicable to this document (and if it isn't applicable, is the
>>>>>> "RPC
>>>>>> (Remote Procedure Call) operation" listing in Section 2 still
>>>>>> necessary?). -->
>>>>>> 
>>>>>> [Yingzhen]: Please remove the “RPC” from section 2.
>>>>>> 
>>>>>> 
>>>>>> 9) <!-- [rfced] *[AD]:  Per the latest updates to the YANG module
>>>>>> in this
>>>>>> document, we added RFCs 9129 and 9130 to the Normative References
>>>>>> section.  Per our process, we need to ask for your approval
>>>>>> regarding
>>>>>> any changes to the Normative References list.  Please confirm that
>>>>>> these additional Normative Reference listings are acceptable. -->
>>>>>> 
>>>>>> [Yingzhen]: Yes.
>>>>>> 
>>>>>> 10) <!-- [rfced] Authors and *[AD]:  Appendix B:  Per
>>>>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fformal-
>>>>>> languages-
>>>>>> use%2F&data=05%7C01%7Cyingzhen.qu%40futurewei.com%7C389e9f5c54e34f5a889e08dbdb055716%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638344588233146700%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ygBVhD8f8wgexx7MoRTqemQmOVBHn64sPtpRjM9bUDc%3D&reserved=0>,
>>>>>> may we cite [W3C.REC-xml-20081126] ("Extensible Markup Language
>>>>>> (XML)
>>>>>> 1.0 (Fifth Edition)") here and list it as a Normative Reference,
>>>>>> per
>>>>>> RFC 8349?
>>>>>> 
>>>>>> Original:
>>>>>> The following is an XML example using the RIB extension module and
>>>>>> RFC 8349.
>>>>>> 
>>>>>> Suggested:
>>>>>> The following is an XML example [W3C.REC-xml-20081126] using the
>>>>>> RIB
>>>>>> extension module and module data from RFC 8349.
>>>>>> 
>>>>>> Under Normative References:
>>>>>> [W3C.REC-xml-20081126]
>>>>>>           Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E.,
>>>>>> and
>>>>>>           F. Yergeau, "Extensible Markup Language (XML) 1.0
>>>>>>           (Fifth Edition)", World Wide Web Consortium
>>>>>> Recommendation
>>>>>>           REC-xml-20081126, November 2008,
>>>>>>           <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fxml%2F&data=05%7C01%7Cyingzhen.qu%40futurewei.com%7C389e9f5c54e34f5a889e08dbdb055716%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638344588233146700%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xBhLvbMFt5%2BDIjXZpldUWxScGQpU7F9%2B1n%2BKbjW4HdE%3D&reserved=0>.
>>>>>> -->
>>>>>> 
>>>>>> [Yingzhen]: Please add it.
>>>>>> 
>>>>>> 11) <!-- [rfced] Appendix B:  Please review whether the note in
>>>>>> this
>>>>>> document should be in the <aside> element.  It is defined as "a
>>>>>> container for content that is semantically less important or
>>>>>> tangential to the content that surrounds it"
>>>>>> (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Fen%2Frfcxml-
>>>>>> vocabulary%23aside&data=05%7C01%7Cyingzhen.qu%40futurewei.com%7C389e9f5c54e34f5a889e08dbdb055716%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638344588233146700%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pmeOG0TrYcRWZlaCEts08GsHwqdHZ9oUqVU7%2Bnr%2B%2BuM%3D&reserved=0)
>>>> 
>>> 
>