RE: Extensible TCs (WAS: Compliance Statements)

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

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?
I guess one could interpret your text that way and
I do not think that such is your(our) intention.
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).

Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: maandag 17 februari 2003 4:16
> To: Wijnen, Bert (Bert)
> Cc: Andy Bierman; Mreview (E-mail)
> Subject: RE: Extensible TCs (WAS: Compliance Statements)
> 
> 
> [ 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 }
>