[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
some issues with draft-ietf-snmpconf-pm-06.txt
In working on implementing draft-ietf-snmpconf-pm-06.txt, several
issues have come up. Many of these are editorial in nature and perhaps
don't merit adding on a general issues list. Some are more fundamental.
Some are likely a reflection of things I don't get yet.
For convenience' sake, I am numbering as if these are on the
open issues list. This does not imply that all of these should
make it on the open issues list.
I apologize for bringing these up so close to the July 20 deadline, but
I have only recently been able to return to these issues.
38. Clarifying ec() and ev() names.
The function names in section 7 mechanism 2 are a bit cryptic.
Explanatory text here and in the function definition in 9.3.4
and 9.3.5 would smooth reading of the text. Something like
The ec() (element count) and ev() (element value) functions ....
39. Use of the term "context".
The use of the term "context" is frequently ambiguous in the
text. In every case, it should be made clear whether we
are talking about an execution context or SNMP context (contextName).
40. Definition of execution context - page 6
I am having some trouble with the definition of context on page 6.
The address of "this element' contains
. index of the element
. context the element was discovered in (contextName?)
. address of system element was discovered on
according to the running text, but does not seem to contain
any reference to the policy being executed or to the base OID
of the element the policy is being executed on. I think
the execution context is fully described by (index, context, address,
There is currently no way to get the base OID for the element
being considered, nor the index (say pmPolicyIndex) of the policy
being executed. I'm not sure it is necessary to be able to get
the OID, since the policies are going to be highly object-specific,
but it could be useful to be able to get the policy.
41. 9.3.6 context()
This is elementContext() in the running text, but context() in
the section header.
42. MIB knowledge
Section 7 implies that there will be some mechanism $* to tell where
the object ends and the index begins in an OID. However,
it has been made clear that the agent implementing this will
not have MIB knowledge (can't use "ifType.7" as an OID, for
Will this information be intuited from the pmPolicyElementTypeFilter?
If the script can't make decisions on the base object, what use
is it to be able to specify multiple element types in
43. 9.1.1 SNMP Operations on Non-Local Systems.
It appears (but is not completely unambiguous) that the contextName can
be passed by the optional context argument that is associated
with SNMP accessor functions. However, there no mechanism to pass
the contextEngineID that I can find. While it seems unlikely that there
will be proxy agents between the policy MIB agent and the managed agent,
not providing a contextEngineID blocks out much of this possibility.
44. 6.9.2 Scope of Constants
We simplified the language by removing scoping for variables.
Unfortunately, we have re-complicated things by introducing
scoping for constants (they only make sense in certain
accessor function invocations).
This leads to two problems:
. The compiler has to be sensitive as to the accessor function
name when compiling the script. This leads to unnecessary
complexity in the compiler.
. Suppose a variable and a constant have the same name. On
invocation of an accessor function that accepts the constant
values, which is used?
This would be solved (and would make the language much neater)
by declaring that the defined constants have global scope.
45. 6 9.4.1 regexp
The use of the word "copied" is ambiguous about the disposition
of the original contents of the "match" string. I'm guessing that
the original contents of "match" are replaced.
46. 7 9.4.2 regexpReplace
Will regexpReplace replace the first or all occurrences of the pattern?
"... which could be the same as the original string ..."
Is there any circumstance where the returned string would not be
the same as the original string if no matches are found?
47. die() semantics
From a recent message: die() as used in Perl has different
arguments than die() in policyScript. Should the die() accessor
function in policyScript be replaced?
48. pmPolicyTypeFilter SYNTAX
Since multiple element types can be registered, is there any
reason to limit the SYNTAX to (SIZE(0..128))?
Steve Moulton SNMP Research, Inc voice: +1 865 573 1434
Sr Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197
firstname.lastname@example.org Knoxville, TN 37920-9716 USA http://www.snmp.com