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

[Andy Bierman <[e-mail]>]

On Thu, Sep 24, 2020 at 1:06 PM Ebben Aries <[e-mail]> wrote:

> 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.
>
>
Look at RESTCONF (RFC 8040). It uses YANG to define some protocol message
components.
Anima WG is also using YANG to define structures (not for use with NETCONF
or RESTCONF).



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


that seems like a separate issue, but nobody is suggesting that existing
protocols need to be rewritten to use YANG to define messages.

If somebody wants to use YANG for this purpose then RFC 8791 can be used.
It should be up to the WG I guess.



> 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


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