| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
All – my apologies for not being able to be there today and Tuesday.
I have provided Natalie and Steve with text for comment 239 as well as some input on making the annex informative. Please know I am perfectly OK with your editing in my absence.
I have also looked over the remaining comments and have a few thoughts for the group to consider:
Comment 285 – vendor-specific bits – the database indicates that the group needs to decide whether to allocate all the additional bits. I suggest the group allocate the bits. If they are needed later, they can always be yanked back – however, if they are unused, they generally don’t get allocated.
Comment 4 – use of “should” notes 2 instances to be decided:
>> on page 99, lines 17-19, there are two “should’s” regarding initialization of the precoder, that may be needed to be made shalls. The task force needs to discuss this.
- These definitely need to be made “shalls”. Not doing this in 10GBASE-T led to problems….
>> page 134 L12 change "should be" to "is" (rx_lp_ping “should be” looped back – but this appears automatic in the state diagram Figure 149-25 p137 L25) (would need to become ‘is’)
- The state diagram is clear, this is loaded into the tx_oam<0>< 3> in LOAD_TRANSMIT_PAYLOAD and looped back – make it “is”.
Comment 81 – is the interleave the same in both directions – I see no reason it needs to be, and, in fact, it might benefit by not being the same in both directions.
Comment 97 – I’m not sure if this has been decided, because it says “REJECT” (not proposed), but the status is “W”, but I would change “The commenter is encouraged to submit a comment to Maintenance to add this to Clause 44. If this is approved, a new comment can be submitted to ch to add this.” To “IF the commenter wishes to pursue this, he should submit a maintenance request to clause 44, which, if maintenance agrees, might be passed to the 802.3ch Task Force.” It’s not an obvious error, it’s a change to the scope of an informative table, so I don’t think we need to encourage extra work…
Comment 127 – this one gets me thinking – it’s late at night as I write this, but it seems that we probably should be scrambling BEFORE RS-FEC encoding and interleaving, If we don’t, it seems that we need to do RS-FEC encoding / interleaving | scrambling | transmission | reception | de-interleaving | RS-FEC decoding | re-interleaving | de-scrambling | de-interleaving. Either that or we have to have parallel de-scramblers for the de-interleaved descrambler phases which can be done, but need to be specified. Maybe it’s just too late at night….
Comment 138 – Informative channel annex - IF there is consensus to provide some sort of informative channel annex, we need to add something to the draft now as a placeholder to keep this in scope. Chris & Haysam have a skeleton. Even that with an editor’s note is sufficient.
Comments 2 & 199 – add a disclaimer paragraph to the front of the annex explaining that this is suggested behavior for consistent use of the OAM channel, for example: “149B.1 Purpose
This annex describes a suggested assignment of the OAM status bits for use with the Clause 149 MultiGBASE-T1 PHYs. Suggested bit behaviors, specified by state diagrams, and bit assignments in the OAM frame are detailed in this annex for informative purposes to enable consistent use of the OAM channel. Use of these specific assignments and the behaviors specified by the state diagrams is implementation dependent.”
Comments 206 & 207 – a better way to specify this, and one the optical guys, like Piers, have used is to say at the point where you are specifying the parameter – “When measured according to the procedure in annex …. The … shall be…”. And then take the shall out of the annex.
MDI stuff – it looks like your all converging in the right direction. If you can finish, don’t wait for me.
Good luck!
-george
George A. Zimmerman, Ph.D.
Chair, IEEE P802.3cg 10Mbps Single Pair Ethernet Task Force
President & Principal Consultant
CME Consulting, Inc.
Experts in PHYsical Layer Communications
1-310-920-3860
From: NATALIE WIENCKOWSKI <NWIENCKOWSKI@xxxxxxx>
Sent: Monday, July 15, 2019 6:06 PM
To: STDS-802-3-NGAUTO@xxxxxxxxxxxxxxxxx
Subject: [802.3_NGAUTO] Comment Status file as of end of today's meeting
Dear NGAUTO participants,
A comment file that shows the progress from today has been updated to our website.
You can look at the "ResponseStatus" column in the Excel file report to determine which comments are completed.
C - Final
W - Proposed
Z - Proposed Reject - Withdrawn
Natalie
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
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
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