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
hartmut.brandt at dlr.de
Mon Jan 2 19:27:25 UTC 2012
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
More information about the svn-src-head
mailing list