I guess what you're saying is that "will" in this case is a statement of IEEE RAC policy. In that case, I understand your point... -----Original Message----- From: Ralph Droms [mailto:rdroms.ietf@xxxxxxxxx] Sent: Tuesday, September 11, 2012 6:43 AM To: Eric Gray Cc: Joe Touch; IETF Chair; IETF list discussion Subject: Re: Draft IESG Statement on Ethertype Assignments for IETF Protocols Importance: High On Sep 11, 2012, at 6:30 AM 9/11/12, Eric Gray wrote: > Ralph, > > It cannot hurt to try to make this as unambiguous as possible. > > The IETF cannot instruct the IEEE RAC not to assign an Ethertype to > anyone who applies for it, assuming they otherwise comply with RAC > requirements and are willing to pay for the assignment, if necessary. Eric - As I understand the IESG statement, the intent is not to give any instructions to the IEEE RAC. I read the text I quoted in my e-mail: the IEEE RAC will not assign a new Ethertype to a new IETF protocol specification that needs one until the IESG has approved the protocol specification for publication as an RFC. as a restatement of the IEEE RAC policy, which was included in the IESG statement as explanation for this text: To let the IEEE RAC know that the IESG has approved an IETF protocol specification for publication, all future requests for assignment of Ethertypes for IETF protocol specifications will be made by the IESG. which describes how the IESG will inform the IEEE RAC about which protocol specifications meet the IEEE RAC policy. - Ralph > > However, the IETF can caution the RAC that any such assignment can > only be (or > become) associated with an IETF protocol specification upon its > approval and publication as an IETF RFC. > > -- > Eric > > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf > Of Ralph Droms > Sent: Friday, September 07, 2012 12:15 PM > To: Joe Touch > Cc: IETF Chair; IETF list discussion > Subject: Re: Draft IESG Statement on Ethertype Assignments for IETF > Protocols > > > On Sep 7, 2012, at 10:51 AM 9/7/12, Joe Touch wrote: > >> Hi, all, >> >> This statement seems fine, but it's worth noting that it would apply only to *IETF* protocol specs. > > What did you have in mind as "noting"? This text seems pretty clear to me as applying only to "IETF protocol specifications": > > the IEEE RAC will not assign a new Ethertype to a new IETF protocol > specification that needs one until the IESG has approved the protocol > specification for publication as an RFC. > > > >> The IESG has, IMO, no authority to make such claims for independent submissions (and what about IRTF ones?), and the IEEE should recognize that such protocols are described by RFCs too. > > Where do you see any such claims in this statement? What would you change? > > - Ralph > >> >> Joe >> >> On 9/3/2012 5:02 PM, IETF Chair wrote: >>> The IESG is considering this IESG Statement. Comments from the community are solicited. >>> >>> On behalf of the IESG, >>> Russ >>> >>> --- DRAFT IESG STATEMENT --- >>> >>> Subject: Ethertype Assignments for IETF Protocols >>> >>> The IEEE Registration Authority Committee (RAC) assigns Ethertypes. >>> (See http://standards.ieee.org/develop/regauth/ethertype/.) Some >>> IETF protocol specification make use of Ethertypes. Since >>> Ethertypes are a fairly scarce resource, the IEEE RAC will not >>> assign a new Ethertype to a new IETF protocol specification that >>> needs one until the IESG has approved the protocol specification for publication as an RFC. >>> >>> To let the IEEE RAC know that the IESG has approved an IETF protocol >>> specification for publication, all future requests for assignment of >>> Ethertypes for IETF protocol specifications will be made by the IESG. >>> >>> Note that playpen Ethertypes have been assigned in IEEE 802 [1] for >>> use during development and experimentation. >>> >>> >>> [1] IEEE Std 802a-2003 (Amendment to IEEE Std 802-2001). >>> IEEE standard for Local and Metropolitan Area Networks: >>> Overview and Architecture -- Amendment 1: Ethertypes for >>> Prototype and Vendor-Specific Protocol Development. >>> >>> >