Hi Joe, Thanks for taking the time. > I found the document very informative and clear on both the > ACTN and network slicing fronts. Admittedly, there are a lot of moving parts > in TEAS that are referenced by this document, and I'm sure many operational > items when it comes to implementations (the excellent examples in this document > highlight these complexities). > > In terms of this document, I have one question. When I look at how the other > work with augment the service-level YANG modules and specifically figure 6, why > aren't the network models (e.g., L2NM and L3NM) referenced? I'd think they > might be more useful in figure 6 than a direct approach to the physical device > interface. Right, so possibly some confusion. As noted in RFC 9291 and RFC 9182, the L2NM and L3NM models sit at the level of "service delivery models" between the service orchestrator and the network orchestrator. Specifically, it is not a "network configuration interface" In ACTN terms, this matches the XMI shown in Figure 1 of our draft. Better still, on Figures 2 and 3. As noted, the XMI is an "internal" interface of the MDSC so, when we get to Figure 6, the L2NM and L3NM models don't appear. I think, however, we should find a way to mention the L2NM and L3NM models for completeness. Probably, in Section 4: OLD Note 2 - The Service Orchestrator-to-MDSC Interface (XMI) is an interface between two MDSC functional elements encompassing different MDSC service-related functions which is not defined in [RFC8453]. NEW Note 2 - The Service Orchestrator-to-MDSC Interface (XMI) is an interface between two MDSC functional elements encompassing different MDSC service-related functions which is not defined in [RFC8453]. Depending on the function being delivered, the XMI might be realised by the Layer 2 VPN Network Management YANG model [RFC9291] or the Layer 3 VPN Network Management YANG model [RFC9182]. END Would that help? Cheers, Adrian -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx