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