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

[802.3_10SPE] Announcement of 802.3cg D1.2 Task Force review

All –

Once again, Valerie Maguire and her editorial team have once again worked hard and fast and now, Draft 1.2 is ready for review.  As before, please review the draft and provide comments to the editorial team.  With this email I announce the start of Task force review of draft 1.2, closing on April 29, 2018 anywhere on earth.  Yes, we are kind of compressed here, but there isn’t much time between meetings and I commend our editorial team for getting this out a few days earlier than planned.


The draft can be found in the 802.3cg private area at: .  There are both “clean text” and “compare” versions of the document in the private area so that you can see what has changed since draft 1.1. PLEASE ONLY COMMENT ON THE ‘CLEAN TEXT’, not the compare file. If you need the password (and are participating in the standards process – getting this email by the reflector is evidence of that), then email me and I will make sure you get it.


Comments should be submitted either by the filemaker comment tool or the spreadsheet tool.  They are available at I personally recommend the spreadsheet tool as I have found it results in fewer commenter errors and you can see all your comments at once – but you may use either tool.  Manual comments, however, are discouraged.


My suggestion – Our focus this time should be on two things:

  1. Technical completeness – do we have all the TBDs, blanks, and missing text filled in?  Are there features referenced in one place (for example in a register) which are not referenced in another necessary place (like in the PHY spec). Focus on technical completeness.  We will have plenty of cycles to refine.  Feel free to suggest unnecessary things be deleted (but remember to explain why it isn’t needed for interoperability, especially if it is normally specified for BASE-T and BASE-T1 PHYs) – to be technically complete, there can be no more “TBDs” or editor’s notes marked “to be removed before working group ballot” (or D2.0) in the document.  We want to get most of those closed this cycle.
  2. Additional specifications to include the 10Mbps backplane application.  I don’t mean scrubbing out the words “twisted pair” – what I mean is making sure that any additional technical inclusions, such as test points and specifications from them, which are often used in backplane PHYs are proposed in a complete manner.  While we can’t make these changes before NESCOM approves the revised PAR, we can get ready to do it at our May meeting by providing technical content for consideration at the May meeting.  We want this to be complete too.


Also, please know that if you plan on presenting presentations or proposals – PLEASE file a comment on the section of text that it would fit into (even if there is nothing there currently). IF RESOLVING YOUR COMMENT INVOLVES A PRESENTATION – please send a draft to the editorial team by 29 April – that way we know what you are suggesting and can recommend proposed resolutions.  Also, consider presenting to an ad hoc, as we have a longer comment period this time.


Finally – KEEP DISCUSSIONS GOING on the reflector or in the ad hocs.  If  you see a hole and don’t know how to close it, send a note to the reflector.  Others may know easily, and just need to be pointed to the problem.


Some of you have heard me say “Better is the enemy of good enough” which I learned in the early 90’s from a project manager at NASA. A decade later someone put a nice description together of how ‘correct’ and ‘better’ interact in project management ( .


We need to be ‘good enough’ at this point.  The goal of Task Force review is “Technically Complete”.  Does it hang together technically, even if not perfect or perfectly verified.  We want to get to Working Group Ballot, which is the “Checking” phase of the project – do we have it editorially and technically correct.

I understand from Steve Carlson that we will have limited time in Rosemont, and we have lots of work to do, so we are going to work hard to make comment resolution efficient.  You can help by following the guidelines below.


Again, Thank you to our industrious editorial team: Valerie Maguire, Piergiorgio Beruto, Chris Diminico, Curtis Donahue and Jon Lewis.




Below are some important FAQs and guidelines:


Who can review the draft – Anyone.  Participation is by individual basis.


Scope of the review: The ENTIRE draft is still in scope.



Good commenting guidelines: See  where there are lots of good information.  It is most helpful if you:

-          Quote the offending text (or enough of it for us to find) in your comment, AND, say what the problem is.  Any explanation should go in the comment.

-          Give a specific change to the text in the proposed response.  Try not to say more than just what needs to be done.  If there is more than one possibility, give both and briefly say what makes the determination in your mind (for example, “if the proposed functionality is supposed to be P, then change “y” to “z”.  if the proposed functionality was supposed to be Q, then change “y” to “x”.  If you need formatting or graphics, then put them in another file (text – word or PDF, or powerpoint).  Remember, equations, italics, etc. don’t come through in the comment tool.  If you need a presentation to explain and present the solution, please flag that and give it a name in the proposed response – BUT, give your editors an idea of what you will be proposing.

-          Please focus on the technical completeness of our draft.  While pointing out obvious typos or errors is useful, editorially rewording text takes valuable task force time and likely will just get reworded again during working group ballot.  A useful rule is – if you can clearly understand what is meant, then others can too, but if there are 2 or more interpretations and you need ‘inside knowledge’ or have to guess to figure out what is meant, please go ahead and comment.

-          If you think there is an issue to discuss, flag that (in addition to providing your proposed resolution).  That will be a cue to your editors not to mark the comment “EZ”.


Voting and “Required” comments:  Task Force review is informal, there is no ballot or vote.  Therefore, there is NO POINT in marking your comments “required” or not.  They will all be considered equally.


George Zimmerman, Ph.D.

President & Principal

CME Consulting, Inc.

Experts in Advanced PHYsical Communications




To unsubscribe from the STDS-802-3-10SPE list, click the following link: