Hi Ines, Thank you for the review. Please see inline. Cheers, Med > -----Message d'origine----- > De : Ines Robles via Datatracker [mailto:noreply@xxxxxxxx] > Envoyé : vendredi 9 octobre 2020 00:48 > À : gen-art@xxxxxxxx > Cc : opsawg@xxxxxxxx; draft-ietf-opsawg-model-automation- > framework.all@xxxxxxxx; last-call@xxxxxxxx > 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? > 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". > 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. > 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. > 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). > 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. > > 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. > 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). > > 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. > > 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
