Re: Status of the WG

On Mon, 17 Feb 2003, Juergen Schoenwaelder wrote:
> Bert> APPLICATION 4 is the Opaque datatype that we claim in RFC2578 to
> Bert> be there only for backward compatibility (see sect 7.1.9).
> 
> Bert> I doubt that if we do this that many current implementations
> Bert> know how to deal with it without software upgrades. So I do not
> Bert> see that this has much advantages over defining new tags
> 
> The difference is whether an implementation throws an ASN1/BER parse
> error or whether the data moves up potentially all the way to the
> application where an unknown variable will be ignored or something in
> between understand the new datatype. This makes a serious difference
> and that is why the NMRG did choose to use opaque wrappers.

Exactly.  Of course you cannot actually support new data types
without a software upgrade.  But you would like to be able to
deploy such an upgrade incrementally, and you would like for
entities that don't have the SW upgrade to still be able to
communicate with entities that do.

Since EOS apparently will be getting closed down, those who want
an SMIv2.1 has better face the fact that it has to be supported
without a new version of SNMP if it is to be supported at all.
The opaque wrapper will let you do that.  I don't know of anything
else that will.  The coding changes needed depend on the
implementation, of course, but in the ones I'm familiar with the
changes are mostly confined to encoding and decoding routines.  If
I'm not mistaken, the code for one experimental opaque scheme
already exists for net-snmp (courtesy of Dave Perkins).

> Note that we have beaten this horse (and similar horses) already so
> many times that I wonder why we have to do it yet again...
> 
> Note also that doing SMIv2.1 will get us back into all these debates
> which we were never able to end with rough concensus so even while
> SMIv2.1 seems simple and easy to do, the reality will be quite
> different.

That's all completely true.  So, people that want SMIv2.1 had better
face this.  SMIv2.1 _could_ be simple and easy to implement (although
it would not be as easy to deploy), but it _won't_ be if we (meaning
IETF NM people as a group) won't face the music and make the decisions
necessary to make progress.

//cmh