Re: OID motion
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
- References:
- OID motion
- From: Tony Jeffree <tony@jeffree.co.uk>