svn commit: r228990 - in head/usr.sbin: IPXrouted adduser bluetooth/btpand bluetooth/sdpd bootparamd/bootparamd bsnmpd/modules/snmp_bridge bsnmpd/modules/snmp_hostres bsnmpd/modules/snmp_wlan bsnmp...

[Harti Brandt]

Hi Uli,

On Sun, 1 Jan 2012, Ulrich Spoerlein wrote:

US>Sorry for the delay.
US>
US>On Fri, 2011-12-30 at 20:50:16 +0100, Harti Brandt wrote:
US>> On Fri, 30 Dec 2011, Ben Kaduk wrote:
US>> >On Fri, Dec 30, 2011 at 5:58 AM, Ulrich Spoerlein <uqs at freebsd.org> wrote:
US>> >> Modified: head/usr.sbin/bsnmpd/modules/snmp_wlan/BEGEMOT-WIRELESS-MIB.txt
US>> >> ==============================================================================
US>> >> --- head/usr.sbin/bsnmpd/modules/snmp_wlan/BEGEMOT-WIRELESS-MIB.txt     Fri Dec 30 10:45:00 2011        (r228989)
US>> >> +++ head/usr.sbin/bsnmpd/modules/snmp_wlan/BEGEMOT-WIRELESS-MIB.txt     Fri Dec 30 10:58:14 2011        (r228990)
US>> >> @@ -82,8 +82,8 @@ WlanMgmtReasonCode ::= TEXTUAL-CONVENTIO
US>> >>                    associationLeave(8),
US>> >>                    associationNotAuthenticated(9),
US>> >>  -- XXX: TODO - FIXME
US>> >> -                   dissasocPwrcapBad(10),
US>> >> -                   dissasocSuperchanBad(11),
US>> >> +                   disassocPwrcapBad(10),
US>> >> +                   disassocSuperchanBad(11),
US>> >
US>> >This file looks like it might be intended to be machine-readable -- I
US>> >would worry about changing it without test/review.
US>> >Perhaps this spelling "error" is even the reason for the XXX comment above.
US>> 
US>> Absolutely. If there is a spelling error in an SNMP MIB outside comments 
US>> or description strings it must stay there. Otherwise applications reading 
US>> that file will break.
US>> 
US>> This is also true for the corresponding .def file.
US>> 
US>> harti
US>
US>Neither Google, Bing nor Google Code Search can find any occurrence of
US>any of the two words in either spelling, except in our tree, of course.
US>This leads me to believe that at least no known Open Source project will
US>be affected by the change. But that doesn't say much.
US>
US>Is this a non-backwards compatible change that we can do when going from
US>9.x to 10.0? I'm fine with backing it out, too, if you think this will
US>actually break anything for third parties. Just say the word.

Actually there are several RFCs which contain descriptions on doing MIB 
revisions: RFC 2578, RFC 2579 and RFC 4181. There may be others. 4181 
contains the following text:

"RFC 2579 Section 5 specifies rules that apply to revisions of textual
convention definitions.  The following guideline corrects an error in
these rules:

   - Bullet (1) allows the labels of named numbers and named bits in
     SYNTAX clauses of type enumerated INTEGER or BITS to be changed.
     This can break compilation compatibility, since those labels may be
     used by DEFVAL clauses in modules that import the definitions of
     the affected TCs.  Therefore, labels of named numbers and named
     bits MUST NOT be changed when revising IETF MIB modules (except to
     correct typographical errors), and they SHOULD NOT be changed when
     revising enterprise MIB modules."

So for the given MIB the term "SHOULD NOT" applies. What I would do is:

- keep the misspelled definitions and mark them with a comment as 
deprecated (unfortunately one can formally deprecate MIB objects, but not 
integer names).

- add correctly spelled definitions

- in any case add a revision statement to the MODULE-TYPE macro.

Even if you find no open source uses of the MIB, there may be internal 
uses in companies. I have a number of MIB modules that use FreeBSD modules 
(albeit not the WLAN module) that are not intended to be released outside 
our institute because they are quite special-purpose and not of use for 
somebody else. Nevertheless I would try to not break this kind of use.

harti