Subject: [Entmib] Final Closure on Entity State MIB Issues

From: Margaret Wasserman <[email-masked]>
Date: Mon, 22 Mar 2004 08:12:52 -0500

Hi All,

Sharon has proposed changes to all of the issues that have been 
raised regarding the Entity State MIB.  The proposed resolutions can 
be found at:   http://rt.psg.com (userid: ietf, password: ietf). 
Please review Sharon's proposed changes and send mail to the list by 
this Friday (26-Mar-2004) if you have any objections to the 
resolutions that Sharon has proposed.  If there are any contentious 
issues, let's discuss them so that we can determine WG consensus 
regarding their resolution.

We are quite close to finishing this document, so if there are any 
remaining issue, please get them on the table as soon as possible.

Thanks,
Margaret

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Mar 2004 22:31:31 +0100

> regarding their resolution.

I went through all the issues and here is what I think where we are
with respect to the various issues. Note that the server does seem
to have some problems at the moment.

#306: entStateTrap rename/oid to entStateNotifs

	OK

#307: 'notSupported' is semantically wrong

	I think "unknown" as suggested by Keith is what we typically
	use and prefer this over "unavailable" or any other terms.

#308: Shutting Down Admin State

	I tend to agree with Keith' comment and I do not think that
	the response addresses Keith issue with the name/state itself.

#309: Operational State Names and Concepts

	I am not sure I understand the issue so I keep silent.

#310: Alarm State Issues

	OK

#311: DateAndTimeOrZero ?

	The new text refers to the initialization of "the local
	system" - whatever that may be. In a subagent environment, the
	actual instrumentation might not have easy access to what an
	operator would consider "the local system". So I think it
	would be better to adopt the approach where a the special
	value '0000000000000000'H is returned. Sure, this value falls
	not strictly under the DateAndTime TC set of values, but we
	have several MIBs using this special value on the standards
	track so this should work here as well.

#312: Locked Admin State

	I am not sure I understand the issue so I keep silent.

#322: Textual Convention Names (Prefix)

	I think the TC names should be prefixed.

#325:

	The figures in the discussion of this issue are wrong as
	xxxCompliances(1) and xxxGroups(2) are typically registered
	below xxxConformance(2).

#326: Too many state objects

	Andy wants a "green light" MIB which this is not supposed
	to be. There is no way to resolve this issue.

#327: More Editorial Issues

	OK

#328: Containment Hierach and entPhysicalContainedin

	I think this issue is not really solved. It must be clear in
	all cases where a description clause talks about containment
	what this really means.

#329: Usage State Scope

	OK, although I would prefer to have the semantics spelled out
        in the relevant description clauses as well.

#330: Notification Varbinds

	OK

#332: More Standby State/Status Issues

	I am not sure I understand the issue so I keep silent.

#333: Relationship with Alarm MIB

	OK

#334: Table, Index Descriptions

	I am having problems with the suggested new text. In
	particular the following sentence:

	Entries appear in this table for values of entPhysicalClass
        [RFC2737] that in this implementation are able to report any
        of the state or status stored in this table.

	I think that the class is not necessarily the property which
	defines whether a component will be able to report useful
	information in a subagent environment. I think this sentence
	hurts more than it helps. BTW, the most obvious reason for
	sparse augmentations is that new hardware and software will in
	practice be mixed with old hardware and software in subagent
	environments. (Not sure we need to document this. I think it
	is sufficient to say it is a sparse augmentation.)

#335: Notification Comments

	To me, entStateStandby related notifications might make sense
	and this should not be ruled out by being late. However, there
	needs to be a concrete proposal to look at. Without a concrete
	proposal, no change seems OK.

/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, 22 Mar 2004 22:31:31 +0100

OK

#310: Alarm State Issues

	OK

#312: Locked Admin State

#325:

	OK

#329: Usage State Scope

	OK

	OK

/js