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). > 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
