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

some issues with draft-ietf-snmpconf-pm-06.txt

Good Afternoon,

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,
    object, policy).

    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
moulton@snmp.com     Knoxville, TN 37920-9716 USA  http://www.snmp.com