Re: [yang-doctors] Yangdoctors early review of draft-ietf-dots-telemetry-09

Hi,

Jan Lindblad via Datatracker <noreply@ietf.org> wrote:
> 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.

You may also want to look at RFC 8791, which defines a new YANG
extension statement "sx:structure".  This statement can be used to
define messages that are not intended to be generic rpcs or
notifications.

/martin

> 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.
> 
> 
> 
> _______________________________________________
> yang-doctors mailing list
> yang-doctors@ietf.org
> https://www.ietf.org/mailman/listinfo/yang-doctors