RE: Status of the WG

> 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.
> 
APPLICATION 4 is the Opaque datatype that we claim in RFC2578 to
be there only for backward compatibility (see sect 7.1.9).

I doubt that if we do this that many current implementations
know how to deal with it without software upgrades. So I do not
see that this has much advantages over defining new tags

> 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.
> 
Yes it was, and as far as I remember, the consensus was (is?) 
that we did not want to go there. Maybe times have changed?

Bert
> //cmh
> 
>