Re: [Entmib] A state model....

> HI,
>
> I find the document specified below troubling.
> The many reasons inlcude:
>  1) there is already a well known state model for interfaces,
>     which is specified in the IF MIB module.
>     a) The document does not specify why the IF state model
>        should be replaced (or augmented) with another model.

IF state model does not provide the flexibility in defining the states.
When ifOperStatus is down, we do not why it is down. For example
in IPv6, the DAD may fail, there is no way to specify this in the state
info.

>     b) The document does not compare it's states and
>        transitions those from the IF state model

Yep, this document is definitely not complete. The reason behind in
publishing the draft in this form is to see if this approach is useful for
defining
the states. After confirming the usefulness we can complete the draft.

>  2) the state model in the document is primarily based
>     on that found in X.731, but is not the same.

True

>     a) the connection between the two models needs
>        to be explained.
>     b) the terminology used is that from the "TELCO" industry
>        sector and not from the Internet DATACOM industry sector

True. But if the concept of State representation is useful we can define
this with Datacom terminology.

>  3) The state model doesn't support redundancy (and thus, is
>     not sufficiently general to be used for physical
>     (and logical) components that support redundancy)

The current draft does not support this.

>  4) In many components, it can not be determined if the
>     component is "operational", when it is administratively
>     disabled.

What if an entity is Operational and it is locked by the administrator?

>
> Finally, it was sort of strange that the security section specified
> a reference to SNMPv1 when the document is a model and does not
> contain SNMP object nor notification definitions.

As I mentioned earlier the draft is not complete by itself. This can be done
if the approach is useful.
>
> On Tue, 9 Dec 2003, Syam Madanapalli wrote:
> > I am wondering if the following draft brings any interest
> > for the Entity State MIB.
> >
> > State Model for IPv6 Interfaces
> > http://www.ietf.org/internet-drafts/draft-syam-ipv6-state-model-00.txt
> >
> > But this state model is only for IPv6 Interfaces whereas Entity State
MIB
> > covers every thing.
> >
> > Thank you,
> > Syam
> >
> >
> > ----- Original Message -----
> > From: "Juergen Schoenwaelder" <j.schoenwaelder@iu-bremen.de>
> > To: <Margaret.Wasserman@nokia.com>
> > Cc: <entmib@ietf.org>
> > Sent: Monday, December 08, 2003 7:13 PM
> > Subject: Re: [Entmib] Confirmming Meeting Consensus
> >
> >
> > > On Mon, Dec 08, 2003 at 08:24:11AM -0500, Margaret.Wasserman@nokia.com
> > wrote:
> > > >
> > > > During the meeting in Minneapolis, there was agreement
> > > > in the room on a few points, an dI'd like to confirm
> > > > that consensus on the mailing list.
> > > >
> > > > In particular, we reached agreement at the meeting on
> > > > the following points:
> > > >
> > > >  - We will deprecate the Alias Mapping Table so that the Entity
> > > >    MIB can advance to Draft Standard.
> > >
> > > Well, this is what it takes...
> > >
> > > >  - Future extensions to the Entity MIB should be handled as
> > > >    separate MIBs that augment the Entity MIB.
> > >
> > > Not sure how useful such a blanket statement is.
> > >
> > > >  - The Entity State MIB is currently too complex and should be
> > > >    simplified.
> > >
> > > I like to know what precisely people find too complex before
subscribing
> > > to such a blanket statement. Can someone please explain (and perhaps
> > > suggest what precisely needs to be removed)?
> > >
> > > /js
> > >
> > > --
> regards,
> /david t. perkins
>
>

_______________________________________________
Entmib mailing list
Entmib@ietf.org
https://www1.ietf.org/mailman/listinfo/entmib