Conference azur::mcc

    John, the names that you find incongruous are the MIB II standard
    attribute names used in the standards specification. To the
    question of can we use something else; the answer is yes. However,
    to do so means that we have to deviate from the standard and that
    leaves us vulnerable to being non-standard. 
    
    It is unlikely that we will change these names. The MIB II standard
    and the CISCO documentation will use the standard names. Changing
    them means we have to explain the mapping from our non-standard
    names to what CISCO and the rest of the industry uses. I am afraid
    that we need to get used to these names and use them as is.
    
    wally

    I've seen MIB editors that allow the person doing the mib to also input
    'human readable' text to go with the attribute names.  This makes for a
    more friendly system.
    
    bill

    	FWIW, DECMCC-MSU has the human-readable text addition for snmp.
    Makes life easier.
    
    						chuck
    

Maybe I shouldn't mention this, but...

 There's nothing to prevent a user from editing the MIB definition,
 (changing attribute names to what the user wants displayed) before running
 the MIB Translation Utility.

 The problem becomes one of keeping documentation straight and recognizing
 problems in parsing if multiple names conflict.

 Assuming the Translation Utility is enhanced (in a future version)
 to generate online help from the MIB definition, at least the first
 problem would be eliminated...

						Chris

	But I think there is a real difference between mcc and 
	MSU/other products.  They use object ids as the real internal 
	identifier of an 'object' (a MIB variable).  The name is simply an
	aid to humans.  DECmcc use the presentation name of an attribute as its
	real internal identifier.  The object id in this case is simply a 
	a string that is associated with the attribute.

	Thus changing the name in DECmcc seems, at least to me, to have
	much larger implications.  Like potentially breaking things?

	Mike
 	

>   DECmcc use the presentation name of an attribute as its
>   real internal identifier.

 I think of the MCC attribute code as the "real internal identifier"
 (though I suspect many would disagree with me).
 MCC codes are what gets passed across the mcc_call interface...

>   Thus changing the name in DECmcc seems, at least to me, to have
>   much larger implications.  Like potentially breaking things?

 Really? If I change a *vendor specific* attribute name from 
 "proXfaceX25PhyInBytes" to "Bytes Received", what in DECmcc gets
 broken?  Nothing.

 Maybe we're talking about different things:

  I'm talking about making changes to the vendor specific attribute
  names in the vendor MIB that get run through the MIB Translation
  Utility.

  Maybe you're talking about making changes to MIB I or MIB II
  attribute names?  I agree that the latter could cause major headaches...

						Chris

    I think I would disagree with .1
    
    I don't think the intent of the MIB RFCs is to define the user-readable
    names (or strings) associated with each variable, but rather to have
    a program-readable (and hence unique) variable name. Of course, I
    might be wrong - if someone could indicate a page/section number in an
    RFC, I'd appreciate it.
    
    I believe that many have chosen to make the MIB name into the
    presentation name that the user sees. That seems like a reasonable
    DEFAULT. But it is certainly different from the way most other
    MCC-manageable classes are defined.
    
    It seems quite reasonable to use alternate text strings for
    presentation names. However, should Digital do this (for standard MIB
    definitions)? Or should we allow our customers to change them? (We
    already do, but we don't document how).  Then we have to consider how
    to deal with Enterprise MIBS - we certainly would not want to prompt
    the user of the MIB translator utility to provide the text for each
    variable.
    
    Any suggestions from you folks nearer to customers?
    
    Colin

    I am currently working with a customer whose has a large
    multi-vendor environment.  We have a large number of SNMP
    'monitored' devices.  When problems occur with a SNMP monitored
    devices we consult with the customer service organizations of these
    vendors.  The 'language' we speak when dealing with these vendors is
    'MIB variable names'.  The tools I am using better have MIB variable
    names which match what the support person is requesting.  The
    ability to change the presentation name for a variable is a nice
    feature right up until the moment a support person asks me for the
    value of the XyzNetDlkOutPkts and the XyzDlkOutPkts counters.
    
    In my 'self' defined interface I have two variable called
    
    Data link out packets counter #1,  and 
    Data link out packets counter #2.  
    
    Which is which??   
    
    BTW: XyzNetDlkOutPkts was intended to mean the number of packets
    send from the Network layer to the Datalink layer, and 
    XyzDlkOutPkts the number of packets actually send from the Datalink
    layer.
    
    
    What would be nice would be the ability to hit the 'help' key while
    pointing to a variable name, and have the help which the vendor
    supplied in the DESCRIPTION field of the concise MIB definition
    appear in a pop-up window.     
    
    - Mike           

    I agree the point and click would be nice, and it has been on the
    "nice" list since we started the project. One of these days the
    niceities will win time over the functionality, but for now
    we are still trying to get the base system to a higher degree
    of overall functionality.