Re: diverging views on adding range constraints in MIB module revisions

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> C M Heard writes:

Mike> In off-line e-mail exchanges with some of the other MIB doctors
Mike> it became apparent to me that there is some divergence of
Mike> opinion on how much latitude should be allowed in revisions of
Mike> standards-track MIB modules -- in other words, different
Mike> reviewers might well give different answers on whether certain
Mike> changes are allowed, particularly for modules that are recycling
Mike> at Proposed Standard rather than being advanced

[...]

Mike> How serious these problems would be in practice would of course
Mike> depend on what the installed base actually does.  An IETF
Mike> working group, however, cannot have assurances of being able to
Mike> uncover what all (or even most) of the installed base does.

I strongly believe that the WGs have to make the final decision in
such cases and our role is to explain to them the trade-offs and the
impacts of their decisions. I myself had to change a range of a
published MIB object do fix a bug that slipped through and I
personally believe that such fixes when a document recycles at
proposed are sometimes much more valuable than blindly insisting on
SMI rules. (In this particular case I had, the SMI correct way would
have been to deprecate the object and to create a new one. If such on
object is used as part of an index or being pointed to, even whole
tables have to be redone. This is hardly the right cost/benefit
tradeoff.)

In the particular case that you have in mind, I think we clearly made
the MIB authors aware of the impact. I think the whole issue came up
because some "pointer" objects had a range which was not consistent
with the range of things the pointers are supposed to point to. The
group responsible for the MIB module decided that they want to solve
this by declaring that it is indeed Integer32 (1..65535) what
everybody has implemented and I think MIB reviewers (and the IESG)
should accept such decisions.

My understanding of the job of a MIB doctor is to _help_ authors to do
a good job. We should not enforce rules blindly. And we should also
try hard to make the review itself a friendly act, making sure we try
hard to explain things well, in an atmosphere that is friendly and
such. Another issue are turn around times - which are sometimes not as
good as they should be. Perhaps we actually need to draft some text
about MIB reviewer ethics. I am serious.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>