I think that an implementation that supports templates can indeed have the situation where the running is not valid. The template (when expanded) may provide data that completes the data in a way that makes it valid.
I can see how it is intuitive to consider that validation happens after template expansion. But it does break the letter of the RFC. Jason > -----Original Message----- > From: Ladislav Lhotka [mailto:[email protected]] > Sent: Monday, February 20, 2017 10:49 > To: Kent Watsen <[email protected]> > Cc: Sterne, Jason (Nokia - CA) <[email protected]>; [email protected] > Subject: Re: [netmod] netmod-revised-datastores: templates, interactions with > RFC6243 'report-all' > > > > On 20 Feb 2017, at 15:53, Kent Watsen <[email protected]> wrote: > > > > > > Hi Lada, > > > > > >>> Yes, the YANG would have to define schema for both the template and > >>> expanded forms. > >> > >> Are you saying that running and intended (may) have different schemas? > >> The draft indicates that only intended is subject to validation. > >> Either way, it significantly changes the rules of the game because > >> validation in RFC 7950 is bound to running. > > > > I've been assuming that there is only one configuration schema, but > > that the template schema wouldn't apply in the intended datastore. > > This might be an academic distinction if <edit/copy-config>, or > > RESTCONF's unified datastore, only act on the running datastore. Yes, > > I think my problem is rather the opposite: could running containing templates > be invalid? Of course, it depends on how templates work, which isn't clear > from > the document (yet). > > > we'd want to support read-only operations on 'intended', but I'm not > > entirely > sure about read-write operations, including the <lock> or even the <validate> > operations. > > > > Regarding moving validation from running to intended, I think that Section > 6.3 might be just poorly worded. At least, I took it to mean that semantic > validation conceptually takes place after the system has removed inactive data > and flattened templates. Not only does it seem intuitive, but it also helps > simplify must/when/etc. expressions, as they only need to target the > expanded/flattened template paths. > > OK, but RFC 7950 list a number of properties that must be true in "all data > trees". I suspect that running (or candidate) with unexpanded templates might > break some of these properties. > > > > > > >> I cannot help myself: we need to remove all dependecies on protocols, > >> specific datastores and data representation (encoding) from the YANG > >> spec in order to make it generally applicable. > > > > I made a similar comment recently here: https://www.ietf.org/mail- > archive/web/netconf/current/msg12356.html. Read the remainder of the > thread to see the response there. > > Yes, this has been discussed several times, in fact I proposed it even before > work on YANG 1.1 had started (at IETF 87). Juergen wants to have an > architecture document first, but I think we could instead limit the scope of > YANG, make it into kind of schema language for hierarchical data, and use as a > building block that does validation. > > Lada > > > > > That said, I definitely think that a 7950bis should remove all of the XML > > and > NETCONF encoding text in RFC7950. A number of these kinds of changes are > being tracked here: https://github.com/netmod-wg/yang-next/issues. > > > > > > Kent // as an author > > > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
