[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Changing enum labels considered harmful



Hi,

I don't think it is a problem, as long as the semantics of the enumeration are not changed.

An NMS is likely to import a mib module with the old label or with the new label, and as long as the semantics of the enumeration doesn't change, and the OID and value of the enumeration do not change, then the label for the enumeration will only affect the user interface, not the on-the-wire protocol or the ability to aggregate and contrast the enumeration semantics from multiple vendors' systems. 

I don't think it is necessary to develop a new Clarifying Language Rule for this.

dbh

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: Friday, January 17, 2003 12:10 PM
> To: mreview@ops.ietf.org
> Subject: Re: Changing enum labels considered harmful
> 
> 
> On Fri, 17 Jan 2003, Juergen Schoenwaelder wrote:
> > 
> > Mike> I think it was a mistake for the SMI to allow labels 
> associated
> > Mike> with existing enumerations and bit positions to be 
> changed when
> > Mike> a module is revised, and I believe that the practice should be
> > Mike> forbidden in revisions of IETF MIB [modules].  If 
> others on the
> > Mike> mreview list agree with this, I'll put some words to 
> that effect
> > Mike> in the MIB author's and reviewer's guide, and Juergen or Frank
> > Mike> might want to consider adding an equivalent item to 
> the on-line
> > Mike> SMI errata list.
> > 
> > I think it is fine to explain the problem in the guide and to
> > recommend to not change labels. Whether this is indeed considered to
> > be a bug in the SMIv2 specification probably requires more concensus
> > and we will get back to the question how much a language should
> > allow/disallow and how much concrete usage guidelines should
> > allow/disallow.
> 
> Understood.  The reason why I hold to the position that it is a bug
> is that (a) it breaks backward compatibility and (b) similar practices
> that break backward compatibility (in particular, changing the
> descriptor of an existing object) are explicitly banned).  I'll
> move the discussion of that part of the issue over to the
> mibs@ops.ietf.org list.
> 
> //cmh
> 
> 
>