Re: Chassis MIB comments

Bob Stewart <rlstewart@eng.xyplex.com> Mon, 19 October 1992 17:45 UTC

Return-Path: <owner-chassismib>
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA22218; Mon, 19 Oct 92 13:45:52 -0400
Received: from xap.xyplex.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA22214; Mon, 19 Oct 92 13:45:49 -0400
Received: by xap.xyplex.com id <AA26576@xap.xyplex.com>; Mon, 19 Oct 92 13:43:28 -0500
Date: Mon, 19 Oct 92 13:43:28 -0500
Message-Id: <9210191843.AA26576@xap.xyplex.com>
From: Bob Stewart <rlstewart@eng.xyplex.com>
To: chassismib@cs.utk.edu
In-Reply-To: David Perkins's message of Thu, 15 Oct 92 15:05:37 PDT <9210152205.AA02036@immer.synoptics.com>
Subject: Re: Chassis MIB comments


Commenting as a working group member, not as chair, mostly I support Dave's
comments, suggested changes, and questions.

It struck me while looking at Dave's example configuration, which I like, that
we don't have a way to indicate two connections to the same internal segment.
Do we mean to imply that is not allowed?  

I don't see what's wrong with the section on multiple instances of the Chassis
MIB.

Forcing the slot table to be "complete", i.e. have no holes in it, doesn't
allow for creative slot numbers with big gaps between them.  The value
removed(4) seems like a problem.  When would it go away?

Dave's reasons for splitting out Party and Community information are
truncated.  So far I don't agree.

Including chasEntityObjectId is redundant, if not useless.  You can get that
information from the entity's own MIB.

	Bob