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

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

So, you are telling me/us that if anywhere in the future
we were to need a slightly different additional grouping,
then we would have to re-open the MIB module in which
the objects are defined. Oh well... 

Thanks,
Bert 

> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> Sent: zondag 9 februari 2003 23:53
> To: C. M. Heard; mibs@ops.ietf.org
> Subject: RE: section 3.2 of 
> draft-ietf-ops-mib-review-guidelines-00.txt
> 
> 
> 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 
> 
>