On 06/11/2022 11:02, The IESG wrote:
The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'Service
Assurance for Intent-based Networking Architecture'
<draft-ietf-opsawg-service-assurance-architecture-11.txt> as Informational
RFC
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@xxxxxxxx mailing lists by 2022-11-20. Exceptionally, comments may
be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.
This I-D uses 'type' in several different senses, mostly without
qualification.
In the companion YANG module I-D, one use of type is key - literally, in
the YANG sense - but there is no explanation as to what a type is. It
is crucial to the YANG module - obviously - but the explanation of it
there is circular IMHO. This I-D gives one example only of what a type
is and I think that that is inadequate. I think that this I-D needs to
explain what is and what is not a type, with guidelines that can be
applied by those creating supplementary YANG modules. The YANG I-D
should then reference this explanation and should also probably qualify
all uses of 'type' to make it clear what is being referred to.
'parameter' also seems problematic. The YANG I-D calls for augmenting
modules to add a YANG case to a choice with parameter types suitable for
the case but gives no guidance. These parameters are used, as in this
I-D, to decide whether or not the same service instance type is being
referred to. I think this I-D needs to provide guidance as to what a
suitable parameter is, how and where it is used, namespace, uniqueness,
and constraints that that imposes on the choice thereof.
Tom Petch
Abstract
This document describes an architecture that aims at assuring that
service instances are running as expected. As services rely upon
multiple sub-services provided by a variety of elements including the
underlying network devices and functions, getting the assurance of a
healthy service is only possible with a holistic view of all involved
elements. This architecture not only helps to correlate the service
degradation with symptoms of a specific network component but also to
list the services impacted by the failure or degradation of a
specific network component.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-architecture/
The following IPR Declarations may be related to this I-D:
https://datatracker.ietf.org/ipr/3858/
_______________________________________________
IETF-Announce mailing list
IETF-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
