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
