On Thu, Oct 22, 2020 at 08:58:29AM +0000, [email protected] wrote: > Hi Ben, > > Thank you for the comments. > > An updated version taking into account you review is available at: > https://tinyurl.com/auto-iesg-review > > Please find inline replies to track the changes. > > Cheers, > Med > > > -----Message d'origine----- > > De : Benjamin Kaduk via Datatracker [mailto:[email protected]] > > Envoyé : jeudi 22 octobre 2020 06:05 > > À : The IESG <[email protected]> > > Cc : [email protected]; opsawg- > > [email protected]; [email protected]; Adrian Farrel > > <[email protected]>; [email protected] > > Objet : Benjamin Kaduk's No Objection on draft-ietf-opsawg-model- > > automation-framework-07: (with COMMENT) > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-opsawg-model-automation-framework-07: No Objection > > > > When responding, please keep the subject line intact and reply to > > all email addresses included in the To and CC lines. (Feel free to > > cut this introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss- > > criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation- > > framework/ > > > > > > > > -------------------------------------------------------------------- > > -- > > COMMENT: > > -------------------------------------------------------------------- > > -- > > > > [Med] Fixed the nits. Thanks. > [...] > > > Section 3.3 > > > > Note that it is important to correlate telemetry data with > > configuration data to be used for closed loops at the different > > stages of service delivery, from resource allocation to service > > operation, in particular. > > > > Is "closed loops" a well-known term in this space? > > [Med] It is used in management-related RFCs, e.g., RFC1224.
Ah, thanks for the reference. > [...] > > In addition, a customer may require to change the underlying > > network > > infrastructure to adapt to new customer's needs and service > > requirements. This service modification can be issued following > > the > > same Service Model used by the service request. > > > > I'm not sure I understand what "underlying network infrastructure" > > means here -- are there supposed to come into being new routers > > because the customer issues a request in the Service Model? > > > > [Med] This is typically when the customer asks to connect a new site, > requires a strong path diversity (disjoint paths), reach some prefix, etc. > These request may require changes to the network. > > Updated the text to cite some examples. Thanks. > [...] > > > > Section 4.2.1 > > > > configuration models for network elements; the configuration > > information includes: > > [...] > > o Security > > > > I think we need some more details than just "Security". Are these > > security protocols? Security properties? Physical security? What > > is in or out of scope for being covered by any indicated security > > mechanisms? > > > > [Med] This was cited in reference to L3NM. In that model, we manipulate the > following security functions: authentication keys, encryption, ACLs. > > Updated the text accordingly. > > [...] > > Section 5.1 > > > > L3NM inherits some of data elements from the L3SM. Nevertheless, > > the > > L3NM does not expose some information to the above layer such as > > the > > capabilities of an underlying network (which can be used to drive > > service order handling) or notifications (to notify subscribers > > about > > specific events or degradations as per agreed SLAs). Some of > > this > > > > I'm having a bit of trouble putting this bit together -- > > specifically the "not" in "does not expose". The rest of the text > > makes it sound like having the Service layer know some capabilities > > of the underlying network, or receive notifications from network- > > layer events, will be useful to the Orchestrator. But the text as- > > is seems to say that such information will not be provided to the > > Service layer. > > > > [Med] The L3NM as currently scoped does not allow to expose these > capabilities. The text is about identifying the limitations of the current > version of the model and describe the "target" architecture where such > features are provided. > > Tweaked as follows: > > L3NM inherits some of data elements from the L3SM. Nevertheless, the > L3NM as currently designed in [I-D.ietf-opsawg-l3sm-l3nm] does not > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > expose some information to the above layer such as the capabilities > of an underlying network (which can be used to drive service order > handling) or notifications (to notify subscribers about specific > events or degradations as per agreed SLAs). Some of this information > can be provided using, e.g., [I-D.www-bess-yang-vpn-service-pm]. A > target overall model is depicted in Figure 6. Thanks for clarifying. It seems like the point being made is that the current L3NM is a bit limited for "our" purposes, and to point to an extension that can help remedy those limitations, which makes sense. > [...] > > > Section 6 > > > > I agree with the secdir reviewer that it's worth repeating the > > disclaimer that customer/provider interfaces (and thus, the security > > considerations thereof) are out of scope for this document. > > [Med] OK. Added: > > The communication protocols that make use of a service model between > a customer and an operator are out of scope. Relevant security > considerations should be discussed in the specification documents of > these protocols. > > > > > When the service configuration incluedes "security" parameters (see > > my comment on §4.2.1), it is important to include the relevant > > information in the monitoring/assurance pipelines so that the > > correct functioning of the security mechanisms is tracked. > > [Med] Good point. Added: > > When a YANG module includes security-related parameters, it is > recommended to include the relevant information as part of the > service assurance to track the correct functioning of the security > mechanisms. > > > > > In order to prevent leaking sensitive information, special care > > should be considered when translating between the various layers > > in > > Section 4 or when aggregating data retrieved from various > > sources. > > > > It's also important to perform the necessary authentication and > > authorization checks (more specifically than just "special care") > > for operations that cross abstraction-layer boundaries. The > > "confused deputy problem" may be relevant for some of these cases, > > and is an important topic to mention as well. > > [Med] Updated to: > > In order to prevent leaking sensitive information and "confused > deputy" problem in general, special care should be considered when > translating between the various layers in Section 4 or when > aggregating data retrieved from various sources. Typically, > authorization and authentication checks should be performed to ensure > that a data is available to an authorized entity. The network > operator must enforce means to protect privacy-related information > included in customer-facing models. > > And added this NEW text: > > Access to some data requires specific access privilege levels. > Devices must check that a required access privilege is provided > before granting access to specific data or performing specific > actions. Thanks for these! > [..] > > > > Section 6.2 > > > > o Some Service Models may include a traffic isolation clause, > > appropriate technology-specific actions must be enforced at > > the > > underlying network (and thus involved network devices) to > > avoid > > that such traffic is accessible to non-authorized parties. > > > > It may be worth mentioning the potential misconception that a > > "virtual private network" always provides privacy against an > > attacker able to tap the network link(s); only some VPN technologies > > (can be configured to) do so. In some sense, whether such wire- > > level encryption is in use could be an aspect exposed at the service > > model layer. > > [Med] Updated to: > > o Some service models may include a traffic isolation clause, > appropriate technology-specific actions must be enforced at the > underlying network (and thus involved network devices) to avoid > that such traffic is accessible to non-authorized parties. In > particular, network models may indicate whether encryption is > enabled and if so, expose a list of supported encryption schemes > and parameters. Refer for example to the encryption feature > defined in [I-D.ietf-opsawg-vpn-common] and its use in > [I-D.ietf-opsawg-l3sm-l3nm]. Nicely said :) > [...] > > > > Network Element models (Figure 10) are used to describe how a > > service > > can be implemented by activating and tweaking a set of functions > > (enabled in one or multiple devices, or hosted in cloud > > infrastructures) that are involved in the service delivery. > > > > I don't really see how Figure 10 helps demonstrate *how* "a service > > can be implemented by activating and tweaking a set of functions"; > > it seems to just be a listing/categorization of things that have > > YANG models. > > [Med] Updated as follows: > > Network Element models (listed in Figure 10) are used to describe how > a service can be implemented by activating and tweaking a set of > functions (enabled in one or multiple devices, or hosted in cloud > infrastructures) that are involved in the service delivery. For > example, the L3VPN service will involve many PEs and require > manipulating the following modules: > > o Routing management [RFC8349] > > o BGP [I-D.ietf-idr-bgp-model] > > o PIM [I-D.ietf-pim-yang] > > o NAT management [RFC8512] > > o QoS management [I-D.ietf-rtgwg-qos-model] > > o ACLs [RFC8519] Thanks for all the updates! -Ben _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
