Subject: [netmod] regarding draft-bierman-netmod-yang-data-ext-00

From: Kent Watsen <[email-masked]>
Date: Fri, 1 Sep 2017 16:24:04 +0000

I'd like to start a discussion about adopting this draft...or something like it (see below).

The primary driver for wanting to expedite this draft is that it is being discussed as a required aspect of a chartered NETCONF WG effort to define a new encoding for YANG's 'notification' statement.

But I wonder if it would be better to define something like yd:uses-yang-data that can have both 'augment' and 'refine' as substatements.  The motivation for this is because the ANIMA WG wishes to define a "voucher-request" yang-data artifact that is essentially a "voucher" yang-data artifact that has had a leaf changed from "mandatory true" to "mandatory false" (via refinement) while also adding some new fields (via augmentation).  The current ANIMA solution defines a common grouping used by two yang-data statements, but this approach is neither intuitive nor lends itself to further downstream consumption.

Lastly, I wonder if it would be better to have a draft that [re-]defines a 'yang-data' statement outside of RFC8040.  This way drafts wanting to define yang-data wouldn't have to explain why they have an otherwise unexpected normative reference to RESTCONF.

Thoughts?

Kent // pick a hat

---

From: Andy Bierman <[email-masked]>
Date: Fri, 1 Sep 2017 09:39:43 -0700

On Fri, Sep 1, 2017 at 9:24 AM, Kent Watsen <[email-masked]> wrote:

> The primary driver for wanting to expedite this draft is that it is being
> discussed as a required aspect of a chartered NETCONF WG effort to define a
> new encoding for YANG's 'notification' statement.
>
> But I wonder if it would be better to define something like
> yd:uses-yang-data that can have both 'augment' and 'refine' as
> substatements.  The motivation for this is because the ANIMA WG wishes to
> define a "voucher-request" yang-data artifact that is essentially a
> "voucher" yang-data artifact that has had a leaf changed from "mandatory
> true" to "mandatory false" (via refinement) while also adding some new
> fields (via augmentation).  The current ANIMA solution defines a common
> grouping used by two yang-data statements, but this approach is neither
> intuitive nor lends itself to further downstream consumption.
>
>
I am not sure any new construct is needed at all.
The current definition covers it.

module foo {
  grouping plain-old-group1 {
      ...
  }

  rc:yang-data artifact1 {
     uses plain-old-group1;
  }
}

module bar {
   import foo { ... }

     rc:yang-data artifact2 {
       uses foo:plain-old-group1 {
          refine ...
       }
     }
  }

Lastly, I wonder if it would be better to have a draft that [re-]defines a
> 'yang-data' statement outside of RFC8040.  This way drafts wanting to
> define yang-data wouldn't have to explain why they have an otherwise
> unexpected normative reference to RESTCONF.
>
>
We went through that issue at least twice before RFC 8040.
There was no concern about this extension being in the RESTCONF spec.
We really have to try to keep the documents stable, and not republish an
RFC just to move
definitions around.

Thoughts?
> Kent // pick a hat
Andy

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

---

From: Kent Watsen <[email-masked]>
Date: Fri, 1 Sep 2017 17:43:11 +0000

> The current definition covers it.
<snip/>

Right, this is what is currently being done, but it is neither intuitive nor conducive to downstream extensions…

> There was no concern about this extension being in the RESTCONF spec.

I don't think people understood what was at stake at the time - yang-data has since taken on more prominence.    You write "no concern", but I think it was more like "no response", and the solution just rolled on.

> We really have to try to keep the documents stable, and not republish an RFC
> just to move definitions around.

We are talking about a new RFC (this draft).  I don't care if 8040 ever uses the new yang-data statement, it can forever have its own private definition.  I do care that we introduce a long-term solution (again, augment alone seems limited) and would like to make an incremental improvement for normative references.

K.  // contributor

---

From: Andy Bierman <[email-masked]>
Date: Fri, 1 Sep 2017 10:58:11 -0700

> nor conducive to downstream extensions…

I agree with Martin that we do not need to replicate plain YANG in
extensions.
We want to avoid new extensions, especially if a regular YANG statement
with work.

> I don't think people understood what was at stake at the time - yang-data
> has since taken on more prominence.    You write "no concern", but I think
> it was more like "no response", and the solution just rolled on.
>

I think I explained it well enough at the time.
There is a normative reference to RESTCONF to use yang-data.
This is just an RFC detail. In a server, the yang-library can indicate
that ietf-restconf is just imported (not implemented). It really does not
matter
that this extension is in ietf-restconf.yang.

> RFC
> We are talking about a new RFC (this draft).  I don't care if 8040 ever
> uses the new yang-data statement, it can forever have its own private
> definition.  I do care that we introduce a long-term solution (again,
> augment alone seems limited) and would like to make an incremental
> improvement for normative references.
>
>
>

IMO it is not worth the trouble. There are NMDA drafts to work on instead.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Fri, 1 Sep 2017 19:21:55 +0000

> I agree with Martin that we do not need to replicate plain YANG in extensions.
> We want to avoid new extensions, especially if a regular YANG statement with work.

By "downstream extensions" I meant future yang-data definitions.  Imagine we have
yang-data 'A' and then, later, a yang-data 'B' that builds on 'A' and then, even later, a
yang-data 'C' that builds on 'B'.   The grouping approach only works for 'B' if the
definition of 'A' had the foresight to define a grouping 'B' could use, but 'C' could be
out of luck.

> IMO it is not worth the trouble.

Gotcha.  What do other people think, would a "uses-yang-data" statement be generally
more useful?

K.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 1 Sep 2017 22:55:11 +0200

On Fri, Sep 01, 2017 at 07:21:55PM +0000, Kent Watsen wrote:
> 
> The grouping approach only works for 'B' if the definition of 'A'
> had the foresight to define a grouping 'B' could use, but 'C' could
> be out of luck.

This is generally true. YANG kind of require to design something for
reuse (and often you have to be carefuly how you word descriptions
etc.  for things that are intended to be reused).
 
> Gotcha.  What do other people think, would a "uses-yang-data"
> statement be generally more useful?

But does this mean we also do uses-yang-container, uses-yang-list,
uses-yang-xyz to other definitions as well? I do not think this is
desirable and why would yang-data be any different?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Sat, 2 Sep 2017 16:59:27 +0000

> desirable and why would yang-data be any different?

Oh, no.  I view yang-data as a body-stmt, not a data-def-stmt,
akin to 'rpc' and 'notification'.  But back to the draft's 
proposed solution, I understand that augment-stmt is a top-level 
body-stmt, but it's also a uses-stmt, and in that context, it is
a sibling to the refine-stmt.  Already ANIMA has a need to both
augment and refine a yang-data defined structure.  To me, a
'uses-yang-data' statement seems just one step more general than
a 'augment-yang-data' statement.

Specially, if we were updating YANG:

   // just added last entry
   body-stmts          = *(extension-stmt /
                           feature-stmt /
                           identity-stmt /
                           typedef-stmt /
                           grouping-stmt /
                           data-def-stmt /
                           augment-stmt /
                           rpc-stmt /
                           notification-stmt /
                           deviation-stmt /
                           yang-data-stmt)

   // something like this?
   yang-data-stmt            = yang-data-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [status-stmt]
                              [description-stmt]
                              [reference-stmt]
                              *(typedef-stmt / yang-data-grouping-stmt)
                              *data-def-stmt
                              [uses-yang-data-stmt]
                          "}") stmtsep

   // like 'uses-stmt', but with a different keyword
   uses-yang-data-stmt       = uses-yang-data-keyword sep identifier-ref-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [when-stmt]
                              *if-feature-stmt
                              [status-stmt]
                              [description-stmt]
                              [reference-stmt]
                              *refine-stmt
                              *uses-augment-stmt
                          "}") stmtsep

   // like 'grouping-stmt', but with 'action' and 'notification' removed
   yang-data-grouping-stmt       = yang-data-grouping-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [status-stmt]
                              [description-stmt]
                              [reference-stmt]
                              *(typedef-stmt / yang-data-grouping-stmt)
                              *data-def-stmt
                          "}") stmtsep

   yang-data-keyword              = %s"yang-data"
   uses-yang-data-keyword         = %s"uses-yang-data"
   yang-data-grouping-keyword     = %s"yang-data-grouping"

How close to this can we get using an extension statement, so that a
future adoption to YANG will be as seamless as possible?

K.

---

From: Andy Bierman <[email-masked]>
Date: Sat, 2 Sep 2017 11:02:42 -0700

Hi,

The use-cases for groupings/uses and augment are not identical.

Alternative NMDA Approach:

I don't see a big difference between defining YANG for an artifact vs.
defining some YANG for a special-purpose datastore.
There is nothing about the YANG data that is different.
There are only differences in the operations on that data,
which are properties of the datastore. Perhaps an <artifact> datastore
is a cleaner long-term solution.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 04 Sep 2017 09:29:13 +0200 (CEST)

> On Fri, Sep 1, 2017 at 10:43 AM, Kent Watsen <[email-masked]> wrote:

[Re: moving the definition of rc:yang-data to a new document]

> IMO it is not worth the trouble.

If it wasn't for the new 'augment-yang-data' statement, I'd agree.

But if we're doing a new standalone document for 'augment-yang-data',
I think we should also define 'yang-data' in that document.  The cost
is minimal, and we get one self-contained document with all things
related to 'yang-data'.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 4 Sep 2017 09:24:27 -0700

> is minimal, and we get one self-contained document with all things
So you are saying I was right 2 years ago when I brought this issue up
repeatedly?  ;-)
I don't agree that moving YANG definitions around for minor reasons is
helpful.
The larger YANG community (outside the IETF) are not asking for the
foundation
to be constantly replaced. They are not appreciative of constant churn in
the standards.

It seems we have already reached a point where we understand that modules
are cheap.
In some cases a new module does not even cost the length of a namespace
string in a packet.
We should learn to use YANG modularity, because it is almost free.  The
cost of high coupling
and low cohesion is much worse that the cost of splitting up YANG modules
at the start.

Andy