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

[Andy Bierman <[e-mail]>]

On Thu, Sep 24, 2020 at 12:16 PM Acee Lindem (acee) <acee=
[e-mail]> wrote:

> 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.
>


We have been using YANG to drive protocol message automation for years.
Since the tools already support YANG for NETCONF this is not hard to add.

The main reasons:
   - want a formal definition of the message exchanges
   - want to annotate the model with tool-specific extensions to automate
lots of corner-cases
   - want an encoding-neutral message definition
   - want to utilize existing support to send/receive YANG data in
different encodings
       - lots of XML now but we already cover all data with JSON and soon
CBOR
   - using augment it is easy to define message payloads in layers


Thanks,
> Acee
>


Andy


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