Document: IANA Ethernet Considerations
          (draft-eastlake-ethernet-iana-considerations-05.txt)
Reviewer: Eric Gray [eric.gray@ericsson.com]
Review Date:  06/05/2008
IETF LC End Date: 01/30/2008
IESG Telechat date: 

Summary: 

Comments: 

In the Introduction, WRT the difference between "identifiers"
and "protocol identifiers" - this text would make more sense if 
this distinction was clarified.  The document actually includes 
EUI-48 and EUI-64 MAC "identifiers" (collectively called Ethernet 
Address Parameters) and protocol "identifiers" (referred to as 
"parameters" - or "identifier parameters" in the section that 
covers them).

The document also defines acronyms OUI and EUI (Organizationally
and Extended Unique Identifiers, respectively) as identifiers as
well - but it is not clear whether these are also being referred 
to in this text.
___________________________________________________________________

Section 2.1 - On use of the Group bit within an OUI, I recently
sat in on a discussion of this in the IEEE and it is not at all
clear that use of the Group bit works as the text in section 2.1
claims it does.

Note that turning the Group bit on effectively makes the address
"local" and such an address is unlikely to have been assigned to 
a specific MAC device.  Hence it is not clear - or at least not 
in any practical sense - that the scope of a group address is 
limited to the context of an OUI (with notable exceptions - such 
as mapping of IPv4 multicast addresses to group MAC addresses).

For that reason, it appears likely (but not guaranteed) that -
with exceptions - it is largely the local network administrator,
and not the OUI holder that is more likely to be able to construct
Group addresses (almost irrespective of OUI) by setting the Group
bit.

This is not guaranteed, because it is possible that the holder of
a particular OUI might decide to check to make sure the Group bit
is not set for any frame with a destination address from that OUI.
But this is both extra work and unlikely to be useful.  A more
likely problem that might arise is if an OUI holder did decide to
use these Group addresses (for instance, within their device), use
of these group addresses by network administrators might produce 
strange and unexpected results.

However, except for the noted exceptions, it is unclear what the
effect of limiting Group addresses to use by the applicable OUI
holder would mean for the availability of Group MAC addresses to
applications other than - for instance - IPv4 Multicast.  Does a
network administrator need an OUI to construct Group MAC address
values to use in an application for which there is not already a
Group address construction?

I suggest removing the last sentence in the second paragraph of
section 2.1.
__________________________________________________________________

You may wish to consider breaking section 3.1 into two sections:
3.1 and 3.2, or 3.1.1 and 3.1.2, such that there is a clearer
demarcation between current assignment information and the IANA
considerations that relate to future assignments.
__________________________________________________________________

I recommend adding text to section 5 along the following lines:

~~~~~~~~~~~~~~~~ Begin added Text ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Specifically:

Section 1.2.1 provides information on the IANA assigned OUI.

Section 2.1.1 lists current EUI-48 assignments under this OUI.

Section 2.1.2 defines IANA considerations for future EUI-48
assignments.

Section 2.2.2 defines IANA considerations for future EUI-64
assignments.

Section 3.1 provides a pointer to current protocol identifier 
assignments under the IANA OUI, and defines IANA considerations
for future protocol identifier assignments.

Section 4 briefly provides IANA considerations relating to OUI
based miscellaneous assignments (or allocations).
__________________________________________________________________

Section 7 appears to list two different documents as the same
reference ([802]); is this appropriate, or should they be listed
separately?

~~~~~~~~~~~~~~~~~ End added Text ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

NITs:
====

On the first page, E-Mail addresses should be in a consistent
form - i.e. - the first address should be (something like):

    Donald Eastlake III <donald.eastlake@motorola.com>
___________________________________________________________________

In the ToC, it is unusual to see "Status of This Document",
"Abstract" and (particularly) "Table of Contents" as part of
the Table of Contents.

Also, there is apparently artificial and inconsistent spacing
of TOC entries.  For example, there is an extra line before 
entries for sections 1, 2, 3, 4, 5 and 7, but not sections 6 
and 8.
___________________________________________________________________

In section 2.1, second paragraph, last sentence - "construction"
should be "construct"... (note that this NIT goes away if the 
sentence is removed as suggested in above comments).
___________________________________________________________________

In section 5.1, "may includes a" should be "may include a"...
___________________________________________________________________