Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

FW: P802.21 Submission to RevCom: Ethertype change Technical/Editorial



fyi

 


From: Tony Jeffree [mailto:tony@jeffree.co.uk]
Sent: Monday, September 08, 2008 8:30 AM
To: Gupta, Vivek G
Cc: M.Patterson@ieee.org; david.cypher@nist.gov; david_law@ieee.org; d.ringle@ieee.org; M.Kipness@ieee.org; yhcheng@research.telcordia.com; m.d.turner@ieee.org; gthompso@nortel.com; a.n.weaver@ieee.org; p.nikolich@ieee.org
Subject: FW: P802.21 Submission to RevCom: Ethertype change Technical/Editorial

 

Vivek –

 

I believe that the basis for editorial staff deciding that the change was technical is basically:

 

-          My comment was labelled as technical and a required change; and

-          802.21 made the change.

 

I don’t believe that they made that decision on anything other than a procedural basis; neither do I believe that the staff concerned would feel qualified to make a determination on any other (than procedural) basis, as the reasons why it might/might not be considered to be a technical change *other than* on a procedural basis aren’t in their particular area of expertise. I am sure they will correct me if I am wrong.

 

So maybe I can be of some help here.

 

The reason I made my comment on the draft 13 text, as I stated in my comment, is that the notation you used in Draft 13 was indeed ambiguous, and I considered it highly likely that two implementers looking independently at the specification would reach entirely different conclusions as to what the Ethernet type value was and how it was to be represented in protocol. Therefore, to me, and I believe also to some of my RAC colleagues that I discussed the issue with, that piece of notification was a technical error in your draft. I proposed a solution, based on using an existing notation for hexadecimal values, as defined in IEEE Std 802, subclause 3.1.8. The particular utility of that notation is that it not only tells you how to write down the number as hexadecimal numerals, but also what the order of significance of the hexadecimal numerals is, and the mapping of them onto octet values in a protocol data unit. If you don’t appreciate the reasons why those steps are important, then I will tell you the story of the debacle that occurred with the DA/SA in 802.5 frames sometime and the amount of pain that it caused.

 

You are right that Clause 10 of Std 802 fails to use its own notation in the one place that it could – as Std 802 is currently open for revision, I will note that as something that needs fixing as we go through the revision. However, that fact, while interesting, is irrelevant with regard either to the utility of the Std 802 subclause 3.1.8 notation as a vehicle for addressing my comment (please note that I referred to Std 802 subclause 3.1.8 in my comment, not Clause 10) or to whether or not this should be considered to be a technical change.

 

You are also right that the registration authority assignment letters should have been clearer, and that is something that has already changed; the letters do now make it clear that the value is hexadecimal.

 

For what it is worth, my personal analysis of whether this is a technical or an editorial change goes as follows:

 

-          The notation in Draft 13 (0x89 0x17) was ambiguous, and could have led to more than one different, and justifiable, interpretation, both of of what the type value actually is and what should appear in protocol octets.

-          The new notation in Draft 14(?) (89-17), using the hexadecimal representation specified in Std 802 3.1.8, is unambiguous, and clearly specifies both what the type value is in hex numerals and how those numerals should be represented in protocol octets.

-          The change from D13 to D14 is therefore a technical change, because the change makes a material difference to what implementers might actually do in an implementation.

 

Regards,

Tony

 


From: a.n.weaver@ieee.org [mailto:a.n.weaver@ieee.org]
Sent: 08 September 2008 14:44
To: tony@JEFFREE.CO.UK
Subject: Fw: P802.21 Submission to RevCom: Ethertype change Technical/Editorial

 


Hi Tony,

I was forwarded this e-mail because there is a question regarding the possible recirculation of P802.21.  Although the EtherType Field template has been updated so that it contains "hexadecimal" in it, there seems to be a question regarding an assignment that was previously issued.  I do see that the tutorial contains references to hexadecimal.

Is this something that you have already addressed or can address to resolve the issue before October?

Please advise.  Thank you.

Regards,

Angela

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Angela N. Weaver
Senior Administrator, Business Programs
IEEE - Standards Activities
445 Hoes Lane, Piscataway, NJ 08854 USA
Phone:  +1 732-562-3813
Fax:  +1 732-562-1571
E-mail:  a.n.weaver@ieee.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Visit our web site at:  
http://standards.ieee.org/

IEEE.  Fostering technological innovation and excellence for the benefit of humanity.

----- Forwarded by Angela Weaver/STDS/STAFF/US/IEEE on 09/08/2008 09:41 AM -----

----- Forwarded by Michelle Turner/STDS/STAFF/US/IEEE on 09/05/2008 01:47 PM -----

From:

"Gupta, Vivek G" <vivek.g.gupta@intel.com>

To:

"M.Patterson@ieee.org" <M.Patterson@ieee.org>

Cc:

David Cypher <david.cypher@nist.gov>, "david_law@ieee.org" <david_law@ieee.org>, "d.ringle@ieee.org" <d.ringle@ieee.org>, "M.Kipness@ieee.org" <M.Kipness@ieee.org>, Paul Nikolich <paul.nikolich@att.net>, "'Yuu-Heng Alice Cheng'" <yhcheng@research.telcordia.com>, "m.d.turner@ieee.org" <m.d.turner@ieee.org>, Geoff Thompson <gthompso@nortel.com>

Date:

09/05/2008 12:38 PM

Subject:

RE: P802.21 Submission to RevCom: Ethertype change Technical/Editorial

 





Dear Moira,
 
We are not clear as to why this ethertype change is treated as Technical and not Editorial.
As per the formal cover letter sent by Angela N.Weaver / IEEE Registration Authority (See Attachment) the ethernet type number is #8917. This letter did not designate any hexadecimal or decimal notation or representation.  Instead it pointed to an html tutorial.
 
From an audit trail perspective of 802.21 drafts:
- In draft D11 We had the ethertype value "to be assigned".
- In draft D12 We had it as 8917. The formal cover letter did not designate any hexadecimal or decimal notation or representation.  
  There was no comment from Tony Jeffree on D12 about the value being ambiguous.  Instead we got a comment from Clint Chaplin.
- In draft D13 We had this as 0x89 0x17 as per conversations with Clint Chaplin to resolve his comment about the ambiguities of the value from D12.
  On D13 Tony Jeffree commented that this change was ambiguous and that yet another method for representing an Ethernet Type to remove ambiguity is needed.
 
Our Technical Editor (David Cypher) followed the information provided in the cover letter from Angela N. Weaver / IEEE Registration Authority.
#8917 was given. No where on either the cover letter or the html tutorial uses the 89-17 notation.
Instead to find this "dashed" notation one must follow 802.3 3.2.6, then follow a footnote 19 to footnote 18 then to 802 and then 3.1.8 and then to 9.2.1.  
However at this point the hexadecimal representation is used for MAC addresses and OUIs, not ethernet type values.  
802-2001 10.4 covers ethernet types and no where does it use the "dashed" notation.
If changing 0x89 0x17 to 89-17 is a technical change,then the editorial staff is going to have to convince that 89-17 is technically different from 0x89 0x17 and
that 89-17 is the correct notation for ethernet type values.
 
We do not see how one can make such an argument over an Ethernet Type and call it technical or say that this "dashed" notation is correct.
As per the text of 802-2001 10.4:
"An Ethernet type value is a sequence of two octets, interpreted as a 16-bit numeric value with the first octet containing the most significant 8 bits and the second octet containing the least significant 8 bits. Values in the range 0–1535 are not available for use."
0x89 0x17 represents a sequence of two octets. Not 89-17 which is not even clear if it applies to ethernet type.
 
It seems that there is no definitive way of writing this value without appropriate context.
The context is given as Ethernet type and therefore it is clear and is hence this should not be a technical issue.
 
Can you please point us to the IEEE Editorial staff who don’t consider the below ethertype change as Editorial and can they
clarify their line of reasoning for treating this change as Technical?
 
Thanks
-Vivek
 

 



From: M.Patterson@ieee.org [mailto:M.Patterson@ieee.org]
Sent:
Monday, August 18, 2008 3:29 PM
To:
Gupta, Vivek G
Cc:
David Cypher; david_law@ieee.org; d.ringle@ieee.org; M.Kipness@ieee.org; Paul Nikolich; 'Yuu-Heng Alice Cheng'; m.d.turner@ieee.org
Subject:
RE: P802.21 Submission to RevCom


Vivek,


I understand that it is disappointing, but unfortunately we cannot accept late submittals at this time. (This is not the only submittal that was received over the weekend.)


Also, there is a comment that might prove problematic if not recirculated. In response to comment #2 from Recirc 6, the WG states:
       

        Resolution Detail: Clause 5.7.2, page 33, line 23, Table 2, value column; 1) Change "0x89 0x17" to "89-17”  2) Insert table footnote for this value
"This Ethertype value is expressed using the hexadecimal representation defined in IEEE Std. 802."   This comment is treated as Editorial."

Editorial staff reviewed this comment and does not view this proposed change as editorial in nature, therefore it cannot be made without a recirculation.

RevCom Convention 2 states that "If, during the review process, RevCom perceives that post-balloting changes are proposed (e.g., changes from mandatory coordination bodies) which are both non-editorial and required, the draft and proposed changes shall be returned to the Sponsor for appropriate action."


As is, this proposed change seems to fall under this convention. Since this is a Must Be Satisfied comment and appears to have been in scope, a recirc might be necessary.


Please let me know if you have any questions.


Best regards,


Moira

From:

"Gupta, Vivek G" <vivek.g.gupta@intel.com>

To:

"M.Patterson@ieee.org" <M.Patterson@ieee.org>

Cc:

David Cypher <david.cypher@nist.gov>, Paul Nikolich <paul.nikolich@att.net>, "'Yuu-Heng Alice Cheng'" <yhcheng@research.telcordia.com>, "david_law@ieee.org" <david_law@ieee.org>, "d.ringle@ieee.org" <d.ringle@ieee.org>, "M.Kipness@ieee.org" <M.Kipness@ieee.org>

Date:

08/18/2008 02:43 PM

Subject:

RE: P802.21 Submission to RevCom

 

 






Dear Moira,

 
This is most unfortunate.

If there is anything I can do to get this on RevCom’s agenda for Sept 25th meeting please do let me know.

I had to leave for a 3GPP meeting (to Budapest Hungary) on Friday and hence this issue.

This is my first time of submitting something to RevCom….can I be granted a first time grace?

 
Kind Regards

-Vivek

 


 




From:
M.Patterson@ieee.org [mailto:M.Patterson@ieee.org]
Sent:
Monday, August 18, 2008 11:32 AM
To:
Gupta, Vivek G
Cc:
David Cypher; Paul Nikolich; 'Yuu-Heng Alice Cheng'; david_law@ieee.org; d.ringle@ieee.org; M.Kipness@ieee.org
Subject:
Re: P802.21 Submission to RevCom

 


Dear Vivek,


I received your submittal. Unfortunately, the submittal form needed to be submitted by 15 August in order for the project to be placed on the September agenda.


RevCom will be holding an Early Consideration telecon in late October, and I will place the project on the agenda for that meeting. The RevCom recommendations will then be confirmed by the Standards Board by early to mid-November through an email ballot. I will let you know the date for the meeting once it is determined.


Please let me know if you have any questions.


Best regards,


Moira Patterson
Administrator, Governance; IEEE-SA
445 Hoes Lane
Piscataway, NJ 08854
Phone: (732) 562-3809
Fax: (732) 796-6966
Email: m.patterson@ieee.org

IEEE. Fostering technological innovation and excellence for the benefit of humanity.

From:

"Gupta, Vivek G" <vivek.g.gupta@intel.com>

To:

"m.patterson@ieee.org" <m.patterson@ieee.org>

Cc:

Paul Nikolich <paul.nikolich@att.net>, David Cypher <david.cypher@nist.gov>, "'Yuu-Heng Alice Cheng'" <yhcheng@research.telcordia.com>

Date:

08/16/2008 08:44 PM

Subject:

P802.21 Submission to RevCom


 


 







Dear Moira,


This is with regard to submission of P802.21 to RevCom.

The deadline was yesterday Aug-15, but since our last ballot got done on Aug-14, I could only post this today.

I hope that’s Ok.


Please find attached for your reference:

-
         Cover letter which has rebuttals to remaining comments, WG roster and 802.21 PAR information
-
         Summary of ballot information,
-
         Copy of final draft, and
-
         IEEE-SA Standards Board 'Form for Submittal of Proposed Standards'.

I will sign the IEEE-SA Standards Board Form for Submittal of Proposed Standards and fax it to you as well.

The WG Editor, David Cypher will forward the draft source files to IEEE-SA people as well.


If I have missed anything please do let me know.


Kind Regards

-Vivek


[attachment "Cover_Letter_RevCom.doc" deleted by Moira Patterson/STDS/STAFF/US/IEEE] [attachment "P802.21 Ballot Summary.zip" deleted by Moira Patterson/STDS/STAFF/US/IEEE] [attachment "P802-21-D13-0.pdf" deleted by Moira Patterson/STDS/STAFF/US/IEEE] [attachment "sub17624.pdf" deleted by Moira Patterson/STDS/STAFF/US/IEEE]

Attachment: coverletter.pdf
Description: coverletter.pdf