[alto] Éric Vyncke's No Objection on draft-ietf-alto-oam-yang-15: (with COMMENT)

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

Éric Vyncke has entered the following ballot position for
draft-ietf-alto-oam-yang-15: No Objection

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-alto-oam-yang/



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


# Éric Vyncke, INT AD, comments for draft-ietf-alto-oam-yang-15

Thank you for the work put into this document.

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

Special thanks to Mohamed Boucadair for the shepherd's detailed write-up
including the WG consensus and the justification of the intended status.

Other thanks to Ted Lemon and Scott Rose, the DNS directorate reviewers, please
consider this dns-dir review:
https://datatracker.ietf.org/doc/review-ietf-alto-oam-yang-15-dnsdir-telechat-lemon-2023-10-23/
(authors should probably reply on the email thread)
https://datatracker.ietf.org/doc/review-ietf-alto-oam-yang-14-dnsdir-telechat-rose-2023-10-19/
(and I have seen authors' reply)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS

## NMDA support

I often see YANG RFC stating their support (or lack of) NMDA (RFC 8342), is
there any reason why NMDA support is not stated in the text ?

## Section 3 (comments can be ignored)

While it does not hurt, several acronyms are really well-known, hence no need
to expand them.

Is "O&M" really used in other documents ? First time that I see this acronym.

## Section 5.1

As the module is prefixed by the ietf-alto namespace, strongly suggest to use
another term than "alto" at the root and even more s/alto-client/client/
s/alto-server/server/

## Section 5.3.1.1

As I am trusting the SEC ADs' reviews, I will not ballot a blocking DISCUSS,
please remove all HTTP (as opposed to HTTPS) in the text and in the data model
itself. Or is "http" used instead of "https" ? But, then why is there a "tls"

Later in the YANG module itself, it seems that the TLS termination would be
done in a different node, then how can this TLS termination be configured ? If
confirmed, then adding some text in this section would make the reader's task
easier.

## Section 5.3.2

I am sorry, but relying on SYSLOG in 2023 seems really legacy...

## Section 7.1

Some identities would benefit if the units where mentioned in the description
instead of providing a pointer to another RFC (e.g., for delay-rt), adding a
meaningful description (such as "round-trip delay") would also be benefitial
for the reader.

## Section A.5

The example should also have a listen to "::/0" for IPv6

# NITS

## Section 4.2 and other places

s/the data models/the data model/ or /the data modules/ as this I-D defines a
single data model consisting of several data modules.