RE: Extensible TCs (WAS: Compliance Statements)

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

On Mon, 17 Feb 2003, Wijnen, Bert (Bert) wrote:

> Not sure yet that it does address it all.
> Does your new text say that if you use IfType TC
> that you should include it with an enumerated list?

No, it certainly wasn't mean to do that.

> I guess one could interpret your text that way and
> I do not think that such is your(our) intention.

Did you perhaps overlook this part?

   When an imported TC that may be extended in this way is used to
   define an object that may be written or that serves as an index in
   a read-create table,  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   ^^^^^^^^^^^^^^^^^^^

I think that most of the uses of ifType are in objects that either
have a MAX-ACCESS or MIN-ACCESS of read-only.  I'm not concerned
about such cases because the implementation always chooses
what values to return when an object is read-only.

However, if I were to define a writeable object with a SYNTAX value
of ifType, then I'd better say something about values that need to
be supported, even if it's just a statement like "the implementation
need only allow values that correspond to interface types that it
supports".  Note that something of this nature was done in the
mallocScopeAddressType example appended to my previous message.

> How about a more flexible statement that would still make
> people think about it and (hopefully) do the right thing:
> 
>    MIB module authors need to be aware that enumerated INTEGER or BITS
>    TCs may in some cases be extended with additional enumerated values
>    or additional bit positions.  When an imported TC that may be
>    extended in this way is used to define an object, one SHOULD
>    consider if it makes sense to specify the set of values or bit
>    positions that need to be supported in the object's DESCRIPTION
>    clause or in an OBJECT clause in the MIB module's compliance
>    statement(s).

I would prefer something more explicit.  How about:

   MIB module authors need to be aware that enumerated INTEGER or BITS
   TCs may in some cases be extended with additional enumerated values
   or additional bit positions.  When an imported TC that may be
   extended in this way is used to define an object that may be written
   or that serves as an index in a read-create table, then the set of
   values or bit positions that needs to be supported SHOULD be
   specified either in the object's DESCRIPTION clause or in an OBJECT
   clause in the MIB module's compliance statement(s).  This may be done
   by explicitly listing the required values or bit positions, or it may
   be done by stating that an implementation may support a subset of
   values or bit positions of its choosing.

This is not intended to constrain a designer in any way or to make
a lot of etxra work.  The only thing that I am trying to avoid here
is having the requirements become a moving target, which will happen
if _nothing_ is said about the required values for a writeable object
(or read-create index object) that uses an extensible imported TC.

//cmh