[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: monitor schema



At 10:57 PM 4/10/2003, Pierangelo Masarati wrote:
>> I'm concerned with the use of the 'description' attribute
>> to hold monitored/managed values.   I think it would be
>> better to define 'monitored'/'managed' attributes, syntax
>> octet string w/ octet string equality matching, to hold
>> arbitrary values.  The 'monitored' attribute would be
>> NO-USER-MODIFICATION, the 'managed' would, of course, be
>> user modifiable.
>
>Do you intend that finer granularity may be later obtained
>by deriving specifical attributes from 'monitored' and
>'managed'?

I think we likely need to do some modeling here and develop
a few common classes/attributes to represent managed/monitored
elements.  Maybe we can derive (using the term loosely) from
CIM/LDAP.

>> For non-arbitrary values, specific schema should be developed.
>> Then 'description' could be used for as intended, to provide
>> a description of the objection.
>
>or borrowed from existing attribute types, e.g. namingContext
>for database suffixes, labeledURI for listeners and so.

A little of both.

>> I suggest we make this change in HEAD soon for release with
>> 2.2.  We could provide a flag (just for the 2.2 release) for
>> backwards compatibility to help with transition.
>
>Since most if not all values currently are of 'monitored' type,
>backwards compatibility may be provisionaly ensured by giving
>'description' the same value of the corresponding 'monitored'
>attribute.

We may want to split some compound values (such as that used
to monitor a connection).  This makes it easier to do things
like "list all the anonymous connections".

>I have no objections.  Could you please allocate OIDs
>for the purpose?

Sure.  I'm thinking we need to think more about the model
and then design an appropriate schema.  But I think a good
first step is to move away from 'description'.  Then maybe decide
how we want to model 'counters' (one object per counter,
or group them) then take on more complex elements.

>I'd consider this message a HEADS-UP for those who are
>currently using/developing based on back-monitor.

Yes.

Kurt