Subject: [Gen-art] Gen-ART Review of draft-eastlake-ethernet-iana-considerations-07.txt

From: "Eric Gray" <[email-masked]>
Date: Tue, 17 Jun 2008 08:07:11 -0500

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-masked]'
> 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-masked]
> > 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-masked]>
> > ___________________________________________________________________
> > 
> > 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-masked]
https://www.ietf.org/mailman/listinfo/gen-art