Donald, et al,
There are a couple of - essentially typographical or
omission - errors in this review. See corrections below.
--
Eric Gray
Principal Engineer
Ericsson
> -----Original Message-----
> From: Eric Gray
> Sent: Thursday, June 05, 2008 11:40 AM
> To: Eastlake III Donald-LDE008
> Cc: Romascanu, Dan (Dan); [email protected]
> Subject: Gen-ART Review of
> draft-eastlake-ethernet-iana-considerations-05.txt
>
>
> 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:
I omitted "Reviewer" - as follows:
Eric Gray
> Review Date: 20080529
> IETF LC End Date:
> IESG Telechat date:
>
> Summary:
>
I omitted a summary statement, as follows:
This draft is almost ready for publishing as a BCP RFC. I have
a few comments/questions and NITs listed below.
> 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?
The last paragraph above (after the separator) is not meant to be
part of the proposed added text. This should have read:
__________________________________________________________________
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).
~~~~~~~~~~~~~~~~~ End added Text ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
__________________________________________________________________
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
