Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

OID motion



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