RE: LLDP MIBs

["Harrington, David" <dbh@enterasys.com>]

Hi,

I asked a question because I apparently have not been in the gazillion
discussions of this (or fell asleep if I was). 

I personally have no desire to get into discussions of ISO
specifications and their implications to SMIv2 and various compilers. DP
and RP and JS are welcome to do that if they choose, but please at least
change the subject line to something I can easily recognize as a thread
I can delete from my email. Let me know who wins.

In the meantime, somebody raised the point that the way the LLDP MIB was
written may be in error. I did not find anything in SMIv2 or in the mib
review guidelines that say that using the value rather than the name is
in error. I hesitate to go to the IEEE and say "you must change your
mib" if I cannot even identify where the CLR exists. 

Can anybody identify where this rule exists in the SMIv2 or mib review
guidelines?
Is this a problem for the import functions of widely-used SNMP manager
applications, such as HPOV, Tivoli, CA Unicenter, BMC Patrol, Spectrum,
MRTG, and so on, to anybody's knowledge?

Thanks,
Dbh

> -----Original Message-----
> From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of David T. Perkins
> Sent: Wednesday, April 14, 2004 4:07 PM
> To: Randy Presuhn; Mreview (E-mail)
> Subject: Re: LLDP MIBs
> 
> HI,
> 
> Ok, let's open the SMI and address the issue. (I'm being sarcastic,
> if you cannot tell.) Randy will go back to ASN.1 and say that the
> way enums are done in the SMI is really just associating labels
> with integer values and that ASN.1 allows use of numeric values
> or labels. (However, see the note in section 14.10 of X.208/ISO 8824)
> And I'll point out that this is true, but the SMI's
> enumerated integers is patterned after the ASN.1 enumerated type, and
> for the enumerated type values can only be expressed as "labels".
> (see section 15.4 of X.208/ISO 8824)
> We have gone through this discussion gazillion of times.
> At this time, I don't believe that it is worth spending too
> much time on the issue, and suggest that the lintSMI maintainers
> modify their program to require that defvals for enumerated
> values can specify only the value. (And the review guidelines
> be updated.)
> Note that if you want to follow Randy's argument, then one
> should allow SYNTAX clauses like the following, since they
> are valid ASN.1:
>   SYNTAX Integer32 { negone(-1), zero(0), ninety(90) } (-100..100)
> 
> At 10:52 AM 4/14/2004 -0700, Randy Presuhn wrote:
> >Hi -
> >
> >> From: "Harrington, David" <dbh@enterasys.com>
> >> To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> >> Cc: "Mreview (E-mail)" <mreview@ops.ietf.org>
> >> Sent: Wednesday, April 14, 2004 9:55 AM
> >> Subject: RE: LLDP MIBs
> >...
> >
> >> It appears to me that the issue is whether an enumerated 
> value MUST be
> >> specified in a DEFVAL by its name rather than its value. I 
> don't see why
> >> it should make a difference as long as the value is one of 
> the defined
> >> enumerations.
> >>
> >> Is this really an error?
> >...
> >
> >I don't think so.
> >
> >Although the examples of DEFVALs in RFC 2578 use names rather than
> >values, I don't see anything there or in the MIB review guidelines
> >that would make it a requirement.
> >
> >I think one could even argue that page 27 of the MIB
> >review guidelines provides some motivation for preferring numbers
> >to names, even though the names are less human-hostile.
> >
> >However, common practice seems to be to use the names.
> >
> >Randy
> 
> Regards,
> /david t. perkins
> 
> 
> 
> 
>