[OPSAWG] Éric Vyncke's Discuss on draft-ietf-opsawg-service-assurance-yang-10: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-opsawg-service-assurance-yang-10: Discuss

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-service-assurance-yang-10
CC @evyncke

Thank you for the work put into this document. A very interesting piece of work
and a well-written piece of text (even if I am balloting DISCUSS). The examples
are also helping.

Please find below some DISCUSS points (+ suggestions), some non-blocking
COMMENT points (but replies would be appreciated even if only for my own
education).

Special thanks to Michael Richardson for the shepherd's detailed write-up
including the WG consensus *but* it lacks the justification of the intended
status. It would have been nice to list the implementations (even if I know
one).

Please note that Tommy Pauly is the Internet directorate reviewer (at my
request) and you may want to consider this int-dir reviews as well when Tommy
will complete the review (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/reviewrequest/16806/

Also, thanks to the WG chairs and the responsible AD to bundle this I-D and its
companion to the same IESG telechat: it helps a lot!

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

### BCP14 template

As noted by
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-service-assurance-yang-10.txt
and Lars, the BCP14 template is not correct even if it is required for a
proposed standard (it mentions BCP13 ;-) ).

As I have further DISCUSS issues below, I am raising the trivial BCP14 issue to
a blocking DISCUSS.

### Section 3.3

To my SQL eyes, it hurts to use a -1 value for health-score when there is no
value. There is no "mandatory true" statement for this leaf, i.e., it can be
absent in the telemetry. Is there a semantic difference between the absence of
health-score and the value of -1 ? Is the SAIN collector expected to process
those 2 cases differently ?

Suggest to either remove the -1 sentinel value, or add "mandatory true"
attribute, or be specific about the difference (if any).

### Section 4

It is unclear from this section whether it applies to IETF-specified YANG
modules only? I.e., may a vendor augment this IETF YANG module in its own
namespace ? I guess so, but worth writing it (or restrict this section to
future IETF work only).


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


## COMMENTS

### Downref

As noted by
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-service-assurance-yang-10.txt
and Lars, there is a downward reference that was not mentioned in the IETF LC.

### Lack of YANG doctors review ?

Even if one author is Mr. YANG ;-), is there a reason why there is neither a
Last Call nor a Telechat review by the YANG doctors ?

### Section 1

```
[I-D.ietf-opsawg-service-assurance-architecture] specifies an
   architecture and a set of involved components for service assurance,
   called Service Assurance for Intent-Based Networking (SAIN).
```
The SAIN architecture draft is informational, so it cannot "specify". Please
use "describes".

### Section 3.1

```
   The two subservices presented above need different sets of parameters
   to fully characterize one of their instance.  An instance of the
   device subservice is fully characterized by a single parameter
   allowing to identify the device to monitor.  For ip-connectivity
   subservice, at least the device and IP address for both ends of the
   link are needed to fully characterize an instance.
```
s/two subservices presented/two example subservices presented/

While I am not English native speaker, I wonder whether the plural form should
be used for "IP address for both ends" ?

`The dependencies are modelled as an adjacency list,` or simply `The
dependencies are modelled as a list,` ?

### Section 3.2

```
   The date of last change "assurance-graph-last-change" is read only.
   It must be updated each time the graph structure is changed by
   addition or deletion of subservices, dependencies or modification of
   their configurable attributes.
```
Is 'under-maintenance' a triggering change to update the last change time ?
Perhaps worth mentionning.

### Section 3.3

Should the under-maintenance.contact be more specified? I.e., as a URI like
phone:[phone] or mailto:[e-mail] ? One goal of this document
(section 1) is to be 'machine readable' ;-)

leaf health-score-weight, the use of this leaf is rather under specified.
Should it rather be a float between 0.0 and 1.0 ? I also wonder whether the
last sentence of the description applies to this leaf ?

I will let to my fellow ART AD to check whether the waiver `Therefore, no
mechanism for language tagging is needed.` is acceptable for lack of i18n
support (for me: it is ok).

### Section 5

Is a device always a 'physical' device or can it be virtual as well ?

Should there be a link to the miscellaneous 'inventory models' in OPSAWG ? If
not, should there be more information about the device, e.g., its location.

### Section 6

I am not familiar enough with YANG, but should there be some text or YANG
statement to declare the 'device' leaf in this module as a foreign key to the
device module ?

Should the interface model handle the sub-interface (e.g., a specific VLAN on a
GigEthernet interface) ?

### Appendix C

Thanks for using an IPv6 example ;)

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments