> On 11 Jan 2017, at 13:53, Martin Bjorklund <m...@tail-f.com> wrote: > > Ladislav Lhotka <lho...@nic.cz> wrote: >> >>> On 11 Jan 2017, at 13:27, Martin Bjorklund <m...@tail-f.com> wrote: >>> >>> 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. >> >> 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. 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
