Hello Tom, Thanks for your review. We tried to address your comments, see inline. Diff is here: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance-architecture-12 Best, Jean > -----Original Message----- > From: tom petch [mailto:daedulus@xxxxxxxxxxxxx] > Sent: Wednesday 9 November 2022 12:07 > To: last-call@xxxxxxxx > Cc: opsawg@xxxxxxxx; draft-ietf-opsawg-service-assurance- > architecture@xxxxxxxx; opsawg-chairs@xxxxxxxx; mcr@xxxxxxxxxxxx > Subject: Re: Last Call: <draft-ietf-opsawg-service-assurance-architecture- > 11.txt> (Service Assurance for Intent-based Networking Architecture) to > Informational RFC > > 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. Removed one unqualified use of type, otherwise the object being typed should be clear from the sentence. > > '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. > Added a paragraph: When designing a new type of subservice, one should carefully define what is the assured object or functionality. Then, the parameters must be chosen as a minimal set that completely identify the object (see examples from the previous paragraph). Parameters cannot change during the lifecycle of a subservice. For instance, an IP address is a good parameter when assuring a connectivity towards that address (i.e. a given device can reach a given IP address), however it's a not a good parameter to identify an interface as the IP address assigned to that interface can be changed. > 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-a > > rchitecture/ > > > > 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
