Hi Brian, Please see inline. Cheers, Med > -----Message d'origine----- > De : Brian E Carpenter [mailto:brian.e.carpenter@xxxxxxxxx] > Envoyé : mardi 29 septembre 2020 00:25 > À : last-call@xxxxxxxx > Cc : draft-ietf-opsawg-model-automation-framework.all@xxxxxxxx; > opsawg@xxxxxxxx > Objet : Re: Last Call: <draft-ietf-opsawg-model-automation- > framework-06.txt> (A Framework for Automating Service and Network > Management with YANG) to Informational RFC > > Hi, > > I have a question for clarification, and then a comment. > > First, consider these extracts: > > > 5.1. L2VPN/L3VPN Service Delivery > > > > In reference to Figure 5, the following steps are performed to > > deliver the L3VPN service within the network management > automation > > architecture defined in this document: > > > > 1. The Customer requests to create two sites (as per service > > creation operation in Section 4.2.1)... > ... > > 5.2. VN Lifecycle Management > > > > In reference to Figure 7, the following steps are performed to > > deliver the VN service within the network management automation > > architecture defined in this document: > > > > 1. Customer requests (service exposure operation in Section > 4.1.1) > > to create 'VN' based on Access point... > ... > > 3. The Customer exchanges connectivity-matrix on abstract node > and > > explicit path using TE topology model with the > orchestrator... > > In those examples, how does the customer "request" or "exchange" > data? I assume this is intended to happen by software, rather than > by telefax. [Med] We hope this can be by software if we want to benefit from the automation in the full cycle but the approach still apply independently how a service request is captured. We don't zoom that much on that interface because the document is more on the provider's side. So what protocol is involved, and which entity on the > customer side is doing it? [Med] The component at the client side are generally represented as service ordering (see RFC 4176). That component may interact with the Order Handling at the provider side using a variety of means such as https://www.rfc-editor.org/authors/rfc8921.txt (Section 5) or by offering a management interface to the customer, etc. Please let us know if you think that we need to add some text on this part. > > > 5.3. Event-based Telemetry in the Device Self Management > > > > In reference to Figure 8, the following steps are performed to > > monitor state changes of managed objects or resources in a > network > > device and provide device self-management within the network > > management automation architecture defined in this document: > > > > 1. To control which state a network device should be in or is > > allowed to be in at any given time, a set of conditions and > > actions are defined and correlated with network events > (e.g., > > allow the NETCONF server to send updates... > > Second, this is the first mention of NETCONF in the document, and > the only other mention is in the Security Considerations. I suggest > that there should be a short description of the role of NETCONF (and > RESTCONF) earlier in the document, either in section 3 or more > likely in section 4 (Functional Blocks and Interactions). [Med] Point taken. We will also clarify that in some cases the use of YANG does not require NETCONF/RESTCONF. > > Regards > Brian Carpenter _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
