On 08/11/2022 10:13, The IESG wrote:
The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'YANG Modules
for Service Assurance'
<draft-ietf-opsawg-service-assurance-yang-09.txt> as Proposed Standard
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-22. Exceptionally, comments may
be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.
I have never seen a YANG module with so few references and the one and
only one there is is missing from the I-D Normative References.
I think at least there should be a reference to the companion
Architecture document and wonder if there is a non-IETF literature
around for this topic which could be referenced.
I was going to comment on the lack of explanation of what a type is but
see that as a weakness of the architecture and so have commented thereon
on that I-D, which could then be a further reference for this I-D.
My impression from Appendix B is that this could spawn a large number of
related YANG modules for different functions such as 'device'. A
registry of such functions giving a canonical set of names seems a
likely need. This I-D could REQUIRE all such I-D to use a YANG prefix
of sain-....
identity service-instance-type {
"Identity representing a service instance.";
service instance or service instance type?
XPath within a grouping without a prefix leaves me wondering if that
prefix will be needed e.g. by additional type modules.
stop-date-time
What if the symptom is ongoing?
'must (be) after' could be a YANG constraint.
leaf id {
type string;
description
"Identifier of the subservice instance. Must be unique...
YANG string can be very, very long and can contain all sorts of
characters. This is a recurrent problem with YANG (which did not adopt
the SMI approach) and came up -again - on the Netmod list in October but
without a clear resolution IMHO, just that the current situation is ....
well, unsatisfactory.
leaf label {
type string;
config false;
description
"Label of the subservice, i.e., text describing what the
subservice is to be displayed on a human interface.
Again, without constraint this could be a nonsense. At least one AD is
keen on the I18N implications of display strings (which was an issue
with I2NSF I-D).
leaf contact {
type string;
Here there is some guidance but only as to the semantics - I suspect
guidance on the length and character set e.g. would be useful.
leaf service {
type string;
...
}
leaf instance-name {
type string;
Again unqualified string
leaf service {
type leafref {
path "/subservices/subservice/service-instance-parameter/"
+ "service";
}
description
"Name of the service type.";
The more I read the more confused I become. 'service' has just been
defined as the name of the service; how can it be 'service type' here?
As I have said, the use of 'type' in general needs more attention.
list instances {
key "name";
description
"Instances of the parent service type. The list must contain
an entry for every instance of the parent service.";
leaf name {
type leafref {
path
"/subservices/subservice/service-instance-parameter/"
+ "instance-name";
Another string as a key; vide supra.
identifier (device id, hostname, management IP) depends
Is that an e.g. or an i.e.?
s.5.3
leaf interface {
type string;
mandatory true;
description
"Name of the interface.";
As above, unconstricted string. This could be a leafref in order to
reference the YANG interface module; most RFC do just that.
Tom Petch
Abstract
This document specifies YANG modules for representing assurance
graphs. These graphs represent the assurance of a given service by
decomposing it into atomic assurance elements called subservices. A
companion document, Service Assurance for Intent-based Networking
Architecture, presents an architecture for implementing the assurance
of such services.
The YANG data models in this document conforms to the Network
Management Datastore Architecture (NMDA) defined in RFC 8342.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/
The following IPR Declarations may be related to this I-D:
https://datatracker.ietf.org/ipr/3859/
_______________________________________________
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
