[auth48] Re: YANG module change: Final Review: RFC-to-be 10035 (draft-ietf-netconf-yang-library-augmentedby) in XML

["[e-mail]" <[e-mail]>]

Dear all,

We now have the new email for Nacho in the distribution list.

Regards, Benoit

On 21/08/2026 18:11, [e-mail] wrote:
> Dear RFC editor
>
> IMPORTANT NOTE: We need to update the YANG module according to the 
> NETCONF meeting minutes, therefore we need the specfiic attention from 
> the NETCONF chairs, the NETCONF AD Mahesh, and the document shepherd 
> Thomas Graf
>
> The NETCONF meeting minutes 
> <https://datatracker.ietf.org/doc/minutes-126-netconf-202607211200/> says:
>
>     */Discussions about "yang-library-augmentedby"/* [14:10 - 14:12]
>
>     Thomas Graf: My understanding of deprecated is that it should not be
>     augmented. However, I would have expected in RFC 9907
>     <https://datatracker.ietf.org/doc/rfc9907/> that there's some
>     guidance on whether deprecated it can be augmented or should be
>     augmented in which cases, but I couldn't find any. So I think that
>     would
>     be worth clarifying also for the future.
>
>     Robert Wilton: I think augmenting into a deprecated space is fine. I
>     think this is a bug in the interpretation of deprecated in YANG. I
>     know
>     there's sort of been two different views as to whether it
>     hierarchically
>     bubbles down or not. Hopefully in YANG 2 will fix this and do the
>     sensible thing, because it feels to me like the original
>     definition was
>     nicer, that it deprecates everything underneath. If this makes people
>     happy, I've got no objections to this either.
>
>     Per Andersson: So it's actually YANG-next Issue 27, which asks to
>     clarify the inheritance of status.
>
>     Mahesh Jethanandani: Since the document is passed to IANA approval, do
>     you want me to recall it from the RFC editor queue to make the change.
>
>     Per Andersson: As a contributor, I don't mind either way raising this
>     complaint. Instead of recalling the document to the WG, make the
>     changes
>     unrolling the grouping which doesn't change the semantics of the YANG
>     module; OR remove the augment of modules-state which was suggested on
>     list. I suggest to do whatever is fastest to publish the document.
>
>     Mahesh Jethanandani: If it's not semantically changing the model
>     in any
>     way, maybe then we can handle that at the RFC editor level where
>     we will
>     recommend to them the changes they need to make to the model.
>
> Based on 
> https://mailarchive.ietf.org/arch/msg/netconf/B40N7QvHvZbUE83jjy-c3kHCP7Q/, 
> we want to implement Per's suggestion
>
> NOTE REGARDING THE AUTHORS
>     Zhuoyao Lin new email address is [e-mail] 
> <mailto:[e-mail]> The affiliation remains the same
>     Ignacio left Telefonica; I am trying to contact him via linkedin 
> and his previous colleagues
>     There are two locations where to change those: the draft and the 
> YANG module
>
>
> OLD:
>
>     grouping augmented-by {
>     description
>     "Provides augmented-by leaf-list from module info with the
>     module-augmented-by grouping";
>     leaf-list augmented-by {
>     type leafref {
>     path "../../yanglib:module/yanglib:name";
>     }
>     description
>     "Leaf-list of the augmentations used by this server to
>     modify the schema tree of the module associated with
>     this entry. Note that the same module can be used for
>     augmented-by for multiple modules, so the same
>     entry MAY appear within multiple 'module' entries.
>     This reference MUST NOT (directly or indirectly)
>     refer to the module being augmented, and MUST NOT
>     be referenced in the import-only list.
>     Robust clients may want to make sure that they handle a
>     situation where a module augments itself (directly or
>     indirectly) gracefully.";
>     }
>     }
>     augment "/yanglib:yang-library/yanglib:module-set/yanglib:module" {
>     description
>     "Adds Augmented-by leaf-list to the list of modules of a module set";
>     uses augmented-by;
>     }
>     augment "/yanglib:modules-state/yanglib:module" {
>     status deprecated;
>     description
>     "Adds Augmented-by leaf-list to the list of modules of a module set";
>     uses augmented-by;
>     }
>
> NEW:
>
>     augment "/yanglib:yang-library/yanglib:module-set/yanglib:module" {
>     description
>     "Adds Augmented-by leaf-list to the list of modules of a module set";
>     leaf-list augmented-by {
>     type leafref {
>     path "../../yanglib:module/yanglib:name";
>     }
>     description
>     "Leaf-list of the augmentations used by this server to
>     modify the schema tree of the module associated with
>     this entry. Note that the same module can be used for
>     augmented-by for multiple modules, so the same
>     entry MAY appear within multiple 'module' entries.
>     This reference MUST NOT (directly or indirectly)
>     refer to the module being augmented, and MUST NOT
>     be referenced in the import-only list.
>     Robust clients may want to make sure that they handle a
>     situation where a module augments itself (directly or
>     indirectly) gracefully.";
>     }
>     }
>     augment "/yanglib:modules-state/yanglib:module" {
>     status deprecated;
>     description
>     "Adds Augmented-by leaf-list to the list of modules of a module set";
>     leaf-list augmented-by {
>     type leafref {
>     path "../../yanglib:module/yanglib:name";
>     }
>     status deprecated;
>     description
>     "Leaf-list of the augmentations used by this server to
>     modify the schema tree of the module associated with
>     this entry. Note that the same module can be used for
>     augmented-by for multiple modules, so the same
>     entry MAY appear within multiple 'module' entries.
>     This reference MUST NOT (directly or indirectly)
>     refer to the module being augmented, and MUST NOT
>     be referenced in the import-only list.
>     Robust clients may want to make sure that they handle a
>     situation where a module augments itself (directly or
>     indirectly) gracefully.";
>     }
>     }
>
>
> Attached is diff from v18 with these changes above. Hopefully it helps 
> with the visualization.
>
> See inline for more answers.
>
>
> On 21/08/2026 00:32, [e-mail] wrote:
>> Authors,
>>
>> While reviewing this document during Final Review, please resolve
>> (as necessary) the following questions, which are also in the source file.
>>
>>
>> 1. We note that "augmented-by" appears in lowercase throughout the rest of this document. Should "Augmented-by" in the title be lowercase as well?
>>
>> Current title:  Augmented-by Addition to the YANG Library
>> Current abbreviated title:  Augmented-by for YANG Library
>>
>> Perhaps:
>> Title:  YANG Library: Addition of the augmented-by List
>> Abbreviated title:  YANG Library: augmented-by
> That works. Thanks.
>> 2. Please provide any keywords (beyond those that appear in the title) for use onhttps://www.rfc-editor.org/search.
> We have enough with the title keywords, I believe.
>> 3. FYI, we updated the abstract to remove a section reference because the content of the abstract is often separate from the RFCs themselves. Please let us know if you have any concerns.
>>
>> Original:
>> This document updates RFC 8525, as the lists in Section 2 is modified
>> to also include augmented-by list.
>>
>> Current:
>> This document updates RFC 8525 to also include the augmented-by list.
> Fine.
>> 4. May we adjust the text below as follows for clarity?
>>
>> Original:
>>
>> According to the definition of the module ietf-yang-library defined in
>> [RFC8525], the "deviation" list describes that a module is deviated by
>> which other modules.
>>
>> Perhaps:
>>
>> According to the definition of the "ietf-yang-library" module in [RFC8525],
>> the "deviation" list identifies the name of each YANG module with deviation
>> statements affecting the given YANG module.
> Yes, that works.
>> 5. Please review whether the "type" attribute should be set for the sourcecode element used in Section 3.1. If the current list of preferred values for "type" (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) does not contain an applicable type, then feel free to suggest a new one. Also, it is acceptable to leave the "type" attribute not set.
>
> You can use: yang-instance-data+json
>> 6. May we update this sentence and add "is needed" for clarity?
>>
>> Original:
>>
>> However, what a data consumer needs at the end are the YANG modules
>> implemented by the device, hence, the combination of implemented YANG
>> modules with other YANG modules that might deviate or augment the
>> formers.
>>
>> Perhaps:
>>
>> However, what a data consumer needs at the end are the YANG modules
>> implemented by the device; hence, the combination of implemented YANG
>> modules with other YANG modules that might deviate or augment the former
>> is needed.
> Yes
>> 7. How may we rephrase "is in combination" in the text below for readability?
>>
>> Original:
>>
>> A workaround is in combination with the YANG library data to
>> additionally obtain both YANG modules and process them to discover
>> that there is an augment dependency.
>>
>> Perhaps:
>>
>> A workaround is to additionally obtain both YANG modules and process
>> them in combination with the YANG library data to discover that there
>> is an augment dependency.
> Yes.
>> 8. FYI, we have added line wrapping per RFC 8792 (and an informative reference to RFC 8792) to the XML examples in Section 4.2.2, which helped with the XML validation errors.  However, we still receive the following error when validating the XML: "Extra content at the end of the document".  We think this is due to "modules-state" being deprecated. Please review and let us know if any changes are required.
> ok
>> 9. Regarding the Security Considerations, we note some
>> differences from the template in Section 3.7.1 of RFC 9907.
>> Please review and let us know if the differences are intentional.
>>
>> Current:
>>
>> This YANG module defines only readable ("config false") data nodes.
>> Some of these readable data nodes may be considered sensitive or
>> vulnerable in some network environments.  It is important to control
>> read access (e.g., via get, get-config, or notification) to these
>> data nodes.
>>
>> Specifically, the following readable data nodes contain potentially
>> sensitive information:
>>
>> *  /yang-library/module-set/module/augmented-by
>>
>> *  /modules-state/module/augmented-by (modules-state is deprecated)
>>
>> Perhaps:
>>
>> Some of the readable data nodes in this YANG module may be considered
>> sensitive or vulnerable in some network environments.  It is thus important
>> to control read access (e.g., via get, get-config, or notification) to
>> these data nodes.  Specifically, the following subtrees and data nodes have
>> particular sensitivities/vulnerabilities:
>>
>> *  /yang-library/module-set/module/augmented-by
>>
>> *  /modules-state/module/augmented-by (modules-state is deprecated)
> Fine but I would keep the first sentence: "This YANG module defines 
> only readable ("config false") data nodes."
>> 10. FYI, we updated the IANA Considerations section to follow the templates in RFC 9907. Please let us know of any concerns.
> Good.
>> 11. In the YANG tree diagram for "ietf-yang-library", should there be blank lines here?
>>
>> Original:
>> |  |  +- -ro schema    -> ../../schema/name
>>
>>
>> |  +- -ro content-id       string
> No blank line
> Regenerating the tree with the updated YANG produced this diff
>
>
>> Note that we added line wrapping per RFC 8792 to the tree diagram. Please let us know of any concerns.
> No concern
>> 12. The following references only appeared in the Implementation
>> Status section of this document, so they have been removed. Please
>> review:
>>
>> [LY16]
>> [NA25]
>> [NP24]
>> [NTP17]
>> [SR16]
> Make sense.
>> 13. We note some differences in the terminology below. Please review each term
>> and let us know which form you would like us to update to for consistency across the document.
>>
>> "augmented-by" vs. augmented-by
> You used "augmented-by", and this is fine
>> 14. We updated "module set" (3 instances) to "module-set" (29 instances).
>> Please review and let us know if any updates are needed.
> Fine
>> 15. FYI - We have added expansions for abbreviations upon first use
>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
>> expansion in the document carefully to ensure correctness.
>>
>> Standards Development Organizations (SDOs)
> Yes.
>> 16. Please review the "Inclusive Language" portion of the online
>> Style Guide<https://www.rfc-editor.org/authors/rfc-style-guide/#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.
>
> I checked the diff
>
> I prefer to keep "Augment" here, as this is the YANG statement, as the 
> other 3 bullet points.
>
>
> OLD: "augmentation" and "deviation" statements
> NEW: "augment" and "deviation" statements
>
> One more detail: can you add BE (for Belgium), next to my author details.
>
>
> Regards, Benoit
>
>> Thank you,
>> Kaelin Foody and Jean Mahoney
>> RFC Production Center
>>
>>
>> On 8/20/26 5:27 PM,[e-mail] wrote:
>>
>> *****IMPORTANT*****
>>
>> RFC Author(s):
>> --------------
>>
>> Final Review for RFC-to-be 10035 <draft-ietf-netconf-yang-library-augmentedby>
>>
>> Your document is now available for Final Review (previously 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;
>> see the Unavailable Authors section
>> (https://authors.ietf.org/rfc-publication-process#unavailable-authors)
>>
>> 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 an archival mailing list
>>        to preserve discussion about the document while in the RPC editorial
>>        queue; 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://auth48-transition.rfc-editor.org/authors/rfc10035.xml
>>     https://auth48-transition.rfc-editor.org/authors/rfc10035.html
>>     https://auth48-transition.rfc-editor.org/authors/rfc10035.pdf
>>     https://auth48-transition.rfc-editor.org/authors/rfc10035.txt
>>
>> Diff file of the text:
>>     https://auth48-transition.rfc-editor.org/authors/rfc10035-diff.html
>>     https://auth48-transition.rfc-editor.org/authors/rfc10035-rfcdiff.html (side by side)
>>
>> Diff of the XML:
>>     https://auth48-transition.rfc-editor.org/authors/rfc10035-xmldiff1.html
>>
>>
>> Tracking progress
>> -----------------
>>
>> Details on the status of your Final Review are here:
>>     https://queue.rfc-editor.org/final-review/rfc10035/
>>
>> Please let us know if you have any questions.
>>
>> Thank you for your cooperation,
>>
>> RFC Editor
>>
>> --------------------------------------
>> RFC 10035 (draft-ietf-netconf-yang-library-augmentedby)
>>
>> Title            : Augmented-by Addition to the YANG Library
>> Author(s)        : Z. Lin,
>>                     B. Claise,
>>                     I. Martinez-Casanueva
>> WG Chair(s)      : Kent Watsen, Per Andersson
>> Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani
>