RE: Returning zero or empty string for unsupported objects

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

> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com]
> Sent: vrijdag 7 november 2003 9:39
> To: Wijnen, Bert (Bert)
> Cc: Randy Presuhn; Mreview (E-mail)
> Subject: RE: Returning zero or empty string for unsupported objects
> 
> 
> At 10:49 PM 11/6/2003, Wijnen, Bert (Bert) wrote:
> >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.
> 
> Clearly it is wrong for an agent to ignore the semantics of 
> a MIB object and invent new semantics for any portion of the
> object's valid values.  It's just as bad to return values
> which are invalid according to the SYNTAX clause.
> 
yes yes I know. I am trying to locate as much text in RFCs that spells
that out.

Bert
> 
> >Thanks,
> >Bert 
> 
> Andy
> 
> 
> 
> >> -----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.)
> >> 
> >> 
> >> 
>