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

[Ebben Aries <[e-mail]>]

On Sep 24 12:45 PM, Andy Bierman wrote:
> 
> 
> 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
>

Yes and all great reasons however my questions/comments are more
specific as to the publication of protocol message structures in IETF
documents as published IETF and IANA YANG models.

This document is the first I've seen attempting to do such.

And are we going to go back through other protocols to date and develop
message structure modules for those?

Before I raise the question of intent as to why back towards the
document author, I wanted to understand if anyone else has been seeing
this approach in IETF documents yet (or if it is being
promoted/mandated)

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