Conference azur::mcc

	Isn't it illegal to have negative numbers in enumerations? I believe
	the SMI RFC (1155) even disallows the number 0. You can either tell
	NAT to conform to the SMI, or remove the enumeration, in which case
	the integer values will be displayed in MCC instead of the text.

	Rahul.

    re: .1
    How do you read that negative numbers are illegal in enumerations?
    
    The only mention I can find is:
    3.2.1.1.  Guidelines for Enumerated INTEGERs
    
       If an enumerated INTEGER is listed as an object type, then a named-
       number having the value 0 shall not be present in the list of
       enumerations.  Use of this value is prohibited.
    
    
    which seems to disallow the number 0, but doesn't seem to disallow
    negative numbers.....
    
    I guess I will have to remove the negative number from the enumeration
    for now....
    thanks,
    Mike

	You are right, I couldn't find anything disallowing negative numbers
	for enumerations in the RFCs. It is more of an unwritten rule. Anyway,
	their use of the value 0 makes the enumeration non-standard.

	It would be a simple matter to change MTU to handle negative values 
	in enumerations, but the resultant MSL will not work with DECmcc.

	Rahul.

	I put in a note in the snmp mailing list regarding negative 
	enumerations and here were the responses :	

	<Reproduced without permission of the authors>

From:   US2RMC::"[email protected]" "David Perkins"
To:     molar::bose
CC:
Subj:   Re: Negative values in enumerated INTEGERS

Rahal,

Here is some advise:
  1) Design mibs with enumerated values from 1 to N
     (No holes)
  2) Write NMSs to deal with MIBs where there are
     values of zero, negative numbers, and gaps.
     (And also agents that return values that are
      not specified in the MIB.)

/dave perkins

****************************************************************

From:   US2RMC::"[email protected]" "MAIL-11 Daemon"
To:     molar::bose
CC:     [email protected]
Subj:   Re: Negative values in enumerated INTEGERS

 >         RFC 1155 prohibits the use of the value 0 in an enumeration.
 >         Does this mean that all other numbers, including negative numbers,
 >         are valid in an enumeration? I am also curious to find out if
 >         there are a lot of vendors out there using negative values in their
 >         enumerations.

Offhand, I can't recall any MIB with negative values as enumerated
types.  That doesn't mean that they don't exist.

Similarly, I have seen agents which have returned zero values in
enumerated types.  Typically it is merely an accidental use of 0/1
rather than 1/2 to indicate something line interface status.

And you ought to expect that many valued enumerations, for example,
interface hardware types, will grow and grow over the years.

So the standard rules still apply -- be liberal in what you accept.

                        --karl--

	SNMP V2 RFCs clearly state that negative values in enumerations
	are valid. Having restrictions around negative enumeration values
	in DECmcc will prevent us from fully supporting SNMP V2.

	rb

While your point about SNMPV2 is valid, it is also irrelavent.
The agent in qestion is a very old v1 implementation, the last UPDATE
to it was in 1991, is as it is located in the NAT box, it is not likely to 
ever change.  RFC1155 may have not allowd the value of 0 and recomended
that the other numbers be contiguous,  but the implementation in question 
pre-dates rfc1155.  

Anything in this case related to RFC1155 and SNMPV2 are moot.
To correctly support this box, MCC need to support both negative numbers
and the value 0.

    re: the last few.
    
    thanks for all the interest,
    
    Is someone going to fix this, or should I submit a QAR...?
    thanks,
    Mike

	My guess : Chances of it ever happening are extremely slim.

	rb,

    re: .8
    you mean this is never going to get fixed?
    if so why?
    thanks,
    Mike

	I guess there are other higher priority work that is being done at
	the moment, and supporting negative numbers in enumerations is pretty
	low on the list. That's what Jerry_the_dictionary_man tells me. :-)

	Rahul.

If you feel this is a strong requirement, I would suggest entering
an opinion in NOTED::EMF_REQ so that product management sees it.

Its a bug, not a ****** product requirement!

If MCC is going to have any future as an SNMP management station it needs to
be  able to handle *all* the important MIBs.  The SNMP world will just laugh
at a management station that tries to impose restrictions.

If it isn't going to be fixed then stop bothering to try to position MCC for
SNMP management and invest the resources somewhere else.

Graham

Graham:

  No one ever said "it isn't going to be fixed".  All Rahul (and I) said (in 
  .10) was that it seems to be low priority.  Given the small number of 
  occurences of negative numbers in MIB enumerations this conclusion seems to
  make sense to us.  

  I interpreted Erik's note (in .11) to be a question as to whether this really
  is or is not a low priority.  I personally don't care if we classify this issue
  as a bug or a requirement.

  BTW, Rahul told me that he presented a temporary workaround.  If this 
  workaround is acceptable, then maybe the issue is indeed low priority??

  Please help us set priorities.  We have so many things to do and we need to
  make intelligent decisions about where to put our effort.

                                                                       - Jerry
 

>>If MCC is going to have any future as an SNMP management station it needs to
>>be  able to handle *all* the important MIBs.  The SNMP world will just laugh
>>at a management station that tries to impose restrictions.

	For your information, many of the SNMP managers do not even handle
	enumerations. They just dump the integer value on the screen without
	trying to resolve it to the associated text. Our workaround is no
	worse than that.

	Rahul.