Randy Presuhn <[email protected]> writes: > Hi - > >>From: Ladislav Lhotka <[email protected]> >>Sent: Sep 10, 2015 2:02 AM >>To: Randy Presuhn <[email protected]>, [email protected] >>Subject: Re: [netmod] Y26 again, sorry >> >>Randy Presuhn <[email protected]> writes: >> >>> Hi - >>> >>>> From: Andy Bierman >>>> Sent: Sep 9, 2015 12:10 PM >>>> To: Ladislav Lhotka >>>> Cc: Robert Wilton , Randy Presuhn , "[email protected]" >>>> Subject: Re: [netmod] Y26 again, sorry >>> ... >>>> I don't think it really addresses the design pattern very well. >>>> You want to claim that M and Q are both being developed at the >>>> same time,so it's OK that Q adds mandatory nodes to M. YANG >>>> has no such rule.YANG says a server can implement M and never >>>> implement Q.YANG says a server may implement M and then add Q >>>> in a future release.These conformance mechanisms do not align >>>> with your expectationsof how YANG can/should be used. >>> >>> I agree with Andy that there seems to be a mismatch in expectations. >> >>I wonder if we can explain these differences. Is your and Andy's >>expectation that the configuration schema has to reflect actual hardware >>configuration, perhaps even dynamically adjust to the changes? > > I can't speak for Andy, but I would expect that a server's > schema could change dynamically, as a result, for example, > of new hardware or software being introduced into a running > system. We were doing this in the late 1980's - it's one > of the things that pulled us into the subagent technology space.
My (faint) understanding of CMIP/GDMO is that it was about management objects and prototypes, which indeed makes such a plug-in architecture easier. NETCONF/YANG deals with documents and schemas instead, and I assume the data model is in mostly (always?) fixed by NETCONF/RESTCONF server implementation. Am I wrong? > >>In my view, the supported (and advertised) data model and hardware >>configuration of the device are two different things. > > They are different, but there are relationships. When a new > line card is inserted, I would expect the system to acquire > any necessary schema knowledge in order to manage that new > resource. Likewise, if non-present hardware is being provisioned, > part of that provisioning process (possibly implicit) is for > the system being provisioned to acquire the necessary schema > knowledge so that it can perform at least a preliminary validation of > the provisioning data. I would expect that schema parts related to the new hardware have to be present beforehand. Encapsulation in YANG models is just a matter of conventions, so I think a general solution to dynamically changing schemas is next to impossible, also because parts of data model semantics may be expressed in prose (descriptions). > >>> Let's look at a slightly more complex hypothetical case to tease >>> out how folks *want* things to work. Assume the following have >>> been defined: >>> >>> - base module M >>> - augmentation Q >>> - augmentation R >>> >>> On a server claiming to supporting the modules containing M, Q, >>> and R, respectively, which of the following might one encounter >>> concurrently? >>> >>> - plain M >>> - M+Q >>> - M+R >>> - M+Q+R >> >>It depends on what you mean by "encounter" but in terms of datastore >>validity the only possible answer IMO is M+Q+R. > > By "encounter" I mean if a client asks the server for all of its Ms, > and the server also supports Q and R, are all of the Ms *guaranteed* > to be M+Q+R, or is it possible that some of the Ms might lack Q or > lack R of lack both? If what netmod gives us is strictly M+Q+R, > how would one model a system inhabited by a mixture of the four > kinds of Ms? This very much depends on how M, Q and R are designed. In a typical case, such as ietf-interfaces or ietf-routing, the augmenting modules just add new alternatives (interface types, address families, routing protocols). Lada > > Randy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
