RE: [Entmib] Confirmming Meeting Consensus

Hi

Yes, unfortunate I wasn't able to make it to the Minneapolis meeting for
this discussion. I am currently working on, as Dan has indicated, processing
the comments I received as a result of working group last call on the MIB
and should have an update out in a few weeks. It would have been out sooner
but I wanted to focus my efforts in getting the Alarm MIB progressed.

The MIB is currently only 6 objects and two notifications. I believe the
perceived complexity comes from the fact that some people are not yet sure
how to apply some of the states to some of the physical types. I tried to
solve this by adding a bunch of text to the document which I now think made
the problem worse so I have proposed removing this in favour of more concise
object descriptions. 

I don't think the plan was really ever to just add one MIB object. As a
minimum you would always need administrative and operational. As per usual,
we are trying to provide solutions for people with varying requirements. The
people in the meeting in Minneapolis apparently felt there were too many
states but many of the people I talk to feel that some of the other OSI
states that we opted not to include in the MIB are useful and should be
added. This of course could be solved by limiting the list of mandatory
objects but providing the additional states for implementations that require
this additional information.

Another thing people are having some difficulty in getting their heads
around is that this state model is different than that used for interfaces
status. Some have called this the 'IETF State Model', but when I looked into
it I didn't find it that universally deployed throughout the various IETF
MIBs to call it that. It's a decent enough model, but too simplistic at
times. For example, since operational state follows administrative state, I
have no way to tell whether something is going to be operational when I
administratively enable it other than to try it and then see if it fails. I
can certainly appreciate the concern that some people have in this area, so
in response to issue #77, I suggested the following two options, but have
received no replies:

"Hmmm. The problem is then that there are two different ways to interpret
the state of the entity by reading the same values for those three objects.
I'd suggest one of the following then
	1) Always force people to use the states as described. Then even if
the internal 
        state model is as you described, the externally visible behaviour
would be as 
        described in section 2.2.
      2) Support two behaviours for oper state and provide a type object to
tell you 
         which one is being  used. These would be INTEGER {
operIndependentAdmin, 
         operFollowsAdmin (2) }. I'm not sure about this approach, but I
suspect it would
         make some people happy."

I will continue to progress the list of issues as can be seen in
http://rt.psp.com and await further discussion on this within the list.

Sharon

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