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

[Acee Lindem <[e-mail]>]

Hi Lynne,

> On Nov 1, 2023, at 14:06, Lynne Bartholomew <[e-mail]> wrote:
> 
> 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://author-tools.ietf.org/iddiff?url1=draft-ietf-rtgwg-yang-rib-extend-22&url2=draft-ietf-rtgwg-yang-rib-extend-24&difftype=--html) 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 -->

This is fine. 


> 
> 
> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
> title) for use on <https://www.rfc-editor.org/search>. -->

Please use the same keywords as RFC 8349. If none, add “YANG” and “Routing”. 


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


Sounds good.



> 
> 
> 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."; -->
> 
> 
> 5) <!-- [rfced] Section 3.1:  We could not parse this sentence.
> If the suggested text is not correct, please provide clarifying text.

It makes sense to me but then I wrote it. Is this clearer?

   This augmentation is only valid for routes that don’t have
    OSPF or IS-IS as the source protocol. The YANG data models
    for OSPF and IS-IS already include a ‘metric’ augmentation
    for routes. 

Do the same for ’tag’. 


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

Simply changing “which” to “that”. 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.

None. 


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


Ok - this is good. Forgot to add these. 


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

I saw you changed the hyphenation of "Equal-Cost Mult-Path”. What is the reason? 



> 
> 
> 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://wiki.ietf.org/group/ops/yang-security-guidelines> 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?). -->

No - please remove it 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. -->

I agree. 


> 
> 
> 10) <!-- [rfced] Authors and *[AD]:  Appendix B:  Per
> <https://www.ietf.org/about/groups/iesg/statements/formal-languages-use/>,
> 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://www.w3.org/TR/xml/>. -->

I agree it should be added.  


> 
> 
> 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://authors.ietf.org/en/rfcxml-vocabulary#aside).
> 
> Original:
> Note: '\' line wrapping per [RFC8792]. -->

Sure - I’ve never used this but I’ll look at the results in the next revision. 


> 
> 
> 12) <!-- [rfced] Authors and *[AD]:  Appendix B:  Would you like to cite
> RFC 7951 ("JSON Encoding of Data Modeled with YANG") here and add a
> corresponding reference listing?  If yes, please let us know whether
> the listing should be Normative or Informative.
> 
> Original:
> The following is the same example using JSON format.
> 
> Possibly:
> The following is the same example using JSON format [RFC 7951].
> ...
> [RFC7951]  Lhotka, L., "JSON Encoding of Data Modeled with YANG",
>            RFC 7951, DOI 10.17487/RFC7951, August 2016,
>            <https://www.rfc-editor.org/info/rfc7951>. -->


I agree. 


> 
> 
> 13) <!-- [rfced] Please review the "Inclusive Language" portion of the
> online Style Guide at
> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
> and let us know if any changes are needed.
> 
> Note that our script did not flag any words in particular, but this
> should still be reviewed as a best practice. -->


All good from my standpoint. 



> 
> 
> 14) <!-- [rfced] The following term appears to be used inconsistently in
> this document.  Please let us know which form is preferred.
> 
> ietf-rib-extensions / ietf-rib-extension
>   (e.g., "in the ietf-rib-extensions.yang module",
>    "urn:ietf:params:xml:ns:yang:ietf-rib-extension",
>    "Appendix B.  ietf-rib-extension.yang example")
> 
>   * Please note that if the plural "extensions" is correct, we will
>   update this document accordingly and also ask IANA to update their
>   corresponding pages. -->

I only found one instance of “ietf-rib-extensions.yang” in section 8 - please change it to “ietf-rib-extension.yang”. 

Thanks,
Acee




> 
> = = = = =
> 
> 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-xmldiff1.html
>   https://www.rfc-editor.org/authors/rfc9403-xmldiff2.html
> 
> Thank you!
> 
> RFC Editor/lb
> 
> 
>> On Oct 2, 2023, at 4:16 PM, [e-mail] wrote:
>> 
>> Authors,
>> 
>> While reviewing this document during AUTH48, please resolve (as necessary) 
>> the following questions, which are also in the XML file.
>> 
> 
> *** Please see updated list above (1 Nov. 2023).
> 
>> Thank you.
>> 
>> RFC Editor
>> 
>> 
>> On Oct 2, 2023, at 4:11 PM, [e-mail] wrote:
>> 
>> *****IMPORTANT*****
>> 
>> Updated 2023/10/02
>> 
>> 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
>> 
>>  *  [e-mail] (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).
>> 
>>  *  [e-mail], 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, 
>>       [e-mail] 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/rfc9403.xml
>>  https://www.rfc-editor.org/authors/rfc9403.html
>>  https://www.rfc-editor.org/authors/rfc9403.pdf
>>  https://www.rfc-editor.org/authors/rfc9403.txt
>> 
>> Diff file of the text:
>>  https://www.rfc-editor.org/authors/rfc9403-diff.html
>>  https://www.rfc-editor.org/authors/rfc9403-rfcdiff.html (side by side)
>> 
>> Diff of the XML: 
>>  https://www.rfc-editor.org/authors/rfc9403-xmldiff1.html
>> 
>> The following files are provided to facilitate creation of your own 
>> diff files of the XML.  
>> 
>> Initial XMLv3 created using XMLv2 as input:
>>  https://www.rfc-editor.org/authors/rfc9403.original.v2v3.xml 
>> 
>> XMLv3 file that is a best effort to capture v3-related format updates 
>> only: 
>>  https://www.rfc-editor.org/authors/rfc9403.form.xml
>> 
>> 
>> Tracking progress
>> -----------------
>> 
>> The details of the AUTH48 status of your document are here:
>>  https://www.rfc-editor.org/auth48/rfc9403
>> 
>> Please let us know if you have any questions.  
>> 
>> Thank you for your cooperation,
>> 
>> RFC Editor
>> 
>> --------------------------------------
>> RFC9403 (draft-ietf-rtgwg-yang-rib-extend-22)
>> 
>> Title            : RIB Extension YANG Data Model
>> Author(s)        : A. Lindem, Y. Qu
>> WG Chair(s)      : Jeff Tantsura, Yingzhen Qu
>> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
>> 
>> 
>