Re: Status of the WG

[Andy Bierman <abierman@cisco.com>]

At 01:21 PM 2/14/2003 -0800, Wes Hardaker wrote:
>>>>>> On Fri, 14 Feb 2003 12:34:09 -0800, Andy Bierman <abierman@cisco.com> said:
>
>Andy> What is being proposed here?
>Andy> - Unsigned64
>
>Definitely and I think it's generally agreed as needed.

barely needed.  The number of MIBs that need writable 
uint64 objects is insignificant.  I know of one MIB out of
all the IETF MIBs? How many more can you name that are
affected?


>Andy> This is needed for writable 64-bit unsigned integers 
>Andy> (CounterBasedGauge64 works fine for read-only). So far,
>Andy> there is one MIB on the standards track that has been affected
>Andy> by the lack of Unsigned64 (HC-ALARM-MIB)
>Andy> - Integer64
>Andy> I'm not even sure this is needed.  Has any MIB been written that
>Andy> needs large negative numbers?
>
>Um, chicken and egg?  I suspect that many more people have *wanted* to
>write MIBs with larger numbers and just haven't voiced their opinion.
>As more and more protocols come about with 64 bit fields in them,
>we're certainly bound to see an increase in MIBs that need them.

large *negative* numbers.  I don't buy this notion that there is some
pent up demand for large negative numbers.  Can you name a single MIB
that wanted this but had to split the large negative number into
2 32-bit objects?


>I'd even add floats and doubles, which the SMIng working group decided
>should be done and why you wouldn't include them in this list since
>they're equally as simple, I don't know.

Same answer as above, except this has a larger deployment cost
for minimal value.  


>Andy> - SMI clarifications
>Andy> This makes the standards writers feel better but it has no
>Andy> value to anyone else.
>
>Well, it makes the readers happier but I also agree.  I think it's
>more important to accomplish the small technical changes without
>haggling over things that will certainly bring about discussion.
>
>Andy> This doesn't seem like much of an improvement to me.  The deployment
>Andy> costs are low, but so are the benefits.
>
>It would fix the most annoying of the problems.  Small gain for small
>amount of work seems like a good thing.  Fix the problems that can be
>fixed immediately, and then we can continue to whine about the bigger
>problems rather than fixing them like we have been doing.

Any amount of gain for any amount of cost has a large impact
on the user community, due to version skew.  Everybody has
to support applications and agents with and without this
extra support, for at least 10 years.  We still have customers
that insist on MIBs in SMIv1 format because they haven't upgraded
their tools to support SMIv2 yet.  This SMI and protocol change
(we have no ASN.1 tags for these data types) will take a decade
to deploy at least.  If we abandon SMIv3 now, I doubt there will
ever be an SMIv3.

>-- 
>Wes Hardaker
>Network Associates Laboratories 

Andy