RE: Returning zero or empty string for unsupported objects

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Maybe I was not clear enough

The case I was wondering about is NOT if it is OK to sometimes
design a special value in a MIB definition that indicates that
an agent can return that value to say "not supported".

What I am talking about here is that some MIB implementation
of a random MIB is just deciding to return zero or empty strings
because it does not feel like supporting one or more objects
in that MIB module.

Thanks,
Bert 

> -----Original Message-----
> From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]
> Sent: vrijdag 7 november 2003 7:08
> To: Mreview (E-mail)
> Subject: Re: Returning zero or empty string for unsupported objects
> 
> 
> Hi -
> 
> > From: "C. M. Heard" <heard@pobox.com>
> > To: "Mreview (E-mail)" <mreview@ops.ietf.org>
> > Sent: Thursday, November 06, 2003 5:54 PM
> > Subject: Re: Returning zero or empty string for unsupported objects
> >
> 
> > Greetings,
> >
> > I think Dave's analysis is right on ... it is not necessarily wrong
> > for an object definition to specify that a special value be returned
> > to indicate that a function isn't supported.  If we did make such a
> > blanket rule I think we'd be guilty of creating an unnecessary rule.
> > I say let this remain a design choice.  (Of course, it's always
> > fair for a reviewer to ask a designer to consider alternatives ... I
> > just don't think this one should be elevated to the status of a
> > SHOULD or MUST.)
> ...
> 
> I think the underlying principle is that the agent should not lie.
> If the object definition provides a "not supported" value, then
> an agent reporting that value isn't lying.  If the object definition
> (or underlying data type) does not provide for such a sentinel value,
> then instantiating the object will lead management applications to
> draw erroneous conclusions.
> 
> Randy (who just saw a MIB where the WG wanted interface counters
> to count or return constant zero depending on what chip set
> was used in the implementation.)
> 
> 
>