Re: comments on 21-july draft

[[e-mail] (Keith McCloghrie)]

> 1) chasUpTime--I will make one more pitch for this object, then give up:
> Basing chasSlotLastChange (or any other HW timestamp) on sysUpTime implies
> that the hardware portion of an entity/device is always reset when the
> management portion is reset.  In our repeaters, it is possible to
> reset the management without resetting the hardware. 
 
I still don't understand.  The timestamps do not impose any requirement to 
reset the hardware when the mgmt portion is reset (if there is any text
which implies that we need to change it.)  On the other hand, after the 
mgmt portion is reset, how does that mgmt portion know when the slot last 
changed ?  How can it give anything else but a zero, meaning "at or before 
the last mgmt reset", which is exactly the semantics of chasSlotLastChange:

          chasSlotLastChange OBJECT-TYPE
              SYNTAX  TimeTicks
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "The value of MIB-II's sysUpTime (in the agent
                      supporting this MIB) at which a module in this
                      slot was last inserted or removed from this slot.
                      If no module has been inserted or removed from
                      this slot since the last time the network
                      management system was last re-initialized, then
                      this object has a zero value."
              ::= { chasSlotEntry 3 }

> I'm also concerned about the assumption/rule that only one agent per chassis
> implement the Chassis MIB, and therefore chasSlotLastChange is relative to 
> the primary agent.  It may be possible for an NMS to access a secondary 
> agent in the chassis, but not the primary.

I think it was me who said "the model is one agent per chassis implements
the Chassis MIB".  So, I'd like to amend that to "there is no requirement 
to have more than one agent per chassis implement the Chassis MIB, but 
each such agent must implement all mandatory parts of the MIB and contain 
information on all entities/modules/segments in the chassis".  Also
note that I believe "chassis" here can either be a physical chassis, or
a "logical chassis", as David suggested.  (Remember what Jeff said at our
first wg meeting about a "chassis" might be as big as Texas !!  In fact,
I do believe this MIB applies equally well to any related collection of 
devices whether or not they happen to be co-located in a physical chassis.
Would anybody object to having some words in the Overview which discusses
the concept of a "logical chassis" which is not necessarily bounded by
any physical constraints ??)
 
> 2) chasEntityAdminStatus = reset(4)
> This is a great idea.  We have a "chassisSlotReset" capability in our MIBs,
> but resetting per entity is a much better idea.  There should be language 
> in the DESCRIPTION clause that specifies that an agent may disallow setting
> this object (return BADVAL, NOSUCH, or GENERR?).  

How about including the following in the DESCRIPTION:

      Agent support for the writing of any of the values of this 
      object is implementation-specific.  For example, this object 
      might be read only for entities that disabling would compromise 
      the integrity of the chassis.

Note that I don't think it's appropriate to include specific SNMP 
error-codes in the DESCRIPTIONs.
 
> 3) chasEntityFunction
> Obviously, multiple-function devices can be described with different
> values of chasEntityIndex/chasConfigEntity (and the same value of 
> chasConfigSlot). This way, chasEntityFunction can be an OBJECT IDENTIFIER,
> avoiding the "bounded enumeration" problem that exists with INTEGER
>objects.  The trade-off is that the chasEntityTable will be harder to implement
> and harder for an NMS to manage.  It will not take long for this bit-string
> list of 9 functions to be out-dated.
 
Potentially a good idea, but there will be multi-function entities 
(one agent supporting MIBs for multiple functions in the same MIB view).
Thus, this object needs to take on multiple values, which either means 
splitting it off into its own separate table (yuck!), or have the value 
be a sum of the individual values.  Now, objects which are OIDs can not 
be a sum of values, unless an OID value is defined for each combination 
of functions (yuck!).  On the other hand, I don't think this object has 
the potential for the explosion of values which ifType has had, so maybe 
we can live with a bit-string ?  Anybody got a better idea ?  Would it 
be better to have two objects, an INTEGER for a sum of standard functions, 
plus another as an OID for additional not-standardized functions ?

> 4) chasConfigStatus
> Are the enumerations of valid(1) and invalid(2) enough?  I think the
> RMON model (add an OwnerString and use EntryStatus) would be more 
> robust.  

I see this table as very much more stable than any of the RMON tables.
RMON has the concept of allowing multiple managers to create their own
independent entries in its tables; I don't think there's any concept 
of "ownership" here.  As for EntryStatus, there's very little in the
table in the way of parameters which managers can/need to set, other 
than to create/delete entries.  However, if you think there is 
potential for the addition of such settable parameters in the future,
then I wouldn't object to EntryStatus.

> 5) chasConfigIfIndex
> I'm confused about the usefulness of this object. Is this supposed to
> help an NMS figure out how to reach/manage a particular entity? 

No, it's meant to help an NMS figure out how to relate the information
in a managed entity's MIB back to the information in this MIB.  (But
see other messages regarding having an indexType and indexValue.)

Keith.