On Wed, Dec 23, 2015 at 10:22 AM, Acee Lindem (acee) <[email protected]> wrote:
> > > From: Andy Bierman <[email protected]> > Date: Wednesday, December 23, 2015 at 11:18 AM > To: Acee Lindem <[email protected]> > Cc: Ladislav Lhotka <[email protected]>, Kent Watsen <[email protected]>, " > [email protected]" <[email protected]> > Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01 > > > > On Wed, Dec 23, 2015 at 8:11 AM, Acee Lindem (acee) <[email protected]> > wrote: > >> >> >> From: Andy Bierman <[email protected]> >> Date: Wednesday, December 23, 2015 at 10:46 AM >> To: Acee Lindem <[email protected]> >> Cc: Ladislav Lhotka <[email protected]>, Kent Watsen <[email protected]>, " >> [email protected]" <[email protected]> >> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01 >> >> >> >> On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (acee) <[email protected]> >> wrote: >> >>> >>> On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka" >>> <[email protected] on behalf of [email protected]> wrote: >>> >>> > >>> >> On 23 Dec 2015, at 04:06, Kent Watsen <[email protected]> wrote: >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka" >>> >><[email protected] on behalf of [email protected]> wrote: >>> >> >>> >>> >>> >>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder >>> >>>><[email protected]> wrote: >>> >>>> >>> >>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote: >>> >>>> >>> >>>>> I hope that nobody disagrees that the operational state design and >>> >>>>>how >>> >>>>> to structure the models are the two blocking factors to publish >>> YANG >>> >>>>> models. If you disagree or don't see this, let me know, I should >>> >>>>> communicate better. >>> >>>> >>> >>>> Even if it may spoil your day, I disagree that there is a blocking >>> >>>> factor that should stop us from publishing models. There seem to be >>> >>>> ways to address the requirements without having to block all work or >>> >>>> to redo what that we have published. But sure, if you make it a >>> >>>> blocking factor, it will be one. >>> >>> >>> >>> I agree with Juergen. It is not clear to me how the proposed split >>> >>>between intended and applied configuration is supposed to affect the >>> >>>data models we are working on. >>> >> >>> >> >>> >> As I understand it, solution #1 affects the models themselves, whereas >>> >>solutions #2 and #3 are transparent to the models. >>> > >>> >Then #1 looks like a non-starter to me. >>> >>> I’d like to point out that we also have the requirement to allow >>> retrieval >>> of derived-state along with intended-config and applied-config. This will >>> require modification to most of the existing YANG drafts as most now have >>> separate trees for config and operational state. Note that this is >>> discussed in sections 6, 7.3, and 7.4 of >>> https://www.ietf.org/id/draft-wilton-netmod-opstate-yang-02.txt. >>> >>> >> A NETCONF <get> with a subtree filter can retrieveg both config and >> non-config subtrees >> at the same time. A new RPC can be added (or existing <get> RPC >> extended) to >> filter various conditions. I don't see how the YANG data layout affects >> the definition >> of "rpc" statements in another module. >> >> >> There is the requirement to be able to do the retrievals but there is >> also this requirement: >> >> C. The mappings needs to be programmatically consumable >> >> >> Now, if the derived-state nodes are located with the config-nodes, then >> this is readily satisfied. Another way of satisfying the requirement may be >> structural and naming conventions but this is not as sure as co-location. >> >> > There can be meta-data returned (XML attributes) that identify the > additional properties. > This is better co-location since the pattern cannot be unintentional (as > it can with the > config-within-state containers). > > > This may be an option for published models. However, for models in > development, wouldn’t it be easier to just move the nodes rather than > defining the relationships in meta-data? > > I prefer an RPC-based solution using a similar approach to the <with-defaults> parameter already defined in NETCONF and RESTCONF. Not only does it work for all models without changing the data model, it only requires 1 subtree to be retrieved instead of 2. However, any solution that requires lots of data to be retrieved seems counter-productive to the most obvious use-case. It has been stated many times "what if the server is busy adding 100,000 routes, so that is why applied != intended". Well, if the server is busy applying config edits, then burdening the server with lots of retrieval requests can only slow it down. Thanks, > Acee > Andy > > > > > >> Thanks, >> Acee >> >> > Andy > > >> >> >> Thanks, >>> Acee >>> >> >> >> Andy >> >> >>> >>> >>> > >>> >Lada >>> > >>> >> >>> >> Kent >>> >> >>> >> >>> >> >>> >>> Lada >>> >>> >>> >>>> >>> >>>>> I hope that nobody really believes that because some people in IETF >>> >>>>>(or >>> >>>>> in any other SDOs) thinks that what those operators want is a bad >>> >>>>>idea, >>> >>>>> those operators will not get what they request/pay for from their >>> >>>>>suppliers. >>> >>>> >>> >>>> To be fair, those operators also tell us that they use protocols >>> that >>> >>>> are not IETF protocols and it remains somewhat unclear what those >>> >>>> protocols are we are expected to optimize data model solutions for. >>> >>>> >>> >>>> /js >>> >>>> >>> >>>> -- >>> >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >>> Germany >>> >>>> Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> netmod mailing list >>> >>>> [email protected] >>> >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> >>> >>> -- >>> >>> Ladislav Lhotka, CZ.NIC Labs >>> >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> netmod mailing list >>> >>> [email protected] >>> >>> https://www.ietf.org/mailman/listinfo/netmod >>> > >>> >-- >>> >Ladislav Lhotka, CZ.NIC Labs >>> >PGP Key ID: E74E8C0C >>> > >>> > >>> > >>> > >>> >_______________________________________________ >>> >netmod mailing list >>> >[email protected] >>> >https://www.ietf.org/mailman/listinfo/netmod >>> >>> _______________________________________________ >>> netmod mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >> >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
