Re: Question about draft-ietf-hubmib-rfc3636bis

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

I agree with Juergen, and believe that the Heard suggestion,
while technically illegal, is a VERY practical approach
to solve the problem. That is...

If have 
  AMOD DEFINITIONS ::= BEGIN
   ...
    aOI OBJECT-IDENTITY 
      ...
      :: = { foo 1 }
   ...
  END
And change to
  AMOD DEFINITIONS ::= BEGIN
   ...
    aOI OBJECT IDENTIFIER  :: = { foo 1 } -- change from OBJECT-IDENTITY
   ...
  END
  BMOD DEFINITIONS ::= BEGIN -- a new MIB MODULE
   ...
   aOI2 OBJECT-IDENTITY
     ...
     :: = { foo 1 }  -- reuse OID value
   ...
   END
is technically illegal, but practical.

However, the following is legal and practical, but maybe a
a little confusing, since the new MIB module, BMOD, would
have "OBJECT IDENTIFIER" specifications for old items,
and "OBJECT-IDENTITY" specifications for new items.
  AMOD DEFINITIONS ::= BEGIN
   ...
   aOI OBJECT-IDENTITY
     ...    
      :: = { foo 1 } -- no change from original
  ...
  END
  BMOD DEFINITIONS ::= BEGIN -- a new MIB MODULE
   ...
   -- The following OID value is defined in AMOD, but is
   -- defined here (with a different descriptor) so that
   -- all OID values can be contained in one MIB module
   aOI2 OBJECT IDENTIFIER :: = { foo 1 }  -- reuse OID value
                                               
   ...
   -- new items would use OBJECT-IDENTITY
   END
    
Regards,
/david t. perkins

On Mon, 18 Apr 2005, Juergen Schoenwaelder wrote:

> On Sun, Apr 17, 2005 at 09:20:35PM -0700, C. M. Heard wrote:
> 
> > First some background.  Historically, each standard MAU type has
> > been represented both as an OBJECT IDENTIFIER, which can figure as a
> > value for rpMauType, ifMauType, or ifMauDefaultType, and also as a
> > bit position in ifMauTypeListBits.  These values have been entered
> > directly into the MAU-MIB itself as a set of OBJECT-IDENTITY
> > definitions and as bit positions in the type for ifMauTypeListBits.  
> > The WG wants to move these into an IANA-maintained MIB module so
> > that it is not necessary to open up the MAU-MIB every time the IEEE
> > defines a new 802.3 phyisical layer variant.  So far so good, I
> > agree with this goal.
> 
> Has the option been considered to start an IANA module for all new
> assignments and to leave the existing assignments where they are?
> Sure, you would loose the freedom to deprecate/obsolete things
> via IANA actions but you would side-step the problem perhaps.
> 
> > There is, however, a potential backward compatibility issue in
> > moving the existing OBJECT-IDENTITY definitions out of the MAU-MIB,
> > namely that it would break any MIB modules that happened to import
> > those definitions from the MAU-MIB.  I suggested to the author to
> > turn the existing definitions as OBJECT IDENTIFIER assignments (as
> > permitted by RFC 2578 Section 3.6) so that they could continue to be
> > imported from the MAU-MIB.  That suggestion has, however, met with
> > some resistance:  it causes lots of smilint warnings, assuming that
> > default settings are used, and no one has been able to find any
> > example of a MIB module that imports one of the definitions in
> > question (for sure no IETF standard MIB module does so).
> > 
> > What would you other MIB Doctors advise in this case?
> 
> I believe that this decision at the end belongs to the WG. I think it 
> is important that the implications are brought to their attention and
> that the WG takes responsibility of the consequences. Furthermore, if 
> the WG finally decides to move things, I think it is important that 
> the updated document has clear instructions in the module that tell 
> people where definitions have moved to.
> 
> /js (who is in his "be flexible" mood today)
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany
>