> On 11 Jan 2017, at 15:37, Martin Bjorklund <[email protected]> wrote: > > Ladislav Lhotka <[email protected]> wrote: >> >>> On 11 Jan 2017, at 13:53, Martin Bjorklund <[email protected]> wrote: >>> >>> Ladislav Lhotka <[email protected]> wrote: >>>> >>>>> On 11 Jan 2017, at 13:27, Martin Bjorklund <[email protected]> wrote: >>>>> >>>>> Ladislav Lhotka <[email protected]> wrote: >>>>>> >>>>>>> On 11 Jan 2017, at 12:16, Martin Bjorklund <[email protected]> wrote: >>>>>>> >>>>>>> Ladislav Lhotka <[email protected]> wrote: >>>>>>>> >>>>>>>>> On 11 Jan 2017, at 10:36, Martin Bjorklund <[email protected]> wrote: >>>>>>>>> >>>>>>>>> Ladislav Lhotka <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder >>>>>>>>>>> <[email protected]> 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. >>>> >>>> Show me a single YANG data node definition that's duplicate in my >>>> concept above. But then maybe I didn't explain it properly. >>> >>> The interface's "type" leaf. With the new operational-state >>> datastore, /interfaces/interface/type in operational-state and >>> /interfaces-state/interface/type are duplicate. >> >> As I said, ietf-interfaces-state state would consist of augments >> containing extra state nodes (i.e. those that are not in >> configuration). So "type" won't be there. > > So how would a client learn the type of a system-controlled interface? > > >>>> Note also that you slightly misinterpreted my statement that you >>>> cited: >>>> >>>> I believe both the protocols and YANG can work with any set of >>>> datastores [...] >>>> >>>> I didn't say that there cannot be *modules* that are somehow designed >>>> for a particular datastore model - I meant YANG the language. >>> >>> Ok. Yes, you're right, but then we'd probably need some new statement >>> in each module that tells which meta-model the YANG module is written >>> for. >> >> I would prefer to have it as state data, basically separate YANG >> libraries for configuration datastores and operational-state. > > But the use case is that a particular module is designed for a certain > datastore model (which you wrote above). This is a design-time
Not necessarily, and certainly not all modules. In my example with ietf-interfaces, one could still emulate the current situation with "interfaces" and "interfaces-state" by defining these containers as two mount points and then schema-mounting the necessary schemas under each. There are some minor annoyances regarding namespaces but it could IMO also work fine for a client that uses the "old" datastore model. Lada > property, not a rum-time property, so state data (run-time) is not the > right solution. If a module is designed for a certain datastore > model, that module cannot be implemented in a server with some other > datastore model. > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
