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

[Ines Robles <[e-mail]>]

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]> 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
>
> Status:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework/
>
> Htmlized:
> 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
>
> Diff:
> 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]]
> *Envoyé :* dimanche 11 octobre 2020 12:03
> *À :* BOUCADAIR Mohamed TGI/OLN <[e-mail]>
> *Cc :* [e-mail]; [e-mail];
> [e-mail];
> [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.
>
>