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

snmpconf-pm-04 notes




I haven't quite finished reading it, but I thought I'd jot these down
for as far as I've gotten.  I'll try to mark the more serious issues
(as opposed to editorial ones) with a '***'.

1)  section 4:
    "Policies always express a notion of:
       if (an object has certain characteristics) then (apply operation to
       that object)"

    should be replaced with:

    "Policies always express a notion of:
       if (an object has certain characteristics) then (apply an operation(s) to
       an object)"                                            ^^
       ^^
  Operations can apply to objects other than the one with the
  characteristic in question.  Now, since an action can contain
  multiple operations, the following would probably be the best, IMHO:

    "Policies always express a notion of:
       if (an object has certain characteristics) then (apply a set of
       operation(s) to a set of objects)"

2) section 4:
  roles, whereas the percent utilization of a link would not be.
     ->
  roles, whereas "the percent utilization of a link" would not be.

  (the other two examples in the paragraph are quoted)

3) section 4:

  Roles are human defined strings that can be referenced by policy
     ->
  Roles in this model are human defined strings that can be referenced by policy

4) section 4:
  Repeated use of the word 'download' is used to say that the manager
  downloads policies to the managed devices.  IMHO, this is
  "uploading".

***
5) section 4:
  There are security issues with not uploading policies to a managed
  object until they are discovered.  This issue comes up repeatedly in
  the document.  During the time that the policy is not in place it
  obviously can't be enforced (which could be serious if financial or
  highly secure information was transmitted (EG) during that time
  window).  In theory, you'd think, that this shouldn't happen that
  often and the window would be small.  But what if the
  pmNewRoleNotification isn't received by the management station?

6) 5.1

  therefore they can be modeled as one element type.
   ->
  therefore they can be defined in this model as one element type.

7) 5.2

  filter the last time it was checked (or it was a newly-
   ->
  filter the last time it was checked (or it is a newly-

  and just below it:

  the last check, it will remain in the set of elements that
  will whose policyAction will be run within the
    ->
  the last check, it will remain in the set of elements
  whose policyAction will be run within the


8) 5.3

   accessible from accessor functions, 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). If any syntax or
     ->
   accessible from accessor functions, no state is remembered
   from the policy filter evaluation, nor from the previous
   filter/action invocation of this element. If any syntax or

***
9) 5.3 and others
   If syntax or processing errors occur, the action will terminate
   immediately for this element.  I think failures need to be dealt
   with in a better way.  The document repeatedly references failing
   actions and that processing stops.

   First and most importantly, I think a failure notification needs to
   be sent out (if configured to do so), as there are security
   implications with policies that fail to run properly.

   Second, having a policy die in mid stream is a pretty serious event
   since half of the operations (or so) will have succeeded before the
   error occurred (yet another security consideration).  I'm not
   saying there is a way around this (there isn't), but it should be
   noted somewhere (IMHO).

***
10) I certainly understand the reason for not including function
    definitions, but the code duplication issues resulting from this
    are going to be a pain.

11) section 6: define BNF & EBNF somewhere (or state a reference to
    its definition).

12) section 6:

    "The use of comments and newlines are allowed and encouraged
    where they will promote readability of policy code."
    ^^^^^^^^^^^^^^^

    Oh sure, but I can't make comments with snide remarks in them?
    How about:

    "The use of comments and newlines are allowed and encouraged
    in order to promote readability of policy code."

13) section 8.1:

        Copies the value of b to a. After the copy a and
        b are equal but do not share storage.

    Compilers optimized for storage space could simply make a
    reference until a data request is made...

14) section 8.1:
    "Index (with range checking): a[i]"

    What happens when its out of range?

* (it's almost important)

15) 11.1.1.1
   If getint() is retrieving a unsigned int, I suggest calling it
   getunsigned() or getuint() instead.

16) repeatedly, starting in 11.1.1.1:

     The agent will retrieve the instance in the same SNMP context
     in which the element resides.

   What exactly does this mean?  In the SNMP notion of contexts, an
   item can exist in multiple contexts.

17) It's repeatedly stated that oids are specified as dotted-string of
    numbers, but doesn't say what happens if the oid can't be parsed.
    Action stops, like everything else?

18) 11.1.1.2
    the optional argument "value" should be dropped (as someone else
    pointed out).
     a) C has no optional arguments
     b) is not needed.

***
19) why have both longs and ints if they are the same size?  Just drop
    "long"s, or make them 64 bits and drop "long longs"

********
20) repeatedly:

     Note that no actual SNMP PDU needs to be generated and parsed
     when the policy MIB module resides on the same system as the
     managed elements.

    If this is the case, I can write policy scripts that will operate
    on objects that I don't otherwise have permission to modify?  Is
    there *no* access control checking going on here?  The
    DISMAN-EVENT-MIB handles this by using the authentication
    semantics of the person that performed the set operation putting
    it into existence.  Maybe something similar should be done here?

***
21) 11.1.2
    readVarbind() can return bogus values if nothing was ever written
    to that slot location before.  This goes against everything
    previously in the document where the default action was to stop
    processing for situations like that.  Undefined values are
    probably a very bad thing in a policy script.


-- 
Wes Hardaker
NAI Labs
Network Associates