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

From: Steve Moulton <[email-masked]>
Date: Wed, 11 Jul 2001 17:43:46 -0400

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

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

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
[email-masked]     Knoxville, TN 37920-9716 USA  http://www.snmp.com

---

From: Steve Waldbusser <[email-masked]>
Date: Tue, 17 Jul 2001 00:39:04 -0700

>     The ec() (element count) and ev() (element value) functions ....

I definitely agree.

>     are talking about an execution context or SNMP context (contextName).

OK, I've done this.

>     the execution context is fully described by (index, context, address,

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

>     This is elementContext() in the running text, but context() in

Fixed.

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

>     pmPolicyElementTypeFilter?

Very perceptive question, but you missed the elementName() function.

>     not providing a contextEngineID blocks out much of this possibility.

I think this is fine but I'll look at it again.

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

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

>     the same as the original string if no matches are found?

It is all occurrences. I clarified and also replace "could" with
"would".

>     function in policyScript be replaced?

I will rename it. I don't have a name in mind yet. How about term or
terminate?

>     reason to limit the SYNTAX to (SIZE(0..128))?

I think it's arbitrary but sensible.

Steve