On Thu, Sep 14, 2017 at 10:37 PM, Martin Bjorklund <m...@tail-f.com> wrote:
> Andy Bierman <a...@yumaworks.com> wrote: > > On Thu, Sep 14, 2017 at 1:30 PM, Kent Watsen <kwat...@juniper.net> > wrote: > > > > Maybe it is too early for NMDA to be making lots of rules about how > > > > > > > YANG works with new (and unimplemented) datastores. > > > > > > > > > > > > Juniper has the equivalent of <intended> already. I think others said > > > they had > > > > > > something like it as well. > > Yes, we have that as well. (No template expansion, but removal of > inactive nodes). > > > If I can only do YANG validation on expanded templates in <intended>, > does > > that mean > > it is impossible to do YANG validation on the templates themselves in > > <running>? > > The template subtree can only use YANG constraints on external structures > > in <intended> > > and not refer to itself in anyway (in <running>)? > > Note that the architecture draft does not specify any templating > mechanism, it merely points out that templating is a mechanism that > _can_ influence intended. When/if such a mechanism is designed, it > needs to work out all these details. > > Doesn't it say YANG validation is done on <intended> and not on <running>? If so, then how are YANG validation statements inside the template objects evaluated? Do they exist in both datastores, yet YANG validation is done in only 1 datastore? > > /martin > > Andy > > > > > The RD draft sure has a lot of normative details for something that does > > not use RFC 2119 > > terminology at all. I didn't know a Standards Track document could omit > > these terms. > > Architecture documents are usually Informational. > > > > IMO the RD draft should not mention YANG or XPath at all. > > That should be moved to an update to RFC 7950. > > Those parts need more work anyway. The ARCH can move forward > > without any dependence on YANG details. > > > > > > > > > Kent // contributor > > > > > > > > > > > > > > > > > > > Andy >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod