Subject: Re: [Isis-wg] WG Last Call on IS-IS MIB.

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 24 May 2005 11:45:24 +0100

Hi, 

I have a few comments on the MIB module. 

Cheers,
Adrian 

1. Imports
It is useful to indicate the RCF from which the import is taken.
For example... 

       TEXTUAL-CONVENTION, RowStatus, TruthValue
               FROM SNMPv2-TC                              -- [RFC2579]
       MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
           Integer32, Unsigned32, Counter32, mib-2
               FROM SNMPv2-SMI                             -- [RFC2578]
       MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
               FROM SNMPv2-CONF                            -- [RFC2580] 

2. AdminState TC 

   AdminState ::= TEXTUAL-CONVENTION
       STATUS current
       DESCRIPTION
           "Type used in enabling and disabling a row.
            Values match those in RFC 2863."
       SYNTAX INTEGER
           {
               on(1),
               off(2)
           }

   Note that while the values *do* match RFC2863,
   - the names for the values are different
     ("up" and "down"_
   - RFC2863 also defines testing(3)
   Perhaps best just to delete the reference to RFC2863? 

3. Choice between unsigned32 and integer32

  The choice between these Syntaxes appears a bit
  arbitrary throughout. Perhaps you just need to check that
  you are happy with the choice and that the MIB Doctor
  agrees. 

4. isisSysType 

   isisSysType OBJECT-TYPE
       SYNTAX INTEGER
           {
               level1IS (1),
               level2IS (2),
               level1L2IS (3)
           }
       MAX-ACCESS read-write
       STATUS current
       DESCRIPTION
           "At which levels is the Intermediate System
            running? This object may not be modified when
            the isisSysAdminState variable is in state 'on'
            for this Intermediate System."
       REFERENCE "{ISIS.aoi iSType (2)}"
       DEFVAL { level1L2IS }
   ::= { isisSysObject 2 } 

  Why don't you use SYNTAX IsisAdjLevel ?
  Is it the name of the TC that puts you off? In which case
  perhaps change the name? 

5. isisManAreaAddrExistState 

   isisManAreaAddrExistState OBJECT-TYPE
       SYNTAX RowStatus
       MAX-ACCESS read-create
       STATUS current
       DESCRIPTION
           "The state of the isisManAreaAddrEntry.  If the
            isisSysAdminState for this Intermediate System is 'on', and
            an attempt is made to set this object to the value 'destroy'
            or 'notInService' when this is the only
            isisManAreaAddrEntry in state 'active' for this
            Intermediate System should return inconsistentValue. 

            A row entry cannot be modified when the value of this
            object is 'active'."
   ::= { isisManAreaAddrEntry 2 } 

  Since the only objects are the index and the row status it may be
  superfluous to say that the row entry cannot be modified. 

6. isisRedistributeAddrExistState 

  Ditto point 5. 

7. isisSysLevelSetOverloadUntil 

   isisSysLevelSetOverloadUntil OBJECT-TYPE
       SYNTAX Unsigned32
       UNITS "Seconds until clearing manually set Overload Bit"
       MAX-ACCESS read-write
       STATUS current
       DESCRIPTION
           "If this object is non-zero, the overload bit is set at
            this level when the isisSysAdminState variable goes to
            state 'on' for this Intermediate System.  The overload bit
            remains set for isisSysLevelSetOverloadUntil seconds.
            When isisSysLevelSetOverloadUntil seconds have elapsed,
            the overload flag remains set if the implementation has
            run out of memory, or if it is set manually using the
            isisSysLevelSetOverload object."
   ::= { isisSysLevelEntry 6 } 

  I think you also need to describe what happens if you set
  isisSysLevelSetOverload to false when isisSysLevelSetOverloadUntil
  is non-zero. 

8. isisCircLevel 

  Ditto point 4. 

9. isisCircLastUpTime 

   isisCircLastUpTime OBJECT-TYPE
       SYNTAX Unsigned32
       UNITS "Seconds since startup when this circuit was last 'on'"
       MAX-ACCESS read-only
       STATUS current
       DESCRIPTION
           "If the circuit is enabled, the number of seconds
            since system startup when isisCircAdminState most
            recently entered the state 'on', or 0 if the
            circuit has never been 'on'."
   ::= { isisCircEntry 13 } 

  Wouldn't we usually use SYNTAX TimeStamp from RFC2579? 

10. Counters 

  Don't we need some description of the discontinuity behavior
  of the counters? 

11. Wide counters 

  Are you happy with running the hello and packet counters at
  only 32 bits? Woth considering how often they would wrap in
  normal (default timer) processing. Then note that they would
  be used to diagnose misconfiguration of timers when packet
  thrash might occur. 

12. isisISAdjLastUpTime 

  Ditto point 9. 

13. Notifications 

  Can we turn off notifications? 

14. I-D nits 

  Note also that running the idnits script generates a few other
  minor issues. 

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 25 May 2005 09:54:02 -0700 (PDT)

> I have a few comments on the MIB module.

Glad to see these comments.  I'd like to amplify on a few points.

>                FROM SNMPv2-CONF                            -- [RFC2580]

We MIB Doctors have been asking that people not put citation tags in
MIB modules, since that has the effect of creating a dangling
pointer when the MIB module is extracted for separate use.  So, if
you want to do this, please do it like so:

         TEXTUAL-CONVENTION, RowStatus, TruthValue
                 FROM SNMPv2-TC                              -- RFC 2579

>   superfluous to say that the row entry cannot be modified. 

It also does not hurt to have the text there, and having it there will
make MIB module maintenance easier if columns are added in the future.

>   Wouldn't we usually use SYNTAX TimeStamp from RFC2579? 

That would probably be a good idea.  If you do that, adjust the
DESCRIPTION clause and get rif of the UNITS clause (the units of
TimeStamp are 1/100ths of a second).

>   Don't we need some description of the discontinuity behavior

That is needed only if discontinuities can occur at times other than
a management subsystem re-initialization.  For counters that are
tied to interfaces (i.e., where ifIndex is one of the row indices)
ifCounterDiscontinuityTime is sometimes used (see RFCs 2863 and
3289).

//cmh