Yes, in my view, section 4.5 goes a bit too far in making a certain solution part of the requirement.
The solutions that have been written up have different properties in terms of data modeling impact, device implementation impact, NMS implementation impact and backwards compatibility impact. Furthermore, we need to acknowledge that not all devices are asynchronous. These aspects need to be taken into account when selecting a solution. What is needed is clarity what the requirements are that we find agreement on. I believe it is possible to tweak the text in section 4 to something people can agree on. But as it is written in -01, I do not think we are there yet. /js On Wed, Sep 09, 2015 at 10:12:58PM -0400, Lou Berger wrote: > Juergen, > > It sounds like you are agreeing with the requirements but not the solution. > I think this is a valuable distinction, i.e., that it's possible to agree > with one but not the other. I'd also like to point out that the first part > of the discussion is limited to requirements only so we can focus on the > former before delving in to the latter . > > Lou > > > On September 9, 2015 6:01:20 PM Juergen Schoenwaelder > <j.schoenwael...@jacobs-university.de> wrote: > > >On Wed, Sep 09, 2015 at 10:16:06PM +0200, Benoit Claise wrote: > > > >>2. The requirements. > >>If there are still clarifications needed around the requirements in > >>draft-openconfig-netmod-opstate-01 section 4, or around the requirement > >>that the YANG models need some sort of hierarchy > >>(draft-openconfig-netmod-model-structure), like for the routing models, > >>... tomorrow interim meeting is your chance, or between now and then on > >>the mailing list. > > > >For the record (since I won't be able to join the call): I disagree > >with some of the details in the description of the requirement in > >section 4.5. I agree with the part that says that it should be > >possible to 'easily' locate the operational state corresponding to > >configuration state (and I would add that 'easily' means both for > >humans and machines). I would go even further to say that it should > >not just be 'easy' but also be 'robust'. What I disagree with is the > >part that suggests every 'selector' should be encoded in the schema > >path. Note that I am talking about the schema used on a device, I am > >not talking about the schema used within an NMS. > > > >/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 > >https://www.ietf.org/mailman/listinfo/netmod > > > > -- 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 https://www.ietf.org/mailman/listinfo/netmod
