Re: DMTF and IETF hostmib future coordination?

[Pete Grillo <[e-mail]>]

Michael,

>I agree it is not *totally* unavoidable.  However, DMTF, if they are smart,
>can learn from prevous mistakes in the SNMP community and at least try
>to encourage implementation of standard MIFs whenever possible and educate
>the vendors of the pitfalls of a proliferation of MIFs.

The DMTF is very actively pursuing standard MIFs.  I did not mean to imply 
otherwise.   

>
>> However, there are facts of (business) life which stds don't, by 
>> their very nature, address very well.  Most prominent in my mind is that
>> businesses thrive on the edge they build over their competition.  And 
>> if I have a competitive edge, I want to leverage it to the fullest.  
>> To promote this edge, I want it to be in the face of every customer 
>> as an edge, and that often means its some feature 
>> needing/flaunting/wanting management.  And since it's an edge, it can't 
>> be a std, since its mine and no one elses.
>
>Vendors are free to do whatever they want; HOWEVER!, vendors should not
>feed the *propaganda* of *network management standards* to their users
>and the press unless they are really commited to interoperability and
>the standards.  Implementing a proprietary MIB requiring a proprietary
>management application using a standard protocol to exchange the data
>is not standard oriented interoperable systems/network management.
>

There is definately conflict between full interoperability and what 
actions a vendor might take in a given situation.  I do not know how to 
change or fix this.  I do believe that an attempt to restrict a vendors 
creativeness would not be the right solution.  (observation here: I have 
observed at times an attitude among some that mgmt is some sacred, black 
art which is owned by and can only be responsibly steered by a select 
few).  I believe that management is not something which anyone can 
realistically restrict.  Vendors want mgmt, customers want mgmt, support 
costs are astronomical, etc.

As far as claims to compliance, no one can control that.  You obviously 
feel interoperability via std MIBs is a prime concern.  Others may not 
feel that strongly; as I proposed above, some might have other goals.  

>When talking to users and the press, I have to spend a significant amount 
>of time explaining why the *stanards* they hear about are most often being 
>used for *proprietary systems/network managment* (which is what you describe 
>above).

I am curious as to what you tell them, that is, why do you think this is 
happening?  

>
>> We tried to address this by packing as much semantic value in the MIF 
>> grammar as possible to allow for the highest degree of 'on the fly' 
>> semantic learning.  What we have in DMI is not rocket science, but it 
>> does help console vendors learn.  Features like MIF retrieval thru the 
>> APIs don't require a manager to have a MIB compiled on a mgmt station.  
>> We have the ability to retrieve descriptions for defined objects.  We 
>
>That is great.  I would also expect to see some sort of SNMP MIB in the
>future that does the same thing.  

That is possible.

>> THe hostmib does a good job of covering the high spots.  Don't take me 
>> wrong here, given a MIB budget of 100 or so objects, I believe the 
>> hostmib has the right 100.  But there can't possibly be any great degree 
>> of depth in any one area here.
>
>The hostmib does allow new object identifiers to be defined to allow it
>to be extended to new unanticipated "objects".  If it doesnt have the
>extensibility mechanisms that are needed, the WG should address that at
>the next evaluation stage of the MIB (you need to say what extensibility
>mechanisms you need).  

I didn't make myself clear before.  I know what you are referring to, 
OIDs can be assigned for new objects.  What I was trying to describe had 
to do with depth of mgmt in a given area.  The mechanism available in 
hostmib allows new product types to be defined (like a new storageDevice 
type) but doesn't allow for the depth of mgmt control that something 
like a SCSI MIF would.  Or a Spreadsheet MIF.  Or an OS mif.

>
>As I asked above, why cant we take a nice generic standard MIB like this
>and generate MIF descriptions for it.  Then, define the really *necessary*
>extensions to these MIFs.  And finally, get the Host Rescources WG of the 
>IETF to consider these *necessary* extensions for inclusion into the MIB
>when it is evaluated at the next step of the standards process (or for
>a DMTF MIB *extension* to the hostmib)?

If my description came out clear above, what that would amount to is 
1,000,000's of objects describing 10,000's of products.  Too much for one 
MIB. 

>
>When it comes to the need for proprietary MIFs, that can be done if the
>proprietary portion is implemented using something like SNMPv2's AUGMENTS
>or SNMPv1's DESCRIPTION of tables that shadow standard tables.  These sort
>of extensions should be relatively small if vendors act in a responsible
>way.  (Yes, the SNMP community has still not been successful in this regard).
>

This method may make sense in some cases.

>I guess the short answer is that their will be little or no coordination
>between the Host Rescources WG of the IETF and the DMTF, and apparently
>little use of the hostmib by the DMTF?
>

Oh no.  They're cousins; let me explain.

The hostMIB and the DMTF have been intimately involved since the 
inception of both efforts.  Many DMTF tech team members attended both 
sets of WG meetings.  (Hint: look to the authors names on the draft).  
They will work together, we may get something limping by DevCon.  Simply 
put, the std MIFs contain the right fields so that population of a 
hostmib agent on the desktop is a mechanical process.

>Thanks,
>
>----
>[e-mail], [e-mail], or bir!mlk (Michael L. Kornegay)

pete