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

On Tue, Mar 23, 2004 at 09:27:26AM -0500, Sharon Chisholm wrote:
> Comments inline...
> 
> #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?

I think it is not a terminology issue. Consider a hot-swappable line
card which has its own subagent. It can easily report
'0000000000000000'H but making it report the date and time of the
initialization of the "local system" is either very hard (if local
system means the system runnning the master agent) or you just report
the time when the card was inserted, which is kind of meaningless for
the manager. So I think the only workable solution is really to report
the special value '0000000000000000'H since it avoids any ambiguities
and is very easy to implement.

> <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?

As others have noted before: If these TCs are really generic, put them 
into a separate MIB module and perhaps even document so that these 
definitions also get wider review (and actual users). If I were writing
a MIB on a standards track, I would think more than twice whether I
import these TCs for a module which itself depends on other modules
which I really do not want to depend on. Generic TCs really should go
into self contained modules.

To complete this piece of work on the charter, I do not think that we
have to produce generic TCs for operational and usage state.

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

My copy of <draft-ietf-ops-mib-review-guidelines-02.txt> clearly
has the following.

         xxxMIB
         |
         +-- xxxNotifications(0)
         +-- xxxObjects(1)
         +-- xxxConformance(2)
             |
             +-- xxxCompliances(1)
             +-- xxxGroups(2)

And since I contributed this figure to the ID, I am almost sure my 
copy of <draft-ietf-ops-mib-review-guidelines-02.txt> is correct...

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

??? Not sure I understand this.

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

I think the relationship has to be sparse and I do not think we need to 
write lengthy explanations about this.

/js

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

_______________________________________________
Entmib mailing list
Entmib@ietf.org
https://www1.ietf.org/mailman/listinfo/entmib