Hi Randy,
On 01/10/2015 23:27, Randy Presuhn wrote:
Hi -
From: Robert Wilton <[email protected]>
Sent: Oct 1, 2015 10:01 AM
To: "[email protected]" <[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]
https://www.ietf.org/mailman/listinfo/netmod
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
