Re: [802.1] TGi use of OUI 00-00-00
- To: "David Halasz" <email@example.com>
- Subject: Re: [802.1] TGi use of OUI 00-00-00
- From: "Hal Keen" <Hal.Keen@att.net>
- Date: Mon, 6 Oct 2003 13:40:04 -0500
- Cc: "Geoff Thompson" <firstname.lastname@example.org>, "Mike Moreton" <Mike.Moreton@synad.com>, "Tony Jeffree" <email@example.com>, "Johnston, Dj" <firstname.lastname@example.org>, <email@example.com>, "IEEE 802.1" <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org>, <email@example.com>
- References: <0D3F1B25E75EE24483A6E69201142C868B19BF@paris.synad.com> <firstname.lastname@example.org> <email@example.com>
- Reply-To: "Hal Keen" <Hal.Keen@att.net>
- Sender: firstname.lastname@example.org
This is a response to both Dave's and Mike's emails.
> This is a rather large email thread. Instead of answering your question
> directly, I would prefer to include the answer, in a summary of the email
Believe me, I know it's a large thread; I administer the 802.1 list.
I have been staying out of the argument over 802.11i, but if you have a
space which may be occupied by an OUI, you had darned well better not use
someone's OUI (including Xerox's) there without permission from the owner.
The RFC 1042 use was something for which IETF participants obtained
permission, long before it became necessary to document it in Standard 802.
As far as I know, Xerox did not give blanket participation to any and all
standards organizations to grab it for other uses.
As they did give permission for that use, I see nothing to be fixed in the
O&A. I'm still waiting for someone to point out anything that needs to be
fixed in 802.2 (and I searched it for references to "OUI" before my last
To employ OUIs in a new fashion, you need to get RAC approval and you need
to provide a tutorial on that particular use, which they can publish on the
web. These rules were put in place to ensure that various attempts to
"piggyback" new ideas on these useful identifiers did not produce conflicts.
Once you have done this, it seems simplest if table entries which are needed
for standards use be derived from the OUI already administered by 802.1. I
don't think anyone would object, if the process were correctly followed, and
that seems simpler to me than going begging to Xerox just because a zero
looks prettier than other numbers.
> 1) There is a complete absense of a useful OUI/EUI/whatever to enable
> standards to create selection tables with vendor proprietary entries. I
> certainly hope that the RAC assign one for this purpose at the next
> meeting since it's the least messy route to a solution for .11i, LinkSec
> and anything else comes along.
I doubt it. Whether the number that people think they can use with impunity
is all zeroes or some other value, they'll probably find some way to
infringe on each other's assignments. Instead, if you have a new use for an
OUI-derived identifier, why not do the right thing? Apply to the RAC for
permission to add this new use, and go to some standards organization which
already has an OUI for specific assignments needed in the standard. In the
LMSC's bailiwick, 802.1 is already in that business.
> 2) The extreme cunning with which the information on the use and nature
> of OUIs and EUIs has been hidden needs to be undone. Around the time
> that this thread started, I went searching the IEEE site to educate
> myself. I found the 802 document describing MAC addresses and OUIs and
> the RAC pages which provided a submission form and a list of assigned
> OUIs and not much else.
If you find your way to www.ieee.org, all you need is to guess that it has
something to do with "Standards" (one click on the navigation bar), and then
find "OUI" (another click that page's nav bar). A third click on a link
labeled "OUI tutorials" gets you to a list:
CDPD (Cellular Digital Packet Data) Manufacturer Identifier
Control and Status Register (CSR) Architecture
Futurebus+ Physical Layer and Profiles
Local and Metropolitan Area Networks
Scalable Coherent Interface
Guidelines for Use of EUI
Guidelines for Fibre Channel Use of the Company_id
I hardly think this information could be any more in plain sight than it is.