On Fri, Sep 1, 2017 at 9:24 AM, Kent Watsen <[email protected]> wrote:
>
> 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.
>
>
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 protected]
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
