Igor, Just a friendly reminder that this document awaits your approval. Note that this document and RFC-to-be 9732 will be ready to move forward in the publication process once you sign off.
Please review the current version of the document carefully as we do not make changes once published as an RFC. 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 Mar 10, 2025, at 9:54 AM, Megan Ferguson <mfergu...@staff.rfc-editor.org> > wrote: > > 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
