Donald, et al -
I have reviewed version -07 and it addresses all of the
concerns I had in my earlier review of the -05 version.
> -----Original Message-----
> From: Eric Gray
> Sent: Friday, June 06, 2008 5:25 AM
> To: 'Eastlake III Donald-LDE008'
> Cc: 'Romascanu, Dan (Dan)'; '[email protected]'
> Subject: RE: Gen-ART Review of
> draft-eastlake-ethernet-iana-considerations-05.txt
>
> 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
