Subject: draft-ietf-snmpconf-pm-03.txt

From: David Harrington <[email-masked]>
Date: Wed, 25 Oct 2000 17:38:25 -0400

Hi,

some comments on the new draft.

on line 199, "manage" has been changed to "configure" the whole network.
I don't recall the discussion that led to this change. I don't object; I
just wondered what prompted the change, since configure is just a subset
of manage?

275: "where the objects live" may not be true if the policies are
executed "near" the managed device. This may require some rewording for
clarity.

332: I think characteristic should be plural here, or the sentence needs
rewording to keep this singular.

450: "so that" could be simply "so"

504: "element address" may need clarification to prevent unwarranted
assumptions about the address format.

509: The expression returns either zero or non-zero; if the execution
terminates due to a syntax error, what is returned? Maybe we need an
enum - true/false/error ?

531: "passed to the expression" - for clarity should we specify "passed
to the action expression" (and in the preceding paragraphs make the
expression the "condition expression"?

635: As I recall, ISO has adopted the ANSI C specification. Since ISO is
an international organization and ANSI is an American organization, and
we are defining a specification for international use, I suggest we
refer to the ISO standard. (I forget the number and don't have access to
the web right now)

639,654: There is no reference for BNF or EBNF.

656: are underscores allowed in identifiers?

631,662: are arrays allowed? 631 says no; the bnf indicates yes.

660: can successive const_expr's be preceded by declarations, or only
the first?

667: how does one declare a 64-bit integer? I believe this is "long
long" in C; does this BNF permit that usage?

682: does assignment have perisistent side effects when used in a
condition expression? i.e. can I modify an underlying variable (perform
a SET of an underlying mib object) by using these operators in my
condition expression?

685: for and while have been added; what about do-while for a first
pass?

707: if a pre- or -post increment or decrement operator is included in a
condition expression, does the condition evaluation have side-effects? 
 
714: are we passing the results of the expression or the address of the
expression? i.e., are we passing by value or by reference?

719: are wide characters supported, e.g. in strings? 

xxx: are casts supported to ensure consistent promotion rules used
during evaluation?

773: should we add "according to the standard."?

858: "unencoded" is ambiguous? which encoding is being referred to here?
the encoding mentioned in 843, or the ASN.1 encoding?
882: I think it needs work. 

905: "ever" should be "never"

942: "followed by" a decimal digit. Is this limited to 1..9? Since this
refers to the n'th subid, and there can be more than 9 subids, this
should probably not be constrained to being a two-character token.

956: "an 32-bit integer" s/b "a"

958: implies a direct connection between evaluation of the condition and
execution of the action. 

1247: "that who's" s/b "whose"

"beneath it in the tree" - maybe "share this prefix"
"first to send in the search" need rewording for clarity.
is columnoid allowed to be specified either by descriptor OR dotted
decimal OR mixed?

1273: How about a third optional parameter that contains the OID of an
object that provides guidance for selecting the next index, as described
in RFC2579? 

1313: sp: desireable

1315: "to be active at once" - clarity. I don't know what this means.

1327: "The results are stored in the same varbindlist" 
"The results" - I'm not sure what thsi refers to. The results of what?
the snmpsend?
shouldn't the storage of the varbindlist be an implementation decision?

1335: is this unpredictable state detectable?

1375: In my experience, most people use short varbindlists. I don't
think I've ever seen a 60 varbind list in practice. Why are we making
this a requirement? Might it be better to provide two objects that
specify the number and size of lists supported?

1379: Can this be expanded with some reasons as to why these decisions
might be made? "it has written" might be better as "it has itself
written". If this is allocated memory, and it isn't "initialized" isn't
this likely to lead to memeory leaks? Since we're specifiying so much
about implement details, shouldn't we either specify this, or warn about
the issues in this implementation-dependent detail?

1418: Can we mopve this common description to one location and then
refer to it as needed?

1446: in all uses of varbindListIndex and varbindIndex, the range needs
to be specified as starting at 0, for purposes of interoperability.

1449: "into this string" is unclear, probably due to cut-and-paste of
the writeVarbind text. It is unclear what is moving from where to where
during the copy.

1477: if the operation fails, should we return both an error_code and an
error_index? Assuming RFC1905 varbind processing, what happens in the
event of an exception? If the processing is not local, and an error
occurs, it there any reason why no varbinds are modified locally? This
differs from many implementations for the processing of an SNMP response
containing an error. In the case of an exception, the non-exceptional
varbinds would still be considered valid, so why deny that possibility?

1490: (I don't have easy access to rfc1905 right now) Isn't the SNMP
"Error Code" for noErr a zero? Then can't we simply say that the
approrpriate SNMP error code should be returned? 

xxx: we are specifying the language, the parameters, the explicit
behavior, and in some places the storage decisions. Why don't we simply
provide sample code for these libraries as well?

1509: "active" is ambiguous.

1543: why not define these to match their official enumerations (0..18)?

1607: why the change from char to u_char throughout?

1708: are we standardizing which attribute of an element should be
returned? If this is a row-pointer, should we specify that?

1728: the scratchpad functions seem to contradict line 532 which says
"no state is remembered from
the policy filter evaluation, nor from the previous filter/action
invocation of this element nor from the previous invocation of the
policy filter or action"

1734: "previous executions of this policy on this element" is ambiguous.
Does this refer to a previous evaluation of the condition, or only a
previous execution of an action?

1822: would this be more useful if it returned the index of the first
subid which differs, and 0 (or -1) if no subids differ?

2011: is it appropriate to use a display hint of "255a" for a
UTF8String? The text describes different hints.

xxx: in converting octet strings to utf8strings, the ranges were
dropped. should they be respecified?

xxx: in converting syntax to unsigned32 and utf8strings, haven't the
semantics changed? Are all early implementors willing to accept the
change, and not require reassigment of the oids? Would this be
acceptable (to the iesg and rfc-editor) to bypass the rules about
changing semantics?

2358: tweo new objects were added in between existing objects, forcing
renumebring of the higher numbered objects. Doesn't this violate the
rules of OID assignment. Why not add these after the policy status
object? (it ain't as pretty, but it's legal)

3104: should the log indicate whther it was the condition or the action
that was being processed, rather than just the element?

3170: should the debugging log be optional?

-- 
---
David Harrington            Network Management Standards Architect
[email-masked]           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA