> >> 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.
I fully agree and strongly support making YANG generally applicable and independent of protocols and datastores. We also agreed to put out encoding rules for particular protocols out of YANG specification. Mehmet > -----Original Message----- > From: netmod [mailto:[email protected]] On Behalf Of Ladislav > Lhotka > Sent: Monday, February 20, 2017 4:49 PM > To: Kent Watsen <[email protected]> > Cc: [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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
