> On 11 Jan 2017, at 14:05, 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. > >> >>> 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.
BTW, this approach could also solve the issue of different "levels" of data that Rob asked about previously: https://www.ietf.org/mail-archive/web/netmod/current/msg17125.html A server could then provide additional operational-state datastores, for example "operational-state-diagnostics" and "operational-state-registers". This is IMO quite a clean solution. Lada > > Lada > >> >> >> /martin >> >> >>> >>> Lada >>> >>>> >>>> >>>> /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 >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: 0xB8F92B08A9F76C67 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > _______________________________________________ > Netconf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
