Andy Bierman writes: >Perhaps the operational requirements are not that clear, so >the terminology is also not that clear?
Are we trying to agree on the former without the later? >Is there really a requirement to know detailed info about the >differences between intended and applied config? I'm assuming this will end up impacting either netconf operations or yang data model construction. At that point (if not before), we'll need clear terms for app writers and data modelers. >It seems like the general requirement is that the client >needs to know when it can start using the network resource >that has been added or modified in the intended config. Consider that case where you add interface config for an interface FRU that's not been inserted. This config might not be used for months, until the tech inserts the FRU. >There are 2 modes that fall out from this requirement: > 1) synchronous: do not return from this RPC until resources are ready > 2) asynchronous: return right away from this RPC, and inform the client > when the resources are ready (could indicate ready in the RPC response) Given the inherently squishy definition of "ready", I'd prefer to avoid #1. Thanks, Phil _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
