[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should a TC be allowed to remove the MAX-ACCESS restrictions ofits base type?
- To: mibs@ops.ietf.org
- Subject: Re: Should a TC be allowed to remove the MAX-ACCESS restrictions ofits base type?
- From: "C. M. Heard" <heard@pobox.com>
- Date: Mon, 2 Sep 2002 16:00:43 -0700 (PDT)
- In-reply-to: <4.3.2.7.2.20020828113329.03fdb620@fedex.cisco.com>
[ With apologies for a 2nd follow-up to the same message,
but it occurs to me that the same type of pragmatic
argument that can be made against adding Unsigned64 to
the SMI can also be made against writeable Counter64 ... ]
>>>>> On Wed, 28 Aug 2002, Andy Bierman wrote:
> [ ... ] The specific changes to a toolset are not that
> important -- the fact that any upgrade at all is required
> is important. The advantages to the upgrade have to be very
> compelling for people to even consider taking the time and
> risking any disruption. [ ... ]
Suppose that we accept this as true (as in fact I do). Then
it would seem that the only prudent course in designing a
standard MIB that is supposed to be deployable _in the short
term_ would be to avoid, if at all possible, practices that
(a) are forbidden by SMIv2 rules and (b) are disallowed by
a significant population of existing toolsets.
As was pointed out before, toolsets are known to exist that
enforce the SMIv2 rule that no read-write or read-create
objects may have a SYNTAX that resolves to Counter64.
Unless there is good evidence that such tools constitute a small
minority of the market, it seems to me that you'd be better off
_from a pragmatic point of view_ to use a 32/32 pair or some
equivalent for all your writeable 64-bit objects if you want
your MIB to be deployable in the short-term.
Mike