Daniele, Thanks for sending along your approval.
Once we hear back from Igor, this document will be ready to move forward in the publication process (see http://www.rfc-editor.org/auth48/rfc9731). RFC Editor/mf > On Mar 10, 2025, at 8:55 AM, Daniele Ceccarelli <daniele.i...@gmail.com> > wrote: > > Hi Megan, > > I approve the document. > Apologies for the late reply. > > Thanks > Daniele > > On Tue, Mar 4, 2025 at 8:13 PM Megan Ferguson > <mfergu...@staff.rfc-editor.org> wrote: > Bin, > > Thank you for your reply. We have updated the AUTH48 status page to reflect > your > approval. > > Please note that we will assume your assent to any further changes submitted > by your coauthors unless we hear otherwise at that time. > > Once we receive approvals from Daniele and Igor, this document will be ready > to move > forward in the publication process. > > The AUTH48 status page is viewable at: > > http://www.rfc-editor.org/auth48/rfc9731 > > Thank you. > > RFC Editor/mf > > > On Feb 25, 2025, at 1:27 AM, by...@etri.re.kr wrote: > > > > Hi, > > > > I approve it. > > > > Regards, > > Bin > > > > From: Young Lee <younglee...@gmail.com> > > Sent: Tuesday, February 25, 2025 7:42 AM > > To: Megan Ferguson <mfergu...@staff.rfc-editor.org> > > Cc: Dhruv Dhody <dhruv.i...@gmail.com>; RFC Editor > > <rfc-edi...@rfc-editor.org>; daniele.i...@gmail.com; i_brys...@yahoo.com; > > by...@etri.re.kr; teas-...@ietf.org; teas-cha...@ietf.org; > > vbee...@juniper.net; James Guichard <james.n.guich...@futurewei.com>; > > auth48archive@rfc-editor.org > > Subject: Re: AUTH48: RFC-to-be 9731 <draft-ietf-teas-actn-vn-yang-29> for > > your review > > > > 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
