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

Mib transition



Hi,

We are working on the legal issues related to the transition of work
from Bridge WG to IEEE 802.1. This question was posed:

> 
> Could a future revision of one of the IETF documents be 
> included in the
> derivative works category? 

I think this comes down to understanding the circumstances that might
require revisions, to determine if this might ever be necessary.

MIB revisions happen for four reasons - something new must be added,
something existing must be changed, something existing becomes
obsolete, or something external to the MIB module itself changes (such
as a new SMI, a new SNMP version, and maybe things like new IETF IPR
rules, or governmental agencies such as ANSI requiring changes to the
security mechanisms). Am I missing any circumstances?

1) adding - If new objects need to be added, the IEEE can simply add
them under their own arc, using the same indices we used in Bridge MIB
(or AUGMENTS if it's a 1:1 relationship).

2) modifying - SMIv2 doesn't generally permit existing MIB objects to
be modified. If IEEE wants to change an object not allowed to be
changed by SMIv2, they can create a new object under their own arc,
and provide a compliance clause that says to use that object rather
than the old object.

There is always the possibility they would want to "clean up" the
descriptions and so on of old modules, but we've just finished doing
that in these documents, while we were upgrading to a new SMI. We tend
to be much pickier than the IEEE on MIB modules, so I don't consider
it likely they'll want to do a republication for cleanup purposes.

If they do, they can ask us to republish with the provided changes.
That avoids the legal issues.

3) We don't often obsolete things in MIB modules. But, if they updated
802.1D in a way that obsoleted significant portions of the existing
MIB module and wanted to republish the document with the necessary
changes, all they need to do is ask us to republish it for them, and
identify the changes. Of course it might take us four years ;-)

But, I don't see that as being likely. Each of the existing documents
will be an IETF standard, and because it would have a serious impact
on interoperability/backwards compatibility, we don't generally go in
and obsolete large portions of a standard MIB except under unusual
circumstances (such as revving RFC1213 or updating existing MIBs for
IPv6 support). 

The only case I see where this would be likely is misguided efforts
like Alex Ruzin's MSTP-MIB where he wanted to copy existing BRIDGE-MIB
objects into his MIB, with new OIDs and descriptors under the ieee802
arc, and obsolete the BRIDGE-MIB objects. This is bad practice from a
standpoint of interoperability, and if IETF MIB Doctors and
knowledgeable 802.1 participants are paying any attention, this is
unlikely to happen.

David Harrington
dbharrington@comcast.net