[yang-doctors] Modeling of protocol message structures

[Ebben Aries <[e-mail]>]

I wanted to solicit feedback/opinions from a recent review (that at
least 1 other of you have had the chance to review) - The draft in
question is draft-ietf-dots-rfc8782-bis-00

Now, this is the first I've seen to make its way through YD review (and
maybe there are others) but the above is an example of modeling the
message structure payload for the DOTS signaling channel over CoAP.
There is no relationship to NETCONF/RESTCONF and/or datastores but
rather just definitions of pure message structures as best as can be
described in the YANG language (with implementation details left to the
specficiation).

For the most part, I think this is fine and a possible use being code
generation but still need to factor in statements that will not
translate directly to underlying language semantics and/or rules and
restrictions that sit outside of the data-model (and only in the
specification or description stmt) - Is the use being force fit for this
type of case?

My questions/comments to everyone:

- Are we starting to see this as the norm for newer protocol
  specifications in general and is there any rule around such or is it
  up to each author if they want to model any message structures or not
  in the YANG language and publish a module?

- Is the above necessary?  Does this provide much if any advantage to
  doing so in comparison to the maintenance, publication and potential
  for confusion?

- We now have the potential for publication of a large amount of YANG
  models that may or may not apply to the regular use to date.  You
  cannot tell the difference or purpose of these modules by purely
  looking at any identifier in the module name or header today.

- To the above point, modules will be published that could very well
  conflict with proper names of future modules that are centered around
  datastore interaction for that same domain.

- (Specific to the review and not structures themselves) - Some modules
  related to above have been published and am assuming these did not go
  through YD review.  We now have very generic prefixes published such
  as 'data-channel'.  While of local significance, we should be more
  descriptive and unique across IETF or IANA published modules.

Thx

/ebben