[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