RE: Extensible TCs (WAS: Compliance Statements)

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

[ note change to subject line ]

On Sun, 16 Feb 2003, Wijnen, Bert (Bert) wrote:
>[Andy Bierman wrote, concening a proposal to RECOMMEND that MCs have]
>[an OBJECY clause listing all enumerations for writeable enumerated ]
>[INTEGER and BITS objects when support for all values is required:  ]
> > This will make M-Cs extremely verbose and a lot of work to create.
> > It would be better to create these verbose OBJECT clauses only
> > when the enum list is extended, when you know for sure the
> > OBJECT clause is needed.  This can go in a new deprecated M-C,
> > at the same time you create a new current M-C.
> > 
> I do understand that concern.
> But if you have for example imported TCs that can be changed, then
> they might happen without the authors of the TC doc knowing all
> the places where it is used.
> 
> I agree that if one uses ENUMs/BITS that are defined in ones
> own module, that it is not needed. Maybe it is more important
> for imported ENUMs/BITS.

Maybe, then, we've gotten off the mark by trying to write a
compliance statement guideline instead of trying to write a
guideline on how to deal with an imported TCs that might be
extended.  Since an OBJECT clause in a compliance statement
is only one way to deal with this -- the DESCRIPTION clause
is another(*) -- the guideline probably belongs in Section
4.6.1.10, "Other Data Types", where the subject of using
standard TCs in object definitions is covered, rather than
in the section on compliance statements.  (Perhaps that's
why RFC 2580 doesn't discuss this subject in connection with
MCs, but only in connection with ACs.)   I'd like to propose
that the following paragraph be added to the end of 4.6.1.10:

   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).

Does this adequately address the issue?

//cmh

-------------------------------------------
(*) Here is an example, from the MALLOC-MIB:

mallocScopeAddressType OBJECT-TYPE
    SYNTAX     InetAddressType
    MAX-ACCESS not-accessible
    STATUS     current
    DESCRIPTION
            "The type of the addresses in the multicast scope range.
            Legal values correspond to the subset of address families
            for which multicast address allocation is supported."
    ::= { mallocScopeEntry 1 }