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

[Ebben Aries <[e-mail]>]

On Sep 24 13:14 PM, Andy Bierman wrote:
> 
> 
> 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).
>

ack yep - so we have a few cases of rc:yang-data and sx:structure out
there not related to NC/RC

So in general - nothing wrong w/ this approach and left up to authors
atm but we could start to see message structures come at time of
protocol definition in one module while config/state (+
rpc/notification/action) for datastores come later on either questioning
the combination into the already published module set or trying best to
ensure module name/prefix/namespaces are correctly reflected towards the
intent of these modules

Simple example:
- 'ietf-bgp' is published defining message structures for the base wire
  protocol
- Later date we now look to publish config/state modules for BGP but now
  need to either look to combine into the same module or come up w/ some
  inconsistent naming for this new module set

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

Agreed and short of going back over existing protocols, is this
something the IETF is looking to promote/enforce going forward?  If not
then I question why for some and not others.

Not to mention likely the need for community based tooling for
consistent code generation from our new source of truth YANG.

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