Subject: SnmpAdminString

From: "Bert Wijnen" <[email-masked]>
Date: Tue, 6 Jul 99 00:01:30 DST

Ref:  Your note of Mon, 5 Jul 1999 14:33:33 -0700

Subject: Re:   SnmpAdminString

Andrew writes:
> What is the intended meaning of "deprecate" for *new* implementors?
>
That they are permitted to implement it in order to foster
interoperability. See RFC2578 section 6.1, which reads:

6.1.  Mapping of the STATUS clause

   The STATUS clause, which must be present, indicates whether this
   definition is current or historic.

   The value "current" means that the definition is current and valid.
   The value "obsolete" means the definition is obsolete and should not
   be implemented and/or can be removed if previously implemented.
   While the value "deprecated" also indicates an obsolete definition,
   it permits new/continued implementation in order to foster
   interoperability with older/existing implementations.

So again, it shows clearly that this "deprecated" is intended to
address the concerns you raise with existing implementations,
both at the agent side and at the manager application side.

> My guess would be that new manager implementations would be well advised to
> implement both the old and the new and that new agent implementations might
> also do both if they want to work with existing deployed managers. Of course
> if people assume this logic this then they can actually get away with
> picking only one of them which sort of defeats the purpose of the new object
> ... I guess people have to make their own estimates of the half-life of
> implementations to decide for themselves.
>
No... if they decide to only implement the depricated objects, then
they do NOT follow the intent of the meaning of deprecated.
Besides, we should include the new objects as mandatory group in
the compliance and the deprecated ones should only be in an old
compliance statement (which should also be deprecated I think.

Hope this explains.

Bert