[802.3_10SPE] clarifications and follow ups from yesterday's ad hoc call

[George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>]

I understand that there was considerable discussion on yesterday’s ad hoc call, some relating to the work at hand, and some relating to confusion I inadvertently generated with my comments on the path forward.

 

First, again, apologies for not being able to make the call.  I had a direct conflict with another meeting that I had to be at face-to-face.

 

I wanted to clarify a couple of items in my prior comments:

1. Meeting times of the 802.3cg Task Force vs. meeting times of the 802.3 10 Mbps Backplane Ethernet Study Group: I had said the meetings would run “in parallel”.  This caused a bit of confusion that people thought there might be two ongoing meetings and they would have to choose – you don’t.  What I meant was that we would open the meetings of both groups on Monday and close both groups on Wednesday.  We are largely the same group of people, and both groups will use the same room, so one person can attend both groups.  Our plan is to spend the first ½ day or so (starting Monday morning) on the business and presentations of the Study Group, then “recess” the Study Group (but not adjourn it) to go to the business of the Task Force, and on Wednesday, allocate a couple of hours near the end of the meeting for any concluding business of the Study Group.  I hope this clears up any confusion.
2. The comment resolution tool.  The Working group STRONGLY RECOMMENDS that you use one of the two comment input tools provided at http://www.ieee802.org/3/WG_tools/index.html .  I recommend the same for Task Force review.  Both the filemaker tool and the spreadsheet tool are available there.  You are free to use either tool for Task Force review, but I strongly urge you against manual comments.  Our editorial team will be working from a comment database to refine our draft, and, if you enter or make manual comments (via email or text in presentations), they will have to be entered.  If you need to make a presentation to support or explain the remedy of your comment, that is fine – just make a comment in the tool referencing the presentation.  YOU ARE FREE TO USE EITHER TOOL.  However, because we have a group with a large number of newcomers to the 802.3 process, and, because my personal experience both as a commenter and an editor has left me with the impression that the spreadsheet tool is a little easier to learn and proof, and will lead to fewer questions, errors, or “comment misfires” (partial comments, empty comments, etc.), I am recommending to newcomers to use the spreadsheet tool.  You will see your comments in plain text, and, if you know how to use excel, you should be familiar with  the basics of the tool.  I was trying to be helpful to our newcomers, not to enforce one tool over the other.  I will be interested offline as to your own experiences.

 

Hopefully that clears up the confusing issues that are just about process.  Now, on to the hard stuff – getting our PAR and CSD modifications done.

Peter Jones shared a presentation that reflected our thoughts (yes, we missed the reference to twisted pair in the title – just a mistake).  We need to work consensus on this text.  I encourage and welcome discussion on the reflector of what modifications are necessary.  I will remind you that we have a draft 1.0 already – the clarity and detail that further specify our solutions to the objectives are (or at least should be) reflected in that document.  We should not try to write the specification in the objectives.  At this point, minimal, surgical changes are needed.

 

I also understand that there was some discussion as to the characteristics of the mixing segment.  The mixing segment definition will be reflected in the draft 1.0 and you are free to comment on it there, as well as what may be needed in the objectives.  It is my thought that the mixing segment can have more than 4 connectors, as there could be one per node.  In the topology presentations (e.g., kaindl_matheus_3cg_01c_09_2017.pdf ) I do not recall seeing connectors other than for attaching the nodes.  I’d like to ask some of the proponents whether this is a correct assumption – specifically, are there ‘inliners’ (inline connectors) which connect the portions of the mixing segment, but do not attach a node, and, is it correct to assume nodes are attached to stubs which are bridged to the mixing segment at an inline connector?  To discuss this further, please use a subject tag on the reflector like MIXING SEGMENT

 

 

There was one more issue that I saw raised, related to the distinct identity CSD. I believe that our existing ‘distinct identity’ CSD could use a little more tweaking to reflect that we are a PHY project.  I know of no other PHY project with a data rate of 10Mbps on a single pair media.  (10BASE2 is specified on a coax (see clause 10.5.2.1.1) - I don’t recall ever seeing the term “single pair” being applied to a coax.). Also, 10BASE2 is purely half-duplex (cannot support full duplex) and detects collisions on the media (rather than at a gate at the PHY), so 802.3cg is distinctly different in that it can support full duplex (long reach pt-to-pt does, and in all discussions short-reach pt-to-pt supports full duplex at least optionally), and gates collisions at the MII.  Our job is how to word that difference.  I suggest we take that to another reflector thread to discuss those issues, maybe tagged 10BP CSD CHANGES.

 

-george

 

George Zimmerman, Ph.D.

Chair, IEEE P802.3cg 10 Mb/s Single Twisted Pair Ethernet Task Force

President & Principal

CME Consulting, Inc.

Experts in Advanced PHYsical Communications

george@xxxxxxxxxxxxxxxxxxxx

310-920-3860