Hi - >From: Ladislav Lhotka <lho...@nic.cz> >Sent: Jan 26, 2016 6:50 AM >To: Robert Wilton <rwil...@cisco.com> >Cc: "netmod@ietf.org" <netmod@ietf.org> >Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt >... >This can IMO work only if the schemas of configuration and >state data are identical or very similar. As an example, >take RIBs (state data) and a list of static routes (configuration). >There is a certain relationship between them, but the exact outcome >depends on a number of other factors. I don't see how they can be >co-located, or how the relationship can otherwise be formally expressed. ...
This is not a new problem. An approach was standardized almost two decades ago. That particular approach has a steep learning curve, but that doesn't mean that the concept should be discarded. In fairness, that specification tries to boil a larger ocean than the one surveyed here. See ITU-T Rec. X.722 Amendment 3 (aka ISO/IEC 10165-4/AMD3) on "Guidelines for the use of Z in formalizing the behaviour of managed objects." https://www.itu.int/rec/T-REC-X.722-199708-I!Amd3/en I think the real problem is the operational complexity of the devices being managed. This is a direct consequence of how the IETF has defined the operational characteristics (and options!) of the protocols in question, and of vendors' drive for market differentiation. If a gizmo is designed to be complicated, it should not surprise us when modeling its behaviour is also complicated. Randy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
