On Wed, May 03, 2006 at 12:38:35PM -0700, Andy Bierman wrote:
There is always engineering trade-offs to consider.
I agree it will always be simpler on the NMS for
a particular task to use a specialized API that moves
complexity to the agent. It is not simpler on the agent
to add new specialized code than it is to reuse existing code.
I am not convinced that using a verb instead of a data model makes any
difference implementation wise on the agent. I accept that your
experience might be different from mine so we do not have to agree on
this.
This approach doesn't scale well.
By the time you define 5 or 10 specialized RPCs for each
possible feature, you have 5000 special RPCs
and no reusable code.
My background is work on DISMAN MIBs and I can assure you that the
fact that we had to cast every disman operation into gets/sets on a
data model did not make things simpler. In fact, it requires some
engineering efforts to cast out verbs from many data models that can
be provided as a library to be used by applications. In some MIBs, I
started to write down procedures how the various knobs should be used
to implement a verb. Here is also a quote from RFC 3535:
- Several standardized MIB modules lack a description of high-level
procedures. It is often not obvious from reading the MIB modules
how certain high-level tasks are accomplished, which leads to
several different ways to achieve the same goal, which increases
costs and hinders interoperability.
I also note that CLIs tend to have lots of verbs and even though you
might not like this approach, they have at least been successful.
Note that I am not arguing we should open up pandora's box and add
verbs for everything (e.g. "shutdown interface" vs. "set interface
status down"). But we should also not fall into the other extreme
where we strictly stick to a fixed set of verbs just for purity
reasons or not very detailed claims of "increased complexity".
We explicitly designed a protocol to provide
a small set of powerful standard operations which can
manipulate any arbitrary data model.
IMO, it is better to stick with this architecture
than ignore it and start on a path of specialized RPCs.
I thought we would have learned from SNMP's history and the success of
CLIs and that we would be a bit more flexible this time around and
take some of the irrational factors of humans also into account when
we design things.
Anyway, I think I stated my preference wrt. notification subscriptions
and if I am just a small minority who has some unusal implementation
experiences, I am fine to accept a more data driven approach (means I
will not object against it).
/js