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 <mohamed.boucad...@orange.com> 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:mariainesrob...@googlemail.com] > *Envoyé :* dimanche 11 octobre 2020 12:03 > *À :* BOUCADAIR Mohamed TGI/OLN <mohamed.boucad...@orange.com> > *Cc :* gen-art@ietf.org; ops...@ietf.org; > draft-ietf-opsawg-model-automation-framework....@ietf.org; > last-c...@ietf.org > *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 Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
