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. > 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. /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 > > > > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
