Re: Methods in SMIng?

[Jerome Duprez <Jerome.Duprez@atosorigin.com>]

    David, Juergen,

    Thank you for your answers.
    Let me include a few comments about methods requirements.


> Both, COPS-PR and SNMP do not support method invocations in the
> protocol. So if we add methods to SMIng, then we have three options (I
> can think of):

>

> - 1 You can define them, but they just do not work with COPS-PR or SNMP.

> For me, option 1 is a bit stupid because allowing people to define
> methods without being able to invoke then seems like a waste of time.

    Two remarks here :

    1) A FAQ, still not definitely answered, is : will SMIng try to be a
universal management information language, independant of protocols, or
merely be a fusion for SMI and SPPI and "restrict" itself to their
respective protocols?

    The current SMIng drafts seem a nice step towards the former, for
example a CORBA mapping seems close at hand, which would support methods.
    However I acknowledge that even the latter, humbler, approach is
already highly desirable, hopefully reducing the number of management
languages by one, and resulting in a more human-friendly and
parser-friendly language... and indeed it seems it is the majoritarian
opinion in the WG!...

    2) Even if SMIng restricts its scope to SNMP+COPS-PR, I think methods
would be useful, both in describing managed entities and in describing the
management operations a management system could perform on these entities.

Description of managed entities:

    Similarly to a "severity" extension to the event statement, a method
description woul carry information such as "to reset my managed entity,
take the value of attribute 1, write it to attribute 2, and use attribute
3 value as a timeout period before resetting attribute 2 to its original
value..."
    Such a description might be either in informal human language, or in a
formal, standardized or not, operations script (see below).
    A subsequent revision of the management portion of the managed entity
may retain the "reset" method, but simplify it to "set attribute 5 to
zero" : from the end-user's point of view, the meaningful information
about resetting the managed entity is the existence of a reset operation,
not the details of the attributes being involved in performing the
operation.

Management station capabilities:

    On the other hand (and end!), a management system may use extended
SMIng MIB description to define operations on these MIBs : to be explicit,
let's take an SNMP-centric example: whereas SNMP does not explicitly
support methods, a management system may support "manager-side" methods
that translate into a succession of native SNMP operations (or other
operations, such as Ping or anything).
    Such a method may be meaningless at the SNMP level, and even at the
managed entity level (which only sees the induced SNMP operations) : it
only has sense at the management station level.

    This may sound awfully proprietary, but the same may hold true for the
event's severity extension example : the severity may be either an
implicit notion of the managed entity, or a notion introduced by the
management station, which knows how to evaluate, sort, handle, events
severity.

    Well, I have a few more questions about such extensions : I'll merely
send another post entirely dedicated to extensions.


> 2 We emulate method invocation on top of what the protocol provides
>   us. In other words, we define some interesting SNMP/COPS-PR tables
>   to emulate method invocations with set/install/remove operations.

> Option 2 is what I consider a truely ugly hack rather than a solution of
> the problem.

    I naively see the issue as the definition of a script language,
defining not only elementary GETs and SETs but also algorithms, and
arithmetic and logic operations on attribute values (see my contrived
reset example above)...
    Unfortunately consensus about standardizing such a management script
language seems far more unlikely than a management info declarative
language, though some vendors have already unsuccessfully tried this.

    If we give up a standard operations script or an operations table, we
may still consider proprietary operations : such a management system would
define its own extension to define/handle methods "implementation", but
putting such an extension statement in the context of a core language
"method" block would enable other management software parsing the same
SMIng "MIB" to be aware of the existence of a method, and display its
description, discarding what they don't understand.


> 3 We convince the protocol folks to support method invocations in SNMP
>   and COPS-PR.

> Option 3 is IMHO technically the only way to do methods, but I doubt
> that the protocol folks are willing to go there. So there is a dilemma.
> And given this dilemma, I prefer to stay away from methods at this point
> in time (but make the language extensible so they might be added later).

David Harrington wrote:

> We are working on trying to identify the requirements at this point.
> If we agree that having methods is a requirement, then we can consider
> syntax and signatures.

    Some existing management systems have already implemented such
methods; as it is not expressable in SMI, they are forced to use either a
proprietary model, or a standard model (such as UML) with a proprietary
mapping, which is the same.

    Putting methods as a core feature of the model would acknowledge their
operational need, which might later influence the protocol design. I deem
the need exists, but I confess it is not obvious; anyway it is easier to
take it into account while designing a new model, and hope the protocols
will take it into account later, than to convince the protocol folks
first!


    Regards,


--
===============================================================

Jerome Duprez (mailto:Jerome.Duprez@atosorigin.com)

Atos Origin

http://www.atosorigin.com/
http://www.ii.atos-group.com/sophia