Hi Brian, An updated version to address your comments can be seen at: https://github.com/boucadair/draft-ietf-opsawg-model-automation-framework/blob/master/draft-ietf-opsawg-model-automation-framework-06.txt You can track the changes at: https://tinyurl.com/ycpt62dh Please let me know if we need to say more. Thank you. Cheers, Med > -----Message d'origine----- > De : Brian E Carpenter [mailto:brian.e.carpenter@xxxxxxxxx] > Envoyé : mardi 29 septembre 2020 21:55 > À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@xxxxxxxxxx>; 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 Med, see below... > On 29-Sep-20 18:40, mohamed.boucadair@xxxxxxxxxx wrote: > > 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. > > Well, I'd rather see a standardised and generic solution to that > problem, as noted in my reply to Adrian. But indeed, that is the > requirement. > > > Please let us know if you think that we need to add some text on > this part. > > I think it needs just a few words in section 3 or 4, even just to > say that the mechanism is out of scope for this document. > > > > >> > >>> 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. > > Thanks. (For example, draft-ietf-anima-grasp-distribution can serve > for distributing YANG.) > > Brian > > > >> > >> 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
