| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Please remove comments 22, 79 and 130 from the EZ bucket. A short description of the rationale is below: Comment 22: With the proposed change, the wording doesn’t make sense. the sentence refers to initializing the precoder to the zero state when transitioning to PAM4 encoding. The change would say “when entering PAM4 encoding” – encoding
isn’t something you “enter”. - suggest ACCEPT IN PRINCIPLE - change text to read “when transitioning to PAM4 encoding.” Comment 79: While implementations may do the interleaving and RS encoding together, the proposed change makes it look like the parity symbols for the RS-FEC are actually added after the interleaving and are not subject to the interleaver.
("… OAM field, then interleave and add 340 bits of parity for the RS-FEC, …" – the existing wording, fixing the typo, doesn’t have this problem, clearly interleaving the full RS-FEC, including the parity… “OAM field, then add 340 bits of parity for the RS-FEC,
interleave the RS-FEC symbols, …” – suggest ACCEPT IN PRINCIPLE, partially accommodated by 148. (fixes the typo) Comment 130: The proposed accept in principle doesn’t address the larger problem that this is an untestable shall. How do you test that a packet is never corrupted by a transition? If you have a finite probability of bit error, then you
WILL have packets corrupted during a transition. Naturally, the PHY state will be slightly less robust coming out of LPI, so this probability is arguably larger than during normal operation… – suggest ACCEPT IN PRINCIPLE - change text to read: "The transition to or from LPI mode should not cause any MAC frames to be lost or corrupted.". (this is consistent with 100 and 42) To unsubscribe from the STDS-802-3-NGAUTO list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGAUTO&A=1 |