All, This issue somewhat dropped from our radar - we didn't discuss it during the interim or since. Nonetheless, my interpretation of the below thread is that Robert's proposal was accepted. So I'm going to replace 1.D with the text below (albeit s/system/server/) and move this issue to the REVIEW state.
Thanks, Kent On 10/14/15, 2:08 PM, "Kent Watsen" <[email protected]> wrote: > >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
