[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Place Holders
HI,
Mike brings up an issue that I had long forgotten. Years ago, I made
a proposal for a "delegation" construct so that the "hand off" of
authority was clear with OID assignments.
Presently, today the best way to do this is an OBJECT-IDENTITY in
a MIB module delegation by the owner of the parent OID, and then
an IMPORTS by the owner of the child. However, if you don't
want to "burn a level of OIDs", then only one side can use
a construct.
That is, if you do some thing like
Approach 1:
IANA-ENTERPRISE-ASSIGNMENTS DEFINITION ::= BEGIN
...
del2Ent1194 OBJECT-IDENTITY
...
DESCRIPTION "Enterprise assignment for MIBs4You"
::= { enterprises 1194 }
...
END
MIBS4YOU-ROOT DEFINITIONS ::= BEGIN
IMPORTS
del2Ent1194 FROM IANA-ENTERPRISE-ASSIGNMENTS
....
;
<definitions under 1194>
END
Approach 2:
IANA-ENTERPRISE-ASSIGNMENTS DEFINITION ::= BEGIN
...
del2Ent1194 OBJECT IDENTIFIER ::= { enterprise 1194 }
...
END
MIBS4YOU-ROOT DEFINITIONS ::= BEGIN
IMPORTS
enterprises FROM SNMPv2-SMI
....
;
MIBS4YOUROOT OBJECT-IDENTITY
....
::= { enterprises 1194 }
<definitions under 1194>
END
With the delegation construct, you may have something like:
IANA-ENTERPRISE-ASSIGNMENTS DEFINITION ::= BEGIN
...
del2Ent1194 OBJECT-DELEGATION
STATUS current
WHEN "199509130000Z"
ORGANIZATION "MIBs4You"
CONTACT-INFO "...."
::= { enterprise 1194 }
...
END
MIBS4YOU-ROOT DEFINITIONS ::= BEGIN
IMPORTS
enterprises FROM SNMPv2-SMI
....
;
MIBS4YOUROOT OBJECT-IDENTITY
....
::= { enterprises 1194 }
<definitions under 1194>
END
(note that two constructs have value { enterprises 1194 })
At 12:46 PM 7/5/2003 -0700, C. M. Heard wrote:
>>>>>> On Thu, 3 Jul 2003, Andy Bierman wrote:
>Andy> At 12:10 AM 7/3/2003, Romascanu, Dan (Dan) wrote:
>Andy> >Why should we leave them in? I understand that this is legal
>Andy> >SMI, but this smells like documented OID sparseness. One of the
>Andy> >MIBs I authored lately received a comment from the MIB Doctor
>Andy> >concerning OID sparseness. That one was caused as it often
>Andy> >happens because of the evolution of the MIB, some OIDs being
>Andy> >removed in the process, because the WG decided not to implement
>Andy> >the objects. I fail to see the difference. If OID sparseness is
>Andy> >a bad thing, we should avoid creating such cases by reserving
>Andy> >OIDs for 'future use'.
>Andy>
>Andy> Maybe the WG is going to implement objects under the placeholder
>Andy> OID later. In any case, this is a totally trivial problem.
>Andy> It doesn't matter either way. This has no impact on implementation.
>Andy> This is just MIB style, about as important as the number of
>Andy> spaces you should indent before starting a comment.
>
>There is one significant drawback to using placeholder OIDs if they are
>intended to be used for objects defined in a separate document: it is
>a lot easier to make transcription errors (e.g., erroneously importing
>an OID descriptor defined in the "base" document into two "extension"
>documents) when OIDs are managed this way than it is when all OIDs in a
>given MIB module have a prefix unique to that module, namely the module's
>the MODULE-IDENTITY value, whichis usually assigned by the IANA. Recall
>the discussion on the mreview@ops.ietf.org list regarding WG-assigned
>vs. IANA-assigned OID "roots".
>
>Having said that, I agree 100% with the following:
>
>>>>>> On Thu, 3 Jul 2003, Romascanu, Dan (Dan) wrote:
>Dan> Thanks. This looks like a wise and balanced approach. Thanks to
>Dan> everybody for the time and bandwidth consumed on advising on
>Dan> this (rather minor) issue. Dan
>Dan>
>Dan>
>Dan> > -----Original Message-----
>Dan> > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
>Dan> > Sent: 03 July, 2003 2:57 PM
>Dan> > To: Andy Bierman; Romascanu, Dan (Dan)
>Dan> > Cc: Robert Moore; Harrington, David; mibs@ops.ietf.org
>Dan> > Subject: RE: Place Holders
>Dan> >
>Dan> >
>Dan> > I personally do not like such/any non-specific reserved OID
>Dan> > branches. Neither do I like spareseness in OID assignment.
>Dan> > And so I always mention it when I see it and ask: why?
>Dan> > And suggest: would it not be better to make it contiguous
>Dan> > (certainly at PS time this is the last time it can
>Dan> > easily be done).
>Dan> >
>Dan> > But as stated before, it is not a violation. So Dan, I would
>Dan> > point it out to the authors and WG and suggest to them to
>Dan> > (re-)consider if this is wise/wanted. Not that it would block
>Dan> > further progress of the document.
>Dan> >
>Dan> > Thanks,
>Dan> > Bert
>
>//cmh