> This doesn't seem to be consistent with the rfc6241 section 5.1 that states:
> "The running configuration datastore holds the complete configuration
> currently active on the network device."
Good catch! RFC 6241 appears to be inaccurate, unless we assume "currently
active" means active from the control plane's perspective, but not necessarily
operationally active. Does this require errata?
Popping the stack on this issue, the issue remains as to what to do with
requirement 3:
3. Support for both transactional, synchronous management systems
as well as distributed, asynchronous management systems
A. For asynchronous systems, the ability to request a protocol
operation to not return (i.e. block) until the intended
configuration has been fully synchronized.
B. The protocol operation's response would indicate the result
of the operation (success, failure, partial, etc.)
Again, my position is that sub-requirements A and B are not actual requirements
in the sense that we're being asked to add to NETCONF/RESTCONF (the only
protocols supported currently) an ability to block protocol operations until
the intended configuration is fully propagated to the operational components of
a system. So I think that 3A and 3B should be removed.
But the top-level statement in 3 remains valid, and yet it now seems like a
duplicate to the requirement #1. That is, a synchronous system presumably has
no "applied" configuration whereas an asynchronous does. So it seems that
satisfying this requirements is one and the same as satisfying the desire for a
system to advertise (or not) support for an "applied" configuration. Agreed?
If this is agreed, then we can close this issue by replacing A and B with a
note indicating that requirement #3 is a duplicate of #1.
Thanks,
Kent
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
