Hi Joe, Thank you for the review and comments. The latest version of the I-D uses the new text agreed below. BR, Dan (on behalf of the authors). From: Joe Clarke (jclarke) <jclarke@xxxxxxxxx>
Sent: 14 August 2024 13:54
To: adrian@xxxxxxxxxxxx; ops-dir@xxxxxxxx
Cc: draft-ietf-teas-applicability-actn-slicing.all@xxxxxxxx; last-call@xxxxxxxx; teas@xxxxxxxx
Subject: [Teas] Re: Opsdir last call review of draft-ietf-teas-applicability-actn-slicing-07 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? [JMC] Yeah, it helps. And maybe change the southbound text in the figure to be physical device/network interface? It was that figure that really started me scratching my head as to why you’d go straight to the devices necessarily (you might, but you might also use another network-layer abstraction given some of the examples). Joe
Cheers,
Adrian
|
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
