[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: some issues with draft-ietf-snmpconf-pm-06.txt
Steve Moulton wrote:
> 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 ....
I definitely agree.
> 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).
OK, I've done this.
> 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,
> object, policy).
The "address of this element" is different than the "execution context".
You are right that the execution context is fully described by (index,
context, address, object, policy). But within a script (where the policy
is implicitly known), the script will want to know the address of the
thing it is currently working on, and that is described by (index,
> 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.
The base OID can be retrieved by elementName(). There isn't a way to get
the policyIndex, but I don't think it is necessary for a script to
reference the MIB row in which it is contained. Another way to say it is
that I always know what policy I am.
But I think there's a small hole here. If a policy can work with two
kinds of elements, the base OID will need to be part of the "address".
This just augments the terminology a bit: $1, $2, ... will still be
index components only. If you need to get the base OID (infrequent), use
elementName() (that's why it exists).
So the element's address is (objectName, context, address).
> 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?
The break point from base oid to index is specified by the length of the
pmElementTypeRegOidPrefix. No MIB knowledge is required.
> If the script can't make decisions on the base object, what use
> is it to be able to specify multiple element types in
Very perceptive question, but you missed the elementName() function.
> 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.
I think this is fine but I'll look at it again.
> 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.
I have no problem with this. In fact, I never believed them to be scoped
to begin with. Do you just want me to explicitely say that they are
global (or did I inadvertently say they are locally scoped?).
> 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.
I've reworded. How about:
If the optional argument 'match' is provided and a match is
found, 'match' will be replaced with the text of the first
substring of 'str' that matches 'pattern'. If no match is
found it will be unchanged.
> 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?
It is all occurrences. I clarified and also replace "could" with
> 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?
I will rename it. I don't have a name in mind yet. How about term or
> 48. pmPolicyTypeFilter SYNTAX
> Since multiple element types can be registered, is there any
> reason to limit the SYNTAX to (SIZE(0..128))?
I think it's arbitrary but sensible.