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

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 25 Mar 2004 11:33:38 -0500

hi

Ok, that means we are not tied to one end of the spectrum. Here are my two
views on where we setting in the spectrum.

Personal: I'm worried about change for the sake of changes or
over-simplification of this MIB which in this continuum could be considered
moving too far over the other way.   The first would end in mapping tables,
which while not ideal are not too bad, the latter would result in me and
others having to continue to use proprietary MIBs to get meaningful state
management. We've put a lot of effort into getting to current set of objects
to try to meet WG needs and I think we are pretty close. If we focus our
efforts on resolving the known issues without falling down the slippery
slope of re-designing everything, we can be done soon. If we don't we could
be here for another two years. I haven't yet seen consensus for deleting any
of the states, but if we get there I think I'd prefer to see them made
optional instead.

Co-Editor: As indicated, if we deviate too much we need to provide a mapping
back to the OSI model much like we have done with other state objects. 

Sharon

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Thursday, March 25, 2004 10:34 AM
To: Chisholm, Sharon [CAR:0S00:EXCH]; [email-masked]
Subject: RE: [Entmib] Entity comments

In hindsight (after having seen discussion over the last 2 days) and based
on:
<clip>
> 
> 1. Prefixing the TCs with ITU prefix. The answer to this
> depends on where we are in that spectrum.
> 
It seems that a ITU is NOT the proper prefix.
But some prefix does make sense.

Bert

_______________________________________________
Entmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/entmib

_______________________________________________
Entmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/entmib

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 25 Mar 2004 11:33:38 -0800

Hi -

> From: "Sharon Chisholm" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, March 25, 2004 8:33 AM
> Subject: [Entmib] #355: OSI State to Something New Spectrum
...
> back to the OSI model much like we have done with other state objects.

Such deviation seems contrary to the whole point of developing this MIB
module in the first place.  The more closely the semantics are aligned
with the OSI ones (within the constraints imposed by the differing object
models), the better.

...
> But some prefix does make sense.
...

I'd have no problem with EntState as a prefix for the TCs, although I'd
also have no objection to leaving them un-prefixed, but in a separate
MIB module in the same document.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 25 Mar 2004 11:33:38 -0800

Hi -

...

...
...

Randy

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 25 Mar 2004 12:04:04 -0800

HI,

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?

>MIB module in the same document.

Regards,
/david t. perkins

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 25 Mar 2004 12:30:57 -0800

Hi -

> From: "David T. Perkins" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Thursday, March 25, 2004 12:04 PM
> Subject: Re: [Entmib] #355: OSI State to Something New Spectrum
...
...

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
used.

Randy

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 25 Mar 2004 12:04:04 -0800

HI,

Regards,
/david t. perkins

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 25 Mar 2004 12:30:57 -0800

Hi -

...
...

Randy