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
