Hi Eric, Thanks for the review. See responses below at @@@
-----Original Message----- From: Eric Gray [mailto:[EMAIL PROTECTED] 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). @@@ Yes. Where it says "These include identifiers and protocol identifiers." it should say "These include MAC identifiers and protocol identifiers." > 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? @@@ (A network administrator can always use local group MAC addresses.) > I suggest removing the last sentence in the second paragraph of > section 2.1. @@@ I believe I understand your point above and I think it is reasonable to remove the reference to "OUI holders" but I would like to leave that sentence in the document, probably changed to: "Multicast addresses may be constructed by turning on the Group bit and unicast addresses constructed by leaving the Group bit zero." > __________________________________________________________________ > > 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. @@@ 3.1 is a pretty short section and contains, as far as I can see, only a single sentence concerning current assignment. So I am not inclined to make this split. > __________________________________________________________________ > > 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@@ It seems reasonable to add text along the lines that you suggest above. __________________________________________________________________ Section 7 appears to list two different documents as the same reference ([802]); is this appropriate, or should they be listed separately? @@@ I believe it is an accepted, although relatively rare, practice for a reference in an Internet Draft / RFC to refer to a set of document all listed under the same square bracketed reference tag. This seems appropriate here were the second document is an adopted and in force amendment to the first document. __________________________________________________________________ > ~~~~~~~~~~~~~~~~~ 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]> @@@ OK. > ___________________________________________________________________ > > 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. @@@ Well, the RFC Editor has their own standards for how ToC's look and where, if anywhere, to do a skip to the start of a new page or the like and I have my standards :-) I never complain when the RFC Editor changes (edits) such things around in my documents and, so far, the RFC Editor has never complain about the format of my Internet Drafts. @@@ (As to the blank lines, if you are interested in the mechanics, I use raw nroff for all my drafts includes a few macros of my own that I define in my draft source to automatically produce the ToC. These macros automatically add a blank line in the ToC before any header when they skip to the start of a new page for that header and do not add such a blank line if the header just appears in line.) > ___________________________________________________________________ > > 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). @@@ Also fixed in my replacement sentence above. > ___________________________________________________________________ > > In section 5.1, "may includes a" should be "may include a"... @@@ Right, that should be fixed. > ___________________________________________________________________ @@@ Thanks, @@@ Donald @@@ PS: Erik Nordmark cc'ed as he is the document shepherd. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
