RE: section 3.2 of draft-ietf-ops-mib-review-guidelines-00.txt

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

The members of groups can be only objects and notifications defined
in the same MIB module where the group is defined.

This does not create an impossible situation. It just means that
MIB designers have to put some thought into their work. Otherwise,
a compliance may contain many "not-accessible" specifications.
Also, believe that many "problems" are due to inappropriate usage
of items from other MIB modules, such as for an index.

At 01:04 PM 2/9/2003 -0800, C. M. Heard wrote:
>On Sun, 9 Feb 2003, Wijnen, Bert (Bert) wrote:
>> So could I read that 2nd sentence as "if not defined
>> in this module it must be imported" ?
>
>I sure don't think so.  It seems quite clear to me that
>it means "if not defined in this module it can't be in
>a group defined in this module".  As I understand it,
>this is the reason why you need the rule that every
>notification or object must appear in at least one group.
>
>> I agree with Dan ROmascanu here that if we indeed intended
>> to prohibit to define OBJECT-GROUPS that have objects from
>> other modules, that we have then sort of maneuvred ourselves
>> a bit into a corner, no?
>
>As I explained in my answer to Dan, it's always possible cite
>as many groups as it takes to get all the foreign objects you
>want, and then use OBJECT clauses with MIN-ACCESS of
>not-accessible to exclude them.  Admittedly, one can envision
>situations where this would be awkward.
>
>I do agree that having the SMIv2 authors chime in at this
>point would be quite helpful.
>
>Thanks,
>
>Mike
Regards,
/david t. perkins