Subject: [Isis-wg] draft-ietf-isis-wg-mib-16.txt, question on the isisSysLevelTable

From: [email-masked]
Date: Wed, 28 Jul 2004 17:10:38 -0400 (GMT-04:00)

Hi Jeff,

The index for the isisSysLevelTable is read-only and should be
not-accessible.  Also, there are read-create objects in the entry
BUT there is no RowStatus object.

Based on my understanding of this table, there
probably should be a RowStatus object in the entry.  For example, is it
possible to have NO level2IS entry?  Is so, then a
RowStatus object is needed.

If not, then is the intention that there are 2 rows in this table (always),
one row for level1IS and one row for level2IS?  If so, then these read-create objects should 
change to read-write.   

  thanks,
    -Joan

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

---

From: [email-masked]
Date: Thu, 29 Jul 2004 08:18:53 -0400

At 05:31 PM 7/28/04 -0400, Jeff Parker wrote:
>Joan -

Hi Jeff,

See below.

>	I have taken a look at the table, and don't understand your concern.
>
>	The isisSysType object is used to select the active levels - 1, 2,
>or both.
>The issiSysLevelTable holds a number of objects: I have edited the MIB to
>include the relevant sections.  They all seem appropriate to me: those that
>I want to change are read-write, while those that I want to read are
>not-accessible.  The Overload state may be set by hand, but may also be set
>by the implementation when it is low on memory.  
>

So let me see if I am understanding you.  If the
scalar object isisSysLevelType has the value of
level1IS(1), then there is ONE row in the isisSysLevelTable
and this row has the isisSysLevelIndex with a value
of level1IS(1).

If the value of the scalar isisSysLevelType has the value
of levelIS(2), the thre is ONE row in the isisSysLevelTable
and this row has the isisSysLevelIndex with a value of
level2IS(2).

If the value of the scalar isisSysLevelType has the value
of levelL1L2IS(3), then there are 2 rows in the isisSysLevelTable
where one row is the isisSysLevelIndex with a value of level1IS(1)
and the other row with the isisSysLevelIndex with a value of
level2IS(2).  Is this correct?

If the above is correct than I think the DESCRIPTION clauses for
both the scalar object, isisSysLevel and the isisSysLevelTable
need to state this clearly so that the agent is responsible
for creating/destroying rows in this table if the scalar object
is changed.  The operator using this MIB and the developer 
implementing this MIB should understand
the relationship between that scalar and this table.  (This wasn't
obvious to me as a fairly new reader of the MIB.)

Also, in addition to clarifying the DESCRIPTION clauses,
I would strongly suggest moving the scalar object to just before
the table to emphasize the relationship between the scalar and
the table.

The SMI is still incorrect in that the Index of the isisSysLevelTable
needs to be not-accessible (think we are in agreement on this).

Also, if the agent is responsible for creating/destroying rows,
then all of the read-create objects should be changed  to 
read-write (as Don also states).   read-create is when the
operator is creating/destroying rows (and related to RowStatus).

Does this make sense?

  thanks, Joan

>	Do you have a specific suggestion?
>
>- jeff
>
>    isisSysType OBJECT-TYPE
>        SYNTAX INTEGER
>            {
>                level1IS (1),
>                level2IS (2),
>                level1L2IS (3)
>            }
>        MAX-ACCESS read-write
>        
>	-- The System Level Table
>-- This table captures level-specific information about the System
>
>    isisSysLevelTable OBJECT-TYPE
>        SYNTAX SEQUENCE OF IsisSysLevelEntry
>        MAX-ACCESS not-accessible
>        STATUS current
>        DESCRIPTION
>            "Level specific information about the System."
>    ::= { isisSysLevel 1 }
>
>    isisSysLevelEntry OBJECT-TYPE
>        SYNTAX IsisSysLevelEntry
>        MAX-ACCESS not-accessible
>        STATUS current
>        DESCRIPTION
>            "Describe variables defined for Area or Domain."
>        INDEX { isisSysLevelIndex }
>    ::= { isisSysLevelTable 1 }
>
>(Edited to put field and access on a single line)
>
>    isisSysLevelIndex 	MAX-ACCESS read-only
>    isisSysLevelOrigLSPBuffSize MAX-ACCESS read-create
>    isisSysLevelMinLSPGenInt 	MAX-ACCESS read-create
>    isisSysLevelOverloadState 	MAX-ACCESS read-only
>    isisSysLevelSetOverload 	MAX-ACCESS read-create	
>    isisSysLevelSetOverloadUntil    MAX-ACCESS read-create
>    isisSysLevelMetricStyle 	MAX-ACCESS read-create
>    isisSysLevelSPFConsiders 	MAX-ACCESS read-create
>    isisSysLevelTEEnabled 	MAX-ACCESS read-create
> 
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Wednesday, July 28, 2004 5:11 PM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: draft-ietf-isis-wg-mib-16.txt, question on the
>> isisSysLevelTable
>> 
>> 
>> 
>> Hi Jeff,
>>