RE: comment on draft-ietf-ops-mib-review-guidelines-03.txt (fwd)

["C. M. Heard" <heard@pobox.com>]

>>>>> On Mon, 10 Jan 2005, Wijnen, Bert (Bert) wrote:
Bert>[David Perkins wrote:]
Bert> > More importantly is that if application A is created
Bert> > to access table T, such as to create and delete rows
Bert> > in T. Then adding support for augmentation table T1
Bert> > MUST NOT cause A to stop working or to work differently.
Bert> > This means that a MIB designer is quite constrained 
Bert> > in the design of augmentation tables!
Bert> > 
Bert> > This should be obvious.
Bert> 
Bert> I guess you are right that it should be obvious. However, I
Bert> suspect I never took it that restricted when reviewing new MIB
Bert> modules. It restricts it very very seriously. For example, all
Bert> the columns in the augemented table should have DEFVALs to
Bert> allow the row to become active based on DEFVALs.

>>>>> On Mon, 10 Jan 2005, David B Harrington wrote:
dbh> I think the point about DEFVALs is good, and not obvious. It
dbh> would be good to provide an explicit guideline on this point.

Well, one thing we can't do is to say that DEFVALs are required.

According to RFC 2578, DEFVALs are optional hints to implementors.
They are not required to be present and can be changed in future
revision.  They also are not binding on the agent.  Cf.:

7.9.  Mapping of the DEFVAL clause

   The DEFVAL clause, which need not be present, defines an
   acceptable default value which may be used at the discretion of
   an agent when an object instance is created.  That is, the value
   is a "hint" to implementors.

10.2.  Object Definitions
   An object definition may be revised in any of the following ways:
[ ... ]
(4)  A DEFVAL clause may be added or updated.

Further, RFC 2580 allows an agent-caps statement to override the
DEFVAL given in an object definition:

6.5.2.5.  Mapping of the DEFVAL clause

   The DEFVAL clause, which need not be present, is used to provide
   [an] alternate DEFVAL value for the object named in the
   correspondent VARIATION clause.  The semantics of this value are
   identical to those of the OBJECT-TYPE macro's DEFVAL clause.

Finally, note that a sensible default value does not always exist.

What IS required is that the agent needs to be able to create a row
even if values for the augmenting columns are not specified.  One
way to do that is to provide default values for the augmenting
columns.  Another way is to "fall back" and operate like it is
implementing the un-AUGMENTed table.

//cmh