Conference azur::mcc

       <<< Note 1303.0 by MAIL::CLAYTON "Merlin Clayton DTN 445-7217" >>>
                   -< SNMP V1.1 EFT Private MIB Extensions? >-

Reading through the release notes for the new SNMP V1.1 EFT access module
I see that MIB extensions for Wellfleet, Chipcom, Synoptics, and Appletalk
are included with the module.  MSU on the other hand has MIB extensions for 
those above plus private MIBs for Cisco, Proteon, Lantern, and one other I 
believe.

Q1.  If we have the private MIB extensions for all of the vendor devices
     supported by MSU, why don't we provide those same MIBs as part of the
     SNMP V1.1 AM?

	There will  be  when  the product ships.  The DECmcc SVP people
	have a list of the hot vendors and MIBs will be included on the
	kit when it ships.


Q2.  Is there a tool available to convert the MSU MIBs to a format compatable
     with the SNMP V1.1 AM?

	This doesn't make sense.   The MSU MIBs started in ASN.1 format
	and were converted to MSU  format.  All that one needs to do is
	find the original ASN.1 concise MIB  format and loaded then into
	DECmcc.

Q3.  Has anyone within engineering or elsewhere generated any additional 
     MIBDEF.TXT definitions for the SNMP V1.1 EFT AM that may be available
     over the net?  I'm looking particularly for Cisco, Proteon, and 3Com
     private MIBs.

	Contact Elias Hatem (TOOK::E_HATEM).  He is  working  with many
	SNMP vendors and juggling MIBs like a pro.

Thanks.

Merlin

    However the fact remains that there are two groups gathering mibs.
    Some synergy between msu and mcc would be nice to see in this area, so
    as problems came up in mibs, they could be solved for both products.
    Customers often ask which vendors we support - and the answer for MSU
    so far has been "well there are in there but we don't support them".
    A nice fat list of supported vendors would help sell our products.
    
    bill

    To .2, Bill, It is one thing to provide someones publicly available
    MIBs in your kit, It is another to say you support their product.
    The second involves both legal risk and significant resources to
    continually checking for conformance. I believe it is in our best
    interest to distribute as many publicly available MIBs on our kit
    as is feasible. By distributing them, we should have checked that
    they pass our MIB compiler syntactically and that in use they
    don't cause the target object to barf (ie. reset or otherwise
    catastrophically fail). However, we should stop at that point for
    any object that we don't sell or have a signed marketing agreement
    with. 
    
    As you are aware, most of the private MIB extensions are not stable
    and the vendors are constantly monkeying with them without adequately
    documenting or communicating the changes they are making. Until they
    start displaying some discipline in their use of private MIB extensions
    DEC should be very careful not to assume an obligation or liability
    that we can not deliver to.
    
    wally

    
    While installing V1.1 SNMP EFT kit, it asks the questions if
    one wants to build, dictionary, parse table, and help files.
    
    I answered NO to these questions to see if I can build them later.
    
    Then I enrolled the Wellfleet and Chipcom MIBDEF by saying NO to
    questions like dictionary and parse table building.
    
    Then I went and BUILT manually the dictionary, parse table, and 
    help files as per instructions that were displayed on-screen while
    installing SNMP AM that took approx 2 hours.
    
    Then I ran the MTU utility to build the dictionary and parse table for
    the two MIB extensions (Which is still going for the past one hour).
    
    Questions:
    
    What is the logical way to do this steps?
    
    Can I run the MTU utility before building the other SNMP AM related
    pieces?
    
    Can I avoid building the SNMP AM related pieces and go straight with
    MIB Extensions builder which also builds dictionary and parse table?
    
    Documentation must be provided clearly about the steps and logical
    steps in doing them. (Need to mention about creating DNS IP creation)
    
    Thanks...
    
    

	The most efficient method of accomplishing what you've done would
	be as follows,

	1. install the AM, load the dictionary, don't build the parse tables.

	2. run the MTU, load each new mib updating the dictionary for each one,
	   for the last mib, load the dictionary and build the parse tables.

	The parse table builder uses the full dictionary to build the parse
	tables.  Therefore, load as much into the dictionary as you want 
	before running the parse table builder.  This is the most time
	efficient method, however, keep in mind that the AM is unusable until
	the parse tables have been built.

	The documentation does indeed need to do a good job of describing this.

The other option for loading multiple MIBs before building the parse tables is
to use "non-interactive" mode when invoking the MTU command procedure,

	eg., @mcc_tcpip_mtu mib1,mib2 load build

This will translate both mibs, load them both into the dictionary and then
build the parse tables.