Re: Should a TC be allowed to remove the MAX-ACCESS restrictions ofits base type?

["C. M. Heard" <heard@pobox.com>]

On Wed, 28 Aug 2002, Andy Bierman wrote, in an off-list thread:
>At 09:43 AM 8/28/2002 -0700, C. M. Heard wrote:
>>On Wed, 28 Aug 2002, Andy Bierman wrote:
>>> Since the proposed Unsigned64 would be tagged as a Counter64,
>>> how is this any better than using a TC which accomplishes 
>>> the same thing?
>>
>>In terms of what MIBs it lets you write the effects are exactly
>>the same.
>>
>>However, I do not agree with your statement (in an earlier e-mail)
>>that proto ops restrictions should be tied strictly to object
>>definitions and not to data types.  On the contrary, I think the
>>semantic and syntactic restrictions on Counter32 and Counter64
>>are perfectly sensible.  What is not sensible is failure to
>>provide Unsigned64 and (to a lesser degree) Integer64.  What I
>>am proposing that we fix the underlying problem, at least for
>>Unsigned64.
>>
>>> A new keyword in a new SMI version would require
>>> every toolset to change.
>>
>>No, it would only require update to toolsets that need to support
>>the new SMIv2.1 feature(s).
>
>As opposed to he very real possibility that existing toolsets
>can support an Unsigned64 TC without any changes at all.

That may apply to some existing toolsets;  it is known, however,
that there are some toolsets to which it does _not_ apply.

>>> A TC would mean only the toolsets which do code-gen-time checks
>>> for Sets on Counter64 would need to change (and this change
>>> might be needed for some toolsets even if a new keyword that
>>> resolves to Counter64 is used).
>>
>>True.
>>
>>> It takes years for any change in the SMI or protocol to
>>> propagate throughout the industry.  I would rather not
>>> introduce a new SMI version that will soon be replaced by
>>> SMIv3.  
>>
>>There is some merit in this.  However, I suspect that SMIv3
>>will take a lot longer to get deployed than an incremental
>>change to SMIv2.
>
>Actually, I have not found this to be the case for Cisco and
>our customers.  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. It would be much more likely that
>people would hack the MIBs to get rid of all occurrences of
>Unsigned64 (convert them to Counter64 or introduce a TC that
>mapped Unsigned64 to Counter64) than upgrade the toolset.

You do have a point, but the hacking would only be worth doing
if the toolset could deal with a writeable Counter64 in the
first place.  Otherwise you are back to an incremental upgrade.

Feedback from toolset people would be awfully helpful in making
an informed decision ...

//cmh