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

[Jean Mahoney <[e-mail]>]

*Mahesh,

Please review the updates to the YANG module in Section 4.2.1 and let us 
know if you approve:

https://www.rfc-editor.org/authors/rfc10035-auth48rfcdiff.html


Zhuoyao, Benoît,

We have noted your approvals and made the requested update to Section 
4.2.2.2:

    https://queue.rfc-editor.org/final-review/rfc10035/

    https://www.rfc-editor.org/authors/rfc10035-lastrfcdiff.html


Ignacio,

We will await word from you regarding other updates or approval.

The latest files can be found here:

    https://www.rfc-editor.org/authors/rfc10035.txt
    https://www.rfc-editor.org/authors/rfc10035.pdf
    https://www.rfc-editor.org/authors/rfc10035.html
    https://www.rfc-editor.org/authors/rfc10035.xml

    https://www.rfc-editor.org/authors/rfc10035-diff.html
       (all changes)
    https://www.rfc-editor.org/authors/rfc10035-rfcdiff.html
       (all changes side by side)

    https://www.rfc-editor.org/authors/rfc10035-auth48diff.html
       (changes made during Final Review)
    https://www.rfc-editor.org/authors/rfc10035-auth48rfcdiff.html
       (changes made during Final Review side by side)

    https://www.rfc-editor.org/authors/rfc10035-lastdiff.html
       (latest changes)
    https://www.rfc-editor.org/authors/rfc10035-lastrfcdiff.html
       (latest changes side by side)

    https://www.rfc-editor.org/authors/rfc10035-xmldiff1.html
       (all changes to the XML)
    https://www.rfc-editor.org/authors/rfc10035-xmldiff2.html
       (all changes to the XML side by side)

Best regards,

Jean Mahoney
RFC Production Center


On 8/25/26 3:08 AM, Zhuoyao LIN wrote:
> Hello Kaelin,
> 
> I have reviewed my contact information and they are accurate.
> I have reviewed and agree with Benoit's input.
> 
> Best,
> Zhuoyao Lin
> 
> On Mon, 24 Aug 2026 at 23:27, Kaelin Foody <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Hi authors, all,
> 
>     Thank you all for your responses. We have incorporated your
>     requested updates and have posted the updated files below.
> 
>     A few notes:
> 
>     a) Ignacio and Zhuoyao, please review our updates to your contact
>     information in the document and confirm that these updates are
>     accurate.
> 
>     b) To confirm, would you like us to add quotation marks to all
>     instances of augmented-by (so that they appear as “augmented-by”),
>     as seen in the text below?
> 
>      >> 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
> 
>     c) Lastly, please review the YANG module to ensure that these
>     updates are accurate.
> 
> 
>     The Final Review status of your document is available here:
>     https://queue.rfc-editor.org/final-review/rfc10035 <https://
>     queue.rfc-editor.org/final-review/rfc10035>
> 
>     — FILES (please refresh): —
> 
>     The updated files have been posted here:
>     https://www.rfc-editor.org/authors/rfc10035.txt <https://www.rfc-
>     editor.org/authors/rfc10035.txt>
>     https://www.rfc-editor.org/authors/rfc10035.pdf <https://www.rfc-
>     editor.org/authors/rfc10035.pdf>
>     https://www.rfc-editor.org/authors/rfc10035.html <https://www.rfc-
>     editor.org/authors/rfc10035.html>
>     https://www.rfc-editor.org/authors/rfc10035.xml <https://www.rfc-
>     editor.org/authors/rfc10035.xml>
> 
>     Diff files showing changes made during Final Review:
>     https://www.rfc-editor.org/authors/rfc10035-auth48diff.html
>     <https://www.rfc-editor.org/authors/rfc10035-auth48diff.html>
>     https://www.rfc-editor.org/authors/rfc10035-auth48rfcdiff.html
>     <https://www.rfc-editor.org/authors/rfc10035-auth48rfcdiff.html>
>     (side by side)
> 
>     Diff files showing all changes:
>     https://www.rfc-editor.org/authors/rfc10035-diff.html <https://
>     www.rfc-editor.org/authors/rfc10035-diff.html>
>     https://www.rfc-editor.org/authors/rfc10035-rfcdiff.html <https://
>     www.rfc-editor.org/authors/rfc10035-rfcdiff.html> (side by side)
> 
>     Thank you,
> 
>     Kaelin Foody
>     RFC Production Center
> 
>      > On Aug 24, 2026, at 5:40 AM, Per Andersson <[e-mail]
>     <mailto:[e-mail]>> wrote:
>      >
>      > Hi,
>      >
>      >
>      > On Fri, Aug 21, 2026 at 6:11 PM [e-mail]
>     <mailto:[e-mail]>
>      > <[e-mail] <mailto:[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 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 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/ <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.";
>      >> }
>      >> }
>      >
>      > As a contributor, this was the change I suggested for the
>      > YANG modeling and I approve of this.
>      >
>      > As NETCONF co-chair, this change is least disruptive and
>      > does not change the semantics of the YANG model. I see
>      > it as the most favourable edit to make in order to not
>      > disrupt the publication of this document.
>      >
>      >
>      > --
>      > Per
>      >
>      >
>      >> 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] <mailto:rfc-
>     [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 on https://www.rfc-editor.org/search <https://
>     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 <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 <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] <mailto:rfc-
>     [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 <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 <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 <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] <mailto:[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] <mailto:auth48archive@rfc-
>     editor.org>, 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 <https://mailarchive.ietf.org/arch/msg/
>     ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc>
>      >>
>      >>     *  The archive itself:
>      >> https://mailarchive.ietf.org/arch/browse/auth48archive/
>     <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] <mailto: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://auth48-transition.rfc-editor.org/authors/rfc10035.xml
>     <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.html>
>      >> https://auth48-transition.rfc-editor.org/authors/rfc10035.pdf
>     <https://auth48-transition.rfc-editor.org/authors/rfc10035.pdf>
>      >> https://auth48-transition.rfc-editor.org/authors/rfc10035.txt
>     <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-diff.html>
>      >> https://auth48-transition.rfc-editor.org/authors/rfc10035-
>     rfcdiff.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 <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/ <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
> 
>