Hi Magan, I approve the document.
Thanks. Young On Tue, Feb 18, 2025 at 11:54 AM Megan Ferguson < mfergu...@staff.rfc-editor.org> wrote: > Dhruv, > > Thanks for pointing that out! We have added this change to the current > version and reposted (see below). > > We have recorded your approval at the AUTH48 status page (see below) and > will await approvals from your coauthors prior to moving forward in the > publication process. > > 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) > https://www.rfc-editor.org/authors/rfc9731-rfcdiff.html (comprehensive > side by side) > https://www.rfc-editor.org/authors/rfc9731-auth48diff.html (AUTH48 > changes only) > https://www.rfc-editor.org/authors/rfc9731-auth48rfcdiff.html (AUTH48 > side by side) > > The AUTH48 status page for this document is available here: > https://www.rfc-editor.org/auth48/rfc9731 > > Thank you. > > RFC Editor/mf > > > On Feb 18, 2025, at 6:24 AM, Dhruv Dhody <dhruv.i...@gmail.com> wrote: > > > > 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
