Subject: REMINDER: [Entmib] WG Last Call: Entity State MIB

From: Margaret Wasserman <[email-masked]>
Date: Thu, 05 Feb 2004 16:11:40 -0500

Hi All,

Just a reminder that we are currently in WG Last Call for the
Entity State MIB.  Please review this document before Friday
and send your feedback (positive or negative) to the list.

Given that this is a second WG Last Call for this document, that
several people reviewed it during the previous WG Last Call, and
that Sharon did a great job of maintaining an issue list and
documenting the resolution of each issue, I am planning to interpret
silence as agreement to send this document to the IESG.

So, if you have any objection to submitting this document for
publication as a Proposed Standard, please make that clear
by Friday.

Thanks,
Margaret

>Date: Fri, 23 Jan 2004 17:00:59 -0500
>To: [email-masked]
>From: Margaret Wasserman <[email-masked]>
>
>Hi All,
>
>This is a two week WG Last Call for submitting the Entity State
>MIB to the IESG for publication as a Proposed Standard.  The latest
>version of this document can be found at:
>
>http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-02.txt
>
>This WG Last Call will end on Friday, February 6th at 5pm EST.
>
>Please review the document and forward substantive comments to
>the mailing list.   Editorial comments can be sent directly
>to the authors.
>
>Thanks,
>Margaret
>
>
>
>_______________________________________________
>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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 6 Feb 2004 12:06:43 +0200

I have no objections to submitting this document for publication as a Proposed Standard. 

Thanks to Sharon for the effort in pushing this ahead.

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Margaret Wasserman
> Sent: 05 February, 2004 11:12 PM
> To: [email-masked]
> Subject: REMINDER: [Entmib] WG Last Call: Entity State MIB
> 
> 
> 
> Hi All,
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 6 Feb 2004 12:06:43 +0200

Regards,

Dan

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 6 Feb 2004 12:30:39 +0100

> silence as agreement to send this document to the IESG.
I do not want to step on the toes of our WG chair, but yet...
I would actually appreciate if the people who spoke up (a while ago)
that the MIB was too complex, that they do state if they are now
OK with this version!

PLEASE PARTICIPATE and express your opinion.

Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 6 Feb 2004 12:30:39 +0100

Bert

---

From: Andy Bierman <[email-masked]>
Date: Fri, 06 Feb 2004 08:27:19 -0800

>PLEASE PARTICIPATE and express your opinion.

okay, okay...

I do not approve of, or object to, the Entity State MIB
going forward.  

My concerns are regarding the intent of the MIB -- the 
actual problem being addressed.  So I looked to the 
Entmib WG charter page for guidance.  This is all it
says about the Entity State MIB:

 Done    Publish state/status extensions as a WG I-D  

 Mar 04  Submit Entity State MIB to the IESG for Proposed Standard  

Not a word about the problem being addressed.

I thought we set out to add an 'operStatus' object for
physical entities -- a simple ( green, yellow, red )
status indicator.  Applications would still need to
know how to use other MIBs to diagnose or correct a fault.
IMO, there's not much value in a generic indicator beyond
this, so it's best to keep it simple.

 From the draft:

  "Objects are defined to capture administrative, operational and usage
   states. In addition there are further state objects defined to 
   provide additional information for these three basic states."

The document clearly attempts to provide more functionality
than a simple 'operStatus' object.  The authors have done
a fine job defining and documenting this functionality.

In order to discuss how well a MIB addresses its intended
function, we have to agree on the intended function.

>Bert

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 06 Feb 2004 08:27:19 -0800

okay, okay...

 From the draft:

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 06 Feb 2004 09:25:34 -0800

>PLEASE PARTICIPATE and express your opinion.

comment on the MIB itself...

the TCs should be named with a prefix. E.g.,
OperState -> EntityOperState.  This applies to
all the TCs in the draft.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 06 Feb 2004 09:25:34 -0800

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 6 Feb 2004 14:28:09 -0500

Hi

I don't understand where the impression that we were only planning on adding
a single object that gave operational status came from. My early
presentations on this topic outlined a large number of state objects that
could be defined and from that we whittled down to what we thought was a
reasonable set. Some people wanted more and some people wanted less. 

Sharon

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Friday, February 06, 2004 11:27 AM
To: Wijnen, Bert (Bert)
Cc: 'Margaret Wasserman'; [email-masked]
Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB

At 03:30 AM 2/6/2004, Wijnen, Bert (Bert) wrote:
>> several people reviewed it during the previous WG Last Call, and that 
>> Sharon did a great job of maintaining an issue list and documenting 
>> the resolution of each issue, I am planning to interpret silence as 
>> agreement to send this document to the IESG.
>> 
>I do not want to step on the toes of our WG chair, but yet... I would 
>actually appreciate if the people who spoke up (a while ago) that the 
>MIB was too complex, that they do state if they are now OK with this 
>version!
>

okay, okay...

 From the draft:

The document clearly attempts to provide more functionality than a simple
'operStatus' object.  The authors have done a fine job defining and
documenting this functionality.

In order to discuss how well a MIB addresses its intended function, we have
to agree on the intended function.

Andy

>> publication as a Proposed Standard, please make that clear by Friday.
>> 
>> Thanks,
>> Margaret
>> 
>> 
>> >This is a two week WG Last Call for submitting the Entity State MIB 
>> >to the IESG for publication as a Proposed Standard.  The latest 
>> >[email-masked] https://www1.ietf.org/mailman/listinfo/entmib
>> 
>>

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 6 Feb 2004 14:28:09 -0500

Hi

Sharon

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Friday, February 06, 2004 11:27 AM
To: Wijnen, Bert (Bert)
Cc: 'Margaret Wasserman'; [email-masked]
Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB

okay, okay...

 From the draft:

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 6 Feb 2004 14:34:02 -0500

Hi

I've created issue 322 to track this.

The intention in creating the textual conventions was that they could be
used in other MIBs that wanted to define state/status objects. Prefixing
them with Entity makes this less obvious.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Friday, February 06, 2004 12:26 PM
To: Wijnen, Bert (Bert)
Cc: 'Margaret Wasserman'; [email-masked]
Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 6 Feb 2004 14:34:02 -0500

Hi

Sharon

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Friday, February 06, 2004 12:26 PM
To: Wijnen, Bert (Bert)
Cc: 'Margaret Wasserman'; [email-masked]
Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB

Andy

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 07 Feb 2004 08:06:48 -0500

Hi All,

Could others please express their opinions on this issue?  Who
believes that these TCs should use a prefix (e.g. EntityOperStatus)
and why?  Who think that they should not include a prefix, and why?

Since we are not planning to meet in Seoul, it is important to
close this issue on the mailing list.

Thanks,
Margaret

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 7 Feb 2004 15:12:23 +0100

Speaking as technical contributor

In general, when a TC is clearly generic, then using the most
intuitive and generic name makes sense. In most cases, such a TC
would be better specified in a generic/independent document 
(or at least a separate MIB module).

As soon as a TC is specific to some technology or to some WG,
then prefixing it with the wg or technology-specific acronym
is the way to go.

Bert 

> From: Margaret Wasserman [mailto:[email-masked]]
> Sent: zaterdag 7 februari 2004 14:07
> To: Sharon Chisholm
> Cc: [email-masked]

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 7 Feb 2004 15:12:23 +0100

Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 7 Feb 2004 17:19:48 +0100

> Following comments were sent on 1/11/2004: But it is not 
> taken care in the latest draft.
> Hoping some one is carrying as part of Editorial fix
> ******
> a Minor Suggestion:
> 
> Instead of having these OID definitions:
> 
> -- Notifications
> 
>   entStateTraps      OBJECT IDENTIFIER ::= { entityStateMIB 2 }
>   entStateTrapPrefix OBJECT IDENTIFIER ::= { entStateTraps 0 }
> 
> 
> We can have
> entStateNotifs OBJECT IDENTIFIER ::= { entityStateMIB 0 }
> 
> and use 'entStateNotifs' in the corresponding NOTIFICATION-TYPE
> 
> Reason we would like to avoid name 'Traps' is: Latest RFCs refer them
> as Notifications
> 
> Also, above OID tree structure will be inline with mib review 
> guidelines document: draft-ietf-ops-mib-review-guidelines-02.txt
> 

I agree with that ... and I would even say:

  entStateNotifications OBJECT IDENTIFIER ::= { entityStateMIB 0 }

Why make the descriptor more cryptic than needed?

Bert

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 08 Feb 2004 17:56:10 -0500

We originally considered doing the state/status extensions as
part of the Entity MIB, and those first discussion did mention
a single object.  However, by November 2002 we had a much more
complex model and agreed that it would be better to do this as
a separate MIB.

We agreed to accept the Entity State MIB as a WG document before
March 2003, and at that time it was at least as complex as it is
now.  We've been working on this MIB for over a year, and I
believe that it should take WG consensus to make a major
change to it now.  Do others agree?

In Minneapolis, the complexity of this MIB was raised as an issue.
There was a general sense of the room that the MIB was too
complex, but many people who were involved in earlier discussions,
including the editor, weren't present.  When the discussion was
brought to the mailing list, I did not see clear consensus that
we need to reduce the complexity of the MIB.

Sharon did try to address concerns about the complexity of this
MIB in the latest version by simplifying and streamlining the
description.

So, where do we stand on this issue?

Are there others who have read the current MIB and strongly
believe that it needs to be simplified?  Or not?

Margaret