Hi Med, Thank you very much for addressing my comments. Please find my answers below.
On Fri, Oct 9, 2020 at 11:04 AM <mohamed.boucad...@orange.com> wrote: > Hi Ines, > > Thank you for the review. > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Ines Robles via Datatracker [mailto:nore...@ietf.org] > > Envoyé : vendredi 9 octobre 2020 00:48 > > À : gen-art@ietf.org > > Cc : ops...@ietf.org; draft-ietf-opsawg-model-automation- > > framework....@ietf.org; last-c...@ietf.org > > Objet : Genart last call review of draft-ietf-opsawg-model- > > automation-framework-06 > > > > Reviewer: Ines Robles > > Review result: Ready with Issues > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed by > > the IESG for the IETF Chair. Please treat these comments just like > > any other last call comments. > > > > For more information, please see the FAQ at > > > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > > > Document: draft-ietf-opsawg-model-automation-framework-06 > > Reviewer: Ines Robles > > Review Date: 2020-10-08 > > IETF LC End Date: 2020-10-08 > > IESG Telechat date: Not scheduled for a telechat > > > > Summary: > > > > This document describes an architectural framework for service and > > network management automation, with respect of service, network and > > device level. > > > > I have some concerns as detailed below that I would like to be > > addressed before publication > > > > Major issues: None > > > > Minor issues: > > > > a-Introduction: > > > > "framework...that takes advantage of YANG modeling technologies" --> > > how does it take advantage? > > > > [Med] We can add this NEW text: > > Concretely, the following benefits can be provided: > > o Allow for vendor-agnostic interfaces to manage a service and the > underlying network. > > o Move from deployment schemes where vendor-specific network > managers are required to a scheme where the entities that are > responsible for orchestrating and controlling services and network > resources provided by multi-vendor devices are unified. > > o Ease data inheritance and reusability among the various > architecture layers promoting thus a network-wise provisioning > instead of device-specific configuration. > > o Dynamically fed a decision-making process (e.g., Controllers, > Orchestrators) with notifications that will trigger appropriate > actions allowing thus to continuously adjust a network stats (and > thus devices) to comply the intended service. > > Do we need to say more? > <ines> Ok, that is great, thank you </ines> > > > b- Section 2.2: I would add in the acronyms list: SP, ASes, SBE/DBE, > > E2E > > [Med] OK. > > > > > c- Section 3.1: > > > > It would be nice to add clarification: Data models can be classified > > .... -> Data models in the context of ..... can be classified... > > > > [Med] Agree. Changed to "Data models in the context of network management". > <ines> Ok, thank you </ines> > > > 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> > > > e- Section 4, Figure 4: > > > > e.1- [RFC8309] divides the Service Model into two categories: > > Customer Service Model and Service Delivery Model > > > > How these categories are descripted into the Service Lifecycle in > > the Figure? > > > > [Med] Customer Service Model are used at the service layer. See for > example this mention in the document: > > L2SM and L3SM are customer Service Models as per [RFC8309]. > > We are not using "Service Delivery Model" as this may not be specific. > Please refer to the following from 8309: > > Some of these models are classified as network service > delivery models (also called service delivery models or network > configuration models depending on the level at which they are > pitched), while others have details that are related to specific > element configuration and so are classed as network element models > (also called device models). > > We are using: network and device models for better clarity. > <ines> Ok, thank you </ines> > > > e.2- in the Device Level: Should be added Accounting Management and > > Security Management [RFC5706]? > > > > [Med] These can also be aggregated at the network level. I'm hesitating to > add a mention about this as this is usually dispatched among many modules > (including defining thresholds and notifications). We do cite YANG examples > to manage ACLs (RFC8519). > <ines> Ok</ines> > > > 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> > > > > f- Section 6: I think it would be nice to explain the security > > considerations based on the possible attacks/threats/privacy to > > Service Level, Network Level and Device Level. In other words, > > explains the vulnerabilities for each part of the entities that > > conform the proposed framework. > > > > [Med] Some considerations apply to all of the layer, but I will see > whether/how to capture this better. > <ines> Ok, thank you </ines> > > > g- Does this framework applies to the management plane, right? > > [Med] YANG can be used to tweak forwarding tables/install paths. Some > consider this as part of the control plane. YANG can also be used to > request services (e.g., customer-facing interface). > <ines> Ok, thank you </ines> > > > > > h- What do you think about policies, e.g.[rfc8328], should it be > > applied here? > > [Med] We used to have this text bit we removed it as there is not > > o Generic Policy Model: > > The Simplified Use of Policy Abstractions (SUPA) policy-based > management framework [RFC8328] defines base YANG modules > [I-D.ietf-supa-generic-policy-data-model] to encode policy. These > models point to other device-, technology-, and service-specific > YANG modules. Policy rules within an operator's environment can > be used to express high-level, possibly network-wide, policies to > a network management function (within a controller, an > orchestrator, or a network element). The network management > function can then control the configuration and/or monitoring of > network elements and services. > > But removed it as there is not wide support of this framework. > > <ines> Ok, thank you </ines> > > > > Nits/editorial comments: > > [Med] Fixed all of these. Thanks. > > > > > cutsomer-facing -> customer-facing > > > > data module --> data model? > > > > expand OSS/BSS -> Operations Support System (OSS) or a Business > > Support System > > (BSS) > > > > Thank you for this document, > > > > Ines. > > > > > > > > _________________________________________________________________________________________________________________________ > > 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
