snmpconf review of pm-mib

Hi,

Steve and I have worked out the issues I had raised and either resolved them
or agreed to disagree.

There are four additional items Steve has agreed to modify, as indicated in
his mail below. 

Thank you Steve,

dbh

-----Original Message-----
From: Steve Waldbusser [mailto:[email protected]]
Sent: Friday, June 14, 2002 12:41 PM
To: Harrington, David
Subject: Some old business



Here are the 4 things we agreed on:

Issue 17: Add text that expresses the following:
PolicyScript is a subset of C++ in which many of the
operators are overloaded to use the "var" class. However, a programmer
programming in the PolicyScript language cannot further overload
operators because the syntax to specify an overloading is not included
in the
PolicyScript syntax.

Issue 51: Add the references to document the enumerations

Issue 52: Reference disman's work in this area.

Issue 90: Fix typo where the text that says "If 'contextEngineID' is
not present, the local system will be used." should read "If
'contextEngineID' is not present, the contextEngineID of this element
will be used."


FYI: I've appended my full annotated list which I'll also send to the
list.

Steve


P.S.
1) Fixed

2) Fixed

3) Fixed

4) Fixed

5) Changed many instances throughout document

6) Reworded extensively including renaming 'accessor function' to
'function' throughout

7) Added an example

8*) Already has two examples

9*) These are all judgement calls. I think they are important to keep
    as they each clarify on a potential misunderstanding.

10) Added the clarifying text: "within the policy script"

11-12)Changed "scheduled" to "Multi-tasked" to clarify and tried to
ensure throughout the document that there weren't similar confusions
about the use of the word 'scheduled'.

13) Merged the 2 sections

14) Changed the title of section 5.1 to Terminology

15) Extensively restructured the contents of ection 5.5 based on this
input

16) Fixed

Todo: Try to put this text into the doc:
17) Answer: PolicyScript is a subset of C++ in which many of the
operators are overloaded to use the "var" class. However, a programmer
programming in the PolicyScript language cannot further overload
operators because the syntax to specify an overloading is not in the
PolicyScript syntax.

18) I don't think we'll *have to* make changes based on SMING changes
but it we find ourselves in a circumstance where we *want to* we can
make the change. For example, we could un-subset floating point if
necessary.

19*) The wording with "For example" more naturally conveys what I want
it to convey.

20*) The original wording more naturally conveys what I want
it to convey.

21) Added clarifying text

22) Question: "Does the postfix_expr rule allow ++A++, or A++++++, or
    A++--++?"

    Answer: Yes, but the underlying language doesn't permit this. This
    is where the rule comes in that says: "The PolicyScript language
    follows the syntax and semantics of ISO C++ [19], but is limited
    to that which can be expressed in the EBNF below.". This is why I
    wrote: "This is done because while EBNF doesn't fully specify
    syntactical rules (it allows constructs that are invalid) and
    doesn't specify semantic rules, it can successfully be used to
    define the subset of the language that is required for conformance
    to this specification."

23) Question: "How does the expression rule work with a comma?
    (A=0,B=1) evaluates as what? Am I allowed to specify A[A=2, B=3]?"

    Answer: The answer is always the same: Consult the C++ spec: in
    the first case the answer is 1, in the second case it is A[3].

24) Consult the C++ spec

25) Question: "'PolicyScript: statement*' is a script with no
    statements a valid script?"

    Answer: Yes. If it is a policyCondition, it returns zero.

26) Question: "Is the index specification ($*) included in the EBNF?"
    Answer: No, it is not part of the language. It is only seen inside
    of strings.

27*) The original wording more naturally conveys what I want
it to convey.

28) dbh: "6.2.1 'The policy script runtime' discusses conversion
        operators that are not part of the language. See item #17
        above."
      Answer: Yes, they are used to specify the language but are not
      part of the language itself.

29*) I tried the best that I could, but since this is a meta-language
(to define the real language) I found myself in a trap where the
next step would be to define a meta-meta-language and then a
meta-meta-meta-language to describe that and so on. At some point
you've got to assume you've got everthing down to natural language
and common sense.

30) Answer: It is the same as in C++.

31) Question: "If I understand correctly, the following will result in
    a RTE. { J="J"; K="K"; J=K } Is that correct? the intent?"

     Answer: No, it doesn't result in an RTE. I don't see anything you
     could have read that would have supported your interpretation.

32) Answer: Yes, you got it right. It is consistent with EcmaScript
and JavaScript, which is where the "var" class is inherited from.

33) Fixed

34) Answer: They wouldn't be needed in policyScript code, I just
wanted to delimit the contents of my example script (which is an octet
string to be downloaded to the agent).

35*) If we did it that way it wouldn't be much of a QuickStart guide
because you would only read it after you had already done the hard
work. Sometimes the benefit of the forward reference outweighs the
downsides. For example, in programming texts, the "Hello World"
example usually precedes the definition of printf().

36*) Same answer as 35

37*) Question: "on a related note, 'Because Policy Script is a least
common denominator' isn't quite true. It contains elements, like $*,
that are not in all the languages referenced."

  Answer: $* is not a language construct. Certain accessor functions
  treat the substring "$*" specially when seen in an oid string. It is
  just an attribute of those accessor functions. A great analogy is
  that "%d" is not a C language construct, it is treated specially by
  the printf() function when seen in the format string. If the
  printf() function was called from Pascal, it would still act the
  same way.

38) Question: "6.3.1 - can accessor functions change the value of
    arguments that are not &references?"

    Answer: No. To quote: "Arguments without the '&' character cannot be

    modified by the function."

39) Question: "6.3.1 - are all variables in the same scope? what about
    scratchpad variables?"

    Answer: This text refers to language variables (i.e. "var
maxLength;").
    Scratchpad variables are only accessable through the scratchpad
    function calls, i.e.: getScratchpad(Global, "foo", val);

40) Question: "6.3.1 - doesn't mention the addition of $*"

    Answer: As above, "$*" isn't a language feature, it is a library
    feature.

41) Fixed

42) Question: "the return value of a PolicyAction script is
    ignored. Why? why not use the return value to indicate whether the
    script ran to completion or not?"

    Answer: I considered something like this: having the return value
    indicate whether the script encountered an error. But then I
    realized that this would "cry wolf" too often because often
    programmers exit without paying attention to return codes or just
    simply exit by hitting the last line of code.

    Instead, you can signal errors explicitely with the signalError()
    function and a management station can find policies with errors by
    checking the pmTrackingTable.

43) Question: "if the return value is ignored, why set it to zero as
    the result of an RTE or indication of a fail()?"

    Answer: This is only interesting for policyCondition scripts where
    the return value makes a difference. This rule makes sure that
    upon an error, the condition does NOT select an element. This is
    designed so that it fails gracefully.

44) Each of these forward references has been addressed.

45) Question: "section 7 - if SMING changes addressing to use
    non-OIDs, will snmpconf be able to be updated in a backwards
    compatible way?"

    Answer: The PM MIB will be fine and the language will be
    fine. Certain accessor functions would not work and would be
    augmented with new ones that would work.

46*) The original wording more naturally conveys what I want
it to convey.

47) Fixed

48*) The original wording more naturally conveys what I want
it to convey.

49) See the answer for #38

50) Fixed

Todo: put these in
51*) I didn't think this really added any value and it seemed a bit
distracting. Will anyone really be confused? I'll add it if it's
important to you.

Todo: give disman credit and blame for this so people "know why this
is done this way":
52) Section 9.1.1 provided further detail

53) Question: "'the agent' - must it be an agent? does it apply to
    mid-level managers as well?"

    Answer: The entity that implements this MIB must be an agent. It may
also
    be a mid-level manager.

54) Fixed

55*) I think this is too much off-topic detail

56) Question: "9.1.2 enum_decimal - are enums required to start with a
    letter?  How would ToInteger( 3Com(12) ) be evaluated? is the
    processing clearly defined to prevent mis-interpretation?"

    Answer: enums are only processed inside of strings. So your
    example looks like a C++ syntax error. Your example should be
    phrased as ToInteger( "3Com(12)" ) and you can probably see
    clearly now that it doesn't matter what the string begins with.

57) Question: "can unsigned64 types with the high bit set be converted
    reliably using ToInteger()?"

    Answer: Yes.

58) Question: "'unencoded' 'encoded' - what does this mean? not ASN.1
    encoded?"

    Answer: It means not encoded as an OID or a decimal number (to
    distinguish it from oids and integer processing).

59) Question: "subid: '0' | decimal_constant - why not use digit?"

    Answer: To avoid "00000" or "00001" etc.

60) Question: "never used in these encodings over the wire" - can we
replace
    "these encodings" with "the scripts"?

    Answer: It is more accurate to state this specifically for these
    accessor functions. For example, another accessor function could
    be defined which *would* accept and translate such descriptors.

61) Fixed: Changed the terminology here and in 49 other places.

62*) dbh: searchColumn - POSIX 1003.2 isn't mentioned in the References
    section

Answeer: I don't have the information that would provide a complete
reference. In the meantime, there is no ambiguity.

63) Question: searchColumn() - "or returns an error without finding a
match" -
    what are the error conditions? Since a zero means both endofView
    and error, how can a programmer determine that they have reached
    the end of the table without error?

    Answer: You can't. You'd have to do it "by hand".

64) Question: Can this script be written as
    while(searchColumn("ifType", oid, ethernet(6), 0)) ?

    Answer: Unfortunately, no. That works for the other SNMP functions
    (the ones that follow the input rules for "Form of SNMP Values")
    when the type field is set to integer yet the string is in the
    form of "blah paren number paren". In this case there's no input
    type because searchcolumn will work with any data type
    returned. That's why it transforms returned values into strings
    and then compares it to this 'pattern' argument.

    (BTW, if it worked, the proper syntax would have had "ethernet(6)"
    in a string).

65) Reworded.

66*) See #53.

67*) The original wording more naturally conveys what I want
it to convey.

68) Reworded.

69) [This is a clarification request and 2 questions. The
clarification request resulting in a rewording].

Question: counterRate() - somewhat ambiguous about how many, and which,
timestamped values must be kept. The paragraph starting "counterRate
retrieves" says it keeps "values" so it can calculate over a longer
period than since the last invocation. The paragraph that starts "The
implementation will need" says it must retain one value older than
minInterval seconds. So, if I have a minInterval of 5 seconds, do I
need to keep the last read (less than 5 seconds ago) and one more
read?

Answer: Yes.

Question: What are the interoperability issues if I set two boxes to
have
minIntervals of 5 seconds, and vendor A keeps the most current and the
most current + 5, but vendor B keeps the most current and the most
current + 15 (discarding the current+5 and current+10 samples?).  70)
is there a way to tell how many samples have been kept?

Answer: The use of the phrase "old values" meant that it would only
delete
"from the end" (i.e. values that had expired). I've reworded this to
make the point more strongly.

70) Question: is there a way to tell how many samples have been kept?
    Answer: No

71) Question: is there a way to access the samples? their timestamps?
    Answer: No to both questions.

72*) I don't see any better way to do this.

73) Question: "Otherwise, this delta will be dividied by the number of
seconds
    elapsed between the two retrievals ..." assumes there are two
    retrieveals. What if an implementation keeps more than two? how
    will the value be calculated?

    Answer: The text specifically refers to two particular retrievals
amongst
    the many that may be stored:
       1) The most recent one (now); and,
       2) The newest retrieval that is at least minInterval old.

74) Fixed. (Rounded down)

75) Fixed. (Formatted into bullets).

76*) It is done this way simply for symmetry.

77*) I think this is an important clarification. I don't want to
delete the clarification.

78) Question: newPDU() - can a PDU that is received in a trap be read
using the
    functions described here?

    Answer: No

79) Question: 9.1.4.4 is snmpSend() synchronous or asynchronous? This is

          important to know for off-box queries.

    Answer: It is synchronous

80*) I don't think it's clear one way or another (it's really a style
issue). But this is a big thing to change at this time without a clear
mandate (things changed now won't receive the same level of review and
concensus as things changed some time ago).

81) Question: 9.2 Are the HC datatypes supported? What does
counterRate() return for a 64-bit counter delta?

Answer: Yes, they are supported. The native integer variables have 64
bits of precision and counterRate has an option for doing 32 bit or 64
bit counters as appropriate.

82) Question: "local" errors - when acting as a MLM, are these local
errors or
remote errors? Do we have remote errors?

Answer: "Local Errors" refers to errors encountered in the API that
aren't present in the protocol. For example, a timeout error.
The distinction between local and remote is the same whether the
transactions stay on the box or go over the wire.

83*) dbh: Constants for SnmpMessageProcessingModel and SnmpSecurityModel
-
    if additional security models are defined, can they be supported
    in snmpconf? A reference to the official definition of these
    values would be better than "hard-coding" the list here. Ditto for
    SNMP operation types, SNMP errors, and other constants. It's ok to
    include the constants here, but there should be a disclaimer that
    the official list is found in [wherever].

Answer: But these are the values that a script can depend on to be
pre-defined. There are no other values defined as constants. If other
security models are defined, the function library would need to be
updated to support them.

84) Fixed

85) Fixed

86*) These are only used internally, not over the wire. They are
defined this way on purpose.

87) Done: reordered all the sections in this chapter.

88*) The argument isn't compelling enough to warrant changing all 10
instances of this phrase.

89) Fixed

90) dbh: elementContext() is provided, and elementAddress() is provided,

but elementContextEngineID() is missing, which is especially notable
given that roleMatch() uses contextEngineID rather than the address.

Answer: You don't need to do this. roleMatch() uses the element,
context, and contextEngineID of "this element" by default. So
roleMatch(string, element, context, elementContextEngineID())
is the same as
roleMatch(string, element, context)

Todo:
But, I do see a bug where the text that says "If 'contextEngineID' is
not present, the local system will be used." should read "If
'contextEngineID' is not present, the contextEngineID of this element
will be used."

91) dbh: roleMatch() ues contextEngineID and doesn't permit using the
address, but nonLocalArgs favors the address over contextEngineID (the
contextEngineID in nonLocalArgs can be not-present, and commands will
be sent to the address specified, which is in keeping with SNMPv3
engineID discovery).

Answer: This is by design. NonLocalArgs is used in the SNMP
library functions as it is used to specify transport information with
which to send SNMP packets (possibly through proxies). RoleMatch()
refers to a local database of role information for local and non-local
systems. The authoritative identifier for a non-local system is the
contextEngineID, regardless of any of the transport addresses it may
be reached through (or next-hop addresses when going through a proxy).

92) Your comment initiated a major rewrite of this section.

93) Done

94) Resolved

95) Fixed.

96) Clarified

97) Question: "Contents of the scratchpad are erased on reboot." -
    doesn't this contradict the purpose of storageType?

    Answer: No. Scripts need to be able to bootstrap themselves when
    they are first installed or when an element appears. This is just
    another one of those times. Think of it as all the elements
    disappearing when the box goes down and re-appearing when it
    starts up again.

98) Fixed

99) Question: I am unclear on how to specify a modifiable parameter in
    a function call - is it the C-style (&val), where the address of
    the variable is provided, or the C++-style (val), where the
    reference is defined in the prototype?

    Answer: It is the C++ style. In the beginning of section 9 you can
    read: "In the function prototype, if the '&' character precedes
    the identifier for an argument, that argument may be modified by
    the function (e.g., "integer &result, ...)"). Arguments without
    the '&' character cannot be modified by the function.  In a
    script, modifiable arguments don't need to be preceeded by a '&'."

100) Question: "Is it an RTE if I specify getScratchpad(Global,"foo",
     "55")? The string "55" is associated with a memory location, just
     as val is, but the memory location for "55" may be read-only
     memory. Writing to it might cause a core dump. Alternately, a
     manifest constant string might be modified, making the rest of
     hte program malfunction."

     Answer: Yes, it is an RTE. I added the following text to the
     beginning of Section 9 to clarify:  "It is a RTE if a constant is
     passed to a modifiable function argument (regardless of whether
     the function actually writes to the argument)."

101) Question: 9.3.9 defines constants for use with the scratchpad
     functions. Shouldn't these constants be defined with the other
     constants?

     Answer: I think it's more modular this way and thus more
     readable. The other constants are many pages away.

102) Fixed

103) Fixed.

     Question: Are all the bits in pmTrackingPEInfo cleared at the
     start of each execution?

     Answer: The bits related to conditions(actions) are cleared at the
     beginning of execution of the condition(action). This is clearly
     spelled out in the pmTrackingPEInfo MIB object.

     Question:     How do I know whether conditionUserSignal or
     actionUserSignal will be set?

     Answer: The pmTrackingPEInfo MIB object spells out clear rules.

     Question: Assuming it
     gets set depending on whether a condition or action is being
     evaluated, does the conditionUserSignal get cleared when the
     action is evaluated, or when the next condition is evaluated?

     Answer: (Your initial assumption is correct). It is only cleared
     when the next condition is evaluated.

104*) dbh: defer() - In the description, the order of discussion is
default
     behavior, defer(1), then defer(0). is the default behavior and
     defer(0) equivalent? if so, they should be discussed together.

     Answer: I tried writing it that way and it just looked more
awkward.

105) Question: defer() - the discussion that preceds the prototype
     talks about gold is appropriate but isn't possible. It doesn't
     say anything about hitting a RTE. But the description in the
     prototype is dependent on hitting an RTE. Is it always true, and
     a restriction that any future library developers must be aware
     of, that an RTE MUST be triggered if it isn't possible to do
     something?

     Answer: No, that isn't the case. If you've been selected as the
     highest precedence policy but then discover you can't fulfill
     your responsibility, you can call fail(1, ...). Defer is used to
     provide instructions in the event that you accidently hit an RTE
     (say, divide by zero). In such an even, you can't choose to call
     fail() because you're dead. Think of defer as the Last Will and
     Testament for a policy :-)

106) Question: Can a script writer choose to voluntarily, as part of
     their logic, fail() and defer()? Is that an RTE, or just
     returning a false condition?

     Answer: You can fail(1, ...) which has the side effect of
     deferring as you die. A script's execution halts when it hits
     fail() so in fail(); defer();, defer() never runs.

     Fail and defer are functions that only provide value in an action
     script, which is only run of the corresponding condition has
     already returned true.


107) Fixed.

108) Fixed.

109) Rewritten.

[pg 4, sec 3, Overview]
There were so many good slides presented in the WG describing
the layering from independent to dependent data abstractions,
but none of that made it into the draft. (The entire overview
is less than a page.)

There is no attempt to describe how this draft addresses any
of the motherhood & apple pie goals listed in para 2.

There is no attempt (anywhere in the draft) to describe the
overall system that is defined within the draft. The draft
reads like a parts list without instructions on how to put
all the parts together.  Some of the missing details:
 - a diagram showing the components of the PM system
 - a diagram showing how the PM system fits within the overall
   managed device
 - a diagram showing how the PM system fits within the overall
   NM system as a mid-level manager
 - explanations of all the components, such as:
    - element discovery
    - element registration
    - capabilities registration
    - roles
    - policies
    - policy groups
    - policy selection
    - policy distribution
    - policy organization
    - policy conditions
    - policy actions
    - policy scheduling
    - policy script execution environment
    - element filtering
    - accessor library
    - policy validation
    - schedule group
 - how the components relate to each other
 - how the entire system fits within the SNMP Architecture

[pg 5, sec 4, Arch.]
This section would make more sense if the system was explained
first. This section doesn't really describe an architecture,
but rather the notion of policy based management (again).
It doesn't really explain the system that implementors are
supposed to create, and how operators are supposed to use it.

[pg 6, para 1, sec 4, Arch.]
The description of "this element" is confusing because there
has been no detailed explanation (and won't be) of the runtime
environment.

[pg 8, para 2, sec 5.1, Terminology]
This section should be moved to a general terms section either before
or after the overview.  The details about RTE should stay in section 5.
Some terms that need introduction:
    - element type
    - element
    - "this" element
    - system element 0.0
    - role
    - policy
    - policy group
    - policy condition
    - policy action
    - accessor function
    - schedule group
    - precedence group

[pg 8, para 4, sec 5.2, Element Discovery]
"as 1 element" -> "as one element". [done]

In the last sentence, it's not clear how this applies to
the runtime environment.  It would help to explain the runtime
environment at a high-level (iterative engine, and how it
operates on elements) somewhere in section 5.

[pg 9, sec 5.2, Element Discovery]
It isn't clear why the details of the element registration
MIB are explained, because the rest of the discussion is
about element discovery. How does NMS registration relate
to discovery?  It is confusing to mix MIB object
details in with this high level discussion.  (They should
be in a separate MIB overview section.) In general, the
MIB objects are discussed in detail before the MIB is introduced.

[pg 10, sec 5.2,1 Implementation Notes]
This section should be moved to later in the document.
because the MIB has not been introduced, and all the
implementation notes should be grouped together.

[pg 11, para 2, sec 5.3 Element Filtering]
This first paragraph contains MIB details about policy
scheduling, and should go in a section for that (added
before this one). This concept is called 'policyCondition'
everywhere but this section.

[pg 11, sec 5.3,1 Implementation Notes]
"It is an implementation-dependent matter as to how policy
conditions are scheduled."  This is pretty much the entire
description of the script invocation and scheduling details.
I think it will be difficult for script developers to port
scripts across PM implementations with this approach. There
are also many constraints placed on scheduling throughout
the document, so this statement is misleading.

[pg 11, sec 5.4 Policy Enforcement]
This concept is called 'policyAction' everywhere but this section.

[pg 12, sec 5.4,1 Implementation Notes]
I think it will be difficult for script developers to port
scripts across PM implementations without specifying scheduling
algorithms, scheduling conflict resolution, etc.)

It is not clear what by the 2nd setence "each ... pair
its own process ... run simultaneously."

The execution control flow should be explained (from engine
to condition script to action script within a specific iteration
sequence, based on registered elements, configured latencies,
system events, etc.)

[pg 12, sec 5.5, Definitions]
These terms should be moved to a general Terms section.

term "precedence policy" should be explained in the Terms section

[pg 22-23, sec. 6.3, QuickStart Guide]

The other examples of finding the gold interface or
killing all application processes that have run for > 5 min
are not very compelling.  IMO. the document doesn't effectively
demonstrate that the PM MIB can be used to perform the
initial configuration of a real managed device, such as a router.

Some code examples for readVar would be helpful.

[pg 47, sec 9.1.4, general]
These functions are very important and it would help to have
a meaningful example that used all of them.

[pg 50, sec 9.3.1, roleMatch]
Meaningful examples of this accessor function would help.

[pg 56. sec 9.3.11, defer]
The concept of precedence groups should be explained
way before here, in an accessor function description.
The whole concept is fuzzy, potentially complicated,
and never explained or shown in examples. How is
the system configured to utilize "runner-up" policies?
The mechanism should be better explained.

[pg 58. sec 9.4.1, regexp]
Example code showing meaningful usage of the match
parameter would be helpful.

[pg 58-59. sec 9.4.2, regexpReplace]
Example code would be helpful.

Are there restrictions on the value of 'replacement'?

Does an RTE occur if the string replacement causes
the 'src' string to overflow?

[pg 62. sec 9.4.9, parseIndex]
An example for each variant of the function would be helpful.

It would help in the example to show what OID fragment values
are actually stored in each var = parseIndex() call.
The example is misleading because the string ipForwardIfIndex
is not actually allowed.

[pg 64. sec 9.4.14-16, chr, ord, substr]
Meaningful code examples of these functions would help.

[pg 65. sec 9.5, Library Accessor Functions]
The full function prototypes for these POSIX functions
should be provided.

No mention of the sprintf format codes is made.

How does each and every format code variant map to a data type
in PolicyScript?

Is an RTE generated if the number of parameters passed
to sprintf does not match the format string?

Is an RTE generated if the type of a parameter passed
to sprintf does not match the format string type?

[pg 65. sec 10, Schedule Table]
There is no overall explanation of time-based scheduling.
This should be in the section on the runtime environment.
This section is out of place here.

The term 'schedule group' is used here but not defined anywhere.

The discussion of the pmScheduleTable should be in
an overview of the MIB.

[pg 68. sec 11, Definitions]
There is no overview section to introduce the MIB groups
as is customary in standard MIBs.  The MIB is harder
to read because of this omission.

A diagram showing the different groups in the MIB
and explanations of each group and its relationship
to the other groups (if relevant) would be helpful.

[pg 72, sec 11, pmPolicyPrecedenceGroup]
There are no examples of this potentially complicated
mechanism in the document. Many runtime environment
features (like this one) are explained and defined
via MIB objects, which makes them hard to figure out.

[pg 76, sec 11, pmPolicyConditionMaxLatency]
   "... may wish to re-run .. change to the role strings"
This is another execution environment tidbit scattered
in the document.  All of these should be collected
and placed outside the MIB description clauses.

[pg 77, sec 11, pmPolicyMaxIterations]
This object is allowed to change at any time, which is
difficult to implement.  If an NMS lowers this object
while a script is running in a while loop, will the
agent instantly detect the change? On the next policy
task invocation?  Within some max latency?

[pg 77-78, sec 11, pmPolicyTable gauges]
It's not clear what the underlying execution model is,
so it's also unclear what starts the counting and
stops the counting for a particular gauge value.

[pg 80, sec 11, Policy Code Table]
This long ASN.1 comment should be in a MIB overview
section instead.

[pg 83, sec 11, Element Type Registration Table]
This long ASN.1 comment should be in a MIB overview
section instead.

What happens to the running script if an entry is removed
from this table. What does the runtime do if the current
loop is the elementType removed? Is there an RTE error
code for this condition?

What happens to the running script if an entry is added
to this table that changes an element filter evaluation?

The document never actually defines what constitutes
an element type, so it's hard to tell how the agent
is supposed to auto-populate this table.

[pg 85, sec 11, pmElementTypeRegOIDPrefix]
The "0.0" system entry is not mandatory (none are),
yet there are accessor functions (like roleMatch)
that need this entry. Is this entry required or
do those accessor functions cause an RTE if they
reference the non-existent 0.0 entry?

[pg 86-87, sec 11, Role Table]
This long ASN.1 comment should be in a MIB overview
section instead.

[pg 88, sec 11, pmRoleElement]
Does this re-indexing rule apply if the element is
in on a different engine? Is there a max latency
for discovering re-indexing?  This is a tall order,
considering other text in the document says the
agent doesn't really know (and doesn't enforce)
the structure of the OID instance in any other cases.

[pg 105-106, sec 11, pmTrackingEPStatus]
What happens if this is set to forceOff while a policy
is running? Does the script complete if it was just
forced off? Does it end with an RTE?

Do other MIB status objects change elsewhere
in the pmPolicyTable when this is set to forceOff?

[pg 112, sec 14, Acknowledgements]
No mention whatsoever, or reference, is given for the
Scheduling MIB, even though several hundred lines of
text were lifted from that MIB.  The cut-and-paste
is bad enough!

[pg 116, sec 17, Intellectual Property]
I think different text is supposed to go here if the WG
knows of any claims of patented IP pertaining to this work,
and I believe BMC Software is making such a claim.

[pg 118, ToC]
This should go in the front of the document.