Ladislav Lhotka <lho...@nic.cz> wrote: > > > On 11 Jan 2017, at 12:16, Martin Bjorklund <m...@tail-f.com> wrote: > > > > Ladislav Lhotka <lho...@nic.cz> wrote: > >> > >>> On 11 Jan 2017, at 10:36, Martin Bjorklund <m...@tail-f.com> wrote: > >>> > >>> Ladislav Lhotka <lho...@nic.cz> wrote: > >>>> > >>>>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder > >>>>> <j.schoenwael...@jacobs-university.de> wrote: > >>>>> > >>>>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: > >>>>>> > >>>>>> I think we need protocol and YANG specs that are not tied to any > >>>>>> particular model and that are thus capable of matching unforeseen > >>>>>> real-world implementations. This is no sci-fi, HTTP and XML schema > >>>>>> languages work this way. > >>>>>> > >>>>> > >>>>> I disagree that HTTP and XML schema languages do the same thing. Our > >>>>> goal is interoperable configuration of network devices; the notion of > >>>> > >>>> Even now, a client that's programmed to write straight to running > >>>> isn't interoperable with a server that has candidate and read-only > >>>> running. A RESTCONF server that supports only JSON isn't interoperable > >>>> with a client that supports only XML. > >>>> > >>>> We are not in a situation that every pair of a randomly chosen server > >>>> and client need to be interoperable. It's IMO perfectly fine if IoT > >>>> and ISP networks use different clients. Yet, both can still use the > >>>> same RESTCONF, same YANG, and even same YANG modules. > >>> > >>> The fact is that that data models are written with a certain set of > >>> protocol features and datastores in mind (the "meta-model"). Some > >>> examples: > >>> > >>> If we had an "operational-state" datastore like the one proposed, we > >>> would not see the /foo vs /foo-state split. > >> > >> Yes, but I assume this will go away anyway. However, we can still have > >> YANG modules (and complete schemas) designed for the operational > >> datastore. The important property of the "meta-model" so far has been > >> that config and state data are separate, and this is not going to > >> change. > >> > >>> > >>> If SNMP would have had a CREATE operation, MIBs would not have used > >>> RowStatus. If NETCONF didn't have a way to create instances, we would > >>> have seen something similar in YANG models. > >>> > >>> If NETCONF had a way to add comments to any node in a datastore, we > >>> wouldn't have "leaf description" sprinkled throughout the models. > >>> > >>> If NETCONF didn't have a generic way to filter retreived data, we'd > >>> see lots of specific get-* rpcs in YANG models. > >> > >> Maybe, but are the last three points relevant to this discussion? > > > > The point is that data models are designed with some meta-model in > > mind. The meta-model includes (some) datastores. You wrote: > > But where and how is this reflected in existing YANG modules (except > for the foo and foo-state split, which is IMO a minor issue)?
I don't this split is a minor issue. For the openconfig group, this is one of the major problems with YANG, leading to their design with duplicate leafs. The reason for adding the operational state datastore in the form we propose in the draft it to be able to get rid of this split. > > I believe both the protocols and YANG can work with any set of > > datastores [...] > > > > And I don't think that this is true (practically). For example, a > > YANG module that is designed with the new operational state datastore > > in mind will be of limited use in a legacy NETCONF server. > > Please explain. If a YANG module is designed with this new architecture in mind, it will have a single top-level tree, which can support pre-configuration and different instances in the config and operational state. If such a module is implemented in a legacy NETCONF server, the only way to get the operational state is to used <get/>. But <get/> will return the union between running and operational state. The client can't tell if an instance is really present in the operational state, or just in the config. My idea what could be done e.g. with ietf-interfaces > is this: > > 1. Split it into two modules, say ietf-interfaces-config and > ietf-interfaces-state. The former would contain exactly what's now > inside "interfaces", and the latter will augment it with extra state > data that are now under "interfaces-state". > > 2. The data model for configuration datastores will be defined to > contain only ietf-interfaces-config whereas for operational-state > datastore it will be ietf-interfaces-config *and* > ietf-interfaces-state. If we do this for all modules then we haven't gained anything; we still have duplicate definitions. /martin > Am I completely misguided here? If not, then I don't see where the new > modules refer to any particular datastore model. Yes, they do reflect > that there is configuration and state data, but we don't want to get > rid of this distinction, right? > > Lada > > > > > > > > > /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
