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?
Thanks,
Kent
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
