Re: [OPSAWG] Last Call: <draft-ietf-opsawg-service-assurance-yang-09.txt> (YANG Modules for Service Assurance) to Proposed Standard

[tom petch <[e-mail]>]

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
> [e-mail] mailing lists by 2022-11-22. Exceptionally, comments may
> be sent to [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> .
>