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

Re: Time to Revise the TC list

Juergen Schoenwaelder wrote:

On Fri, May 05, 2006 at 12:04:50PM -0700, Randy Presuhn wrote:


From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "Wes Hardaker" <wjhns1@hardakers.net>
Cc: "Romascanu, Dan (Dan)" <dromasca@avaya.com>; "Mreview (E-mail)" <mreview@ops.ietf.org>; <ietfmibs@ops.ietf.org>
Sent: Friday, May 05, 2006 1:04 AM
Subject: RE: Time to Revise the TC list

...

- It is (in my view) ALLWAYS possible to take a copy (renamed) of any
  TC and include it in a document that wants to advance and then
  use the renamed TC. It means no semantic change of any object and
  it means no change on the wire.

...

This is problematic for users of MIB compilers that know how to generate code
for certain "interesting" TCs.  Examples of where this is useful include
enforcing repertoire and encoding constraints for DisplayString.


I think it is bad engineering to create problems (duplicating or
moving definitions is asking for problems) just in order to comply to
some rules which have already proven to have rather little value.

In other words, I strongly prefer to simply keep MIB definitions
stable if there is no technical need to touch them and I am willing to
pay the price that MIB modules might simply stay at Proposed Standard
level for a long long time. Lets simply apply good engineering here. ;-)



I agree with Juergen.
There are known problems with some tools which
encounter multiple versions of a TC from different
modules, even if the module being compiled doesn't
actually import these TCs.

Moving a TC for better coupling and cohesion is even risky,
but at least that's an engineering reason.  Cloning a TC
for standards track rule compliance is a bad idea.




/js



Andy