[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Comments on draft-ietf-snmpconf-pm-02



I've just read the Policy-Based Management MIB draft.  Here are some
comments and questions on it. Some are just minor corrections, but
some are major design issues.


Several *Index object types have integer range restrictions
(0..65535). Why at all? Why 64k?

Why is pmPolicyFilter restricted to a maximum size of 65535 octets?
If there's a good reason for this size, why is pmPolicyAction not
restricted?

Why is pmPolicyFilterMaxLatency of type Integer32 (signed) but restricted
to 0..2147483647? Why not just Unsigned32?

What is the purpose of pmPolicyActionMaxLatency? At first sight, it
seems like an action is called exactly when a filter is evaluated being
true. Thus the action latency simply depends on pmPolicyFilterMaxLatency
and the result of the filter evaluation.

The pmPolicyPrecedence DESCRIPTION confuses me completely. ;-) Furthermore,
it says `These values must be unique on the local policy system...' which
is difficult to ensure, I think.

It is not possible to lookup pmPolicyTable rows by pmPolicyGroup,
since pmPolicyGroup is no INDEX element. However this might be useful.

The pmPolicyMatches DESCRIPTION says `The number of policies ...' while
it means the number of elements. However, I do not see much value in
this object type. When a manager reads this variable, it does not know
at which stage in policy evaluation this value is current.

The pmElementTypeRegOIDPrefix has a DESCRIPTION that explains the
separation of the prefix and the instance identifying part, which
consists of N sub-identifiers. This is what I guess is
correct. However, the text describes that "$1" can be used in place of
any (single?!) decimal sub-identifier, e.g. in section 6.2.1.

I think "$1" is not a good name, since there cannot be a "$2". How
about "*"?

It's explicitly stated that `no state is remembered from the previous
invocation' in filters and actions. So: how can counters be evaluated
by a filter in a meaningful way?

The DESCRIPTION of pmElementTypeRegName says it's a `description'.
I guess it should be a `name'.

The MIB module contains various comments. This is no good idea, since
this information is not accessible. Important information should be
places in DESCRIPTIONs. Unimportent information should be removed.

The pmCapabilitiesTable represents a new way to express agent
capabilities, but with a limited scope. I think it is not a good idea.

pmCapabilitiesType is of type OID. The DESCRIPTION says that IANA will
publish a list of valid values. Presuming this is a good idea at all,
it should be an enumeration type.

The comment in front of the pmCapabilitiesTable and the DESCRIPTION
of the pmCapabilitiesSubType talk about `base OIDs' of MIB modules.
What is this? The MODULE-IDENTITY node? E.g. what is the `base OID'
of IF-MIB?

The DESCRIPTION of pmCapabilitiesEntry talks about some
pmCapabilitiesRestrict* objects, while their names are
pmCapabilitiesModification*.

Some terminology is used not very consequently and not explained
clearly. Sections 5.2 and 5.3 introduce the term `script', while this
mean `filter' and `action'. The term `address' is introduced in 5.1
but not used at other places, e.g. where "$1" is explained in 6.2.1
or in the pmElementTypeRegOIDPrefix DESCRIPTION.

The grammar in section 6.1 containes weired quotes for the
unary_operator and char rules.

Section 6.2.1 contains the conditional sentence `...when the policy
MIB module resides on the same system as the manages elements.' This
conflicts with section 4 which says `These policies are executed on
managed devices, where the objects live [...] and where operations on
these objects will be performed.

getstring() (section 6.2.2) returns a string without a length
(probably NULL terminated). This means that no arbitrary octet strings
(containing zero bytes) can be handled.

Section 6.2.5 is named strcmp() but describes strncmp().

Accessor function names look quite arbitrary to me. Some use only
lowercase letters, others are mixed. Some use `_', others don't.
strcmp() is named after a well-known libc function, lc_strcmp()
is not (strcasecmp()).

What happens if "$1" appears in an action, but not in the filter?

Examples of useful filter/action pairs should be added.