Re: [Entmib] #355: OSI State to Something New Spectrum

"Randy Presuhn" <> Thu, 25 March 2004 20:30 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id PAA18920 for <>; Thu, 25 Mar 2004 15:30:33 -0500 (EST)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.20) id 1B6bUH-0004Y3-EB; Thu, 25 Mar 2004 15:30:01 -0500
Received: from ([] by with esmtp (Exim 4.20) id 1B6bTx-0004WY-2T for; Thu, 25 Mar 2004 15:29:41 -0500
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id PAA18899 for <>; Thu, 25 Mar 2004 15:29:28 -0500 (EST)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 1B6bTl-0005DA-00 for; Thu, 25 Mar 2004 15:29:29 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6bSu-0005Bc-00 for; Thu, 25 Mar 2004 15:28:37 -0500
Received: from ([]) by ietf-mx with esmtp (Exim 4.12) id 1B6bSc-00059H-00 for; Thu, 25 Mar 2004 15:28:18 -0500
Received: from ([] helo=oemcomputer) by with smtp (Exim 3.33 #1) id 1B6bSb-0005uI-00 for; Thu, 25 Mar 2004 12:28:17 -0800
Message-ID: <005a01c412a8$145a89a0$7f1afea9@oemcomputer>
From: Randy Presuhn <>
References: <> <>
Subject: Re: [Entmib] #355: OSI State to Something New Spectrum
Date: Thu, 25 Mar 2004 12:30:57 -0800
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: IETF Entity MIB WG <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Hi -

> From: "David T. Perkins" <>
> To: "Randy Presuhn" <>; <>
> Sent: Thursday, March 25, 2004 12:04 PM
> Subject: Re: [Entmib] #355: OSI State to Something New Spectrum
> Randy - it gets back to a fundamental question, which is
> "Is the ITU model and the specification for it worthwhile?"
> In the 10+ years that I have asked this question, I have NEVER
> gotten an answer. NEVER! In my own extensive analysis
> (which included creating both state and alarm MIB modules
> that are MUCH closer to the ITU models and specs than the
> documents created in the IETF), it just isn't forth it.
> Now, if someone would volunteer to show me an implementation
> where the benefits surpass the costs, I'll create time to
> learn from them, and change my tune. But pointing me to
> documents and manuals just doesn't cut it. Is this clear?

I think the difference here is in our understanding of "the ITU model".
It sounds like your understand it to mean *all* the stuff in X.731.
However, that's *not* how X.731 was meant to be used.   It provides
a core (Administrative/Usage/Operational states) of rather wide
applicability, and a bunch of other knobs and dials that an object
definer can use when appropriate.  I'm arguing to keep this thing
simple, i.e., not add anything (even from X.731) unless there is
a clear need for it.

So, if one were defining an object class using X.731, and only
operational state was meaningful, then objects of that class simply
wouldn't have administrative or usage states.  This maps well to
using the TCs in this MIB module.  From my perspective, this alone
would be useful.  When one has to do this in something
like the entity state table, it is not as nice.  The workaround of adding
additional "not applicable" values to the enumerations is ugly, but it's
the kind of ugliness we're accustomed to in the SNMP world.

Returning to your question: is having operational state worthwhile?
Absolutely, for the objects that need it.  Is having administrative state
worthwhile?  Same answer.  This is how X.731 was designed to be


Entmib mailing list