Re: OID motion

["Geoff Thompson" <gthompso@nortelnetworks.com>]

Tony-

If we are willing to claim that we are ISO track on our standards (which
always "used" to be the case then the problem is already solved
although one could argue that it is SC6 that has the root instead of
802.

I offer the following quote from IEEE Std. 802.3q - 1993
"...
REGISTERED
AS

   

{iso(1)std(0)iso8802(8802)csma(3)mauMgt(20)nameBinding(6)repeaterName(205)};"

All 802.3 OIDs whether they have this root or our "other
one":
"...
REGISTERED
AS

   

{iso(1)member-body(2)us(840)802dot3(10006)mauMgt(20)nameBinding(6)repeaterName(205)};"

in either case they are designed to be compatible (as you well know) from
the common point down to the end of the leaf. It is just that we have 2
different possible roots, each of which are expected to produce the same
result in any implementation, i.e.
[[iso(1)std(0)iso8802(8802)csma(3)...]] is intended to produce exactly
the same result as [[iso(1)member-body(2)us(840)802dot3(10006)...]] in
all cases.

We can either continue the SC6 based system or add (sigh) yet another
root which I would assume would be of the form:
"...
REGISTERED
AS

   

{iso(1)member-body(2)us(840)ieee802(????)csma(3)mauMgt(20)nameBinding(6)repeaterName(205)};"

Geoff

At 11:26 AM 10/24/00 +0100, Tony Jeffree wrote:

DISCUSSION

802.1 is currently developing a MIB for our Port Access Control standard (P802.1X), and in order to complete the work, we will need to identify a suitable Object Identifier (OID) arc to hang the MIB under.  Past practice with 802 standards that need to allocate OID values (for MIBs and for other purposes) has been to request ANSI to allocate an OID root on a per-standard basis; for example, 802.1B has its own OID root, and 802.3 (for historical reasons) seems to have 2 root OIDs allocated to it.

When discussing this need relative to 802.1X, the 802.1 WG felt that it would be a "service to the community" to request ANSI to allocate an OID root for the whole of 802; within 802 we could then allocate arcs off that root for any 802 working groups that do not already have their own OID roots allocated (and to the other WGs too, if they have a need for them), and having allocated an arc per working group, the WG could then allocate below that arc per type of use...and so on.

To give an example of how this would work, to fix 802.1X's problem, we would have:

ieee802 ::= { iso(1) member-body(2) us(840) xxx } 
 - where xxx would be allocated to IEEE 802 by ANSI.

The next arc would be defined across 802 to identify the working group:

        ieee802dotN ::= { ieee802 N }
        -- where N is the working group number - 1, 3, 11, 14, 15, ....etc

so for 802.1:
        ieee802dot1 ::= { iee802 1 }

The next arc would be under the control of the WG, and would identify the type of use; for example, MIBs as distinct from OSI managed objects:

        ieee802dot1mibs ::= { iee802dot1 1 }
        ieee802dot1osiobjects ::= { iee802dot1 2 }
        ...etc.

All subsequent arcs would also be under the control of the WG.  In the case of the MIB arc, the next arc below would identify which MIB, ... and so on.

If the other WGs do not see a need for a common root OID, or prefer to continue using their existing allocations, or prefer to request ANSI for their own distinct OIDs, that's fine; 802.1 will request an allocation that meets 802.1's needs only.  However, as the above has the benefit of  avoiding the need for furthher requests to ANSI, it was felt appropriate to offer the above for discussion among the WG chairs.

MOTION:

The 802 Exec encourages 802.1 to proceed with a request to ANSI to allocate an OID root identifier for use across the whole of 802, as proposed in the above discussion document, and to allocate arcs under the root assigned by ANSI for use by all 802 working groups.

Regards,
Tony