Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt

From: Randy Presuhn <[email-masked]>
Date: Tue, 26 Jan 2016 11:15:29 -0800 (GMT-08:00)

Hi -

>From: Ladislav Lhotka <[email-masked]>
>Sent: Jan 26, 2016 6:50 AM
>To: Robert Wilton <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>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