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: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 Feb 2004 14:19:08 +0100

> and send your feedback (positive or negative) to the list.

I could not get email out during the weekend. Anyway, here is what I
wrote down on this subject...

I have reviewed <draft-ietf-entmib-state-02.txt> and I like the
approach, as I have already said before. Below are some review
comments to take into account. Most are just editorial while some
might require some further discussion/thinking.

1) Change the end of the abstract from

	provide information about the state of the entity.

   to the following:

	provide information about the state of physical entities.

   Rationale: This MIB is specific to physical entities and since the
   ENTITY-MIB also has the concept of logical entities, I think it is
   better to more precise.

2) Description of StandByStatus, change

	"... but is will be immediately ..." 

   to the following:

	"... but will be immediately ..."

3) Description of entStateLastChanged, change 

   DESCRIPTION "The value of this object is the date and
               time when state/status of the entity
               last changed, or zero."

   to the following:

   DESCRIPTION "The value of this object is the date and
               time when state/status of the entity
               last changed, or '0000000000000000'H."

4) Description of entStateAdmin. I believe the following two sentences
   are kind of a contradiction:

             [...] This object can not
             be administratively set to 'notSupported'. For
             entities that do not support administrative state,
             changing the value of this object to something other
             than 'notSupported' is not permitted.  A value of
             'inconsistentValue' will be returned in either case.

   With the text in the second paragraph of the description clause, I
   think this can be fixed by just removing a sentence without loosing
   anything:

             [...] This object can not
             be administratively set to 'notSupported'. A value of
             'inconsistentValue' will be returned in either case.

5) Several description clauses refer to "entities within its
   containment hierarchy" followed by a sentence which limits this to
   the entities "having a value of entPhysicalContainedIn that refers
   to this entity". This somehow excludes transitive containment. Is
   this by intention or accident? I mean, if I have C contained in B
   contained in A, then A still provides indirect service to C.

6) AlarmStatus TC: I do not really understand the alarmOutStanding
   bit.  It seems like this is set whenever one of critical, major,
   minor, warning and indeterminate is set. But if this is true, I
   think the bit is not really terrible useful.

   Perhaps the bit has some other meaning. If so, please clarify.

7) The MIB did not compile because you once use
   entStateNotificationGroup and once you use
   entStateNotificationsGroup (see the plural s). Pick one.

8) I was surprised to read the entStateUsage description which says
   the UsageState is strictly bound to the containment relationship
   between entities.

   In general, the containment hierarchy is made up of containers and
   leafs. The entStateUsage description basically says that the
   UsageState is only interesting for containers since leafs are
   always busy. I found this interesting since the other objects do
   not make this distinction and some of them seem to particularly
   useful for leafs (e.g. interfaces). Perhaps it makes sense to
   define for each entState* column how it applies to containers and
   how it applies to leafs. For example, what does it mean to
   lock/unlock a container? (I believe entStateAdmin is more defined
   for leafs rather than containers.)

9) I am wondering why both notifications contain the entStateAlarm
   value, especially entStateOperEnabled notification. This surely is
   not wrong, but I am wondering what the rationale for including the
   entStateAlarm is (and for excluding other objects).

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 Feb 2004 14:19:08 +0100

to the following:

   to the following:

   to the following:

/js