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

From: Jeff Parker <[email-masked]>
Date: Wed, 28 Jul 2004 17:13:37 -0400

I'm not sure that we need the weight of a RowStatus object
for this table.  We don;t spawn off huge numbers of SysLevel
objects: we can expect a Level 1 and a Level 2 object to be
active, but don't expect Level 42.

I will modify the access level of these objects

- jdp

> 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: Jeff Parker <[email-masked]>
Date: Wed, 28 Jul 2004 17:31:08 -0400

Joan -
	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.  

	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,
>

---

From: "Don Goodspeed" <[email-masked]>
Date: Wed, 28 Jul 2004 18:49:51 -0400 (EDT)

Jeff,

I think that Joan says that isisSysLevelIndex should be

not-accessible and that the read-create objects in this 

table should be read-write objects since there is no

desire to add a RowStatus.

-don

========================

Joan -

or both.

- jeff

isisSysType OBJECT-TYPE

SYNTAX INTEGER

{

level1IS (1),

level2IS (2),

level1L2IS (3)

}

MAX-ACCESS read-write

STATUS current

DESCRIPTION

::= { isisSysLevel 1 }

SYNTAX IsisSysLevelEntry

STATUS current

DESCRIPTION

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

---

From: Jeff Parker <[email-masked]>
Date: Thu, 29 Jul 2004 09:02:03 -0400

> >	The isisSysType object is used to select the active 
> levels - 1, 2, or both.
 
> 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).

No.  It may be useful to save the configuration of a level,
even if the system currently does not enable things
at that level.  My car remembers the details of my wife's 
seat position, even when I am driving.  

I can add text to the description for SysLevel to this effect.  

I would rather not move the position of isisSysType from
the rest of the old system 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).

Yes.  

You stated that some "read-only" objects should be changed:
the only one I see is the isisSysLevelOverloadState.  I 
continue to think that read-only is exactly right.  To 
continue the car analogy, this is the oil gauge. 

- jeff parker
 
> >        MAX-ACCESS read-write

...

> >    isisSysLevelIndex 	MAX-ACCESS read-only
	Will change

---

From: [email-masked]
Date: Thu, 29 Jul 2004 10:29:25 -0400 (GMT-04:00)

-----Original Message-----
From: Jeff Parker <[email-masked]>
Sent: Jul 29, 2004 9:02 AM
To: "[email-masked]'" <[email-masked]>, 
	Jeff Parker <[email-masked]>, 
	Jeff Parker <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-ietf-isis-wg-mib-16.txt, question on the isisSysLevelTa	ble

jec>  That is fine as long as this is clarified in the DESCRIPTION
jec>  clauses (for both the scalar and the table).    You *might* want to consider adding a read-only 
jec>  object to the table to indicate which row/rows are "inUse".     If not, this is going to 
jec>   be more checking/guessing  for an operator.  I'd rather have this info captured in
jec>   another row object.   
jec>   

jec>  To be clear, text should be added to both the scalar and the table
jec>  about this, because the 2 are related.

jec>  I disagree because the current MIB style in the IETF is to 
jec>  have scalars moved close to tables they are related to.
jec>   Certainly, this doesn't cause a MIB compilation error/warning, 
jec>   because it is semantic (rather than syntactic) but all the same,
jec>   it is current practice in IETF MIBs to move such a scalar closer to 
jec>   the table.    I don't see why you would NOT want to do this as it
jec>   clarifies the relationship between the scalar and this table.    

Yes.  

jec>  No, sorry if I wasn't clear.    I stated that the read-create objects need to be changed to
jec>  read-write.   (I'm not suggesting changes to  the the read-only objects
jec>  except for the INDEX which we agree should be made "not-accessible".

   thanks, 
     -Joan
 
- jeff parker

...

	Will change