RE: Review comments on draft-ietf-bridge-bridgemib-s miv2-07.txt
"Wijnen, Bert (Bert)" <[email protected]> Mon, 3 Jan 2005 13:36:03 +0100
| Newsgroups | gmane.ietf.bridge |
|---|---|
| Message-ID | <7D5D48D2CAA3D84C813F5B154F43B1550604F2B2@nl0006exch001u.nl.lucent.com> |
> -----Original Message----- > From: [email protected] > [mailto:[email protected]]On > Behalf Of C. M. Heard > Sent: Friday, December 31, 2004 19:49 > To: [email protected] > Subject: RE: [Bridge-mib] Review comments on > draft-ietf-bridge-bridgemib-smiv2-07.txt > > > 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 I think Dave meant "dot1dBridge" (i.e. capital B) in the above > > ::= { 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. > Seems fine to me too. Bert > 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 > > > _______________________________________________ > Bridge-mib mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/bridge-mib >