Subject: [Isms] my review of:

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Wed, 8 Aug 2007 16:57:57 +0200

Just nits I think.

- Sect 2.4, 5th line
   to the appropriate Transport Model through a series of APIs, as
  s/API/ASI/ !!??

  also one but last line in sect 2.4
   a series of APIs, as described in "Transport Subsystem for the Simple
  s/API/ASI/ !!??

- section 6:     6.  Overview

  Maybe change that section title to MIB Module Overview?

-        ::= { snmpModules xxxx }

  Is there a good reason to put this underneath that snmpModules branch?
  I do understand we have the snmpUsmMIB (so to be consistent this one
  should be named snmpTsmMIB) and related MIB modules under snmpModules.
  So from that point it makes sense.

  But we have stated (in RFC4181) that an OID is just an OID and
  MIB modules should go under mib-2. 
  And we have no-where specified IANA guidelines as to how/when to
  assign new values under snmpModules.

  I know that some other WG wants to put their MIB modules under a 
  common branch of their own as well... and they are (as we speak)
  getting push-back from our AD.

-    tsmInvalidCache OBJECT-TYPE
       SYNTAX       Counter32
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION "The number of messages dropped because the
                    tmStateReference referred to an invalid cache.

                    This value is not persistent across reboots.
                   "
       ::= { tsmStats 1 }

     tsmInadequateSecurity OBJECT-TYPE
       SYNTAX       Counter32
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION "The number of incoming messages dropped because
                    the actual securityLevel provided was less than
                    the requested securityLevel.

                    This value is not persistent across reboots.
                   "
       ::= { tsmStats 2 }

  According to our CLRs, the names/descriptors should express plurality.
  Not that I cannot live with them being named as is? Just that we as
  MIB doctors should probably follow our own CLRs.

  I do not understand why we need to say something about "persistency"?
  We May want to state that discontinuties only can occur at a reboot
  or restart of the agent?

- I also see:

  tsmGroups OBJECT IDENTIFIER ::= { tsmConformance 1 }
  tsmCompliances OBJECT IDENTIFIER ::= { tsmConformance 2 }

  While RFC4181 suggests:

       xxxMIB
       |
       +-- xxxNotifications(0)
       +-- xxxObjects(1)
       +-- xxxConformance(2)
           |
           +-- xxxCompliances(1)
           +-- xxxGroups(2)

  So first compliances, then groups.

- I get somehwat worried when following (In IANA Considerations
section):

  2.  a value, preferably 4, to identify the Transport Security Model,
      in the Security Models registry at
      http://www.iana.org/assignments/snmp-number-spaces.  This should

   Because if you go to http://www.iana.org/assignments/smi-numbers and
   search for "SNMP Management Architecture:" you will find that the
number
   space is listed there as well. So for now I guess IANA should update
   both locations. But probably it is best if theu only maintain it in
one
   place.

   The  http://www.iana.org/assignments/snmp-number-spaces uses current
   RFCs as references. The http://www.iana.org/assignments/smi-numbers
uses
   old RFC226x as references.

   I will report this "duplicate registry" issue to IANA seperately.

Bert Wijnen 

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms