the LMP mib

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Just a very quick reaction (better to alert you at rev 00 than
later).

- You have picked up an old template for section 4.
  It references obsolted RFCs. Pls use latest one
- Section 4.1 is redundant and can be removed.
- Remove "using SMIv2" from the title.
  We have been using SMIv2 for 5 years or so. This
  "Using SMIv2" was customary when we had SMIv1
  as the standard tool. These days SMIv2 is mandatory
- Why is the abstract and the 1st para of the intro (just
  underneath each other) exactly the same?
- sect 9. DO not talk about interfaces group of MIB II.
  Instead just stick to IFMIB (RFC2863)
- You are importing/using IpAddress.
  CANNOT do that. Pls use TCs from RFC2851, or better
  from the update that is being done right now.
- REVISION clause(s). In the end, when this MIB is first
  published as RFC, we only want one simple revision
  clause, aka:
    REVISION "yyyymmddhhmmZ"
    DESCRIPTION "Initial version, published as RFC xxxx"
    -- xxxx to be assigned by RFC Editor.
  All the changes made during InternetDraft stages are
  nice for the WG, but not really interesting once we publish.
  You can put them in an appendix till doc goes to RFC-Editor
- lmpNbrNodeId OBJECT-TYPE
   SYNTAX        NodeID
   MAX-ACCESS    accessible-for-notify
   STATUS        current
  This is an INDEX object... should be not-accessible!
- STorageType object needs to describe which objects
  (if any) must be writable when the StorageType is permanent
- RowStatus object needs to describe which objects (if any)
  can be modified when the status is active.
- I do not see a reference to any discontinuity object in you
  counter32/counter64 objects. Is there no potential for
  discontinuity, otehr than at restart of the SNMP agent?
  I guess there is, because you do have such an object
- In general, I would just talk about "notifications" and not
  about traps. A notification can be send as a trap or as
  an inform, but that is under control of the MIB(s) in
  RFC2573.
- I would like to see 2 conformance statements:
 
  lmpMIBFullConformance which allow READ/Create, so that it
                        can be used for configuration and
                        monitoring.
  lmpMIBReadOnlyCompliance which is more or less the one you
                           have now and which allows for just
                           minitoring.

   
- In the security section, can you add some words about which objects
  contain sensitive information and why? That would be usefull for
  users so they can determine how serious they have to excercise
  access control.

Just a quick sniff.
Bert
Bert