Re: [yang-doctors] Modeling of protocol message structures

["Acee Lindem (acee)" <[e-mail]>]

Hi Ebben, Esteemed Doctors,
It would be good to understand the reasons for using YANG as a message schema language and how it relates to the tooling and bits on the wire. Note that I didn't read the document other than looking at the YANG model so perhaps these questions are addressed.
Thanks,
Acee

On 9/24/20, 2:55 PM, "yang-doctors on behalf of Ebben Aries" <[e-mail] on behalf of [e-mail]> wrote:

    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

    _______________________________________________
    yang-doctors mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/yang-doctors