Internet DRAFT - draft-ieee-rac-oui-restructuring
draft-ieee-rac-oui-restructuring
IEEE RAC G. Parsons
Internet Draft Ericsson
Intended status: Informational September 6, 2013
Expires: April 2014
OUI Registry Restructuring
draft-ieee-rac-oui-restructuring-01.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be
modified, and derivative works of it may not be created, and it
may not be published except as an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 9, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Parsons Expires April 9, 2014 [Page 1]
Internet-Draft OUI Registry Restructuring September 2013
carefully, as they describe your rights and restrictions with
respect to this document.
Abstract
The IEEE Registration Authority Committee, which has oversight
for the OUI based registries, is seeking IETF community input as
it finalizes restructuring the OUI registries. This document
provides background on the RAC as well as explaining the proposed
restructuring and the rationale.
Table of Contents
1. Introduction...................................................3
1.1. History of the IEEE RA and RAC............................3
1.2. Mission Statement of the IEEE RAC.........................4
2. Existing OUI based registries..................................4
2.1. OUI.......................................................6
2.2. OUI-36....................................................7
2.3. IAB.......................................................7
3. Common identifiers.............................................8
3.1. EUI-48....................................................8
3.2. EUI-64....................................................8
3.3. Company ID / Protocol identifier..........................8
4. Preventing exhaustion..........................................9
4.1. IEEE RAC Prime Directive..................................9
4.2. New devices..............................................10
4.3. Assignment efficiencies..................................10
4.3.1. MAC (EUI48) Addressing..............................10
4.3.2. Company ID..........................................10
4.4. Virtualization...........................................10
4.4.1. Reusing addresses...................................11
4.4.2. EUI-128 addresses...................................11
5. Proposed new OUI-based registries.............................12
5.1. OUI-24: MAC Addresses - Large............................14
5.2. OUI-28: MAC Addresses - Medium...........................14
5.3. OUI-36: MAC Addresses - Small............................15
5.4. CompanyID................................................15
5.4.1. Application Note....................................16
6. Protocol Considerations.......................................16
7. Security Considerations.......................................16
8. IANA Considerations...........................................16
9. Conclusions...................................................17
10. References...................................................17
10.1. Normative References....................................17
Parsons Expires April 9, 2014 [Page 2]
Internet-Draft OUI Registry Restructuring September 2013
10.2. Informative References..................................17
11. Acknowledgments..............................................17
1. Introduction
The IEEE Registration Authority (RA) operates under the direction
of the IEEE-SA Board of Governors. IEEE is recognized by ISO/IEC
as the authorized Registration Authority to provide this service
world-wide. The IEEE Registration Authority Committee (RAC)
provides technical oversight for the IEEE Registration Authority
Activities.
The IEEE RA administers the assignment of 24-bit identifiers,
formally known as an "Organizationally Unique Identifier" (OUI).
It can be used alone as an identifier, or used to create MAC
Addresses, Bluetooth Device Addresses or Ethernet Addresses.
Given the possibility of consuming all the MAC addresses, the
IEEE RAC places restrictions on their use. While the number
space is large, it is not inexhaustible, and the IEEE-RAC reviews
trends to determine if a new strategy is required to prevent
exhaustion. Current usage trends and new applications have
convinced the RAC that measures are needed to more efficiently
use the MAC address space. This document presents the background
as well as the proposed changes to the OUI registries.
1.1. History of the IEEE RA and RAC
The IEEE Registration Authority (RA) was formed by the IEEE
Standards Board in 1986 at the initiative of the IEEE P802
(LAN/MAN) standards group in order to register Organizationally
Unique Identifiers (OUI). Since that time, the activities of the
Registration Authority have continued to expand.
The IEEE Registration Authority Committee (IEEE RAC) was formed
in 1991 as a volunteer oversight of the IEEE staff operated RA.
In 1998, the IEEE RAC became a committee of the IEEE Standards
Association Board of Governors, (IEEE SA BoG).
In 1997, the IEEE Registration Authority assumed responsibility
for the registration of EtherType Fields, as defined in the
current edition of IEEE Std 802.3, and in 1998 began
administering Individual Address Block assignments in an effort
to preserve the OUI assignments and offer the option of obtaining
a smaller amount of addresses.
Parsons Expires April 9, 2014 [Page 3]
Internet-Draft OUI Registry Restructuring September 2013
In 2003, it assumed responsibility for administering, allocating
and managing the Logical Link Control (LLC) and Standard Group
MAC addresses. IEEE has become the single point of contact with
respect to all information associated with LAN addresses.
In 2004, IEEE established three registration authorities
associated with IEEE 1451.4-2004. They are:
o Unique Registration Numbers (URNS)
o IEEE Templates and TDL Items
o Manufacturer_ID
On 27 April 2007, three additional registries were launched.
Unlike the registries launched in 2004, each registry represents
a different IEEE standard.
o OUI-36
o IEEE 802.16 Operator ID
o Provider Service Identifier (PSID)
The IEEE Registration Authority formerly had administrative
responsibility for the IEEE POSIX Certification.
1.2. Mission Statement of the IEEE RAC
The IEEE Registration Authority Committee (IEEE RAC) is the
oversight committee for the IEEE Registration Authority.
The IEEE RAC is international in scope, assisting standard
developing organizations in their establishment of unambiguous,
sustainable registration authorities.
The IEEE RAC considers the long-term interests of the ultimate
users of these standards, while pragmatically addressing the
needs of the affected organizations, industries, and the IEEE.
2. Existing OUI based registries
The OUI ("Organizationally Unique Identifier") is defined in IEEE
Std 802-2001 [1] and its structure is shown in Figure 1 below
Parsons Expires April 9, 2014 [Page 4]
Internet-Draft OUI Registry Restructuring September 2013
with an example for use as a protocol identifier shown in Figure
2.
Application dependent:
| e.g., I/G or U/L
| address bit, or
| M or X bit in
| protocol ID
|
+-----+
| |
+----+----+----+----+----+----+-+--+--+-+
Octet 0 | | | | | | | | |
|----+----+----+----+----+----+----+----+
Octet 1 | | | | | | | | |
|----+----+----+----+----+----+----+----+
Octet 2 | | | | | | | | |
+----+----+----+----+----+----+----+----+
Figure 1 - Structure of an OUI
Of note is that only 22 bits are actually assigned as there are
specific uses for the first two bits transmitted (the two least
significant bits of octet 0). As a MAC address, the first bit
transmitted indicates either an individual or group address
(I/G), and the second bit transmitted indicates universal or
local administration of the address (U/L). When used as a
protocol identifier (Figure 2), these bits are the M and X bits.
As a result of these uses, all previous OUI assignments have set
these two bits to 0.
Parsons Expires April 9, 2014 [Page 5]
Internet-Draft OUI Registry Restructuring September 2013
Hexadecimal representation: AC-DE-48
Octet: 0 1 2 +--X bit
|+-M bit
LSB MSB LSB MSB +------+++
| | | | Octet 0 |10101100|
| | | | Octet 1 |11011110|
0011 0101 0111 1011 0001 0010 Octet 2 |01001000|
|| +--------+
|+--X bit
+---M bit
Figure 2 - Format of an OUI used as protocol identifier
While the majority of customers purchase the OUI, there are
currently three OUI based registries:
1. OUI
2. OUI-36
3. IAB
The latter two use an IEEE reserved OUI from the first registry
as their root.
These registries support the standards of IEEE 802 as well as
ISO/IEC 8802 and other standards that use unique LAN addresses.
IEEE has been authorized by the ISO Council to act as the
exclusive registration authority for the implementation of
International Standards in the ISO/IEC 8802 series.
2.1. OUI
An OUI or 'company_id' is a 24-bit globally unique assigned
number referenced by various standards. The OUI is usually
concatenated with 24 or 40 bits by an Organization to create a
48-bit or 64-bit number that is unique to a particular piece of
hardware. It can be used to create MAC Addresses, Bluetooth
Device Addresses or Ethernet Addresses.
There are other uses of the OUI as well, such as its use as a
company identifier in the SNAP protocol.
Parsons Expires April 9, 2014 [Page 6]
Internet-Draft OUI Registry Restructuring September 2013
The OUI or 'company_id' can be used in conjunction with a number
of standards. It does not limit your right to use your assignment
for both OUI and 'company_id' purposes.
Additional information can be found on the IEEE RA website:
http://standards.ieee.org/develop/regauth/oui/index.html
2.2. OUI-36
OUI-36 is a 36-bit identifier that can be used as an Individual
Address Block (IAB) or as an extended OUI. The OUI-36 may be
appended with four organization-supplied bits to form a 40-bit
Context Dependent Identifier (CDI-40), with twelve organization-
supplied bits to form an EUI-48, or with organization-supplied 28
bits to form an EUI-64. Applications making use of an OUI-36
should make no assumptions about the bit pattern that will be
present in the (24-bit most-significant) OUI portion of the
assigned OUI-36.
Additional information can be found on the IEEE RA website:
http://standards.ieee.org/develop/regauth/oui36/index.html
2.3. IAB
An IAB is for organizations that need less than 4097 unique 48-
bit numbers (EUI-48) and thus find it hard to justify buying
their own OUI. It is a particular OUI concatenated with 12
additional IEEE-provided bits, leaving only 12 bits for the
owners to assign to their (up to 4096) individual devices.
Unlike an OUI, which allows the assignee to assign values in
various different number spaces (for example, EUI-48, EUI-64, and
the various CDI number spaces), the IAB can only be used to
assign EUI-48 identifiers.
The Individual Address Block (IAB) can be used in conjunction
with a number of standards. It does not limit your right to use
your assignment for multiple purposes.
Additional information can be found on the IEEE RA website:
http://standards.ieee.org/develop/regauth/iab/index.html
Parsons Expires April 9, 2014 [Page 7]
Internet-Draft OUI Registry Restructuring September 2013
3. Common identifiers
The OUI defined in IEEE Std 802-2001 [1] can be used to generate
48-bit Universal LAN MAC addresses to uniquely identify Local and
Metropolitan Area Networks stations, and Protocol Identifiers to
identify public and private protocols. A revision [3] of this
standard is underway (expecting to complete in late 2013) that
will, among other updates, also describe the 64-bit address.
3.1. EUI-48
The IEEE defined 48-bit extended unique identifier (EUI-48) is a
concatenation of either a 24-bit Organizationally Unique
Identifier (OUI) value administered by the IEEE Registration
Authority (IEEE-RA) and a 24-bit extension identifier assigned by
the organization with that OUI assignment, or the concatenation
of a 36-bit Individual Address Block (IAB) identifier /or 36-bit
Organizationally Unique Identifier (OUI-36)/ and a 12-bit
extension identifier assigned by the organization with that IAB
assignment.
Additional information can be found on the IEEE RA website:
http://standards.ieee.org/develop/regauth/tut/eui48.pdf
3.2. EUI-64
The IEEE-defined 64-bit extended unique identifier (EUI-64) is a
concatenation of the Organizationally Unique Identifier (OUI)
value assigned by the IEEE Registration Authority (IEEE RA) and
the extension identifier assigned by the organization with that
OUI assignment resulting in a 64-bit unique identifier. The
extension identifiers shall be 40 bits for the 24-bit OUI-24 and
28 bits for the 36-bit OUI-36. Other OUI lengths will have
extension identifiers making up the difference between each
assigned OUI length and the 64-bit EUI-64.
Additional information can be found on the IEEE RA website:
http://standards.ieee.org/develop/regauth/tut/eui48.pdf
3.3. Company ID / Protocol identifier
IEEE Std 802 provides for the use of Protocol Identifiers in
conjunction with the SNAP/SAP reserved LLC address. A Protocol
Identifier is defined as a sequence of five octets. The first
Parsons Expires April 9, 2014 [Page 8]
Internet-Draft OUI Registry Restructuring September 2013
three octets take the values of the three octets of the OUI in
order; the following two octets are administered by the OUI
assignee. The hexadecimal representation of the Protocol
Identifier consists of the hexadecimal values of the five octets
in order, separated by hyphens, in the order transmitted by the
network application, left to right.
Additional information can be found on the IEEE RA website:
http://standards.ieee.org/develop/regauth/tut/lanman.pdf
4. Preventing exhaustion
Given the possibility of consuming all the MAC addresses, the
IEEE RAC places restrictions on their use. For new applications,
EUI-48 identifiers are restricted to use in low volume
applications, such as the identification of software interface
standards or hardware model numbers.
While the number of EUI-48 identifiers is large, it is not
inexhaustible, and the IEEE-RAC reviews trends to determine if a
new strategy is required to prevent exhaustion. Current usage
trends and new applications have convinced the RAC that measures
are needed to more efficiently use the EUI-48 address space.
4.1. IEEE RAC Prime Directive
A "prime directive" of the IEEE RAC is to not run out of global
EUI-48 addresses (previously called MAC or MAC-48 addresses) for
100 years. The clock started in 1980 when this space was created
by Xerox (and was called Block ID at the time).
In about 30 years, less than 20,000 OUIs have been assigned. So
if the growth is linear, there is more than 99% of the space
left, giving the world a 4000 year supply. However, the growth
trend from last few years is not linear. If that trend
continues, then there is only 26 years left before exhaustion of
OUIs and global address space they are used to create. The IEEE
RAC is studying these trends and has considered several possible
causes.
Parsons Expires April 9, 2014 [Page 9]
Internet-Draft OUI Registry Restructuring September 2013
4.2. New devices
There has been an increase in new device categories in the last
several years - including smart phones, tablets and various
sensors - all that have more than one network interface (e.g.,
WiFi, Bluetooth, Ethernet) that requires a MAC address.
In addition, there are a few manufacturers that are volume users.
That is, they are using more than 32 million MAC (EUI-48)
addresses per month.
4.3. Assignment efficiencies
Most manufacturers, however, use far less MAC (EUI-48) addresses
per month. They either have a smaller production volume or are
just starting. And actually, most OUI customers have only bought
one OUI. If they need only MAC addresses, then they could
benefit from options that would offer them fewer.
This would reduce the many "lost" or "unused" MAC addresses from
OUIs that were assigned but the manufacturer did not use the full
16 million.
4.3.1. MAC (EUI48) Addressing
~260 billion EUI-48 (of ~70 trillion possible) addresses have
been assigned. While the RAC knows these have not all be used in
devices, there is no way to confirm this. The RAC does however,
require that repeat customers confirm that they have used 95% of
the addresses before they are assigned another OUI block.
The RAC requires that only one (or at most a few) global EUI-48
addresses be assigned to a single hardware device. This is to
avoid stockpiling of addresses in devices. However, this may be
problematic for some applications like virtualization
4.3.2. Company ID
In order to get a Protocol identifier or company ID, an OUI must
be assigned. If the manufacturer does not intend to use it for
addressing, then those addresses are lost.
4.4. Virtualization
Virtualization from the IEEE RAC perspective is essentially the
usage of global MAC (EUI-48) addresses by software - instead of
Parsons Expires April 9, 2014 [Page 10]
Internet-Draft OUI Registry Restructuring September 2013
by a hardware device (i.e., "burned in") as was originally
intended.
Traditionally the RAC limited manufacturers to only a few
addresses per hardware device to prevent stockpiling addresses in
devices. This would invalidate virtualization solutions. As a
result, the RAC is now allowing assignment of an OUI (16M EUI-48
addresses) for virtualization use until a further policy is
clarified.
One requirement for virtual machines is that they are mobile and
can be moved around on a rack, within a data center or even
across data centers. Such movement in a multi-vendor environment
requires a globally unique MAC (EUI48) address to be scalable.
4.4.1. Reusing addresses
However, another inherent nature of virtualization is the
creation and destruction of the virtual machine. Hundreds,
thousands or millions can be created or destroyed per second in a
data center. If kept in a closed environment, this requires a
local or reusable MAC (EUI48) address. If a global address is
used, then they could be used at an alarming rate as they are not
defined as reusable.
Unfortunately, there appears to be violation of the IEEE RAC
policy in the virtualization sector. That is, some are using
global MAC (EUI-48) addresses per rack / cluster / data center
and then reusing them in an adjacent rack / cluster / data
center.
Clearly this is not permitted and the RAC has been studying what
guidance should be given to virtualization vendors such that the
global MAC address space is not tainted.
It has been suggested that a DHCP-like mechanism or a standard
allocation should be developed for reusable MAC addresses such
that there is some order to assignment in an environment where
addresses are created and destroyed.
4.4.2. EUI-128 addresses
Given the potential for using a large number of addresses, the
RAC is also exploring the feasibility of defining a new "EUI-128"
identifier (i.e., 128 bits) specifically for future
virtualization applications.
Parsons Expires April 9, 2014 [Page 11]
Internet-Draft OUI Registry Restructuring September 2013
5. Proposed new OUI-based registries
The IEEE RAC has been studying options to restructure the OUI-
based registries and products for over a year and is now
reviewing a final proposal. This proposal provides a refinement
of the OUI-based registries improves efficiency of assignment
allocations and attempts to address virtualization issues.
While there was some desire for the OUI registries to fully
separate the semantic of protocol identifier (e.g., the 24 bits
assigned) and addresses (e.g., a 48-bit address created based on
the 24 bits assigned), the concern raised was that this was not
enforceable by definition.
The IEEE RAC conducted a survey of its customers and it quickly
became clear that there were first-time customers (and in most
cases they never made another purchase) and repeat customers
(many of who were volume users). It was also very clear that the
dominant use was to create global MAC (EUI48) addresses. As a
result, the assignment decisions could be separated as proposed
in Figure 3 below.
Parsons Expires April 9, 2014 [Page 12]
Internet-Draft OUI Registry Restructuring September 2013
Customer Type Requirements for IDs
''''''''''''' ''''''''''''''''''''
+------------------------+
| |
''''' Company ID only |
| | |
| +------------------------+
|
| +------------------------+
| | MAC Addresses and |
+-----------+ |---| other unique IDs only |
| First- | | | |
| time |____| +------------------------+
|''''''''| Customers | |
| | | | +------------------------+
| +-----+-----+ | | Combined Company ID |
| |...| and MAC Addresses or |
| | other IDs |
| +------------------------+
,--+--.
,' `.
,' `.
; Customer :
| Decision |
: Tree ;
`. ,'
`. ,'
`-----' +------------------------+
| | MAC Addresses and |
| |--| other unique IDs only |
| +-----------+ | | |
| | Repeat | | +------------------------+
| | Customers | |
|--------| ''''''|
| | | +------------------------+
+-----------+ | | Combined Company ID |
|..| and MAC Addresses or |
| other IDs |
+------------------------+
Figure 3: Decision Tree for assignment of Unique IDs/MAC
addresses
The proposal that the IEEE RAC is considering is to add an
additional size option for creating MAC (EUI48) addresses -- 1
million -- as well as creating a new CompanyID registry. This is
Parsons Expires April 9, 2014 [Page 13]
Internet-Draft OUI Registry Restructuring September 2013
shown in Table 1 below and described in the following sub-
sections.
Table 1: New Proposed OUI-based Product Registries
+-------------------+------------+-------------------+
|Manufacturer field |Product |EUI48(MAC)addresses|
+-------------------+------------+-------------------+
| 24-bit identifier |OUI-24/MA-L |16777216 |
+-------------------+------------+-------------------+
|- |OUI-28/MA-M |1048576 |
+-------------------+------------+-------------------+
| 36-bit identifier |OUI-36/MA-S |4096 |
+-------------------+------------+-------------------+
| 24-bit identifier |CompanyID |- |
+-------------------+------------+-------------------+
5.1. OUI-24: MAC Addresses - Large
The OUI-24 is a 24-bit globally unique assigned number.
This is the base OUI registry. It is simply a renaming of the
existing OUI registry.
An assignment from this registry includes the ability to create:
o 24-bit company ID / protocol identifiers
o 48-bit EUI48 addresses
o 64-bit EUI64 addresses
5.2. OUI-28: MAC Addresses - Medium
The OUI-28 is a 28-bit globally unique assigned number.
This new OUI-28 is created by the IEEE RA by assigning an
additional 4 bits from an OUI-24 (that would be listed as IEEE
reserved).
An assignment from this registry includes the ability to create:
o 48-bit EUI48 addresses
Parsons Expires April 9, 2014 [Page 14]
Internet-Draft OUI Registry Restructuring September 2013
o 64-bit EUI64 addresses
Note that the IEEE RAC does not intend to define the usage of a
28-bit company ID / protocol identifier at this time.
5.3. OUI-36: MAC Addresses - Small
The OUI-36 is a 36-bit globally unique assigned number.
The OUI-36 is created by the IEEE RA by assigning an additional
12 bits from an OUI-24 (that is listed as IEEE reserved).
This is the existing OUI-36 registry, and it is proposed to merge
the IAB registry with this as well.
An assignment from this registry includes the ability to create:
o 36-bit company ID / protocol identifiers
o 48-bit EUI48 addresses
o 64-bit EUI64 addresses
5.4. CompanyID
The CompanyID is a 24-bit globally unique assigned number.
However, any MAC addresses created with this Company ID would
only be locally significant (i.e., the U/L bit is set to 1)
This new CompanyID is created by the IEEE RA assigning an OUI
with the X bit set to 1 (this bit becomes the U/L bit when used
to create a MAC address). Traditionally, this use has been
reserved to separate the local and global address spaces but no
use had been defined for protocol identifiers. It is proposed
that only a segment (e.g., the bottom half) of the potential 22-
bit space be made available for allocation.
An assignment from this registry includes the ability to create:
o 24-bit company ID / protocol identifiers
NOTE: This requires that legacy uses of the OUI in protocols do
not try to define the M and X bits for other uses. The RAC is
not aware of any standard uses of the M and X bits that would
prevent defining this new registry.
Parsons Expires April 9, 2014 [Page 15]
Internet-Draft OUI Registry Restructuring September 2013
5.4.1. Application Note
It is further proposed that virtualization manufacturers apply
for assignments of these CompanyIDs. These could then be used to
create MAC (EUI48) addresses in the local space that could be
reused. Additionally, it would also provide some order and allow
for multi-vendor usage of a subset of the local space for the
virtualization application (or any application that could benefit
from reusable addresses).
6. Protocol Considerations
There may be unintended consequences of these additions to the
OUI-based registries for existing protocols. A study and review
of many protocols was conducted and there were no apparent issues
identified.
IETF community input is requested, especially as it relates to
the embedded use or carriage of addresses or protocol identifiers
in other protocols. For protocol identifiers, the IEEE RAC would
be interested if any protocol defines the M and X bits for other
uses.
7. Security Considerations
There may be unintended consequences of these additions to the
OUI-based registries, though none are apparent.
IETF community input is requested.
8. IANA Considerations
There may be some affect on the existing IANA registries based on
the restructuring of the OUI based registries.
However, this has not yet been studied.
IETF community input is requested.
Parsons Expires April 9, 2014 [Page 16]
Internet-Draft OUI Registry Restructuring September 2013
9. Conclusions
While the background presented in this document is representative
of the current situation, the proposals in this document have not
yet been implemented, and therefore may change.
The IEEE-SA Board of Governors has made a decision, based on the
recommendation of the IEEE RAC, on the implementation of the OUI
registry restructuring. A summary has been provided in this
document, but full details are under development by the IEEE RAC.
It is expected that implementation will start in 2014.
IETF community input is requested to identify any issues with the
restructuring proposal, especially as it affects IETF protocols.
Please provide your comments to the RAC public list with "IETF
community comment" as the start of the subject field:
STDS-RAC-PUBLIC@LISTSERV.IEEE.ORG
10. References
10.1. Normative References
[1] IEEE Std 802-2001, "IEEE Standard for Local and Metropolitan
Area Networks: Overview and Architecture"
https://standards.ieee.org/about/get/802/802.html
10.2. Informative References
[2] IEEE Registration Authority website
http://standards.ieee.org/develop/regauth/
[3] IEEE P802 - Overview & Architecture revision project
http://www.ieee802.org/1/pages/802-rev.html
11. Acknowledgments
The IEEE RAC appreciates the cooperation of IETF in publicizing
these proposals to the IETF community including at its meetings.
Some of the background material in this document is based on
information previously available on the IEEE RA website [2].
Parsons Expires April 9, 2014 [Page 17]
Internet-Draft OUI Registry Restructuring September 2013
Authors Addresses
Glenn Parsons
Ericsson
Phone: +1-613-963-8141
Email: glenn.parsons@ericsson.com
Parsons Expires April 9, 2014 [Page 18]
