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: "Sharon Chisholm" <[email-masked]>
Date: Tue, 23 Mar 2004 09:27:26 -0500

hi

I've updated the issues in http://rt.psg.com. The tool often has a lot of
issues with timeouts and things. I've learned a few tricks to work around
them.

Comments inline...

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, March 22, 2004 4:32 PM
To: Margaret Wasserman
Cc: [email-masked]
Subject: Re: [Entmib] Final Closure on Entity State MIB Issues
<clip>

#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.

Sharon> I don't have a strong opinion on this. Others did though.

#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.

Sharon> Well, shutting down has to be an administrative state since you have
a choice of graceful shutdown and just shutting it down. As far as the name
goes, in order to fully describe state, it would have to be
'noNewUsageThenShuttingDown'. It's sort of a fun name, but some may think it
too long.

<clip>

#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.

Sharon> I like this simpler approach. I had been half way down the path of
defining new TCs to behave like this when I looked up how we did it in the
Alarm MIB. Would answering the question of what the 'local system' is or
using a better term help?

<clip>

#322: Textual Convention Names (Prefix)

	I think the TC names should be prefixed.

Sharon> Ok. I think we need to step back a level on this one. We seemed to
have had agreement on the list that if the TCs were intended to be not
specific to Entities, then they should not have the prefix but if they were
they should. So, I suspect we are disagreeing on whether these TCs are
specific to Entities. I certainly never intended them to be and went out of
my way to ensure they weren't. Is there something in their definition that
leads you to believe they are limited in their application to Entities?

#325:

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

Sharon> This is from the MIB Review Guidelines. 

<clip>

#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.

Sharon> Embedded? Perhaps.

<clip>

#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.)

Sharon>I have had a lot of trouble with this text since I actually don't
think this table should be sparse augment. I was just going with a working
group consensus we agreed to a long time ago. Your reasons makes more sense.
I'll try to rework the text.

#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.

Sharon> Ok, so in the absence of that ...

Sharon

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 23 Mar 2004 16:13:13 +0100

> leads you to believe they are limited in their application to 

It seems to me that your TCs shoudl be prefixed with something aka

   ItuXxxx
   
or
   UtuX731Xxxx

That is what they claim to represent.
And having said that... should it be a separate ITU module (i.e. have ITU
in the name and TC-MIB as a suffix) ??
Maybe to heavy ?

> Sharon> This is from the MIB Review Guidelines. 
I think Juergen meant to say that you are using xxxConformance(3)
while you should be using xxxConformance(2).

Your OIDs look like:
OID tree
1.3.6.1.2.1.xx  entityStateMIB  [ENTITY-STATE-MIB]: module-identity
1.3.6.1.2.1.xx.0  entStateNotifications  [ENTITY-STATE-MIB]: oid-value-assignment
1.3.6.1.2.1.xx.0.1  entStateOperEnabled  [ENTITY-STATE-MIB]: notification-type
1.3.6.1.2.1.xx.0.2  entStateOperDisabled  [ENTITY-STATE-MIB]: notification-type
1.3.6.1.2.1.xx.1  entStateObjects  [ENTITY-STATE-MIB]: oid-value-assignment
1.3.6.1.2.1.xx.1.1  entStateTable  [ENTITY-STATE-MIB]: table-object-type
1.3.6.1.2.1.xx.1.1.1  entStateEntry  [ENTITY-STATE-MIB]: row-object-type
1.3.6.1.2.1.xx.1.1.1.1  entStateLastChanged  [ENTITY-STATE-MIB]: columnar-object-type
1.3.6.1.2.1.xx.1.1.1.2  entStateAdmin  [ENTITY-STATE-MIB]: columnar-object-type
1.3.6.1.2.1.xx.1.1.1.3  entStateOper  [ENTITY-STATE-MIB]: columnar-object-type
1.3.6.1.2.1.xx.1.1.1.4  entStateUsage  [ENTITY-STATE-MIB]: columnar-object-type
1.3.6.1.2.1.xx.1.1.1.5  entStateAlarm  [ENTITY-STATE-MIB]: columnar-object-type
1.3.6.1.2.1.xx.1.1.1.6  entStateStandby  [ENTITY-STATE-MIB]: columnar-object-type
1.3.6.1.2.1.xx.3  entStateConformance  [ENTITY-STATE-MIB]: oid-value-assignment
1.3.6.1.2.1.xx.3.1  entStateCompliances  [ENTITY-STATE-MIB]: oid-value-assignment
1.3.6.1.2.1.xx.3.1.1  entStateCompliance  [ENTITY-STATE-MIB]: module-compliance
1.3.6.1.2.1.xx.3.2  entStateGroups  [ENTITY-STATE-MIB]: oid-value-assignment
1.3.6.1.2.1.xx.3.2.1  entStateGroup  [ENTITY-STATE-MIB]: object-group
1.3.6.1.2.1.xx.3.2.2  entStateNotificationsGroup  [ENTITY-STATE-MIB]: notification-group
**end of oid tree**

And so 1.3.6.1.2.1.xx.2 was skipped (for as far as we can tell no good reason).

Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 23 Mar 2004 16:13:13 +0100

ItuXxxx
   
or
   UtuX731Xxxx

Your OIDs look like:
OID tree

Bert

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 23 Mar 2004 12:22:28 -0500

Comments inline

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Tuesday, March 23, 2004 10:13 AM
To: Chisholm, Sharon [CAR:0S00:EXCH]; [email-masked]
Subject: RE: [Entmib] Final Closure on Entity State MIB Issues

<clip>

   ItuXxxx
   
or
   UtuX731Xxxx

Sharon> Except we have made a couple of modifications to the states. I think
we would have to undo these to call them OSI or ITU states.

Your OIDs look like:
OID tree
1.3.6.1.2.1.xx  entityStateMIB  [ENTITY-STATE-MIB]: module-identity
1.3.6.1.2.1.xx.0  entStateNotifications  [ENTITY-STATE-MIB]:
oid-value-assignment
1.3.6.1.2.1.xx.0.1  entStateOperEnabled  [ENTITY-STATE-MIB]:
notification-type
1.3.6.1.2.1.xx.0.2  entStateOperDisabled  [ENTITY-STATE-MIB]:
notification-type
1.3.6.1.2.1.xx.1  entStateObjects  [ENTITY-STATE-MIB]: oid-value-assignment
1.3.6.1.2.1.xx.1.1  entStateTable  [ENTITY-STATE-MIB]: table-object-type
1.3.6.1.2.1.xx.1.1.1  entStateEntry  [ENTITY-STATE-MIB]: row-object-type
1.3.6.1.2.1.xx.1.1.1.1  entStateLastChanged  [ENTITY-STATE-MIB]:
columnar-object-type
1.3.6.1.2.1.xx.1.1.1.2  entStateAdmin  [ENTITY-STATE-MIB]:
columnar-object-type
1.3.6.1.2.1.xx.1.1.1.3  entStateOper  [ENTITY-STATE-MIB]:
columnar-object-type
1.3.6.1.2.1.xx.1.1.1.4  entStateUsage  [ENTITY-STATE-MIB]:
columnar-object-type
1.3.6.1.2.1.xx.1.1.1.5  entStateAlarm  [ENTITY-STATE-MIB]:
columnar-object-type
1.3.6.1.2.1.xx.1.1.1.6  entStateStandby  [ENTITY-STATE-MIB]:
columnar-object-type
1.3.6.1.2.1.xx.3  entStateConformance  [ENTITY-STATE-MIB]:
oid-value-assignment
1.3.6.1.2.1.xx.3.1  entStateCompliances  [ENTITY-STATE-MIB]:
oid-value-assignment
1.3.6.1.2.1.xx.3.1.1  entStateCompliance  [ENTITY-STATE-MIB]:
module-compliance
1.3.6.1.2.1.xx.3.2  entStateGroups  [ENTITY-STATE-MIB]: oid-value-assignment
1.3.6.1.2.1.xx.3.2.1  entStateGroup  [ENTITY-STATE-MIB]: object-group
1.3.6.1.2.1.xx.3.2.2  entStateNotificationsGroup  [ENTITY-STATE-MIB]:
notification-group
**end of oid tree**

And so 1.3.6.1.2.1.xx.2 was skipped (for as far as we can tell no good
reason).

Sharon> This sounds like a different problem then what he is saying.

Sharon

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 23 Mar 2004 12:22:28 -0500

Comments inline

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Tuesday, March 23, 2004 10:13 AM
To: Chisholm, Sharon [CAR:0S00:EXCH]; [email-masked]
Subject: RE: [Entmib] Final Closure on Entity State MIB Issues

<clip>

   ItuXxxx
   
or
   UtuX731Xxxx

Your OIDs look like:
OID tree

Sharon