Hi Megan,
Sorry for a late reply. I have done a full check!
There is an error in the YANG file which is leading to a YANG validation
error.
--
OLD:
reference
"RFC 8454: Information Model for Abstraction and Control of TE
Networks (ACTN)";
"RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies";
NEW:
reference
"RFC 8454: Information Model for Abstraction and Control of TE
Networks (ACTN)
RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies";
END
Please run all the YANG validation checks after fixing that
--
Apart from that please note my AUTH48 approval.
Thanks!
Dhruv
On Sat, Feb 8, 2025 at 6:26 AM Megan Ferguson <
mfergu...@staff.rfc-editor.org> wrote:
> Dhruv,
>
> Thank you for your reply. We have updated accordingly. Please pay
> particular attention to:
>
> -any updates that may have overlapped with leaf names,
> -the way we updated to cite RFC 8792 (does further marking like that in
> RFC 9646 need to be added?), and
> -the way we updated the names of the YANG modules
>
> and let us know if any further updates are necessary.
>
> Please review the files carefully as we do not make changes after
> publication.
>
> The files have been posted here (please refresh):
> https://www.rfc-editor.org/authors/rfc9731.txt
> https://www.rfc-editor.org/authors/rfc9731.pdf
> https://www.rfc-editor.org/authors/rfc9731.html
> https://www.rfc-editor.org/authors/rfc9731.xml
>
> The relevant diff files have been posted here (please refresh):
> https://www.rfc-editor.org/authors/rfc9731-diff.html (comprehensive
> diff)
> https://www.rfc-editor.org/authors/rfc9731-auth48diff.html (AUTH48
> changes only)
> https://www.rfc-editor.org/authors/rfc9731-lastdiff.html (last to
> current version only)
>
> Please contact us with any further updates/questions/comments you may
> have.
>
> We will await approvals from each of the parties listed on the AUTH48
> status page prior to moving forward to publication.
>
> The AUTH48 status page for this document is available here:
>
> https://www.rfc-editor.org/auth48/rfc9731
>
> Thank you.
>
> RFC Editor/mf
>
> > On Feb 5, 2025, at 5:53 AM, Dhruv Dhody <dhruv.i...@gmail.com> wrote:
> >
> > Hi,
> >
> > On Tue, Jan 28, 2025 at 11:09 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] Please insert any keywords (beyond those that appear in
> > the title) for use on https://www.rfc-editor.org/search. -->
> >
> >
> > Dhruv: ACTN, SDN, TE
> >
> >
> >
> > 2) <!--[rfced] Is the final sentence of the Abstract pointing to another
> > document (RFC 8453)? Or is this a general mention of the concept?
> >
> > Original:
> > This includes VN operations as per the Abstraction and Control of TE
> > Networks (ACTN) framework.
> >
> > Perhaps:
> > This includes VN operations as per the Abstraction and Control of TE
> > Networks (ACTN) framework described in RFC 8453.
> >
> > -->
> >
> >
> > Dhruv: Add reference to RFC 8453 is fine.
> >
> >
> >
> > 3) <!-- [rfced] FYI, the authors' comments in the XML file have been
> > marked with [auth]. Please let us know if any updates are needed
> > based on those comments; if not, they will be removed.
> > -->
> >
> >
> > Dhruv: Please remove!
> >
> >
> >
> > 4) <!--[rfced] Might the following update to the Terminology section be
> > helpful to the reader? It reduces redundancy, groups the
> > abbreviations in one list, and makes the treatment of the terms
> > more similar. Otherwise, we have "Connectivity Matrix" without
> > any descriptor in the original...
> >
> > Original:
> >
> > 1.1. Terminology
> >
> > This document borrows the following terms from [RFC8453]:
> >
> > VN: Virtual Network
> >
> > AP: Access Point
> >
> > VNAP: VN Access Point
> >
> > ACTN: Abstraction and Control of TE Networks
> >
> > CNC: Customer Network Controller
> >
> > MDSC: Multi-Domain Service Coordinator
> >
> > CMI: CNC-MDSC Interface
> >
> > This document borrows the following terms from [RFC8795]:
> >
> > LTP: Link Termination Point
> >
> > Connectivity Matrix
> >
> > This document borrows the terminology in Section 1.1 of [RFC7926].
> >
> > This document uses the term 'Service Model' as described in
> > [RFC8309].
> >
> > Perhaps:
> > 1.1. Terminology
> >
> > This document borrows the following abbreviations from [RFC8453]
> > and/or [RFC8795]:
> >
> > VN: Virtual Network
> >
> > AP: Access Point
> >
> > VNAP: VN Access Point
> >
> > ACTN: Abstraction and Control of TE Networks
> >
> > CNC: Customer Network Controller
> >
> > MDSC: Multi-Domain Service Coordinator
> >
> > CMI: CNC-MDSC Interface
> >
> > LTP: Link Termination Point
> >
> > This document borrows the terminology in Section 1.1 of
> > [RFC7926], the term "Service Model" from [RFC8309], and the term
> > "Connectivity Matrix" from [RFC8795].
> >
> > -->
> >
> >
> > Dhruv: Happy with the change.
> >
> >
> >
> > 5) <!--[rfced] The use of the blockquote element with this text may be
> > confusing to readers. If this is simply a paraphrase instead of
> > a direct quote from RFC 8543 (which it appears to be), we suggest
> > removing the blockquote element.
> >
> > Original:
> > As defined in [RFC8453], a Virtual Network is a customer view of the
> > TE network. To recapitulate VN types from [RFC8453], Type 1 VN is
> > defined as follows:
> >
> > | The VN can be seen as a set of edge-to-edge abstract links (a Type
> > | 1 VN). Each abstract link is referred to as a VN member and is
> > | formed as an end-to-end tunnel across the underlying networks.
> > | Such tunnels may be constructed by recursive slicing or
> > | abstraction of paths in the underlying networks and can encompass
> > | edge points of the customer's network, access links, intra-domain
> > | paths, and inter-domain links.
> >
> > Perhaps:
> > As defined in [RFC8453], a Virtual Network is a customer view of the
> > TE network. To recapitulate VN types from [RFC8453], Type 1 VN is
> > defined as follows:
> >
> > The VN can be seen as a set of edge-to-edge abstract links (a Type
> > 1 VN). Each abstract link is referred to as a VN member and is
> > formed as an end-to-end tunnel across the underlying networks.
> > Such tunnels may be constructed by recursive slicing or
> > abstraction of paths in the underlying networks and can encompass
> > edge points of the customer's network, access links, intra-domain
> > paths, and inter-domain links.
> >
> > -->
> >
> >
> > Dhruv: Fine.
> >
> >
> >
> > 6) <!--[rfced] We are unsure of how to parse the list below beginning
> > with "which". Please rephrase.
> >
> > Original:
> > Type 1 VN can be seen as a higher abstraction of a Type 2 VN (which
> > along with a single node abstract topology, an underlay topology and
> > the intended path is specified).
> >
> > -->
> >
> >
> > Dhruv: A Type 1 VN can be viewed as a higher-level abstraction of a Type
> 2 VN, which represents a single node abstract topology over the underlay
> topology and includes a mechanism to specify intended paths.
> >
> >
> >
> > 7) <!--[rfced] In the "Type 1 VN Illustration" figure (Figure 5), should
> > "multi-s-d" instead read as "multi-s/d" to more closely mirror
> > the text to the right of the figure? -->
> >
> >
> > Dhruv: Yes please!
> >
> >
> >
> > 8) <!--[rfced] This sentence may trip up some readers; particularly, how
> > does "only" apply to the sentence (especially considering the use
> > of "as well")? Please consider a rephrase.
> >
> > Original:
> > The VN operation allows the creation of a VN with only a PE identifier
> > as well.
> >
> > -->
> >
> >
> > Dhruv: Please remove "as well".
> >
> >
> >
> > 9) <!--[rfced] Please review the use of lowercase "vn" in this sentence.
> > Is this the abbreviation for Virtual Network? Or is this the
> > Prefix defined in Section 1.3?
> >
> >
> > Original:
> > To achieve this, the 'ap' container has a leaf for 'pe' node that
> > allows AP to be created with PE information. The vn-member (and vn)
> > could use APs that only have PE information initially.
> >
> > -->
> >
> >
> > Dhruv: Thanks for spotting it. Change that to "VN member (and VN)", as
> this is about them in general and not YANG container and leaves.
> >
> >
> >
> > 10) <!--[rfced] We had a few questions about the bulleted list following
> > Figure 10:
> >
> > a) May we replace "This" with its antecedent for clarity? Note that
> > this text occurs twice (in the first two bullets of the list):
> >
> > Original:
> > This also overrides any constraints in the referenced abstract node in
> > the TE topology.
> >
> > Pephaps:
> > The VN-member level also overrides any constraints in the referenced
> > abstract node in the TE topology.
> >
> > b) In the following, is the meaning "at the VN level and/or VN-member
> > level"? Note that this text also occurs twice in the first two bullet
> > points of this list.
> >
> > Original:
> > This is used optionally in the RPC input at the VN and/or VN-member
> > level.
> >
> > Perhaps:
> > This is used optionally in the RPC input at the VN level and/or the
> > VN-member level.
> > -->
> >
> >
> > Dhruv: Here is the updated list which builds on your suggested changes -
> >
> > To achieve this, the VN-compute RPC reuses the following common
> groupings:
> >
> > • te-types:generic-path-constraints: is used optionally in the RPC
> input at the VN-level and/or VN-member-level. The VN-member-level overrides
> the VN-level data including any constraints in the referenced abstract node
> in the TE topology.
> > • te-types:generic-path-optimization: is used optionally in the
> RPC input at the VN-level and/or VN-member-level. The VN-member-level
> overrides the VN-level data including any optimization in the referenced
> abstract node in the TE topology.
> > • vn-member: identifies the VN member in both RPC input and output.
> > • vn-policy: is used optionally in the RPC input to apply any
> VN-level policies.
> >
> >
> >
> > 11) <!--[rfced] We would suggest making the following updates for clarity
> > as two YANG models are being discussed in close proximity.
> >
> > Original:
> > Note that the YANG model is tightly coupled with the TE Topology
> > model [RFC8795]. Any underlay technology not supported by [RFC8795]
> > is also not supported by this model. The model does include an empty
> > container called "underlay" that can be augmented. For example the
> > Segment Routing (SR) Policy [RFC9256] information can be augmented
> > for the SR underlay by a future model.
> >
> > Perhaps:
> > Note that the VN YANG model is tightly coupled with the TE Topology
> > model [RFC8795]. Any underlay technology not supported by the TE
> > Topology model in [RFC8795] is also not supported by the VN YANG
> > model. However, the VN YANG model does include an empty container
> > called "underlay" that can be augmented. For example, the Segment
> > Routing (SR) Policy [RFC9256] information can be augmented for the
> > SR underlay by a future model.
> > -->
> >
> > Dhruv: Yes, this is better!
> >
> >
> >
> > 12) <!--[rfced] RFC 4124 does not use the term "cos" or "class of
> > service". Is this citation in the right place in the sentence?
> >
> > Original:
> > Apart from the te-types:generic-path-constraints and te-
> > types:generic-path-optimization, an additional leaf cos for the class
> > of service [RFC4124] is added to represent the Class-Type of traffic
> > to be used as one of the path constraints.
> >
> > Perhaps:
> > Apart from the te-types:generic-path-constraints and te-
> > types:generic-path-optimization, an additional leaf cos for the class
> > of service is added to represent the Class-Type of traffic [RFC4124]
> > to be used as one of the path constraints.
> > -->
> >
> >
> > Dhruv: Works for me!
> >
> >
> >
> > 13) <!--[rfced] We had the following questions about the YANG module in
> > Section 6:
> >
> > a) Is "This module contains a YANG module" correct?
> >
> > Original:
> > This module contains a YANG module for the Virtual Network (VN).
> >
> > Perhaps:
> > This YANG module is for the Virtual Network (VN).
> >
> >
> > Dhruv: Works for me!
> >
> > b) The beginning of the module lists abbreviations, but they are
> > expanded on first use in the module anyway. May we cut these first
> > expansions?
> >
> >
> > Dhruv: Yes!
> >
> >
> > c) Same for src and dest: they are introduced, but not used in
> > descriptions consistently. Please let us know if updates should be
> > made.
> >
> >
> > Dhruv: My suggestion would be to use "source" and "destination" in the
> description clause. But the yang leaf names or feature name should be src
> and dest.
> >
> > So the change needed would be in -
> > - feature multi-src-dest
> > - leaf if-selected
> > - leaf vn-ap-id
> > - leaf if-selected (inside the rpc)
> >
> >
> >
> > d) FYI - We will update the expansion of CMI to match the version used
> > in the Terminology section (i.e., CNC-MDSC Interface) as follows (if
> > you decide to keep the abbreviations list we mentioned above - if not,
> > we will simply update in the running text):
> >
> > Original:
> > It describes a VN operation module that can take place
> > in the context of the Customer Network Controller (CNC)-
> > Multi-Domain Service Coordinator (MDSC) interface (CMI) of
> > the Abstraction and Control of Traffic Engineered (TE)
> > Networks (ACTN) architecture where the CNC is the actor of
> > a VN Instantiation/modification/deletion as per RFC 8453.
> >
> > This module uses following abbreviations:
> > - VN: Virtual Network
> > - AP: Access Point
> > - VNAP: Virtual Network Access Point
> > - LTP: Link Termination Point
> > - PE: Provider Edge
> > - COS: Class of Service
> >
> >
> > Perhaps:
> > It describes a VN operation module that can take place
> > in the context of the Customer Network Controller (CNC)
> > Multi-Domain Service Coordinator (MDSC) interface of
> > the Abstraction and Control of Traffic Engineered (TE)
> > Networks (ACTN) architecture where the CNC is the actor of
> > a VN instantiation/modification/deletion as per RFC 8453.
> >
> > This module uses following abbreviations:
> > - VN: Virtual Network
> > - AP: Access Point
> > - VNAP: Virtual Network Access Point
> > - LTP: Link Termination Point
> > - PE: Provider Edge
> > - COS: Class of Service
> > - CMI: CNC-MDSC Interface
> >
> >
> > Dhruv: Ok!
> >
> >
> > e) Because this description clause mentions RFC 8795, should a
> > reference to it be added as well?
> >
> > container underlay {
> > description
> > "An empty container that can be augmented with underlay
> > technology information not supported by RFC 8795 (for
> > example - Segment Routing (SR).";
> > }
> > reference
> > "RFC 8454: Information Model for Abstraction and Control of TE
> > Networks (ACTN)";
> >
> >
> > Dhruv: yes!
> >
> >
> > f) Note that the YANG module has been updated per the formatting
> > option of pyang. Please let us know any concerns.
> >
> > Dhruv: No concerns!
> >
> >
> > -->
> >
> >
> > 14) <!--[rfced] We note that IANA lists both RFCs 6020 and 8407 as
> > references for the "YANG Module Names" registry. Should this
> > text be updated to add RFC 8407 (and an entry added to the
> > Informative References section)?
> >
> > Original:
> > IANA is requested to make the following allocation for the YANG
> > module in the "YANG Module Names" registry [RFC6020]:
> >
> > Perhaps:
> > IANA has made the following allocation for the YANG module in the
> > "YANG Module Names" registry ([RFC6020] and [RFC8407]):
> >
> > -->
> >
> > Dhruv: No! Keep the original. I see the same in many recently published
> YANG RFCs.
> >
> >
> >
> > 15) <!--[rfced] Replacing "this" with its antecedent may help the reader
> > with clarity.
> >
> > Original:
> > It should be noted that this YANG module relies on the TE-Topology
> > Model [RFC8795] by using a reference to an abstract node to achieve
> > this.
> >
> > Perhaps:
> > It should be noted that the VN YANG module described in this document
> > relies on the TE-Topology Model in [RFC8795] by using a reference to
> > an abstract node to provide VN-level constraints and optimization
> > criteria.
> > -->
> >
> >
> > Dhruv: Okay!
> >
> >
> >
> > 16) <!--[rfced] We have received guidance from Benoit Claise and the YANG
> > Doctors that "YANG module" and "YANG data model" are preferred.
> >
> > a) We will update to use the above forms unless we hear objection.
> >
> > b) Note that we have already updated the short/running title of the
> > document from "VN YANG Model" to "VN YANG Data Model". Please let us
> > know any objections.
> >
> > c) Please let us know if any uses of "VN model" (particularly in the
> > Introduction) should also be updated with the above guidance in mind.
> > We see the following inconsistent use of that term. Please also let
> > us know any updates to the capitalization scheme of this term.
> >
> > VN model vs. VN Model
> >
> > Dhruv: VN model
> >
> >
> > VN module
> >
> > Dhruv: we can change that to VN model (and also change TE-topology
> Connectivity Matrix module -> TE-topology model)
> >
> >
> >
> > VN-YANG model vs. VN YANG model vs. VN Yang model
> >
> >
> > Dhruv: VN YANG model
> >
> >
> > d) Please review the way that the module from RFC 8795 is referred to
> > and let us know if/how this may be made uniform:
> >
> > TE-Topology Model vs. TE-topology Model vs. TE-Topology model
> > vs. TE-topology model vs. TE Topology model
> >
> > and
> >
> > TE-Topo Model vs. TE-topo model
> >
> > and
> >
> > TE-topology YANG
> > TE-topo
> >
> >
> > Dhruv: TE Topology model (we can change all of the above to this)
> >
> > e) We also see "TE-tunnel Model" (with Model capped). Please review
> > and advise on if Model should be used for these names of YANG modules.
> >
> >
> > Dhruv: change that to "TE model"
> >
> >
> > -->
> >
> >
> > 17) <!-- [rfced] We had a few comments/questions regarding sourcecode and
> > artwork elements:
> >
> > a) FYI - We updated <artwork> to <sourcecode> in Sections 4.3.1,
> > 4.3.2, 5, and 6 and in Appendix B.1 and B.2. Please confirm that this
> > is correct.
> >
> >
> > Dhruv: ok
> >
> >
> > b) Please consider whether the "type" attribute of any sourcecode
> > element should be set and/or has been set correctly.
> >
> > The current list of preferred values for "type" is available at
> > <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
> > If the current list does not contain an applicable type, feel free to
> > suggest additions for consideration. Note that it is also acceptable
> > to leave the "type" attribute not set.
> >
> >
> > Dhruv:
> > Section 4: yangtree
> > Section 5: yangtree
> > Section 6: yang
> > Appendix B.1 and B.2: json
> >
> >
> > c) FYI - We updated the list in Section 3.2 to <artwork> to match the
> > artwork in Section 2.1 and Appendix B.1. Please confirm that this is
> > correct.
> >
> >
> > Dhruv: ok
> >
> >
> > d) We note that the tree structures represented in Sections 4.3.1,
> > 4.3.2, and 5 all have line lengths over the 72-character limit. RFC
> > 8792 defines the use of the backslash character for breaking these
> > lines. We will update to use backslashes where necessary and add an
> > informative reference to RFC 8792 unless we hear objection.
> > -->
> >
> >
> > Dhruv: ok
> >
> >
> >
> > 18) <!--[rfced] We had the following questions related to figure titles
> in
> > this document:
> >
> > a) We note that Figures 2, 6, and 11 do not have titles while the
> > other figures in the document do. Please let us know what, if any,
> > titles you would like to add.
> >
> >
> > Dhruv:
> > Figure 2: VN members (Type 1 VN)
> > Figure 6: VN members (Type 2 VN)
> > Figure 11: Example
> >
> >
> > b) We note that Figures 9 and 10 have the same titles. Please let us
> > know if these figures can be differentiated in some way. We also feel
> > doing so might lead to an updated of this text, in which "In either
> > case" might be able to become more easily understandable to the
> > reader:
> >
> > Dhruv:
> > Figure 9: VN Compute with reference to TE topology model
> > Figure 10: VN Compute
> >
> >
> > Original:
> > In either case the output includes a reference to the single node
> > abstract topology with each VN-member including a reference to the
> > connectivity-matrix-id where the path properties could be found.
> >
> >
> > Dhruv: Maybe -
> > "Regardless of whether the TE topology model is referenced, the RPC
> output includes a reference to the single node abstract topology, with each
> VN member containing a reference to the connectivity-matrix-id where the
> path properties could be found".
> >
> >
> >
> >
> >
> >
> > c) We see the title of Figure 3 includes "One Node Topology" while the
> > title of Figure 4 is "Type 2 Topology". Should these be made more
> > similar? That is, is Figure 3 actually "Type 1 Topology"?
> >
> >
> > Dhruv: Makes sense to change!
> >
> >
> > -->
> >
> >
> > 19) <!--[rfced] We had the following questions/comments regarding
> > abbreviation use in this document:
> >
> > a) To match the guidance at
> > https://www.rfc-editor.org/styleguide/part2/#exp_abbrev, we will
> > remove the expansions from abbreviations that have already been
> > expanded (excluding repeats in the YANG). Examples as follows:
> >
> > VN
> > PE
> >
> > b) We have expanded these abbreviations on first use as follows.
> > Please let us know any objections:
> >
> > LSP - Label Switched Path
> > RPC - Remote Procedure Call
> >
> > c) To reduce redundancy, we cut repeated words from following an
> > abbreviation. Please let us know any objections.
> >
> > RPC call
> >
> >
> > Dhruv: okay to above!
> >
> >
> > d) We note that the document uses both "cos" and "COS" as relates to
> > Class of Service. Please review if this capitalization variance
> > should be made uniform and if so, which form is preferred.
> >
> >
> > Dhruv: cos is used when talking about the leaf in YANG, and COS for the
> generic concept.
> >
> >
> > -->
> >
> >
> > 20) <!--[rfced] The following terminology appears to have been used
> > inconsistently throughout the document. Please review each use
> > carefully and let us know if/how they may be updated. Note: it
> > may be easier for authors to directly update our edited XML,
> > which they are welcome to do.
> >
> > a) Please review the mixed use of capitalization, hyphenation, and
> > word order in the instances of the following. Please let us know
> > if/how to update.
> >
> > VN Members vs. VN members vs. VN-members vs. vn-member
> >
> >
> > Dhruv: lets use "VN member" as per RFC 8453, except when talking about a
> yang leaf "vn-member"
> >
> > VN Type vs. VN type
> >
> >
> > Dhruv: VN type
> >
> >
> > abstract node vs. Abstract Node vs. Abstract node vs. node abstract
> >
> >
> > Dhruv: abstract node
> >
> >
> > single-node-abstract topology vs. single node abstract topology
> > vs. single node topology abstract1
> >
> >
> > Dhruv: single node abstract topology
> >
> >
> > TE topology vs. TE Topology vs. TE-topology vs. TE network topology
> > vs. TE-topo
> >
> >
> > Dhruv: TE topology
> >
> >
> > Connectivity Matrices vs. connectivity matrix and Conn. Matrix
> > vs. conn. matrix
> >
> >
> > Dhruv: connectivity matrix
> >
> >
> > vn-compute vs. VN compute vs. Computed VNs vs. computed VN vs.
> > VN computation
> >
> >
> > Dhruv: VN compute
> >
> >
> > explicit path vs. explicit abstract path vs. Explicit path
> >
> >
> > Dhruv: explicit path
> >
> >
> >
> > b) Please review the use of multi-source vs. multi-src and
> > multi-destination vs. multi-dest and let us know if updates are
> > desired.
> >
> >
> > Dhruv: Section 7, update to multi-source and multi-destination
> >
> >
> > c) May we update to use hyphenation with VN-level when in attributive
> > position throughout?
> >
> >
> > Dhruv: if you do that, will you also do VN-member-level?
> >
> >
> > d) We note that this document uses "compute only" while
> > draft-ietf-teas-yang-te-36 uses "compute-only". Please let us know
> > how you would like to update for consistency.
> >
> >
> > Dhruv: yes please!
> >
> >
> >
> > -->
> >
> >
> > 21) <!--[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.
> >
> > For example, our script pointed out:
> >
> > native TE topology / native TE Topology
> > Native/White topology
> >
> >
> > Dhruv: This is fine! no change!
> >
> >
> > With the use of "Gray topology", we assume "Native/White topology" is
> > related. Please advise.
> >
> > Dhruv: Grey topology is from RFC 8453 as it is used there! No change for
> this!
> >
> > Thanks!
> > Dhruv
> >
> >
> > -->
> >
> >
> > Thank you.
> >
> > RFC Editor/mf
> >
> > *****IMPORTANT*****
> >
> > Updated 2025/01/27
> >
> > 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/rfc9731.xml
> > https://www.rfc-editor.org/authors/rfc9731.html
> > https://www.rfc-editor.org/authors/rfc9731.pdf
> > https://www.rfc-editor.org/authors/rfc9731.txt
> >
> > Diff file of the text:
> > https://www.rfc-editor.org/authors/rfc9731-diff.html
> > https://www.rfc-editor.org/authors/rfc9731-rfcdiff.html (side by
> side)
> >
> > Diff of the XML:
> > https://www.rfc-editor.org/authors/rfc9731-xmldiff1.html
> >
> >
> > Tracking progress
> > -----------------
> >
> > The details of the AUTH48 status of your document are here:
> > https://www.rfc-editor.org/auth48/rfc9731
> >
> > Please let us know if you have any questions.
> >
> > Thank you for your cooperation,
> >
> > RFC Editor
> >
> > --------------------------------------
> > RFC9731 (draft-ietf-teas-actn-vn-yang-29)
> >
> > Title : A YANG Data Model for Virtual Network (VN) Operations
> > Author(s) : Y. Lee, D. Dhody, D. Ceccarelli, I. Bryskin, B. Y.
> Yoon
> > WG Chair(s) : Oscar Gonzalez de Dios, Vishnu Pavan Beeram, Lou
> Berger
> >
> > 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
