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

snmpconf =?utf-8?B?UkU6IHNubXBjb25mIE5ldyBkcmFmdCBvZiB0aGUgUG9saWN5IE1h?==?utf-8?B?bmFnZW1lbnQgTUlC?=

	This is my first reading of the draft, and I haven't been monitoring
the group for very long, so some of the below may have already been
discussed or may be mid-discussion.  My apologies in advance for any
confusion on my part.


{6.1.  Formal Definition}

	1.)  Identifying the top block of the grammar (block?) would be
nice.  I'm still not quite sure where it starts.

	2.)  I think the string part of the grammar was never cleared up.
{6.} states that arrays and pointers have been removed, but an unexplained
'char*' appears in the grammar, as well as 'var_or_array', which permits,
e.g. declaration of 'int array[26]'.  Are arrays and pointers permitted or

	3.)  'const_exp' does not permit " '{' block '}' ", which would
allow nested blocks.

	4.)  For enhanced readability, please consider lining up the '|'
symbols in a row for all primary choices, on the left side, e.g.:

    const_exp         :   compound_exp
                        | conditional_exp
                        | assignment
                        | 'for' '(' const_exp? ';' const_exp? ';'
                                    const_exp? ')'
                                 ( const_exp? | '{' block '}' )
                        | 'while' '(' const_exp? ')'
                                 ( const_exp? | '{' block '}' )

	If my mail system converts spaces to tabs above, the above will
probably look pretty hideous, but it is intended to emphasize that the '|'
in " ( const_exp? | '{' block '}' ) " are not primary alternatives for those
of us who have a little difficulty with these things.

	5.)  In 'const_exp', " ( const_exp? | '{' block '}' ) " should be "
( const_exp? ';' | '{' block '}' ) ", I think.

{8.  Base Accessor Function Library}

	6.)  "This library contains three types of functions:" - it contains

{8.1.  SNMP Access Functions}

	7.)  In the "Object Identifier" section, "Note that ascii
descriptors (e.g. "ifIndex") are ever used in these encodings "over the
wire"" - should be "are never used".

{  getvar()}

	8.)  This function and many following make reference to a "u_char *"
type which is not defined in the grammar.

{  exists()}

	9.)  This function and many following return 1 for success and 0 for
failure, the reverse of the C convention.

{  searchcolumn()}

	10.)  "searchcolumn performs an SNMP walk on a portion of the MIB
searching for objects that who's values match value" - How about "objects
which match value", or "objects with values equal to the parameter 'value'"

{8.1.2.  General SNMP Functions}

	11.)  "Implementations may, but are not required, to initialize" -
should be "required to, initialize".

{  writeVarbind()}

	12.)  This and {} reference unspecified type "int *".

{8.2.  Constants}

	13.)  The SNMP error constants are not given their usual values.
Since they will not appear in an ASN.1 type field, this makes no sense.  Is
there a reason for this?

{8.3.4.  setScratchpad()}

	14.)  {5.2} reads "(in particular, no state is remembered from the
previous invocation of this element nor from the previous invocation of the
policy filter)".  This clause should be qualified in light of the
scratchpad, which enables exactly what {5.2} claims is not possible.

	15.)  Note that if one uses scratchpads during, say, iteration of
rows in a table, it may be impossible to use the scratchpad elsewhere, since
no row (and therefore translated scratchpad varIndex) may be guaranteed to
be unused.  Also, I see no implementation instructions for the scratchpad.
I suspect this is a place where implementations could rapidly diverge by
restricting scratchpad space or permitting virtually unlimited space.
Further thought in this area may be necessary.

{8.4.4.  oidsplice()}

	16.)  The starting point of the splice is not specified for oid2.


	17.)  {8.3.4} states "Every maxLatency time period, every policy
runs once for each element".  However, here it states "In other words, in
any given interval of this duration, all elements must be re-checked", which
implies that the policy may run several times within this time period.
Clarification is necessary.


	18.)  Wouldn't it be better to index this table via
pmElementTypeRegOIDPrefix and eliminate pmElementTypeRegIndex?  A "shortest
match wins" rule would mitigate ill effects should a manager register an
instance instead of an object.

	19.)  "Note that entries that differ only in the last OID (which
specifies which object in an entry) are effectively duplicates and should be
treated as such by the manager."  This should read "(which specifies
instances of an object)".


	20.)  "The agent must store role string associations in NVRAM."
"NVRAM" would be better listed as "nonvolatile storage", since, strictly
speaking, a hard drive is not NVRAM.

	21.)  "The pmRoleESTable is a read-create table that organized role
strings sorted by element."  Should be "organizes".


	22.)  "Entries will exist that contain values for the
pmCapabilitiesRestrictOID, pmCapabilitiesRestrictType,
pmCapabilitiesRestrictValue and pmCapabilitiesRestrictString objects
only..."  These should be pmCapabilitiesModification*.

{pmTrackingPolicyToElementTable} & {pmTrackingElementToPolicyTable}

	23.)  After reading these sections three times, I am still baffled.
Questions include:

	-  Why are there two tables?
	-  Why the special objects for row status?  Won't a rowStatus work?
	-  Why does pmTrackingElementToPolicyEntry vanish when the
corresponding pmPolicyFilter fails?

	Much enlightenment is needed.


	24.)  "The pmDebuggingPolicyTable logs debugging messages when
policies experience runtime errors." - should be "pmDebuggingTable".


	25.)  This is instantiated as policyMgt.20, leaving 11 unused
objects between it and pmDebuggingTable.  Is there any reason for this?

/"\                                            /|/|ike /+yers
\ /     ASCII Ribbon Campaign
 X      Against HTML Mail                       Test Engineer
/ \                                        BMC Software, Inc.