Kent Watsen <kwat...@juniper.net> wrote: > > > 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?
I think the term "active configuration" can be interpreted to mean "intended configuration". I don't think we should file an errata at this point, and in any case we should wait until we have a (published) definition of the term. > 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. +1 /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
