RE: Status of the WG

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

On Sat, 15 Feb 2003, Andy Bierman wrote:
> I made the statement above without thinking through the
> actual benefits that HC data types will bring.  I don't
> know if there is some set of incremental changes that
> will be worthwhile.  I think that introducing a third
> SMI variant will have a minimum cost which will be 
> roughly the same no matter what the feature set of the
> new variant. We also have to introduce a new protocol
> variant, since new data types need to be encoded with
> new ASN.1 tags.

You actually don't need to instroduce new tags _into
the PDU definition_ in order to transport additional
data types.  You can do it with "double wrapping".
For example (courtesy of D. Perkins):

Integer64 ::= [APPLICATION 4]
                  [APPLICATION 10] IMPLICIT
                      INTEGER (-9223372036854775808..9223372036854775807)

Unsigned64 ::= [APPLICATION 4]
                   [APPLICATION 11] IMPLICIT
                       INTEGER (0..18446744073709551615)

This is compatible with the existing SNMPv2-PDU definition.

In the past we've heard a lot of screaming about this idea,
but not for any very good reason that I can figure.  Forget
about what [APPLICATION 4] is called, and think about it
_just_ as an encoding method that makes incremental
deployment possible.

I've not been monitoring this list (or the EOS list) for a
while, but I thought that this technique was suggested long
ago as the basis for transporting the new data types in the
IRTF proposal.

//cmh