From: Andy Bierman <a...@yumaworks.com<mailto:a...@yumaworks.com>> Date: Wednesday, December 23, 2015 at 11:18 AM To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>> Cc: Ladislav Lhotka <lho...@nic.cz<mailto:lho...@nic.cz>>, Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>, "netmod@ietf.org<mailto:netmod@ietf.org>" <netmod@ietf.org<mailto:netmod@ietf.org>> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
On Wed, Dec 23, 2015 at 8:11 AM, Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>> wrote: From: Andy Bierman <a...@yumaworks.com<mailto:a...@yumaworks.com>> Date: Wednesday, December 23, 2015 at 10:46 AM To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>> Cc: Ladislav Lhotka <lho...@nic.cz<mailto:lho...@nic.cz>>, Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>, "netmod@ietf.org<mailto:netmod@ietf.org>" <netmod@ietf.org<mailto:netmod@ietf.org>> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01 On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>> wrote: On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka" <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org> on behalf of lho...@nic.cz<mailto:lho...@nic.cz>> wrote: > >> On 23 Dec 2015, at 04:06, Kent Watsen >> <kwat...@juniper.net<mailto:kwat...@juniper.net>> wrote: >> >> >> >> >> >> >> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka" >><netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org> on behalf of >>lho...@nic.cz<mailto:lho...@nic.cz>> wrote: >> >>> >>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder >>>><j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>> >>>> 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? Thanks, Acee 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 >>>> netmod@ietf.org<mailto:netmod@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org<mailto:netmod@ietf.org> >>> https://www.ietf.org/mailman/listinfo/netmod > >-- >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C > > > > >_______________________________________________ >netmod mailing list >netmod@ietf.org<mailto:netmod@ietf.org> >https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
