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?
Never mind; I misread your proposal, sorry about that. But I agree with Rob; how is the proposal with two modules different than having them in the same module (apart from the additional namespace required)? /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
