RE: Review comments on draft-ietf-bridge-bridgemib-smiv2-07.txt

"C. M. Heard" <[email protected]> Fri, 31 Dec 2004 10:48:40 -0800 (PST)
Newsgroups gmane.ietf.bridge
Message-ID <[email protected]>
On Thu, 30 Dec 2004, David B Harrington wrote:
> For the SMI experts amongst us, can we legally register the
> MODULE-IDENTITY in the following way?
> 
> dot1dBridge MODULE-IDENTITY
> 	...
> 	::= { mib-2 17 }
> 
> RFC1493 registered dot1dbridge using "dot1dbridge OBJECT IDENTIFIER
> ::= { mib-2 17 }"
> Juergen pointed out that the SMIv2-to-SMIv1 translation of a
> MODULE-IDENTITY is simply an OID, so this might be legal.

This is legal.  The effect is to associate a registration, as well as
an OID value, with the descriptor dot1dBridge, but the semantics
remain unchanged, and any MIB module that imports the descriptor will
continue to compile, and all subordinate OIDs will resolve to the same
value as before.  Note that RFC 2578 Section 3.6 explicitly allows the
same descriptor to be associated with a registration and an assignment:

   A descriptor is allowed to be associated with both a registration and
   an assignment, providing both are associated with the same OBJECT
   IDENTIFIER value and semantics.

For some precedents, the following definition in RFC 1406

   ds1 OBJECT IDENTIFIER ::= { transmission 18 }

has been translated to

   ds1 MODULE-IDENTITY
   ...
   ::= { transmission 18 }

in RFCs 2495 and 3895 and the following definition in RFC 1407

   ds3  OBJECT IDENTIFIER ::= { transmission 30 }

has been translated to

   ds3 MODULE-IDENTITY
   ...
   ::= { transmission 30 }

in RFCs 2496 and 3896.

> If we can do this, it would move the mib up under mib-2, and eliminate
> the forward reference (issue #757). 
> It would also place the object and notification subtrees under the
> dot1dBridge MODULE-IDENTITY, approximating the recommended practices
> from draft-ietf-ops-mib-review-guidelines Suggested OID layout. 

All of these sound to me like Good Things.

Mike Heard