Subject: [Entmib] Confirmming Meeting Consensus

From: [email-masked]
Date: Mon, 8 Dec 2003 08:24:11 -0500

Hi All,

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.
 
 - Future extensions to the Entity MIB should be handled as
   separate MIBs that augment the Entity MIB.
 
 - The Entity State MIB is currently too complex and should be
   simplified.

Please feel free to express your opinion on any of these
points on the mailing list.

Thanks,
Margaret

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 8 Dec 2003 15:51:04 +0200

>    separate MIBs that augment the Entity MIB.

OK with the two above.
 
>  - The Entity State MIB is currently too complex and should be

As the editor of the document was absent from the meeting I suggest that we hear her opinion. It is my impression that she is working to update the document, based on concrete comments received before the Vienna IETF. As far as I remember, the opinions in the meeting (including mine) were not necessarily addressing specific aspects of the perceived complexity, but rather mentioned the fact that the MIB design went far away from the original one column extension of the entPhisical table. To be useful, comments should be more specific, and address the Internet-Draft version that is out there. 

> points on the mailing list.

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 8 Dec 2003 15:51:04 +0200

OK with the two above.

Regards,

Dan

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 8 Dec 2003 09:25:36 -0500

Hi

Yes, unfortunate I wasn't able to make it to the Minneapolis meeting for
this discussion. I am currently working on, as Dan has indicated, processing
the comments I received as a result of working group last call on the MIB
and should have an update out in a few weeks. It would have been out sooner
but I wanted to focus my efforts in getting the Alarm MIB progressed.

The MIB is currently only 6 objects and two notifications. I believe the
perceived complexity comes from the fact that some people are not yet sure
how to apply some of the states to some of the physical types. I tried to
solve this by adding a bunch of text to the document which I now think made
the problem worse so I have proposed removing this in favour of more concise
object descriptions. 

I don't think the plan was really ever to just add one MIB object. As a
minimum you would always need administrative and operational. As per usual,
we are trying to provide solutions for people with varying requirements. The
people in the meeting in Minneapolis apparently felt there were too many
states but many of the people I talk to feel that some of the other OSI
states that we opted not to include in the MIB are useful and should be
added. This of course could be solved by limiting the list of mandatory
objects but providing the additional states for implementations that require
this additional information.

Another thing people are having some difficulty in getting their heads
around is that this state model is different than that used for interfaces
status. Some have called this the 'IETF State Model', but when I looked into
it I didn't find it that universally deployed throughout the various IETF
MIBs to call it that. It's a decent enough model, but too simplistic at
times. For example, since operational state follows administrative state, I
have no way to tell whether something is going to be operational when I
administratively enable it other than to try it and then see if it fails. I
can certainly appreciate the concern that some people have in this area, so
in response to issue #77, I suggested the following two options, but have
received no replies:

"Hmmm. The problem is then that there are two different ways to interpret
the state of the entity by reading the same values for those three objects.
I'd suggest one of the following then
	1) Always force people to use the states as described. Then even if
the internal 
        state model is as you described, the externally visible behaviour
would be as 
        described in section 2.2.
      2) Support two behaviours for oper state and provide a type object to
tell you 
         which one is being  used. These would be INTEGER {
operIndependentAdmin, 
         operFollowsAdmin (2) }. I'm not sure about this approach, but I
suspect it would
         make some people happy."

I will continue to progress the list of issues as can be seen in
http://rt.psp.com and await further discussion on this within the list.

Sharon

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 8 Dec 2003 09:25:36 -0500

Hi

Sharon

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 9 Dec 2003 15:07:07 +0200

Syam,

Can you clarify what is IPv6-specific in the state model proposed by the Internet-Draft that you are referring to?

Thanks and Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Syam Madanapalli
> Sent: 09 December, 2003 11:14 AM
> To: [email-masked]
> Subject: Re: [Entmib] Confirmming Meeting Consensus
> 
> 
> 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-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> 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-masked]
> wrote:
> > >
> > Well, this is what it takes...
> >
> > Not sure how useful such a blanket statement is.
> >
> > 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
> >
> > --
> > Juergen Schoenwaelder     International University Bremen
> > <http://www.eecs.iu-bremen.de/>     P.O. Box 750 561, 28725 Bremen,
> Germany
> >

---

From: [email-masked]
Date: Wed, 10 Dec 2003 08:44:00 -0500

Hi Syam,

I am sorry, but defining a state model for IPv6 interfaces is
not within the charter of the Entity MIB WG.  We are working on
state/status only as it applies to augmenting the Entity MIB
with a "health indicator" regarding the status of each defined
entity.

As Dave Perkins pointed out, there is already a state model 
for IP interfaces defined in the IF MIB.  If you believe that
we should update that model, I would suggest that you discuss
your ideas on the IETF MIBs list ([email-masked]), and see
if there is sufficient community interest to pursue this work.

Margaret

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Syam Madanapalli
> Sent: Tuesday, December 09, 2003 4:14 AM
> To: [email-masked]

---

From: [email-masked]
Date: Wed, 10 Dec 2003 08:44:00 -0500

Hi Syam,

Margaret

---

From: Syam Madanpalli <[email-masked]>
Date: Thu, 11 Dec 2003 04:56:58 +0000 (GMT)

Hello Margaret, I will do this.
Thank you for the information.
Syam

------- Original Message -------
Sender : [email-masked]<[email-masked]> 
Date   : Dec 10, 2003 22:44
Title  : RE: [Entmib] Confirmming Meeting Consensus

Hi Syam,

Margaret

---

From: Syam Madanpalli <[email-masked]>
Date: Thu, 11 Dec 2003 04:56:58 +0000 (GMT)

------- Original Message -------

Hi Syam,

Margaret