> > I strongly suggest submitting a -04 version of this draft to make > > the necessary single character correction (e.g., as opposed to using > > a RFC Editor Note for that purpose). > > I defer entirely to Joel Jaeggli, the sponsoring AD. I'm happy to leave that decision up to Joel. I'm concerned about readers who aren't as cognizant of and comfortable/familiar with the relationships among OUIs and the identifiers based on them as people like you and me. Thanks, --David > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3@xxxxxxxxx] > Sent: Sunday, June 09, 2013 2:07 PM > To: Black, David > Cc: joe.abley@xxxxxxxxx; General Area Review Team; joelja@xxxxxxxxx; > ietf@xxxxxxxx > Subject: Re: Gen-ART review of draft-eastlake-rfc5342bis-03 > > Hi David, > > On Sun, Jun 9, 2013 at 1:47 PM, Black, David <david.black@xxxxxxx> wrote: > > The -03 version of this draft resolves all of the concerns raised by > > the Gen-ART review of the -02 version. > > Thanks. > > > Unfortunately, a serious typo/thinko snuck into the -03 version (been > > there, done that, myself). Section 3.2 currently says: > > > > 00-42 is a protocol number under the IANA OUI (that is, > > 00-00-0E-00-42) to be used for documentation purposes. > > > > The parenthetical expansion of the protocol number is incorrect. > > The correct expansion uses -5E- instead of -0E-: > > My apologies, you are correct. However, I believe that, in context, > the typo is pretty obvious. > > > 00-42 is a protocol number under the IANA OUI (that is, > > 00-00-5E-00-42) to be used for documentation purposes. > > > > I strongly suggest submitting a -04 version of this draft to make > > the necessary single character correction (e.g., as opposed to using > > a RFC Editor Note for that purpose). > > I defer entirely to JoelJaeggli, the sponsoring AD. > > I'd be happy to submit a -04 or it seems to me it could easily be > fixed with an RFC Editor Note or at AUTH48 time. (Actually, it seems > likely to me that during IESG consideration, some other change will be > decided on and this can be fixed at the same time.) > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@xxxxxxxxx > > > Thanks, > > --David > > > >> -----Original Message----- > >> From: Black, David > >> Sent: Wednesday, June 05, 2013 6:13 PM > >> To: d3e3e3@xxxxxxxxx; joe.abley@xxxxxxxxx; General Area Review Team > >> Cc: Black, David; joelja@xxxxxxxxx; ietf@xxxxxxxx > >> Subject: Gen-ART review of draft-eastlake-rfc5342bis-02 > >> > >> I am the assigned Gen-ART reviewer for this draft. For background on > >> Gen-ART, please see the FAQ at > >> > >> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > >> > >> Please resolve these comments along with any other Last Call comments > >> you may receive. > >> > >> Document: draft-eastlake-rfc5342bis-02 > >> Reviewer: David L. Black > >> Review Date: June 5, 2013 > >> IETF LC End Date: June 4, 2013 > >> > >> Summary: > >> This draft is on the right track but has open issues, described in the > review. > >> > >> This draft updates the IANA registered Ethernet parameters for IETF use, > >> including recording values assigned for documentation. It also makes some > >> minor changes to IANA procedures. > >> > >> IANA should review this entire draft, not just its IANA Considerations > >> section; > >> Pearl Liang appears to have done that comprehensive review for IANA. > >> > >> Major issues: None > >> > >> Minor issues: One, the IANA review also found this issue. > >> > >> Section 3.2 states: > >> > >> IANA will assign "00-00-0E-00-42" as the protocol number under the > >> IANA OUI to be used for documentation purposes. > >> > >> IANA has not made this assignment, but this assignment request is not > >> recorded in the IANA Considerations section where IANA actions are > >> requested and recorded by IANA after they have been performed. This > >> assignment needs to be added to the IANA Considerations section; > >> see item 5 in the IANA review. > >> > >> Nits/editorial comments: > >> > >> Section 1: This document uses an "IESG Ratification" process for some > >> assignments. This is not the same process as the "IESG Approval" process > >> defined in RFC 5226. As those names could be confused by a casual reader > >> who is not strongly familiar with IANA processes, I suggest adding a > >> statement that the "IESG Ratification" process is defined in this document > >> and is not the same as the "IESG Approval" process in RFC 5226. This could > >> be added after the sentence that cites RFC 5226. > >> > >> Section 1.4: It would be helpful to point out that there is no OUI assigned > >> for documentation purposes, but there are identifiers based on the IANA OUI > >> that have been assigned for documentation purposes. > >> > >> In general, the use of the acronym IAB for Individual Address Block is > >> unfortunate, but unavoidable, and this is clearly pointed out in the > >> definition of the IAB acronym in section 1.2. Nothing can or should be > >> done about this. > >> > >> idnits 2.12.17 did not find any nits. > >> > >> Thanks, > >> --David > >> ---------------------------------------------------- > >> David L. Black, Distinguished Engineer > >> EMC Corporation, 176 South St., Hopkinton, MA 01748 > >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > >> david.black@xxxxxxx Mobile: +1 (978) 394-7754 > >> ---------------------------------------------------- > >