The new 1-D works for me. It is similar in spirit to the proposal I just sent in the issue #4 thread.
Thanks, Kent On 10/13/15, 9:14 AM, "Robert Wilton" <[email protected]> wrote: >In an attempt to try and close on some of the proposed requirement text >before Thursday's interim meeting. > >Does anyone have any outstanding objections on using this proposed text >for Requirement 1.D, or is it sufficiently clear to update the draft, >and resolve issue 1? > >OLD text for Requirement 1: > > 1. Ability to interact with both intended and applied configuration > > A. The ability to ask the operational components of a system > (e.g., line cards) for the configuration that they are > currently using. This is the "applied configuration". > > B. Applied configuration is read-only > > C. The data model for the applied configuration is the same as > the data model for the intended configuration (same leaves) > > D. For asynchronous systems, when fully synchronized, the data > in the applied configuration is the same as the data in the > intended configuration. > > >NEW text (as above, changing 1.D only): > > 1. Ability to interact with both intended and applied configuration > > A. The ability to ask the operational components of a system > (e.g., line cards) for the configuration that they are > currently using. This is the "applied configuration". > > B. Applied configuration is read-only > > C. The data model for the applied configuration is the same as > the data model for the intended configuration (same leaves) > > D. When the configuration change for any intended configuration > node has been successfully applied to the system (e.g. not > failed, nor deferred due to absent hardware) then the > existence and value of the corresponding applied > configuration node must match the intended configuration > node. > > >Thanks, >Rob > > >On 06/10/2015 21:54, Juergen Schoenwaelder wrote: >> On Tue, Oct 06, 2015 at 09:00:30PM +0100, Robert Wilton wrote: >>> Hi Juergen, >>> >>> On 06/10/2015 17:01, Juergen Schoenwaelder wrote: >>>> On Tue, Oct 06, 2015 at 10:38:11AM +0100, Robert Wilton wrote: >>>>> Hi Kent, >>>>> >>>>> On 06/10/2015 01:40, Kent Watsen wrote: >>>>>> This issue appears to have become more like issue #5 should we >>>>>>mark >>>>>> this one a duplicate of the other? >>>>> I suggest that we can just finalize on the text being discussed to >>>>> replace 1.D and then resolve issue #1. >>>>> >>>>> Jason had proposed this text: >>>>> >>>>> When the configuration change for any intended configuration node has >>>>> been successfully applied to the system (e.g. not failed, nor >>>>>deferred >>>>> due to absent hardware) then the existence and value of the applied >>>>> equivalent of the node (whether that be a corresponding node in the >>>>>data >>>>> model, an attribute associated with the intended config node, the >>>>> configuration node read from a different datastore or context, etc) >>>>>must >>>>> match the intended configuration node. >>>> I have no clue what "an attribute associated with the intended config >>>> node" or "the configuration node read from a different datastore or >>>> context" or "etc". means. What exactly is an "applied equivalent of >>>> the node"? >>>> >>>>> Or perhaps this slightly briefer alternative is better?: >>>>> >>>>> D. When the configuration change for any intended >>>>> configuration node has been successfully applied to the >>>>> system (e.g. not failed, nor deferred due to absent >>>>>hardware) >>>>> then the existence and value of the corresponding, >>>>>possibly >>>>> notional, applied configuration node must match the >>>>>intended >>>>> configuration node. >>>> What is the purpose of the phrase "possibly notional"? >>> There was a concern that my previous text, i.e. as above but without >>> "possibly notional", implied that applied configuration had to be >>> actually represented as real data nodes in a YANG schema, which would >>> disallow the solutions presented in draft-kwatsen-netmod-opstate-00 and >>> draft-wilton-netmod-intf-ext-yang-00. >>> >>> On balance, my preference is to exclude the "possibly notional" phrase >>> if the text is sufficiently clear without it. >> My understanding is that draft-kwatsen-netmod-opstate-00 proposes to >> represent applied config as nodes in a different datastore, so there >> is no need for 'possibly notational'. I do not understand why >> draft-wilton-netmod-intf-ext-yang-00 is relevant here. Do you mean >> draft-wilton-netmod-opstate-yang-00? I do have major concerns about >> this particular proposal since it changes the YANG data encoding >> fundamentally. There was another proposal to use attributes, which is >> also not without problems but it is likely a bit less painful. But >> again, it all depends on the final definition of what applied config >> really is. So where is the latest version and how far are we with >> agreeing on it? >> >> Yet another way to look at this is to expose not the applied config in >> addition to the intended config (I have been told configs can be >> really large) but instead expose lets say a yang patch that says how >> the applied config differs form the running config. Having to retrieve >> two large configs just to diff them locally seems to a potentially >> expensive exercise, in particular if the difference is often small. I >> think Randy mentioned something like this before and no there is no >> I-D. But even with this approach, the definition without "possibly >> notational' would hold; you would just not expose the applied config >> entirely but instead a patch that allows to calculate it. >> >> /js >> > >_______________________________________________ >netmod mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
