Re: [OPSAWG] Last Call: <draft-ietf-opsawg-model-automation-framework-06.txt> (A Framework for Automating Service and Network Management with YANG) to Informational RFC

[Brian E Carpenter <[e-mail]>]

Hi Med,

Thanks, that is much clearer to me.

I saw one typo in the changes:
 RESTOCNF ==> RESTCONF

Regards
   Brian

On 02-Oct-20 01:49, [e-mail] wrote:
> 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:[e-mail]]
>> Envoyé : mardi 29 septembre 2020 21:55
>> À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>; last-
>> [e-mail]
>> Cc : [e-mail];
>> [e-mail]
>> 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, [e-mail] wrote:
>>> Hi Brian,
>>>
>>> Please see inline.
>>>
>>> Cheers,
>>> Med
>>>
>>>> -----Message d'origine-----
>>>> De : Brian E Carpenter [mailto:[e-mail]]
>>>> Envoyé : mardi 29 septembre 2020 00:25 À : [e-mail]
>> Cc :
>>>> [e-mail];
>>>> [e-mail]
>>>> 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.
>