On 14/10/2015 19:00, Kent Watsen wrote:
Thank you Robert for bringing the discussion back to the github issues.
Robert writes:
> In particular:
> - does it include support for templating (as per
openconfig-netmod-opstate-01 section 7.3.)?
> - is it allowed to represent system created objects that have no
corresponding configuration?
>
> Requirement 1.D states
D. For asynchronous systems, when fully synchronized, the data
in the applied configuration is the same as the data in the
intended configuration.
>
> So, if this requirement statement stands as being valid (which I
think it should) then that would imply that the answer for both the
two issues above must be "no". The only question would be whether
these need to be explicitly listed out?
[KENT] so I think I have to (begrudgingly) agree with your logic. I
have heard the operators state that they want the intended/applied
comparison to be drop-dead simple. To that end, it would not be
possible to flatten templates or apply defaults, or make any other
change – it needs to be as close as possible to a carbon-copy of the
original intended configuration (where deviations are allowed only for
cases like a missing line-card). To this end, yes, I think that we
could tack on a statement like the following:
That is, the intended configuration is a subset of the applied
configuration where omissions are only due to when the
configuration cannot be applied (e.g., a missing line-card).
What do you think?
>> - how does it relate to the state of the system after a equivalent
synchronous config commit (if at all)?
>>
> Again, I think that definition of requirement 1.D, along with the
proposed definition of synchronous configuration operation vs
asynchronous configuration operation, will provide a sufficient answer
to this question. I.e. that the state of the system after an
asynchronous config operation must, when fully synchronized, be the
same as the state of the system after an equivalent synchronous
configuration operation completes and replies back.
[KENT] I agree with this, but I think it impacts issue #6 more so than
issue #4 - right?
The original question that I was responding to was recorded in the
description of issue #4, but I agree that this is also effectively
covered by the proposed descriptions for #6 anyway.
Thanks,
Rob
Thanks,
Kent
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
