Last Hurdle

["David L. Arneson ([e-mail])" <[e-mail]>]

I appears to me that we have one last thing to problem to resolve.  I will
attempt to consolidate to help direct our engery.

Manu Kaycee writes:

Briefly, let's consider the case where multiple modules are used to realize
a single entity.  Depending on where, and how, the agent(s) and managed
objects are realized, such a logical to physical mapping is required, internal
to said entity.  (Case in point: the ifTable...which interface resides on which
module?)

Now, for two questions.  At lease one of them has been asked before, with
insufficient response.  Hence, this poll.

	1.  Is there added value, if such mapping information is made
            available, externally?  What do other WG members feel?

            (I believe it provide extra, added value...details not
            not articulated, here.)

	2.  Does a table providing such mapping information belong in
            the chassis mib?  What do other WG members feel?

	    (I believe it does.)

            
Now Dan Romascanu seems to agree that the table is useful.  He also would
like to see Keith's ifType proposal added.

Just to refresh your memories here is the table under discussion I have cleaned
it up a bit.

-- Interfaces group

-- The term interface should be read as logical interface.  In fact this
-- may be defined as interface, bridge port, repeater port, etc.

-- Implementation of this group is optional.

chasIfTable	OBJECT-TYPE
	SYNTAX	SEQUENCE OF chasIfEntry
	ACCESS	not-accessible
	STATUS	mandatory
	DESCRIPTION
		"A table the contains information about which
		 interfaces/ports are connected to which segments on
		 which entities."
	::= { chassis 5 }

chasIfEntry	OBJECT-TYPE
	SYNTAX	ChasIfEntry
	ACCESS	not-accessible
	STATUS	mandatory
	DESCRIPTION
		"A configuration relationship between an entity, its
		 interfaces and the segments those interfaces maybe 
		 connected to.  Such a relationship exists if an entity
		 realizes an interface."
	INDEX	{ chasIfEntity,
		  chasIfIndex,
		  chasIfSegment }
	::= { chasIfTable 1 }

ChasIfEntry ::= SEQUENCE {
	chasIfEntity
	    INTEGER,
	chasIfIndex
	    INTEGER,
	chasIfSegment
	    INTEGER,
	chasIfSlot
	    INTEGER
	}

chasIfEntity	OBJECT-TYPE
	SYNTAX	INTEGER (1..65535)
	ACCESS	read-only
	STATUS	mandatory
	DESCRIPTION
		"The entity for this interface relationship.  The entity
		 identified by this object is the same entity identified
		 by chasEntityIndex."
	::= { chasIfEntry 1 }

chasIfIndex	OBJECT-TYPE
	SYNTAX	INTEGER (1..65535)
	ACCESS	read-only
	STATUS	mandatory
	DESCRIPTION
		"An INTEGER which is the particular index value of whatever 
               object type chasIfIndexType points to, such that it 
               identifies a particular interface/port/whatever."
	::= { chasIfEntry 2 }

chasIfSegment	OBJECT-TYPE
	SYNTAX	INTEGER (1..65535)
	ACCESS	read-only
	STATUS	mandatory
	DESCRIPTION
		"The segment of this interface relationshil.  The segment
		 identified by this object is the same entity identified
		 by chasSegmentIndex."
	::= { chasIfEntry 3 }

chasIfSlot	OBJECT-TYPE
	SYNTAX	INTEGER (1..65535)
	ACCESS	read-only
	STATUS	mandatory
	DESCRIPTION
		"The slot that this interface relationship exists on.
		 The slot identified by this object is the same slot
		 identified by chasSlotIndex."
	::= {chasIfEntry 4 }

I think the above provides alot of information that pertains to chassis
organization that is not available in other MIBs.  I also think Keith's
idea is real slick.

So which direction do we go?  Do others like this table?  Jeff Case do
we get an out of bounds tweeet?  Do we implement Keith's idea alone?
Or maybe we do both in some way.  I seems that this table as optional
provide those that need to can implement it.  Those that have no current
need don't have to.

It seems if we get past this we have a MIB we can live with.

/David Arneson [[e-mail]] [ [phone] ]