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
On Sat, Sep 2, 2017 at 9:59 AM, Kent Watsen <kwat...@juniper.net> wrote:
>
>
> >> 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?
>
>
> 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.
>
>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
