Re: [OPSAWG] Benjamin Kaduk's No Objection on draft-ietf-opsawg-model-automation-framework-07: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Thu, Oct 22, 2020 at 08:58:29AM +0000, [e-mail] 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:[e-mail]]
> > Envoyé : jeudi 22 octobre 2020 06:05
> > À : The IESG <[e-mail]>
> > Cc : [e-mail]; opsawg-
> > [e-mail]; [e-mail]; Adrian Farrel
> > <[e-mail]>; [e-mail]
> > 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