> 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 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. 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. 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
