This draft is basically providing a YANG model as an abstraction over existing (connectionless OAM) functionality, perhaps with some intention of facilitating similar functionality in new spaces.  (E.g., ICMP ping/traceroute exist, but entries are also given for SFC, MPLS, MPLS-TP, TWAMP, BIER, and I do not expect that all of those currently have such functionality.).

The modeled functionality is intended to be run over management protocols such as NETCONF or RESTCONF (i.e., ssh or HTTPS), which are at least nominally secure transports.  Though it is possible to configure either of them in an insecure fashion, I don't feel a particular need to beat the reader over the head with notes about actually verifying TLS certificates, etc..  The security considerations duly mention that access control is appropriate and that some operations may be considered sensitive or vulnerable in some environments, which is true, and probably the most that can reasonably be said at this level of abstraction.

I do see several appearances of an abstract "location-type" field and other system identifiers ("identityref", "system-id", MAC/IPv4/IPv6 addresses), which  are sometimes considered sensitive, especially when they can be associated back to individual users, which leads to privacy considerations about user tracking and similar.  Since this is OAM work, I don't actually know that there are real users in scope as opposed to fixed infrastructure, but perhaps a statement in the security considerations about privacy and this sort of identifiers would still be useful.

The document could benefit from some general copy editing for language/grammar/etc., but unfortunately given the short turnaround between last call end and the telechat, I cannot provide a more detailed patch or comments at the present time.