> On 20 Feb 2017, at 15:53, Kent Watsen <kwat...@juniper.net> 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
