William, the intent on 197 was just to remove the shalls from the descriptive paragraph, but as they are germane to the larger fix, it would be best they not be in the EZ bucket.
Natalie – please remove 197 from the EZ bucket, and group it with comments 196, 198, and 115 in the link sync topic. It would be best if they were considered as a group (and the presentation and offered text
does that). They’re all part-and-parcel the same thing.
While 195 is related too, I believe 195 is OK in the EZ bucket, – it’s much simpler and just relates to getting the requirement statement editorially correct.
George Zimmerman, Ph.D.
President & Principal
CME Consulting, Inc.
Experts in Advanced PHYsical Communications
george@xxxxxxxxxxxxxxxxxxxx
310-920-3860
From: William Lo <will@xxxxxxxxxx>
Sent: Wednesday, March 4, 2026 11:39 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: [802.3_ISAAC] IEEE P802.3dm request removal from EZ bucket
Hi Natalie,
Below are items I like to remove from the EZ bucket and reasons why.
|
Comment #
|
Reason for removal from EZ
|
|
161
|
OK in principle removing -V1 but -T1 should be -T1/V1
|
|
64
|
Cannot delete this. This tells the bit order in a RS symbol. Page 102 line 7 tells the symbol order and not the bit order of the symbol.
|
|
180
|
For the low speed path it needs to indicate interleaverDepth and PrecodeDepth in addition to OAMen so that the high speed transmitter can comply with the high speed
receiver request
|
|
70
|
This was a clarifying remark on what to do with the OAM field during training. If this is not there then the question becomes is the OAM active during training.
If so when should it be active. When should the receiver be active? Setting to all 0s clarifies and simplifies all this.
|
|
129
|
Related to 70 and 192
|
|
192
|
The suggested remedy is even more clarifying vs comments 70 and 129.
|
|
133
|
The remedy is not quite true. See figure 201-12 in page 98.
The training frame is send in place of the aggregated 64/65.
THe 65 bits are placed per figure 201-16. But there is no sense of mapping XGMII to 65-bits as discussed in the PCS section.
|
|
127
|
Are we removing figure 201-16 in its entirety, or just the bottom half of the diagram. I prefer the figure as is. However if we want to remove the bottom half
then the "65-bit infofield" label in the diagram should be change to "65-bit infofield control block"
|
|
96
|
We should keep this section here. Perhaps say something like: PMA_state<7:6> greater than 01 is reserved for future use.
|
|
113
|
The remedy is not 100% correct. Propose reject.
Page 120 line 37 defines the SEND_S signal precisely for LEADER.
For the FOLLOWER it is a single SEND_S pulse following reception of SEND_S pulse from the LEADER.
|
|
197
|
Is this EZ bucket item simply replacing the text in the remedy or accepting the PDF contents wholesale?
|
Thanks,
William
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