RE: Guidelines Section 4.6.4 (OID Values Assigned to Objects)

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

I do not have a strong objection.

At the other hand, I am not aware that we have had
these type of problems in (IETF) MIB documents, so 
it seems to add stuff that is (mostly) not needed?

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: maandag 17 februari 2003 2:18
> To: Mreview (E-mail)
> Cc: Michael Kirkham
> Subject: Re: Guidelines Section 4.6.4 (OID Values Assigned to Objects)
> 
> 
> On Wed, 5 Feb 2003, C. M. Heard wrote:
> > On Wed, 5 Feb 2003, Michael Kirkham wrote:
> > > I think a 'SHOULD NOT' would also be beneficial in this section 
> > > with regards to registering OIDs to objects that are subordinate
> > > to, e.g., NOTIFICATION-TYPEs, MODULE-COMPLIANCEs, etc.  [ ... ]
> > > You mention this type of organization elsewhere (e.g. in the
> > > notifications section, recommending against defining notifications
> > > under objects/groups/etc.), but the reverse is also just as bad.
> > 
> > I meant to [include] some text to that effect here, but 
> overlooked it
> > in the hurry to finish.  I'd like to get feedback from the other
> > MIB reviewers as to whether it would add value or would 
> just be bloat
> > (and if the latter, whether the stuff I put in about not registering
> > notifications in strange places is also bloat).
> 
> Well, nobody said anything one way or another, and I think some text
> would be useful.  So I propose to add the following paragraph at the
> end of Section 4.6.4:
> 
>    Although it is not specifically required by the SMI, it is 
> customary
>    (and strongly RECOMMENDED) that object definitions not be 
> registered
>    beneath group definitions, compliance statements, capabilities
>    statements, or notification definitions.  It is also customary (and
>    strongly RECOMMENDED) that group definitions, compliance 
> statements,
>    capabilities statements, and notification definitions not be
>    registered beneath object definitions.
> 
> Any objections?
> 
> //cmh
> 
>