Conference azur::mcc

    HP has an editor that allows editing a mib into the system by hand. 
    Perhaps this is how you saw the cisco mib put in there.  Also, before
    MSU had their compiler, they had a routine that took sloppy mib format
    (for lack of a better name) and shoved it directly into their SQL
    database - things that didn't work were edited using their MIB editor. 
    MCC requires the conversion of MIB to MSL - which requires a bit more
    formal syntax.  The industry is going CSF - so I don't see it as a
    problem that MCC requires it.
    
    Cisco is not still as bad as you say.  They are now aware of what they
    have to do with their MIB.  They are also not always pushing their own
    network manager.  They have it when they need it, but it's not critical
    to their strategy.  In fact, when they win a router bid in a DEC shop,
    they really hate to have to say that the customer requires a SUN
    workstation to run their netmgt software.  They met with Digital a few
    months ago (both MSU and MCC) and either have, or will soon have, a MSU
    station running in their Waltham sales office.  
    
    bill

We may have different perceptions internally, but when the cusotmer develops
bad vibs from a vendor, that can mean lost sales.

Can you tell us what they had to say about or with regard to MCC?

Running MSU in their shop is fine, but MCC is really the strategic direction
for DEC, I would assume.  Since Cisco is the predominant router vendor today,
we must be able to manage them from MCC.  My customer has more than 60 units
and is still buying.  This will more than likely be their router of choice for
the next three years.

Al

	RE .0

>>Which leads to a question....why don't we allow or tolerate "sloppy MIB format"?

>>I can certainly understand the reasons for following the suggested RFC and
>>other proposed or accepted standards, but the customer only sees results
>>and if another solution can solve their problem, then even the best architecture
>>or well planned/built product will not be accepted if it does not do what 
>>they need it to.

>>Would it be a difficult thing for us to accept a non-RFC1212 compliant
>>MIB definition? 

	The SNMP AM tries to algorithmically map the SNMP mib objects into
	EMA entities and creates an entity model for each mib extension. For 
	this to happen the mib must be clearly defined without any ambiguity. 
	The problem we most commonly face is during the mapping of tabular 
	objects. MIB tables map into child entities. Table index map into 
	the instance identifier for that child entity. 

	To do such a mapping we need to know unambiguosly which are the table
	objects and what they are indexed by. RFC 1212 "suggests" the use
	of the INDEX clause in tabular object definitions, which allow us 
	to correctly create our entity model. In the "old" mib format the
	index clause is not present, and hence we cannot handle those mibs
	properly. 

	The "powerful" GETNEXT snmp request allows us to request
	and receive table objects from the agent, without even knowing what
	the instance values are. However, there is no way we can display this
	information in MCC without having a corresponding entity model in 
	place. This might explain why both MSU and OpenView can handle those
	"sloppy" mibs and we cannot.
	
	RE .2


>>Running MSU in their shop is fine, but MCC is really the strategic direction
>>for DEC, I would assume.  Since Cisco is the predominant router vendor today,
>>we must be able to manage them from MCC.
	
	Adding the INDEX clauses to a non-concise mib and making it usable 
	by the SNMP AM is not that complicated once you have all the required
	information at hand. Mike Reilly has already done it for Cisco's mib 
	and he has made it publicly available. Some of our customers have 
	already used it to manage cisco routers. 

	Hope this helps,

	rahul.

    cisco was shown both MSU and MCC - and they feel they can better sell
    MSU to their customers.  MSU is a SNMP manager by all definitions,
    while MCC is an enterprise manager that also does SNMP.  Memory usage,
    performance, cost, and availability of SNMP related features are some
    problems that MCC must fix before going head to head with simple SNMP
    managers.  Also, remember, while MCC/ULTRIX seems like it's been around
    forever, out in the world cisco sees - MCC only runs on VMS.  I think
    as MCC becomes all it's intended to be, we'll see that classic network
    managers will gravitate to SNMP manager, and classic system managers
    will gravitate to MCC.  MCC's nitch will be the managers that must deal
    in both worlds.  OSI layer 4 is probably the point of distinction.
    The SNMP market will generate over 2 billion dollars in sales over the
    next 5-6 years - so it makes sense for MCC to scale down, speed up,
    become easier to use, and add more end-user features.  Look to MSU for
    the features required to compete in the SNMP market - but focus on the
    enterprise stuff that MCC was designed for.
    
    bill