From: Andy Bierman <[email protected]<mailto:[email protected]>> Date: Wednesday, December 23, 2015 at 10:46 AM To: Acee Lindem <[email protected]<mailto:[email protected]>> Cc: Ladislav Lhotka <[email protected]<mailto:[email protected]>>, Kent Watsen <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[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]<mailto:[email protected]>> wrote: On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka" <[email protected]<mailto:[email protected]> on behalf of [email protected]<mailto:[email protected]>> wrote: > >> On 23 Dec 2015, at 04:06, Kent Watsen >> <[email protected]<mailto:[email protected]>> wrote: >> >> >> >> >> >> >> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka" >><[email protected]<mailto:[email protected]> on behalf of >>[email protected]<mailto:[email protected]>> wrote: >> >>> >>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder >>>><[email protected]<mailto:[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. Thanks, Acee 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]<mailto:[email protected]> >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> [email protected]<mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/netmod > >-- >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C > > > > >_______________________________________________ >netmod mailing list >[email protected]<mailto:[email protected]> >https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
