Hi, What about the data models that do not follow 1D?
- templates: the intended data model and applied data model are disjoint - 'auto-duplex' corner-case: the intended and applied leaf are the same, but they will never have the same value - 'use-dhcp' corner-case: intended config just enables specific derived state to be used; disjoint data models Somebody asked an important question at the interim: Is the intent of this group to limit all YANG data models such that they conform to 1D? (IMO that is a non-starter) IMO requirement 1D presume that the solution involves separate objects in the YANG data model for intended and applied states, and therefore it is an invalid requirement. Only the 2 protocol-based solutions address this issue by using the same object identifier no matter which state is being queried. Andy On Fri, Oct 2, 2015 at 10:44 AM, Sterne, Jason (Jason) < jason.ste...@alcatel-lucent.com> wrote: > I agree with "e.g." rather than "i.e.". I'm sure there are lots of other > examples of situations where intended config and applied config don't match > when we consider the variety of systems out there that may use > NETCONF/YANG. We should include some of these examples in the draft (in > some informational section and have a reference/pointer to them just after > the definition). > > Note that this updated definition for 1.D does not preclude the applied > config object from matching the intended *before* it has been applied. Do > we need to clarify that with some "conversely" clause or is that clear > enough when considering the other requirements ? > > We should also cleanly define "applied" (and provide illustrative examples > of when something is and is not applied). Should that be a separate email > thread ? > > Jason > > > -----Original Message----- > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Robert Wilton > Sent: Friday, October 02, 2015 5:24 > To: Randy Presuhn; netmod@ietf.org > Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully > synchronized" in "Requirement 1.D" > > Hi Randy, > > On 01/10/2015 23:27, Randy Presuhn wrote: > > Hi - > > > >> From: Robert Wilton <rwil...@cisco.com> > >> Sent: Oct 1, 2015 10:01 AM > >> To: "netmod@ietf.org" <netmod@ietf.org> > >> Subject: [netmod] opstate-reqs issue #1 - Define/Clarify "fully > synchronized" in "Requirement 1.D" > >> > >> To clarify what I failed to eloquently express in the interim meeting. > >> > >> I propose changing the text for requirement 1.D. This also removes > >> the need to define what fully synchronized means. > >> > >> > >> Old text for 1.D > >> D. For asynchronous systems, when fully synchronized, the data > >> in the applied configuration is the same as the data in the > >> intended configuration. > >> > >> > >> Proposed text for 1.D: > >> D. When the configuration change for any intended > >> configuration leaf has been successfully applied to the > >> system (i.e. not failed, nor deferred due to absent > hardware) > >> then the existence and value of the corresponding applied > >> configuration leaf must match the intended configuration > >> leaf. > > Are "not failed" and "deferred due to absent hardware" the > > *only* possibilities? If not, then the "i.e." needs to be replaced > > with an "e.g." > I'm not sure if it is the only possibility. Two other possible reason > might be: > - Configuration that cannot be applied because some dependent > configuration hasn't been applied. (E.g. if you have configuration where > an interface-ref couldn't be fulfilled because the referenced interface > configuration hadn't been applied because either it had failed or been > deferred due to absent hardware). But perhaps this would be classified as > being one of the two cases above? > - There is also the case the configuration is currently in the process > of being applied. > > If it is agreed that github issue #2 (i.e. "Is there a requirement to > indicate why intended config != applied cfg?") is a valid requirement, and > I think that there might have been some support for this in the interim > meeting yesterday, then I would hope that the final solution would > enumerate the reasons why the applied configuration may not match the > intended configuration. > > As such, changing from i.e. to e.g. seems like a good choice. > > So also taking into account Martin's suggestion the updated proposed text > for 1.D would be: > > D. When the configuration change for any intended > configuration node has been successfully applied to the > system (e.g. not failed, nor deferred due to absent hardware) > then the existence and value of the corresponding applied > configuration node must match the intended configuration > node. > > Thanks, > Rob > > > > > > Randy > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > . > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod