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

Re: [802.3_NGAUTO] [EXT] [802.3_NGAUTO] Thoughts on the remaining comments - RE: Comment Status file as of end of today's meeting



George,

 

I’m not following your logic on moving the scrambler prior to RSFEC and interleaving.   

Since the scrambler is sidestream and is seeded during training, there’s no error propagation or interaction with the RS-FEC and interleaving.   The scrambling should be done last prior to mapping and is independent of number of interleaves.

 

Brett

 

 

 

 

From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: Monday, July 15, 2019 4:30 PM
To: STDS-802-3-NGAUTO@xxxxxxxxxxxxxxxxx
Subject: [EXT] [802.3_NGAUTO] Thoughts on the remaining comments - RE: Comment Status file as of end of today's meeting

 

External Email


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

george@xxxxxxxxxxxxxxxxxxxx

 

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