| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
All, Please be advised that we have uploaded the comment resolution files from today’s meeting, so that you can see the progress so far.
https://www.ieee802.org/3/cp/public/2009/index.html I also have revised the contribution on the RS-FEC issue to fix a few typos, and the agenda to fix a wrong date.
At the meeting, there were two issues that we would like to gather additional views on, as detailed below.
The driving comment is #32, which points out that a lot of the 10G test material is old and outdated. The suggested remedy is to not reproduce this old stuff (thereby propagating the oldness), and go back to just referencing the
material where it sits now. But we know that there were comments to 2.0 that directed us to include all the old material, so there is a conflict. (One note: this comment does not apply to 25G and 50G test methods, where are included in cl 159 and 160 and
are being improved in other comments yet to be reviewed. This only addresses 10G).
To look at these comments critically, doing it either way is technically equivalent. It’s the same test, ultimately, that will be done. This is more of a style question. Also, the 10G tests, however old, are still
in-force in the standard. If there is truly something wrong with them, shouldn’t that go into a maintenance request? In my humble individual opinion, I would like to go back to the referencing style (only for 10G), and reduce the amount of text in clause
158. At this point, I do not expect to get any help from contributors to fix up the 10G material (unlike the 25G and 50G, where we are already getting good input). So, it is better to let sleeping dogs lie, and just reference the old stuff. Any comments?
Other suggestions? Please speak up!
The presentation that explained the issue was presented at the meeting. The suggested way forward is to add XSBI interfaces to clause 108 RS-FEC (both upper and lower interfaces). This would be done in the style
of Clause 74, which also supports multiple interfaces to interface with multiple speeds. We also note that this is one of the proposed remedies that is proposed in comment 52, so I would expect it satisfies the commenter. Any comments on this approach?
Any opposition? Please let us know, so your voice can be heard. Thank you, Frank E. To unsubscribe from the STDS-802-3-NGBIDI list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGBIDI&A=1 |