| chris you replied with what i asked thank you regards john Sent from my iPhone On Nov 6, 2025, at 9:22 AM, Chris Cole <chris.cole@xxxxxxxxxxxx> wrote:
John
here you go:
Given how impactful they were, I assumed everyone was aware of the Meta measurements of the Broadcom CPO switch at ECOC and OCP. Here is the OCP presentation which had additional data to the ECOC presentation.
What you may find even more helpful is to ask your colleagues at your affiliated company to share with you the measurements they are taking and encourage them to bring the measurements into the 802.3.
Chris
From: John D'Ambrosia <jdambrosia@xxxxxxxxx>
Sent: Thursday, November 6, 2025 4:51 AM
To: STDS-802-3-B400G@xxxxxxxxxxxxxxxxx <STDS-802-3-B400G@xxxxxxxxxxxxxxxxx>
Subject: [EXTERNAL]: Re: [802.3_B400G] [802.3dj] Proposed Responses & Bucket1 Posted
Chris,
Many of us are reading these emails, very closely.
You stated in the prior email
below – “Your characterization that the Functional Test is without data is factually incorrect.”
Additionally, you noted “It's a disservice to characterize this as anything but rock solid.”
However, please note that Mark did not say that the Functional Test is without data.
What Mark stated is “Based on TF consensus, the well-supported proposal was adopted, but there was no data presented into the Task Force.”
I do not see you pointing to a presentation given to the Task Force, only stating “Every company making measurements will make their own decision on whether to publish measurements and were.”
So based on this, I can only assume that, as Mark stated, no data has been presented into the Task Force.
Is there perhaps a presentation pointing to presentations that were potentially given at ECOC 2025 or OCP 2025?
Can you point to this presentation? A pointer to publicly available data would be just as useful.
Otherwise, for the functional test it appears that you are arguing that the task force should vote based on the experts being aware of this data, that is not available to the task force.
If I have missed a presentation that would help me understand this situation better, I would greatly appreciate a URL to it so I can review.
Thanks and regards,
John
From: Chris Cole <chris.cole@xxxxxxxxxxxx>
Sent: Wednesday, November 5, 2025 5:22 PM
To: STDS-802-3-B400G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G] [802.3dj] Proposed Responses & Bucket1 Posted
I agree that the Editorial Team is doing an awesome job for what is probably the most challenging project in 802.3.
As you correctly point out, that doesn't mean they can keep an eye on every detail and certainly cannot have every decision go to everyone's liking. If everyone was pleased, we would make no progress, which means
no one would be pleased. That's why they rely on Task Force participants.
Your characterization that the Functional Test is without data is factually incorrect. Every supplier making 200G/lane optics and every end user evaluating and deploying them uses Functional Testing. The proposal
didn't spring out of a hypothesis about how things should be done, which unfortunately other proposals have, but rather out of labs. The Author Team drafted the proposal based on actual experience, with a back and forth to reach consensus on the final methodology
and numbers. This included deep insight from great lab work by Marco, who shares affiliation with you. The standard would be in much better shape if all specifications were done this way. It's a disservice to characterize this as anything but rock solid.
Every company making measurements will make their own decision on whether to publish measurements and were. If they chose to publish their results at ECOC 2025 or OCP 2025 instead of 802.3, we should respect
their views about what's important for their business. I have done my best to encourage participants to bring in data for measurements they are already doing. I have commented to others, including the Editors, that I generally support your approach to get
more data, up to and including submitting comments. Where I took exception was having comments by a single individual, with no supporting material, no supporters, ACCEPTED IN PRINCIPLE, no matter how well intentioned. This has been addressed as part of the
normal back and forth between the Editorial Team and TF participants. The process is working.
I also want to make very sure that others in the Task Force who don't have the background vote for a comment that is meant simply as a call for data.
I do want to clarify or comment on a few things in your message below.
I agree that there is no value in hashing over the dynamics of the September meeting, but I do want to reinforce that as a leadership team managing a very large and busy
project we have prioritized transparency in how we plan and manage the workloads in the meetings. We will consistently be following the same approach for the meeting next week. We cannot insist that everyone tracks all of this,
but I would encourage folks to pay attention at the openings of the meetings where we explain it all and solicit any questions. We then update the group as things inevitably change and communicate that as well.
Of course, anyone can reach out to us directly to for any clarifications.
As you have noted, I have submitted comments against all the SMF IMDD TQM tests to encourage contributions into the Task Force to share the much-needed validation data that we can all use to make an informed
decision. While I have discussed this in many offline consensus discussions, I also sent
this message [ieee802.org] to the fall Task Force in early Oct to raise awareness and presented
my perspective [ieee802.org] in the last ad hoc meeting. So, it should come as no surprise.
I’m looking forward to some good discussion on the topics next week. I know that people have been doing some work in their labs, but we unfortunately have not as much contributed data next week as I was hoping.
Nevertheless, we’ll work with what we have and see what decisions we can make now or whether we defer to future meetings.
You do comment below that the Tx functional test was adopted based on actual lab testing and I need to comment on that. Based on TF consensus, the well-supported proposal was adopted, but there was no data presented
into the Task Force. This was a concern raised by individuals in the Task Force, but I did advocate for it to be adopted, based on the strength of the support, and so that the test procedure could be defined clearly to allow validation testing to be consistently
performed. Many spoke that they would be bringing in data because of this decision. As I said, above, there has been less than I hoped or anticipated.
With regards to the "Proposed Response" this is a starting point for discussion based on the editorial team making their best effort. We resolve the comments based on the direction of the Task Force participants
and this often changes the disposition from the proposed response. With regards to my comments (#136-139) where I’m uniformly putting pressure on each test, the editorial team is similarly uniformly providing something consistent in the “Proposed response"
field as a starting point with the most important aspect of the Proposed Response indicating the Final Response would be pending review and discussion by the participants. With that said, I remain in awe of our editorial team's hard work and diligence in
what they do for this project.
With these TQM tests, like other topics assigned to the common track, they collectively touch on many of the expertise areas in our Task Force from optical
parametrics, to DSP and SerDes design, to PCS functionality, and to system and module design. We will be looking for broad review and participation in this discussion to help us find the best path forward.
I’m looking forward to the discussions next week.
Dear 802.3dj Participants,
Since proposed responses to comments against D2.2 have been published, it's important to learn from the last comment resolution cycle.
Comment #399 was submitted against D2.1
proposing [ieee802.org] to add a jitter test to Tx optical specs. Over the previous year and half, during multiple unofficial SMF
concensus building calls, no optics expert supported the test, which is reflected in no support in the proposal.
Going into September Interim meeting, the proposed response was:
There has been some discussion on the clock jitter impact and output jitter spec in previous meetings. However, no obvious consensus has been observed, partly due to lack of strong evidence showing the necessity
of adding such parameter. Evidence or data is also lacking to support defining the values of the proposed parameter. The proposed remedy provides detailed changes for implementation, which could be a good starting point of further discussion. Further technical
contribution is encouraged to move forward."
During a joint comment
resultion meeting, based on a nearly even split vote, the response was changed to ACCEPT IN PRINCIPLE and jitter test was added. Afterwards, when concerns were raised about such an important change being forced onto the optics industry, it was pointed
out that if the issue was so important, opposition should have been better organized going into and at the meeting. This ignores that given everything that happened up to then, there was no expectation that the outcome would be any different than over the
previous year and half.
This is water under the bridge, and all that we can do is apply lessons learned going forward.
The Optical Tx Functional Test was adopted with
overwhelming optics industry support [ieee802.org], based on actual lab testing by all optics vendors and end users working on 200G/lane optics. We have now seen examples of this methodology published in public forums, for example ECOC and OCP. We expect
this to be the foundation of 200G/lane measurements going forward.
Since multiple Tx Tests were added into D2.1, the Optics Track Chair, during unofficial SMF
concensus building calls, proposed removing the added Tx tests if supporting data was not brought in. While only some of the added Tx Tests critically need this, the approach was applied to all of them. In line with that, comment
#138 has been submitted against D2.2, proposing to remove the Optical Tx Functional Test.
Remove the changes made due to the adoption of the TFSEM methodology into D2.1 and
modifications into D2.2. Delete subclause 180.9.9 and associated references. Apply the equivalent changes to
clauses 181, 182 and 183.
A background presentation will be provided.
PROPOSED ACCEPT IN PRINCIPLE."
Normally, there would be zero expectation that comment #138 has any chance of getting adopted. However, given the experience with #399, we
can not take a reasonable outcome for granted. This is especially worrisome, given the PROPOSED ACCEPT IN PRINCIPLE which makes no sense since there
is no supporting material and no optics industry support.
Most important is building
awereness among our colleagues in logic and electrical tracks, about the importance of a functional optical test to the optics industry. Please take the time before the meeting, to discuss with your optics colleagues so that when you vote, you have the
full picture.
The P802.3dj Task Force Chair delegated to me the announcement of the proposed response reports and “bucket 1”.
Note to all commenters and participants –
In the interest of devoting as much meeting time as possible to perceived issues, the editorial team was encouraged to make liberal use of “Bucket 1” for comments.
During the P802.3dj Task Force meeting, a motion is anticipated on Monday, 10 November 2025 to accept the proposed responses to comments in “Bucket 1.” Please note any comments withdrawn from “Bucket 1” will be excluded
explicitly in this motion.
Additionally, the editorial team may continue to refine the proposed responses to comments that are not contained in bucket1 and may provide updated proposed response comment reports. These updates, if made, will be announced
via the email reflector.
My thanks to all individuals for their review of the document, and Matt Brown and our editorial team for their diligent efforts in responding.
IEEE P802.3dj Task Force Recording Secretary
To unsubscribe from the STDS-802-3-B400G list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G&A=1 [listserv.ieee.org]
To unsubscribe from the STDS-802-3-B400G list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G&A=1 [listserv.ieee.org]
To unsubscribe from the STDS-802-3-B400G list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G&A=1 [listserv.ieee.org]
To unsubscribe from the STDS-802-3-B400G list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G&A=1
To unsubscribe from the STDS-802-3-B400G list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G&A=1
|