Re: [802.3_ISAAC] P802.3dm D2.1: Follow-up on Comments #66, #67, and #68

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

On Fri, Sep 11, 2026 at 12:44 PM Ragnar Jonsson <ragnar.jonsson@xxxxxxxxx> wrote:

Hi Natalie,

I have sent to the reflector some initial suggestions for edits, but others should review them. Sujan and I are also discussing this off line, and we plan to discuss this f2f in Lisbon.

Ragnar

On Fri, Sep 11, 2026 at 2:10 PM Natalie Wienckowski <natalie@xxxxxxxxxxxxxxxxxxx> wrote:
Hi Sujan and Ragnar,

I will take the blame for the response to change it everywhere. Generally when this kind of a change is requested it applies everywhere, so I assumed this was the case. Thanks for letting me know that this is not what was meant and is not correct.

Please let me know if only the spots listed by Sujan should be changed, or if you want to work together to determine additional changes that may be needed.

Thanks,

Natalie Wienckowski
In-Vehicle Networking Solutions LLC
IEEE P802.3dm Chair and Chief Editor
natalie@xxxxxxxxxxxxxxxxxxx

On Fri, Sep 11, 2026 at 9:07 AM Sujan Pandey <sujanpandey1021@xxxxxxxxx> wrote:
Hi Ragnar,

I did not join the last ad-hoc call and I am happy that you sent out this email and came to my attention.
I submitted that comment about data mode (SEND_N) but I didn't mean to replace all the "normal operation" throughout the draft as far as my proposed remedy is concerned. Maybe that was a misunderstanding. What I did mean in my comment is that in the draft I found there are expressions as "normal operation" in many other places, which contradict with page 81 line 16, 17, and 25. And we need to change only on page 81 line 16, 17, and 25. Other places I believe we need to keep the term "normal operation" as it is.

I hope I made it clear here.

Kind regards,
Sujan

On Fri, Sep 11, 2026 at 2:37 PM Ragnar Jonsson <ragnar.jonsson@xxxxxxxxx> wrote:
Dear Colleagues,

Before the 802.3dm Interim meeting on September 8, I requested that Comments #66, #67, and #68 be pulled from the EZ bucket. These comments propose a blanket replacement of the term "normal operation" with "data mode (SEND_N)" throughout the draft. I mentioned during the meeting that I had concerns about unintended consequences with this replacement, and I promised to provide more information to the reflector.

While I fully agree with the commenters that the term "normal operation" is somewhat ambiguous and can certainly be improved, a blanket search-and-replace to "data mode (SEND_N)" is problematic and introduces several technical contradictions into the draft.

Here are five specific examples where substituting "data mode (SEND_N)" breaks the text or creates technical ambiguity:

1. Fault Recovery (e.g., 191.12.3 & 192.8.2)
The draft currently states: "Normal operation shall resume after the short circuit(s) is (are) removed."
If changed to "Data mode (SEND_N) shall resume...", the text implies that the PHY jumps straight back to transmitting high-speed payload data after a fault clears. In reality, a short circuit drops the link, meaning the PHY must go through Auto-Negotiation, SEND_S, and SEND_T before it can ever reach SEND_N again.

2. Transmitter Peak Output Limits (191.6.2.7)
The draft states: "In test mode 5 (normal operation), the transmit signal... shall be less than the peak-to-peak limits... These limits apply to all transmitted symbol sequences, including SEND_S, SEND_T, and SEND_N."
If Test Mode 5 is redefined to mean strictly "data mode (SEND_N)", it creates a logical contradiction. We cannot verify the peak output voltage of SEND_S and SEND_T using Test Mode 5 if Test Mode 5 is explicitly restricted to only the SEND_N state.

3. Test Mode Electrical Integrity (e.g., 191.7.1 and PICS)
The draft states that test modes do not alter the electrical and jitter characteristics of the transmitter "from those of normal operation."
If changed to "from those of data mode (SEND_N)", it implies that test modes only need to emulate the electrical constraints of the data payload phase. However, electrical constraints (like transmitter droop or maximum peak output) must also be respected during SEND_S and SEND_T.

4. Test Mode 5 Transmit Power (191.6.2.6)
The draft states: "In test mode 5 (normal operation), the transmit power... shall be as specified..."
Replacing "normal operation" here implies the transmit power limits only govern the SEND_N phase, when in reality the transmitter must adhere to power and PSD masks throughout the entire link initialization sequence as well.

5. Auto-Negotiation (e.g., 191.1.3)
The draft states that Auto-Negotiation is used to "determine common abilities, and configure for normal operation."
Changing this to "configure for data mode (SEND_N)" is too narrow. Auto-Negotiation configures parameters (like Leader/Follower roles and training seeds) that govern the entire link initialization sequence, not just the final data phase.

While the replacement works perfectly in some subclauses (such as when describing the PAM4 symbol alphabet in 191.3.2.2), a blanket replacement is not acceptable.

I would be happy to work with the commenter and others to review the instances of "normal operation" case-by-case to come up with improved text proposals (e.g., using "non-test operation" or "the standard link initialization and data transmission sequence" where appropriate).

Best regards,
Ragnar

To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1

To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1

To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1

To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1

Re: [802.3_ISAAC] P802.3dm D2.1: Follow-up on Comments #66, #67, and #68 (Replacing "normal operation")