[Dots] Yangdoctors early review of draft-ietf-dots-telemetry-09

[Jan Lindblad via Datatracker <[e-mail]>]

Reviewer: Jan Lindblad
Review result: Not Ready

This is the YD early review of draft-ietf-dots-telemetry as requested by the
DOTS WG.

The ietf-dots-telemetry YANG module is not like other YANG modules. It
specifically states that it does not pertain to NETCONF/RESTCONF management,
but is only meant to be mapped to a specific CoAP based protocol
"dots-signal-channel" created by the DOTS WG. The draft-ietf-dots-telemetry
says in section 4.7:

   The DOTS telemetry module (Section 9.1) is not intended to be used
   via NETCONF/RESTCONF for DOTS server management purposes.  It serves
   only to provide a data model and encoding, but not a management data
   model.  DOTS servers are allowed to update the non-configurable 'ro'
   entities in the responses of DOTS telemetry messages.

While this approach is highly uncommon, after giving it some thought, I believe
this approach could be useful to client and server implementors. However, I
find two fundamental problems in the particular way this has been done in this
case. I believe the problems are fixable, but may involve updating existing
DOTS RFCs.

#1) YANG data declarations used as message bodies

You can define your own message types with whatever content you desire in YANG.
Just use rpc/action and notification statements. This draft does not do that,
but instead defines message bodies as if they were top level YANG config
elements. This obviously violates the aras of YANG that speak about data
stores, accessible data trees, and what not. Apart from confusing experienced
YANG users, the meaning of statements like "config false" is suddenly most
unclear when the foundations of YANG are disregarded.

In my opinion the top level of the module needs to be rewritten to use proper
YANG rpc/action and notification statements. The existing message bodies, and
the way they are augmented, could all work very well. It's just the framework
around them that isn't sound.

Unfortunately the problematic top level structures of draft-ietf-dots-telemetry
are based on structures imported from ietf-dots-signal-channel.yang, which is
already published in DOTS RFC 8782. I have not been able to find any YD review
of this module, so I would suspect none were ever performed. To make the DOTS
signal-channel framework usable, I would suggest obsoleting RFC8782 and write a
bis with an improved YANG action/notification based foundation. The number of
changed lines in the YANG can probably be kept rather small.

#2) Missing pieces in YANG to dots-signal-channel protocol mapping

The draft-ietf-dots-telemetry references CoAP RFC 7959, which defines a number
of basic management operations (GET, PUT, POST, ...), and CBOR RFC 7049 content
encoding, with the draft-ietf-core-yang-cbor-12 addendum for how YANG data is
to be encoded in CBOR. Unfortunately, a protocol specification that consists of
these three references is not quite complete. Since this is an early review, it
may be that the draft authors are already planning to pull the protocol
specification up a notch, or I may have missed some piece(s) of the puzzle. In
any case, a protocol specification on par with what is available for RESTCONF
or NETCONF would be required.

The dots-signal-channel specification in RFC 8782 makes an Informative
Reference to draft specification for a protocol called CoMI
(draft-ietf-core-comi-09), which attempts to take on the YANG to CoAP mapping.
One way of filling in the blanks for dots-signal-channel might be to leverage
the CoMI work. Fixing #1 would be required to leverage CoMI.

Currently, dots-signal-channel protocol specification (taken as the sum of
CoAP, CBOR and draft-ietf-core-yang-cbor-12) is missing information about
operation semantics, operation encoding, error handling, for example. RFC 8040
sections 5, 6, 7 or RFC 6241 sections 4, 7, 8 contain the sort of information
I'm looking for.

#3) Other than that, probably good

Other than issues #1 and #2 above, the module seems to be in pretty good shape.
Some content is hard to judge since the intended meaning of config true/false
for example is unclear, so a new review will be required after the fundamentals
have been resolved. The module is both easy to read and conforms with IETF
standards except as noted above, staying on the clean and simple side.