+1 Gert Sent from my Apple ][
> On 19 Oct 2015, at 18:10, Kent Watsen <kwat...@juniper.net> wrote: > > > 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" <kwat...@juniper.net> 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" <rwil...@cisco.com> 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 >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
