Re: [OPSAWG] [Gen-art] Genart last call review of draft-ietf-opsawg-model-automation-framework-06

[Alissa Cooper <[e-mail]>]

Ines, thanks for your reviews. Med, thanks for making the updates. I entered a No Objection ballot.

Alissa


> On Oct 12, 2020, at 4:41 AM, Ines Robles <mariainesrobles=[e-mail]> wrote:
> 
> Hi Med,
> 
> Thank you very much for the provided information. I have updated my gen-art review.
> 
> BR,
> 
> Ines
> 
> On Mon, Oct 12, 2020 at 9:41 AM <[e-mail] <mailto:[e-mail]>> wrote:
> Hi Ines,
> 
>  
> 
> Thank you. A new version that takes into account all reviews, including yours can be seen at:
> 
>  
> 
> URL:            https://www.ietf.org/id/draft-ietf-opsawg-model-automation-framework-07.txt <https://www.ietf.org/id/draft-ietf-opsawg-model-automation-framework-07.txt>
> Status:         https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework/ <https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework/>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-model-automation-framework <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-model-automation-framework>
> Htmlized:       https://tools.ietf.org/html/draft-ietf-opsawg-model-automation-framework-07 <https://tools.ietf.org/html/draft-ietf-opsawg-model-automation-framework-07>
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-model-automation-framework-07 <https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-model-automation-framework-07> 
> 
>  
> 
> Please see also inline.
> 
>  
> 
> Cheers,
> 
> Med
> 
>  
> 
> De : Ines Robles [mailto:[e-mail] <mailto:[e-mail]>] 
> Envoyé : dimanche 11 octobre 2020 12:03
> À : BOUCADAIR Mohamed TGI/OLN <[e-mail] <mailto:[e-mail]>>
> Cc : [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> Objet : Re: Genart last call review of draft-ietf-opsawg-model-automation-framework-06
> 
>  
> 
> Hi Med,
> 
>  
> 
> Thank you very much for addressing my comments. Please find my answers below.
> 
>  
> 
>  
> 
> 
> > d- Figure 3: The box Device includes Device Modeling. Should be
> > added in Device as another box for "Resource Orchestration"? (As
> > e.g. Service has Service
> > Orchestration)
> > 
> 
> [Med] Resource orchestration/allocation is more on the network level. The network model definition says the following: 
> 
>       It can be used by a network operator to allocate resources (e.g.,
>       tunnel resource, topology resource) for the service or schedule
>       resources to meet the service requirements defined in a Service
>       Model.
> 
> Of course some of this may be distributed, but I don't think that we need to overload the document with this.
> 
>  
> 
> <ines> Ok,  it is fine for me, my question was more related to device resources e.g. sensors/actuators as device resources </ines>     
> 
>  
> 
> [Med] Thank you for the clarification. This is a sub-component of the overall “Device Modelling”. Please refer to “A.4.2.  Device Management”. We don’t want to overload figure 3 with many internal components.
> 
>  
> 
> 
> > e.3- In the explanation of the Functional Blocks and Interactions
> > section, why the following blocks are not defined/explained in the
> > subsections?: *Service Assurance *Specific Service
> > Creation/Modification *Specific Service Optimization *Specific
> > Service Assurance
> 
> [Med] We don’t repeat "Specific-*" as we do say the following: 
> 
>    The end-to-end service lifecycle management is technology-independent
>    service management and spans across multiple network domains and/or
>    multiple layers while technology specific service lifecycle
>    management is technology domain specific or layer specific service
>    lifecycle management.
> 
> We also include in the description of the journey among layers. For example, the service creation section says: 
> 
>    If the request is accepted, the service orchestrator/management
>    system maps such service request to its view.  This view can be
>    described as a technology specific Network Model or a set of
>    technology specific Device Models and this mapping may include a
>    choice of which networks and technologies to use depending on which
>    service features have been requested. 
> 
> That is basically about "Specific Service Creation".
> 
> Will double check, though.
> 
>   <ines> Ok,  thank you. But what about the service Assurance? </ines> 
> 
> [Med] A new sub-section was added.
> 
>   
> 
>  
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art