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

From: Ebben Aries <[email-masked]>
Date: Thu, 24 Sep 2020 12:54:41 -0600

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 24 Sep 2020 19:16:42 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    Thx

    /ebben

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Sep 2020 12:45:49 -0700

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

> 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" <
> [email-masked] on behalf of [email-masked]> wrote:
>

---

From: Ebben Aries <[email-masked]>
Date: Thu, 24 Sep 2020 14:06:27 -0600

On Sep 24 12:45 PM, Andy Bierman wrote:
>    - want to annotate the model with tool-specific extensions to automate lots
> of corner-cases
>    - 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 

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)

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Sep 2020 13:14:20 -0700

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

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

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

Andy

> >         specification or description stmt) - Is the use being force fit
> for
> >     this
> >         type of case?
> >

---

From: Ebben Aries <[email-masked]>
Date: Thu, 24 Sep 2020 17:28:14 -0600

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

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