[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guidelines Section 4.6.4 (OID Values Assigned to Objects)
>>>>> On Sun, 16 Feb 2003, C. M. Heard wrote:
C> I propose to add the following paragraph at the end of Section 4.6.4:
C>
C> Although it is not specifically required by the SMI, it is customary
C> (and strongly RECOMMENDED) that object definitions not be registered
C> beneath group definitions, compliance statements, capabilities
C> statements, or notification definitions. It is also customary (and
C> strongly RECOMMENDED) that group definitions, compliance statements,
C> capabilities statements, and notification definitions not be
C> registered beneath object definitions.
C>
C> Any objections?
>>>>> On Mon, 17 Feb 2003, Wijnen, Bert (Bert) replied:
B> I do not have a strong objection.
B>
B> At the other hand, I am not aware that we have had
B> these type of problems in (IETF) MIB documents, so
B> it seems to add stuff that is (mostly) not needed?
>>>>> On Mon, 17 Feb 2003, Michael Kirkham rejoined:
M> At any rate.. I brought this item up only because the other
M> sections of the document contained similar wording, but the
M> section for objects didn't. It should be consistent, if nothing
M> else, IMHO. If you leave it out of the objects section, it
M> should probably be left out of the others as well. I think you
M> should leave it in, though, given the problems it causes beyond
M> simple compatibility with broken tools.
I completely agree with Mike Kirkham regarding consistency in
the document. That is, either the propose paragraph or some
equivalent should go in, or else the comparable stuff that is
present in the notifications section (4.7) needs to go out.
Unless I receive further comments I will probably leave the
material in, but I have to confess to a lot of ambivalence.
Only once have I made any comments in a MIB review about OID
tree organization, and that was not for the specific sins
preached against here but for some rather different sins.
//cmh