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