[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guidelines Section 4.6.4 (OID Values Assigned to Objects)
- To: "Mreview (E-mail)" <mreview@ops.ietf.org>
- Subject: Re: Guidelines Section 4.6.4 (OID Values Assigned to Objects)
- From: "C. M. Heard" <heard@pobox.com>
- Date: Wed, 5 Feb 2003 13:43:39 -0800 (PST)
- Cc: Michael Kirkham <mikek@muonics.com>
- In-reply-to: <Pine.BSF.4.44.0302042113420.94680-100000@slepton.muonics.com>
On Wed, 5 Feb 2003, Michael Kirkham wrote:
> | 4.6.4. OID Values Assigned to Objects
> ..
> | - A conceptual row has as many subordinate objects as there are
> | columns in the row; there MUST be at least one. The OID assigned
> | to each columnar object MUST be derived by appending a non-zero
> | sub-identifier, unique within the row, to the OID assigned to the
> | conceptual row.
>
> I think it would be a good idea to clarify this to say "...there MUST be
> at least one [that is accessible for read operations]." A table having
> one column, that is not-accessible or accessible-for-notify, still doesn't
> make a valid table.
I'm not sure that would add much value. I think Bert (in his off-line
response) said the same thing.
> 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 might go a little easier
> on objects under OBJECT-GROUPs, perhaps with a lowercase "should not" or
> "SHOULD NOT ... if there is any foreseeable possibility of new objects
> being defined and placed in a new group containing the objects of the old
> group". It might make some amount of organizational sense and be tempting
> to place objects under the object groups they're in, but it pretty much
> breaks that organization if any new objects are defined and grouped with
> the old. If that weren't a problem, then I would be inclined to suggest
> that objects *do* get defined under groups, but it can be a problem so I
> don't.
>
> 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 incluce 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).
In any case, I don't think that registering objects underneath of
OBJECT-GROUPs is something we want to even give a hint of encouraging,
so if we say anything at all, we should not go any easier on that
practice.
//cmh