Date: Mon, 2 Jan 2012 20:26:55 +0100 From: Harti Brandt <hartmut.brandt@dlr.de> To: Ulrich Spoerlein <uqs@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Harti Brandt <harti@freebsd.org>, Ben Kaduk <minimarmot@gmail.com> Subject: Re: 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... Message-ID: <20120102201549.X41320@beagle.kn.op.dlr.de> In-Reply-To: <20120101171324.GM83814@acme.spoerlein.net> References: <201112301058.pBUAwFsw010478@svn.freebsd.org> <CAK2BMK6p3VJXezt%2Bpa7-0MbP4=Uv79i=D=cxmDrpAwUK2Mw2vQ@mail.gmail.com> <20111230204653.Y31442@beagle.kn.op.dlr.de> <20120101171324.GM83814@acme.spoerlein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--1964543108-640420677-1325532415=:41320
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: QUOTED-PRINTABLE
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@freebsd.org> w=
rote:
US>> >> Modified: head/usr.sbin/bsnmpd/modules/snmp_wlan/BEGEMOT-WIRELESS-M=
IB.txt
US>> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
US>> >> --- head/usr.sbin/bsnmpd/modules/snmp_wlan/BEGEMOT-WIRELESS-MIB.txt=
=9A =9A Fri Dec 30 10:45:00 2011 =9A =9A =9A =9A(r228989)
US>> >> +++ head/usr.sbin/bsnmpd/modules/snmp_wlan/BEGEMOT-WIRELESS-MIB.txt=
=9A =9A Fri Dec 30 10:58:14 2011 =9A =9A =9A =9A(r228990)
US>> >> @@ -82,8 +82,8 @@ WlanMgmtReasonCode ::=3D TEXTUAL-CONVENTIO
US>> >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9AassociationLeave(8),
US>> >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9AassociationNotAuthenticated(=
9),
US>> >> =9A-- XXX: TODO - FIXME
US>> >> - =9A =9A =9A =9A =9A =9A =9A =9A =9A dissasocPwrcapBad(10),
US>> >> - =9A =9A =9A =9A =9A =9A =9A =9A =9A dissasocSuperchanBad(11),
US>> >> + =9A =9A =9A =9A =9A =9A =9A =9A =9A disassocPwrcapBad(10),
US>> >> + =9A =9A =9A =9A =9A =9A =9A =9A =9A 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>>=20
US>> Absolutely. If there is a spelling error in an SNMP MIB outside commen=
ts=20
US>> or description strings it must stay there. Otherwise applications read=
ing=20
US>> that file will break.
US>>=20
US>> This is also true for the corresponding .def file.
US>>=20
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=20
revisions: RFC 2578, RFC 2579 and RFC 4181. There may be others. 4181=20
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=20
deprecated (unfortunately one can formally deprecate MIB objects, but not=
=20
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=20
uses in companies. I have a number of MIB modules that use FreeBSD modules=
=20
(albeit not the WLAN module) that are not intended to be released outside=
=20
our institute because they are quite special-purpose and not of use for=20
somebody else. Nevertheless I would try to not break this kind of use.
harti
--1964543108-640420677-1325532415=:41320--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120102201549.X41320>