I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other comments
you may receive.
Document: IANA Ethernet Considerations
(draft-eastlake-ethernet-iana-considerations-05.txt)
Reviewer:
Review Date: 20080529
IETF LC End Date:
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 <[EMAIL PROTECTED]>
___________________________________________________________________
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"...
___________________________________________________________________
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
