Good point that the wording does imply separate objects in the YANG data model. We should try to adjust the wording so that it could apply to other solutions (e.g. attributes, different datastore, etc). Perhaps the following ?
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 applied equivalent of the node (whether that be a corresponding node in the data model, an attribute associated with the intended config node, the configuration node read from a different datastore or context, etc) must match the intended configuration node. Templates: Perhaps templates (not instances of the template, but the template itself) are always considered as “applied” as soon as they are configured ? Auto-duplex: The configured duplex setting and the negotiated resulting operational value are two separate and independent leaves IMO. The configured duplex setting will have both an intended view and an applied view (which are separate an independent from the negotiated duplex). E.g. AdminDuplex (intended & applied) and OperDuplex (pure ‘derived’ state). I’m not familiar with the use-dhcp example. But maybe as soon as the system is actually “using DHCP” down on the linecards then the applied value would reflect that ? Re all data models conforming to 1D: If the solution ends up being in the protocols (instead of the models) then there are no requirements for models. If the solution ends up being in the models then I don’t think we can mandate that *all* models follow these requirements. Controllers/clients will have to be able to manage systems that have a mix of “opstate compliant” modules and non compliant modules. Operators who are keen on these requirements will encourage them to be adopted by as many IETF modules as possible. Implementation feasibility & impacts is something that we’ll need to consider but for now I’m trying to ignore that and purely clarify what is being requested. Jason From: Andy Bierman [mailto:[email protected]] Sent: Friday, October 02, 2015 14:11 To: Sterne, Jason (Jason) Cc: Robert Wilton; Randy Presuhn; [email protected] Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D" 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) <[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>] On Behalf Of Robert Wilton Sent: Friday, October 02, 2015 5:24 To: Randy Presuhn; [email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>> >> Sent: Oct 1, 2015 10:01 AM >> To: "[email protected]<mailto:[email protected]>" >> <[email protected]<mailto:[email protected]>> >> 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 > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/netmod > . > _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
