[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: use of OBJECT-IDENTITY



On Wed, 17 Mar 2004, Wijnen, Bert (Bert) wrote:
> Juergen answers me:
> > 
> > 
> > On Wed, Mar 17, 2004 at 04:44:04PM +0100, Wijnen, Bert (Bert) wrote:
> > 
> > > In draft-ietf-dhc-server-mib-10.txt I see the use of
> > > OBJECT-IDENTITY that I think was not intended.
> > 
> > I agree. But I think there is nothing in the written SMI that renders
> > this illegal. 
> 
> I know, and that is why I bring it to MIB Doctors list. TO try and get
> some discussion and to try and come up with a common/consistent answer
> that we should gibve when we see this type of use.

If I saw this usage in a MIB module I would point out to the authors
that it is customary to use simple OID value assignments (rather than
the OBJECT-IDENTITY construct) to define sub-branches in a MIB module,
and I would suggest (but but not insist) that they follow this custom.

I think that it is justified to suggest that that people follow
long-established stylistic customs precisely so that a reader of
the MIB module does not need to ask the the question "why on earth
did they do that?"  On the other hand, since the usage is not actually
illegal or harmful, it would be hard to justify telling someone that
the MIB module could not be published unless it was changed to follow
the custom.

I would not object to putting something about this in the MIB review
guidelines when I spin the -03 update (I've promised to set aside
some time early in April to do that).  We do have some similar things
in there, such as saying that Unsigned32 is preferred for variables
that cannot be negative, but Integer32 is allowed.  As long as we
don't make these things more than a suggestion (rather than SHOULDs
or MUSTs) I don't think we would be manufacturing CLRs.  (Of course,
we MIB Doctors would in practice to be bound to follow our own
suggestions in any IETF MIB modules that we edit :-)

> > This usage of the OBJECT-IDENTITY macro also raises 
> > interesting questions what the status clause really means for the
> > things registered on that branch...
> > 
> It seems that the branch should always stay current and that stuff
> underneed it may get deprecated or obsoleted. Would that not work?

Yes, that would work.  But I think it would be OK to deprecate or
obsolete the OBJECT-IDENTITY definition if there was a conscious
intent to deprecate or obsolete the entire branch (i.e., deprecate
or obsolete all stuff underneath and not define any new stuff).
For an example when that might apply see RFC 1406 and RFC 1232.

Mike