On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder < [email protected]> wrote:
> On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote: > > > > > > > > I disagree that the datastore model is a protocol specific aspect. I > > > consider datastores an architectural component binding data models and > > > protocols together. In fact, the 'traditional' datastore model > > > > I would agree with this if datastores were a general concept in YANG, > but the revised-datastores draft explicitly introduces the "intended" and > "applied" datastores that may be irrelevant to other protocols using YANG, > and even needn't be used in all NETCONF implementations. I wouldn't call > this "an architectural component" of YANG. > > > > An architectural component of this new management framework (that does > not have a name). The fact that not all protocols may expose all > datastores is IMHO not a reason that the datastore model is not an > architectural framework. > > > If you are saying that it will have nontrivial impact on YANG, I would > like to see it explained in sec. 6.3. Without this information I am quite > reluctant to agree with the adoption. > > An operational state datastore has implications how one writes data > models. It may not directly affect YANG itself but surely the usage of > YANG. > > > See above - architectural aspects need to be relevant to all protocols. > > Yes, but relevant to all protocols does not mean every protocol needs > to expose say all datastores. But every protocol should be clear about > how what it exposes relates to the architectural framework. > > There is a "current solution" consisting of hard-wired object semantics (e.g., ifAdminStatus and ifOperStatus). This solution does not require special protocols or datastores, but it is being replaced by a generic solution. If the "generic" solution requires special procedures which differ on each protocol, then it might end up be worse than the hard-wired solution that works on every protocol. So I agree with Juergen that this is primarily an architectural issue. /js > Andy > > -- > 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 >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
