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

From: "Eric Gray" <[email-masked]>
Date: Fri, 6 Jun 2008 04:25:22 -0500

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

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Fri, 6 Jun 2008 14:34:31 -0400

Hi Eric,

Thanks for the review. See responses below at @@@ 

-----Original Message-----
From: Eric Gray [mailto:[email-masked]] 
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

Donald, et al,

--
Eric Gray
Principal Engineer
Ericsson  

Eric Gray

> "parameters" - or "identifier parameters" in the section that 

@@@ Yes. Where it says "These include identifiers and protocol
identifiers." it should say "These include MAC identifiers and protocol
identifiers."
 
> well - but it is not clear whether these are also being referred 

@@@ (A network administrator can always use local group MAC addresses.)

> I suggest removing the last sentence in the second paragraph of

@@@ 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."

@@@ 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.

Specifically:

@@@ It seems reasonable to add text along the lines that you suggest
above.

@@@ 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.

>     Donald Eastlake III <[email-masked]>

@@@ OK.

@@@ 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.)

@@@ Also fixed in my replacement sentence above.

@@@ Right, that should be fixed.

@@@ Thanks,
@@@ Donald

@@@ PS: Erik Nordmark cc'ed as he is the document shepherd.