[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: section 3.2 of draft-ietf-ops-mib-review-guidelines-00.txt
So could I read that 2nd sentence as "if not defined
in this module it must be imported" ?
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?
> -----Original Message-----
> From: C. M. Heard [mailto:firstname.lastname@example.org]
> Sent: zondag 9 februari 2003 21:43
> To: email@example.com
> Subject: RE: section 3.2 of
> On Sun, 9 Feb 2003, Wijnen, Bert (Bert) wrote:
> > I did see those section 3.1 and 4.1 of 2580.
> > They do state that you MUST define OBJECT GROUPS in the
> > same module and make sure that every object is present in
> > at least one OBJECT GROUP.
> > But I don't think that these 2 sections preclude/prohibit
> > that you can define additional OBJECT GROUPS in other modules,
> > does it? Maybe the SMIv2 authors can chime in here?
> The wording in RFC 2580 seems quite clear to me. See the second
> sentence of each of the paragraphs quoted below.
> 3.1. Mapping of the OBJECTS clause
> The OBJECTS clause, which must be present, is used to specify each
> object contained in the conformance group. Each of the specified
> objects must be defined in the same information module as the
> OBJECT-GROUP macro appears, and must have a MAX-ACCESS clause value
> of "accessible-for-notify", "read-only", "read-write", or "read-
> [ ... ]
> 4.1. Mapping of the NOTIFICATIONS clause
> The NOTIFICATIONS clause, which must be present, is used to specify
> each notification contained in the conformance group. Each of the
> specified notifications must be defined in the same information
> module as the NOTIFICATION-GROUP macro appears.
> I interpret the words
> Each of the specified ... must be defined in the same information
> module as [the one in which] the ... macro appears.
> to mean that module B can't import notifications or objects from
> module A and define a group that includes them. To put it another
> another way: every group defineed in module B may contain only
> objects or notifications defined in module B.
> P.S. smilint apparently does not enforce this rule. I've
> not yet checked
> whether other MIB compilers do.