[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,
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.

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.

Fixed.

> 
> 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
>     example).
> 
>     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
>     pmPolicyElementTypeFilter?

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
"would".

> 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
terminate?


> 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.


Steve