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

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



Hi George,

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.  

We can take out the shall in the annex and just write ... "the test methodologies to be used to measure...."  as you proposed.

With the main body text to be "when measured accoding to the procedure in the annex." is a little weak. This means I could use any other procedure as well, but I think people should not use absorbing clamp method or similar, because the test methodology may not be appropriate for the relatively high frequency range, which may lead to results not be comparable to triaxial method or beeing not very well reproducable. 

 If it is still made clear, that the specified electrical requirements refer to the specified testsetup, I am also fine with George's proposals.

Best regards

Thomas


Am Di., 16. Juli 2019 um 04:03 Uhr schrieb George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>:

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