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

Margaret Wasserman <> Mon, 03 May 2004 11:57 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id HAA22566 for <>; Mon, 3 May 2004 07:57:18 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.20) id 1BKbwV-0001e2-0V; Mon, 03 May 2004 07:49:03 -0400
Received: from ([] by with esmtp (Exim 4.20) id 1BKbsJ-0008RT-8v for; Mon, 03 May 2004 07:44:43 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id HAA22121 for <>; Mon, 3 May 2004 07:44:41 -0400 (EDT)
Received: from ([] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKbsI-0003eD-Iw for; Mon, 03 May 2004 07:44:42 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKbpP-000387-00 for; Mon, 03 May 2004 07:41:45 -0400
Received: from ([] by ietf-mx with esmtp (Exim 4.12) id 1BKbmZ-0002Z4-00 for; Mon, 03 May 2004 07:38:47 -0400
Received: from [] (account margaret HELO []) by (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 68624; Mon, 03 May 2004 07:37:52 -0400
Mime-Version: 1.0
Message-Id: <p06020413bcbbde655c8f@[]>
Date: Mon, 03 May 2004 07:35:45 -0400
To: Sharon Chisholm <>
From: Margaret Wasserman <>
Subject: RE: [Entmib] #355: OSI State to Something New Spectrum
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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: <>, <>

Sharon corrected my understanding of issue #355 (see below).  But, my 
conclusion is much the same.

At this point we have had multiple WG Last Calls on this document 
and, according to our charter, we are quite overdue to send it to the 
IESG...  So, I think that it should require consensus of the group to 
make any major changes to the document at this point.  Do others 
agree with that position?

Given that we are split on this particular issue, I do not believe 
that we have consensus to make these changes so we should not make 
them.  Does that make sense?


>Actually, the issue was more/also whether there was consensus to change the
>current MIB a lot to diverge from the ITU-T model. We've diverged from it as
>has made sense to the working group, but there were a few requests for
>changes such as object renaming which in my personal view didn't make sense
>to do since they seemed non-value add changes. My take on consensus to
>diverge further is that we are somewhat split on the issue.
>-----Original Message-----
>From: Margaret Wasserman []
>Sent: Saturday, May 01, 2004 11:28 AM
>To: Randy Presuhn;
>Subject: Re: [Entmib] #355: OSI State to Something New Spectrum
>Hi Randy,
>I did not see strong support for making changes to the Entity State
>MIB to bring it more in line with the ITU model, so I do not think
>that we have consensus to make these changes.
>Unless you disagree with my assessment, Sharon should mark this issue
>as closed.
>At 12:30 PM -0800 3/25/04, Randy Presuhn wrote:
>>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
>Entmib mailing list
>Entmib mailing list

Entmib mailing list