Re: 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.
    b) The document does not compare it's states and
       transitions those from the IF state model
 2) the state model in the document is primarily based
    on that found in X.731, but is not the same.
    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
 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)
 4) In many components, it can not be determined if the
    component is "operational", when it is administratively
    disabled.

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.

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" <[email protected]>
> To: <[email protected]>
> Cc: <[email protected]>
> Sent: Monday, December 08, 2003 7:13 PM
> Subject: Re: [Entmib] Confirmming Meeting Consensus
> 
> 
> > On Mon, Dec 08, 2003 at 08:24:11AM -0500, [email protected]
> 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