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

From: Christian Hopps <[email-masked]>
Date: Wed, 18 May 2005 08:43:10 -0700

As the MIB doctor review is complete the IS-IS MIB is now in WG last  
call. Please recall that we are only looking for issues with the  
current version of the MIB as we need to get this document published.  
It was pointed out that we could add support for graceful restart;  
however, changes such as this will have to be addressed in a later  
revision of the MIB.

Please post any comments by June 1st.

Chris and Dave.

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

---

From: [email-masked]
Date: Sat, 28 May 2005 15:50:41 -0400

Most of my comments deal with the following 2 objects:

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 }

isisCircLevel OBJECT-TYPE
        SYNTAX INTEGER
            {
                level1(1),
                level2(2),
                level1L2(3)
            }
        MAX-ACCESS read-create
        STATUS current
        DESCRIPTION
            "Indicates which type of packets will be sent and
             accepted on this circuit. The values used will be
             modified by the settings of isisSysType. This
             object follows the replaceOnlyWhileDisabled behavior."
        DEFVAL { level1L2 }
    ::= { isisCircEntry 8 }

1a)  Why can't the TC IsisAdjLevel be used for isisSysType and isisCircLevel?

IsisAdjLevel ::= TEXTUAL-CONVENTION
        STATUS current
        DESCRIPTION
            "Identifies one or more levels."
        SYNTAX INTEGER
            {
                level1(1),
                level2(2),
                level1and2(3)
            }

If this TC can be used (and I think that it can/should) then 
please rename this to something more generic such as IsisLevelType

1b)  The naming is inconsistent for the following related objects

isisSysType and
isisCircLevel

Since these are related, could they be renamed 
so as to indicate they are related, e.g. isisSysType, isisCircType
or isisSysLevel, isisCircLevel, or isisSysLevelType, isisCircLevelType?

1c)  Could the description of isisCircLevel be clarified such that
an implementor understands what the agent is supposed to
return for an error in the event that isisSysType has a value of level1(1)
and an operator attempts to set isisCircLevel to level2(2) or level1and2(3)?

2)  Several Entry descriptions contain a phrase similar to 
    "Configured values will survive an agent reboot", I don't understand
    why this would be dictated by a MIB?  In other words, why isn't 
    a StorageType object present in these tables?

3)  The following object's

   isisCircIfSubSelector OBJECT-TYPE
        SYNTAX Integer32
        MAX-ACCESS read-create
        STATUS current
        DESCRIPTION
            "A specifier for the part of the interface ifIndex to which
             this circuit corresponds, such as a DLCI or VPI/VCI.
             This object cannot be modified after creation.

             Holds 0 if not used."
        DEFVAL { 0 }
    ::= { isisCircEntry 3 }

DESCRIPTION is confusing.  In the case of ATM, does this value contain
an ifIndex or zero, and if so, what is the ifType that corresponds to this
ifIndex?

Or, could it contain an actual VPI/VCI in which case 0 could be a valid
VPI/VCI?

Furthermore, the Abstract states:

   "This document describes a management information base for the IS-IS
   Routing protocol when it is used to construct routing tables for IP
   networks."

so why is there a need to have this object at all?  

Thanks, 
  -Joan

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 31 May 2005 10:26:03 -0700 (PDT)

>     a StorageType object present in these tables?

Having a StorageType column is one option, but it is not the only
option.  According to draft-ietf-ops-mib-review-guidelines-04.txt
Section 4.6.4,

   - If dynamic row creation and/or deletion by management applications
     is supported, then:
     [ ... ]
     - There either MUST be one columnar object with a SYNTAX value of
       StorageType [RFC2579] and a MAX-ACCESS value of read-create, or
       else the row object (table entry) DESCRIPTION clause MUST specify
       what happens to dynamically-created rows after an agent restart.

The language in the DESCRIPTION clause is equivalent to having an
a StorageType column that can assume only the value nonVolatile(3).

Mike Heard