# Globals

SingleEditorNoCheck:
Disabled (Forces project to be single editor)


# Main

Comment:
*** Comment submitted with the file 33723600024-T09-SG05-090525-TD-GEN-0137MSW-E.doc attached ***

Illogical
The a) 1500 V rms AC voltage is 2121 V peak. Thus the impulse should not be 1500 V, but at least 2121 V.

SuggestedRemedy:
Change 1500 V to least 2121 V, 2400 V preferred.
See Annex C of the attached

Response:
PROPOSED REJECT. 

These are well established parameters set forth by the IEEE as minimum functional requirements and are not replacements for safety (or other) requirements that may need to be met by a specific product in a specific jurisdiction.  IEC 60950-1 is only referenced for the methodologies.

Accepting this comment may make currently compliant devices already in service non-compliant.

MyBallotComment:
Illogical
The a) 1500 V rms AC voltage is 2121 V peak. Thus the impulse should not be 1500 V, but at least 2121 V.

MyBallotProposedChange:
Change 1500 V to least 2121 V, 2400 V preferred.
See Annex C of the attached


Comment:
Specifying "UTP" in the Type 1 value column excludes the use of F/UTP and S/FTP media, which are perfectly suitable for supporting Type 1 applications.

MyBallotComment:
Specifying "UTP" in the Type 1 value column excludes the use of F/UTP and S/FTP media, which are perfectly suitable for supporting Type 1 applications.


Comment:
This document meets all editorial requirements.

Response:
PROPOSED ACCEPT IN PRINCIPLE. 

Procedural comment.  Accepting it results in no change to the document.

MyBallotComment:
This document meets all editorial requirements.


# MainCSVOutput

Comment:
In Figure 76-10, IdleCount counter can overflow during a long interburst gap.

Proposed Change:
Add this line to RESET_ALIGNMENT state:
"IdleCount = DelayBound"
(use proper assignment symbol)


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2790)]
In the last Denver meeting, the number of Columns in Table 75-5 was reduced from three to two, combining PR-D1/PRX-D1 and PR-D3/PRX-D3, because those values are identical, while, in Table 75-6, PR-D2 and PR-D3 Columns still remain, although theirs are also identical.
It seems logical not to duplicate the column, indicating properly the commonality over classes. But it also seems confusing for readers to distinguish three power budget classes without seeing three Columns.
Additionally the texts, started with 'Note that there is only two groups.', are incorrect. The first group should be shared by D1 and D3, and the second group by D2.

Proposed Change:
Revive the old three-Column table for Table 75-5, and fill all the PR-D3/PRX-D3 values same as those of PR-D1/PRX-D1. Or, fill the PR-D3/PRX-D3 Column across with the text 'same as 10GBASE-PR-D1 and 10/1GBASE-PRX-D1 transmit parameters'.
Delete all the notes about 'two groups of transmit parameters' in Lines 22-25
Table 75-6 and Table 75-11 should also be revisited.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2792)]
Incorrect PHY name and clause references.

Proposed Change:
Change:
"The P2MP PHYs for the 10/10G-EPON use the 10GBASE-PR PCS (see Clause 75) and
PMA (see Clause 76). The P2MP PHYs for 10/1G-EPON use the 10GBASE-PR PCS and PMA for the downstream direction (see Clause 75 and Clause 76 respectively) and 1000BASE-X PCS (see Clause 65) for the upstream direction."
to:
"The P2MP PHYs for the 10/10G-EPON use the 10GBASE-PR PCS and PMA (see Clause 76). The P2MP PHYs for 10/1G-EPON use the 10GBASE-PRX PCS and PMA (see Clause 76)"


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2794)]
Wordsmithing

Proposed Change:
Change:
"Additionally, EFM introduces a family of Physical Layer signaling systems which are derived from 10GBASE-R, but which include a 10GBASE-PR RS, PCS and PMA adapted for 10G-EPON, along with a mandatory FEC capability, as defined in Clause 76."
to:
"Additionally, EFM introduces a family of Physical Layer signaling systems which are derived from 10GBASE-R, but which include RS, PCS and PMA sublayers adapted for 10G-EPON, along with a mandatory FEC capability, as defined in Clause 76."


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2796)]
wordsmithing/consistency

Proposed Change:
Change:
"This bit indicates that the PCS supports ...."
to
"A read of 1 in this bit indicates that the PCS supports ...."


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2797)]
wordsmithing

Proposed Change:
Change:
"(mandatory for 10/1GBASE-PRX or 10GBASE-PR)"
to
"(always reads as 1 for 10/1GBASE-PRX or 10GBASE-PR)"


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2798)]
Terminology

Proposed Change:
Change:
"The FEC decoder provides a user option to indicate an uncorrectable FEC block (due to an excess of symbols containing errors) to the PCS layer."
to:
The FEC decoder provides a user option to indicate an uncorrectable FEC block (due to an excess of symbols containing errors) to the higher layers.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2799)]
wordsmithing + incorrect reference

Proposed Change:
Change
"The register describing ability to enable forward error correction in the 10/1GBASE-PRX upstream is specified in 45.2.7.3"
to
"The register for enabling and disabling forward error correction in the 10/1GBASE-PRX upstream is specified in 45.2.8.3"


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2800)]
Clause 65 defines the RS, PCS, and PMA for 1G.
It's not the case that the RS for 10G-EPON subclause (76.2) "extends" clause 65. Though 76.2 does incorporate the P2MP preamble from clause 65.
It's probably OK. to just delete the reference to cl65.

Proposed Change:
Change:
"This subclause extends Clause 46 to enable multiple data link layers to interface with a single physical layer and Clause 65 to enable 10/1G-EPON data links, transmitting at one data rate (e.g. 10 Gb/s) and receive at
another data rate (e.g. 1 Gb/s)."
to:
"This subclause extends Clause 46 to enable multiple data link layers to interface with a single physical layer, and to enable data links which transmit at one data rate (e.g. 10 Gb/s) and receive at another data rate (e.g. 1 Gb/s)."


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2801)]
Currently, the "Delay Constraints" for the PHY layer (ie. RS, PCS, and PMA sublayers) appears in the "summary of major concepts" of the RS.
It seems more appropriate for the section to appear at the beginning of c76.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2803)]
Draft 2.2 removed the statement that the value of "alpha" for the GF used to define the RS(255, 223) code is represented bitwise as 0x02.
Some treatments/implementations of RS codes use reversed bit-ordering (cf. "Error Control Coding" by Lin and Costello pg. 564). Using the different representation of alpha will result in different Ax constants.
Hence the representation of alpha should be stated explicitly.

Proposed Change:
Change:
"alpha is a root of the binary primitive polynomial x8+x4+x3+x2+1"
to:
"alpha is a root of the binary primitive polynomial x8+x4+x3+x2+1 and is represented as 0x02"


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2804)]
The OLT control multiplexer erroneously performs the check for the PCS Parity region before it receives permission for transmission from Multipoint Transmission Control.
As a consequence there is no effective check for whether the PCS is transmitting parity - leading to transmit delay variation in excess of the maximum value of 1 TQ.
A similar problem is found in the ONU control multiplexer.
This is one of three serciou issues related to FEC handling in MPCP. The TF should evaluate these issues and resolve them in the current draft or the next one.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2805)]
The FEC_Overhead() function duplicates logic already present elsewhere in the control multiplexer - consequently unneccessary IDLEs are appended following end-of-frame.
This is one of three significant technical issues related to FEC handling in MPCP. The TF should evaluate these issues and resolve them in the current draft or the next one.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2807)]
The alignmentCorrect variable also checks for the data (rather than parity) transmission region.
This important function should be reflected in the name of the variable.za

Proposed Change:
Change "alignmentCorrect" to either "alignmentAndTransmitRegionCorrect" or perhaps "DataTransmitOK"


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2811)]
The 10 Gb/s downstream transmission uses 1574-1580 nm.......

Proposed Change:
The 10 Gb/s downstream transmission uses 1575-1580 nm.................


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2814)]
In the OLT, the PCS operates at a 10 Gb/s rate in a continuous mode. In the ONU, the PCS may operate at a 10 Gb/s rate, as specified herein (10GBASE-PR), or at a 1 Gb/s rate, compliance with Cause 65 (10/1GBASE-PRX).

Proposed Change:
In the OLT, the PCS transmit function operates at 10 Gb/s rate in a continuous mode. In the ONU, the PCS transmit function may operate at 10 Gb/s rate, as specified herein (10GBASE-PR), or at 1 Gb/s rate, compliance with Cause 65 (10/1GBASE-PRX).


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2820)]
The first group is shared by 10GBASE-PR-D1, 10/1GBASE-PRX-D1, 10GBASE-PR-D2, and 10GBASE-PRX-D2. The second group is shared by 10GBASE-PR-D3 and 10/1GBASE-PRX-D3

Proposed Change:
Change to "The first group is shared by 10GBASE-PR-D1, 10/1GBASE-PRX-D1, 10GBASE-PR-D3, and 10/1GBASE-PRX-D3. The second group is shared by 10GBASE-PR-D2 and 10/1GBASE-PRX-D2"


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2821)]
In the 3rd row of Table 75-5, Wavelength (range) 1574 to 1580 nm

Proposed Change:
Change Wavelength(range) to "1575 to 1580" nm
The same change is applied to Table 75-11


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2823)]
In Figure 76-14, there is no EOB after data and FEC.

Proposed Change:
According Figure 76-15, there should be a EOB after the last FEC codeword. So Figure 76-14 should be modified to show a EOB after the last FEC codeword.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2829)]
There is superfluous "data rate" hanging around without much need. If the value is expressed in "Gb/s", there is little doubt it is data rate.

Proposed Change:
remove "data rate" in lines 18, 21, 24, 27


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2836)]
Figure 76-3 needs minor changes. We still use 10/10 Gb/s and 10/1 Gb/s. Change as proposed below

Proposed Change:
Change "10/10 Gb/s" to "10/10G-EPON"
Change "10/1 Gb/s" to "10/1G-EPON"


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2837)]
Text says "The Idle Detection function is implemented in the PCS as depicted in Figure 76-10 for ONUs and as depicted in Figure 76-9 for OLTs." while Figure 76-9 is first in the draft. Change as proposed below.

Proposed Change:
Change to read "The Idle Detection function is implemented in the PCS as depicted in Figure 76-9 for OLT and as depicted in Figure 76-10 for ONUs."


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2841)]
Text "in either one or both directions." would seem to allow to say that 10G-EPON can perate at 10Gb/s upstream only, which is not true. Text needs clarification

Proposed Change:
Change "in either one or both directions." to "in either downstream or both downstream and upstream directions."


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2843)]
"10/1GBASE-PRX Clause 76 10/1G-EPON 10 Gb/s 64B/66B with 1 Gb/s 8B/10B" - someone reading this may think we use both coding schemes in the same data path. This needs some clarification

Proposed Change:
Change "10/1GBASE-PRX Clause 76 10/1G-EPON 10 Gb/s 64B/66B with 1 Gb/s 8B/10B" to read "10/1GBASE-PRX Clause 76 10/1G-EPON 10 Gb/s 64B/66B downstream and 1 Gb/s 8B/10B upstream". The same for line 19


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2849)]
Text reads "For 10G-EPON architectures, the XGMII is the interface used to transfer data between the MAC and the PHY." is not true since 10G-EPON also has GMII as per definitions in Clause 1.4

Proposed Change:
Change to read "For 10/10G-EPON architectures, the XGMII is the interface used to transfer data between the MAC and the PHY."


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2854)]
For TIA-455-127-A, you have already given the (year) date just before the title. Also, internationally, there is no month 00 ;)

Proposed Change:
Delete 'Date:11/00/06'. Consider deleting 'Revision:A'.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2856)]
Distributed Feedback Laser (abbreviation is used in 67A.3 and 75.5.1)

Proposed Change:
Change to
distributed feedback (no capitals, no 'laser')


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2858)]
Thanks for adding the third column in Table 45-3. I wasn't clear enough in describing how it is used in P802.3ba: it's to allow the reader to click to the definition of the register concerned.

Proposed Change:
Please change '75' to a clickable '45.2.1.11'.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2862)]
Need to update 45.2.1.6.1 PMA/PMD type selection (1.7.3:0) because you have changed from the former 4-bit PMA/PMD type selection to 5-bit PMA/PMD type selection.

Proposed Change:
Show revision of
45.2.1.6.1 PMA/PMD type selection (1.7.3:0)
The PMA/PMD type of the PMA/PMD shall be selected using bits 3 through 0.
to
45.2.1.6.1 PMA/PMD type selection (1.7.4:0)
The PMA/PMD type of the PMA/PMD shall be selected using bits 4 to 0.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2863)]
Following improvements to 31C.1, need to add two more references, either here or in Annex A.

Proposed Change:
Add ITU-T G.984 and ITU-T G.983 to the references.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2868)]
Confusing for abreviation: RS=Reconciliation Sublayer vs. RS=Reed-Solomon


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2871)]
Suggest some changes in Table 75-1 to avoid ambiguity. Line 22 actually talking about nominal operating distance, not clear what >10km and >20km actually means?

Proposed Change:
Change "Maximum reach" as "(nominal) operating distance", take out >=.
Maybe consider to add a footnote such as:
"...exceeds the operational range requirement while meeting all optical specifications and power budget is considered compliant."
(-2, +3) is confusing, suggest to change to wavelength range as 1570 to 1580.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2878)]
The description of OLT PMDs is wrong.

Proposed Change:
Change "The first group is shared by 10GBASE.PR.D1, 10/1GBASE.PRX.D1,
10GBASE.PR.D2, and 10/1GBASE.PRX.D2. The second group is shared by 10GBASE.PR.D3 and 10/1GBASE.PRX.D3." to "The first group is shared by 10GBASE.PR.D1, 10/1GBASE.PRX.D1, 10GBASE.PR.D3, and 10/1GBASE.PRX.D3. The second group is shared by 10GBASE.PR.D2 and 10/1GBASE.PRX.D2."


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2879)]
1. In the "Check Size" state of figure 77-14, when the result of the CheckGrantSize() function is divided by the tqSize, the quotient is rounded down rather than rounded up.
2. It will sometimes happen that the result of CheckGrantSize (in octet times) is larger than the number of TQ left in the grant, whereas the result of division by TqSize (ie. Rounded down) is precisely equal to the number of TQ remaining in the grant.
3. In such a case, MPCP will allow the packet to be transmitted, but the data detector in the PCS will continue to transmit data past the end of the grant. This can then cause a collision with the transmission of a subsequent ONU and a missed burst.
This issue should be addressed by the TF and resolved in the current draft or the next one

Proposed Change:
1. On page 186 line 4 Change:
----- -----
"CheckGrantSize(length) = | (fecOffset + length) / FEC_PAYLOAD_SIZE| x FEC_CODEWORD_SIZE"
to:
--- ----
"CheckGrantSize(length) = | T / tqSize |
where:
----- -----
T = | (fecOffset + length) / FEC_PAYLOAD_SIZE| x FEC_CODEWORD_SIZE"
2. In the "Check Size" state of figure 77-14, modify the expression:
"nextTxTime <= CheckGrantSize(sizeof(data_tx) + tailGuard))/tqSize"
to:
"nextTxTime <= CheckGrantSize(sizeof(data_tx) + tailGuard))"
3.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2880)]
In Draft 2.2, the 10GEPON Discovery State diagrams are instantiated on both the 10G and the 1G broadcast LLIDs.
This breaks the ability for a 10G OLT to support 1G ONUs in "dual-rate mode".
The cl77 state diagrams are supposed to be instantiated only on 7ffe and not 7fff.
This issue should be addressed by the TF and resolved in the current draft or the next one.

Proposed Change:
Change:
"Instantiation of state diagrams as described in Figure 77-19, Figure 77-20, and Figure 77-21 is performed only at the Multipoint MAC Control instances attached to the appropriate broadcast LLID(s) (0x7FFF
and/or 0x7FFE for 1G-EPON and 10G-EPON, respectively)."
to:
"Instantiation of state diagrams as described in Figure 77-19, Figure 77-20, and Figure 77-21 is performed only at the Multipoint MAC Control instances attached to the broadcast LLID (0x7FFE).


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2881)]
The equation of CheckGrantSize(length) is wrong.

Proposed Change:
Add "- fecOffset" at the end of the current one.
Correct equation is as below. See also 3av_0901_kozaki_1.pdf.
FEC_Overhead(length) = ceiling((fecOffset + length) / FEC_PAYLOAD_SIZE) * FEC_CODEWORD_SIZE - fecOffset


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2884)]
Since several drafts ago we have removed units from " Rate" column header, all entries in this column should have units added to them.

Proposed Change:
Add "Mb/s" to rate for 10PASS-TS and 2BASE-TL


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2886)]
"Two consecutive XGMII transfers provide eight characters that are encoded into one 66-bit transmission block. The burst may occasionally be required to transmit an extra 4 bytes of data, causing the burst to extend into the next grant period."
The first sentence does not provide any new information. It describes 64B/66B encoding and thus is out of place in the Data Detector section. The second sentence is technically incorrect. EPON cannot work with a burst extending into another grant period.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2887)]
In Figure 76-23, timer should follow the notation defined in 64.1.5 or in 77.1.5

Proposed Change:
1) add expiration interval to the timer in state START_TIMER
2) add brackets around timer in state START_TIMER
3) add underscore between "interval_timer" and "done" in 4 places


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2888)]
Message parameters should not have default values. The parameters are always set expicitly in generating state diagrams.

Proposed Change:
Remove "This parameter has the default value of 0" from definitions for laserOnTime and laserOffTime


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2889)]
Constund IDLE_COLUMN is not used anywhere in the draft.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2890)]
"the ONU TX clock tracks the ONU RX clock and in turn locks to OLT TX clock" is better written as
"the ONU TX clock tracks the ONU RX clock, which in turn locks to OLT TX clock"


Comment:
This document has met all editorial requirements.


Comment:
The OUI is defined by IEEE stds 802 overview and archtecture.

Proposed Change:
Change "see http://standards.ieee.org/regauth/index.html" into
"IEEE std 802-2001".


# MainOutput

Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2868)]<CR>Confusing for abreviation: RS=Reconciliation Sublayer vs. RS=Reed-Solomon


Comment:
This document has met all editorial requirements.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2863)]<CR>Following improvements to 31C.1, need to add two more references, either here or in Annex A.

SuggestedRemedy:
Add ITU-T G.984 and ITU-T G.983 to the references.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2854)]<CR>For TIA-455-127-A, you have already given the (year) date just before the title. Also, internationally, there is no month 00 ;)

SuggestedRemedy:
Delete 'Date:11/00/06'. Consider deleting 'Revision:A'.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2841)]<CR>Text "in either one or both directions." would seem to allow to say that 10G-EPON can perate at 10Gb/s upstream only, which is not true. Text needs clarification

SuggestedRemedy:
Change "in either one or both directions." to "in either downstream or both downstream and upstream directions."


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2829)]<CR>There is superfluous "data rate" hanging around without much need. If the value is expressed in "Gb/s", there is little doubt it is data rate.

SuggestedRemedy:
remove "data rate" in lines 18, 21, 24, 27


Comment:
The OUI is defined by IEEE stds 802 overview and archtecture.

SuggestedRemedy:
Change "see http://standards.ieee.org/regauth/index.html" into<CR>"IEEE std 802-2001".


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2856)]<CR>Distributed Feedback Laser (abbreviation is used in 67A.3 and 75.5.1)

SuggestedRemedy:
Change to<CR>distributed feedback (no capitals, no 'laser')


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2843)]<CR>"10/1GBASE-PRX Clause 76 10/1G-EPON 10 Gb/s 64B/66B with 1 Gb/s 8B/10B" - someone reading this may think we use both coding schemes in the same data path. This needs some clarification

SuggestedRemedy:
Change "10/1GBASE-PRX Clause 76 10/1G-EPON 10 Gb/s 64B/66B with 1 Gb/s 8B/10B" to read "10/1GBASE-PRX Clause 76 10/1G-EPON 10 Gb/s 64B/66B downstream and 1 Gb/s 8B/10B upstream". The same for line 19


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2858)]<CR>Thanks for adding the third column in Table 45-3. I wasn't clear enough in describing how it is used in P802.3ba: it's to allow the reader to click to the definition of the register concerned.

SuggestedRemedy:
Please change '75' to a clickable '45.2.1.11'.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2862)]<CR>Need to update 45.2.1.6.1 PMA/PMD type selection (1.7.3:0) because you have changed from the former 4-bit PMA/PMD type selection to 5-bit PMA/PMD type selection.

SuggestedRemedy:
Show revision of<CR>45.2.1.6.1 PMA/PMD type selection (1.7.3:0)<CR>The PMA/PMD type of the PMA/PMD shall be selected using bits 3 through 0.<CR>to<CR>45.2.1.6.1 PMA/PMD type selection (1.7.4:0)<CR>The PMA/PMD type of the PMA/PMD shall be selected using bits 4 to 0.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2796)]<CR>wordsmithing/consistency

SuggestedRemedy:
Change:<CR>"This bit indicates that the PCS supports ...."<CR>to<CR>"A read of 1 in this bit indicates that the PCS supports ...."


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2797)]<CR>wordsmithing

SuggestedRemedy:
Change:<CR>"(mandatory for 10/1GBASE-PRX or 10GBASE-PR)"<CR>to<CR>"(always reads as 1 for 10/1GBASE-PRX or 10GBASE-PR)"


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2799)]<CR>wordsmithing + incorrect reference

SuggestedRemedy:
Change<CR>"The register describing ability to enable forward error correction in the 10/1GBASE-PRX upstream is specified in 45.2.7.3"<CR>to<CR>"The register for enabling and disabling forward error correction in the 10/1GBASE-PRX upstream is specified in 45.2.8.3"


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2792)]<CR>Incorrect PHY name and clause references.

SuggestedRemedy:
Change:<CR>"The P2MP PHYs for the 10/10G-EPON use the 10GBASE-PR PCS (see Clause 75) and<CR>PMA (see Clause 76). The P2MP PHYs for 10/1G-EPON use the 10GBASE-PR PCS and PMA for the downstream direction (see Clause 75 and Clause 76 respectively) and 1000BASE-X PCS (see Clause 65) for the upstream direction."<CR>to:<CR>"The P2MP PHYs for the 10/10G-EPON use the 10GBASE-PR PCS and PMA (see Clause 76). The P2MP PHYs for 10/1G-EPON use the 10GBASE-PRX PCS and PMA (see Clause 76)"


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2794)]<CR>Wordsmithing

SuggestedRemedy:
Change:<CR>"Additionally, EFM introduces a family of Physical Layer signaling systems which are derived from 10GBASE-R, but which include a 10GBASE-PR RS, PCS and PMA adapted for 10G-EPON, along with a mandatory FEC capability, as defined in Clause 76."<CR>to:<CR>"Additionally, EFM introduces a family of Physical Layer signaling systems which are derived from 10GBASE-R, but which include RS, PCS and PMA sublayers adapted for 10G-EPON, along with a mandatory FEC capability, as defined in Clause 76."


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2884)]<CR>Since several drafts ago we have removed units from " Rate" column header, all entries in this column should have units added to them.

SuggestedRemedy:
Add "Mb/s" to rate for 10PASS-TS and 2BASE-TL


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2871)]<CR>Suggest some changes in Table 75-1 to avoid ambiguity. Line 22 actually talking about nominal operating distance, not clear what >10km and >20km actually means?

SuggestedRemedy:
Change "Maximum reach" as "(nominal) operating distance", take out >=.<CR>Maybe consider to add a footnote such as:<CR>"...exceeds the operational range requirement while meeting all optical specifications and power budget is considered compliant."<CR>(-2, +3) is confusing, suggest to change to wavelength range as 1570 to 1580.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2878)]<CR>The description of OLT PMDs is wrong.

SuggestedRemedy:
Change "The first group is shared by 10GBASE.PR.D1, 10/1GBASE.PRX.D1,<CR>10GBASE.PR.D2, and 10/1GBASE.PRX.D2. The second group is shared by 10GBASE.PR.D3 and 10/1GBASE.PRX.D3." to "The first group is shared by 10GBASE.PR.D1, 10/1GBASE.PRX.D1, 10GBASE.PR.D3, and 10/1GBASE.PRX.D3. The second group is shared by 10GBASE.PR.D2 and 10/1GBASE.PRX.D2."


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2790)]<CR>In the last Denver meeting, the number of Columns in Table 75-5 was reduced from three to two, combining PR-D1/PRX-D1 and PR-D3/PRX-D3, because those values are identical, while, in Table 75-6, PR-D2 and PR-D3 Columns still remain, although theirs are also identical.<CR>It seems logical not to duplicate the column, indicating properly the commonality over classes. But it also seems confusing for readers to distinguish three power budget classes without seeing three Columns.<CR>Additionally the texts, started with 'Note that there is only two groups.', are incorrect. The first group should be shared by D1 and D3, and the second group by D2.

SuggestedRemedy:
Revive the old three-Column table for Table 75-5, and fill all the PR-D3/PRX-D3 values same as those of PR-D1/PRX-D1. Or, fill the PR-D3/PRX-D3 Column across with the text 'same as 10GBASE-PR-D1 and 10/1GBASE-PRX-D1 transmit parameters'.<CR>Delete all the notes about 'two groups of transmit parameters' in Lines 22-25<CR>Table 75-6 and Table 75-11 should also be revisited.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2820)]<CR>The first group is shared by 10GBASE-PR-D1, 10/1GBASE-PRX-D1, 10GBASE-PR-D2, and 10GBASE-PRX-D2. The second group is shared by 10GBASE-PR-D3 and 10/1GBASE-PRX-D3

SuggestedRemedy:
Change to "The first group is shared by 10GBASE-PR-D1, 10/1GBASE-PRX-D1, 10GBASE-PR-D3, and 10/1GBASE-PRX-D3. The second group is shared by 10GBASE-PR-D2 and 10/1GBASE-PRX-D2"


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2821)]<CR>In the 3rd row of Table 75-5, Wavelength (range) 1574 to 1580 nm

SuggestedRemedy:
Change Wavelength(range) to "1575 to 1580" nm<CR>The same change is applied to Table 75-11


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2811)]<CR>The 10 Gb/s downstream transmission uses 1574-1580 nm.......

SuggestedRemedy:
The 10 Gb/s downstream transmission uses 1575-1580 nm.................


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2800)]<CR>Clause 65 defines the RS, PCS, and PMA for 1G.<CR>It's not the case that the RS for 10G-EPON subclause (76.2) "extends" clause 65. Though 76.2 does incorporate the P2MP preamble from clause 65.<CR>It's probably OK. to just delete the reference to cl65.

SuggestedRemedy:
Change:<CR>"This subclause extends Clause 46 to enable multiple data link layers to interface with a single physical layer and Clause 65 to enable 10/1G-EPON data links, transmitting at one data rate (e.g. 10 Gb/s) and receive at<CR>another data rate (e.g. 1 Gb/s)."<CR>to:<CR>"This subclause extends Clause 46 to enable multiple data link layers to interface with a single physical layer, and to enable data links which transmit at one data rate (e.g. 10 Gb/s) and receive at another data rate (e.g. 1 Gb/s)."


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2849)]<CR>Text reads "For 10G-EPON architectures, the XGMII is the interface used to transfer data between the MAC and the PHY." is not true since 10G-EPON also has GMII as per definitions in Clause 1.4

SuggestedRemedy:
Change to read "For 10/10G-EPON architectures, the XGMII is the interface used to transfer data between the MAC and the PHY."


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2836)]<CR>Figure 76-3 needs minor changes. We still use 10/10 Gb/s and 10/1 Gb/s. Change as proposed below

SuggestedRemedy:
Change "10/10 Gb/s" to "10/10G-EPON"<CR>Change "10/1 Gb/s" to "10/1G-EPON"


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2801)]<CR>Currently, the "Delay Constraints" for the PHY layer (ie. RS, PCS, and PMA sublayers) appears in the "summary of major concepts" of the RS.<CR>It seems more appropriate for the section to appear at the beginning of c76.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2814)]<CR>In the OLT, the PCS operates at a 10 Gb/s rate in a continuous mode. In the ONU, the PCS may operate at a 10 Gb/s rate, as specified herein (10GBASE-PR), or at a 1 Gb/s rate, compliance with Cause 65 (10/1GBASE-PRX).

SuggestedRemedy:
In the OLT, the PCS transmit function operates at 10 Gb/s rate in a continuous mode. In the ONU, the PCS transmit function may operate at 10 Gb/s rate, as specified herein (10GBASE-PR), or at 1 Gb/s rate, compliance with Cause 65 (10/1GBASE-PRX).


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2837)]<CR>Text says "The Idle Detection function is implemented in the PCS as depicted in Figure 76-10 for ONUs and as depicted in Figure 76-9 for OLTs." while Figure 76-9 is first in the draft. Change as proposed below.

SuggestedRemedy:
Change to read "The Idle Detection function is implemented in the PCS as depicted in Figure 76-9 for OLT and as depicted in Figure 76-10 for ONUs."


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2889)]<CR>Constund IDLE_COLUMN is not used anywhere in the draft.


Comment:
In Figure 76-10, IdleCount counter can overflow during a long interburst gap.

SuggestedRemedy:
Add this line to RESET_ALIGNMENT state:<CR>"IdleCount = DelayBound"<CR>(use proper assignment symbol)


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2803)]<CR>Draft 2.2 removed the statement that the value of "alpha" for the GF used to define the RS(255, 223) code is represented bitwise as 0x02.<CR>Some treatments/implementations of RS codes use reversed bit-ordering (cf. "Error Control Coding" by Lin and Costello pg. 564). Using the different representation of alpha will result in different Ax constants.<CR>Hence the representation of alpha should be stated explicitly.

SuggestedRemedy:
Change:<CR>"alpha is a root of the binary primitive polynomial x8+x4+x3+x2+1"<CR>to:<CR>"alpha is a root of the binary primitive polynomial x8+x4+x3+x2+1 and is represented as 0x02"


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2823)]<CR>In Figure 76-14, there is no EOB after data and FEC.

SuggestedRemedy:
According Figure 76-15, there should be a EOB after the last FEC codeword. So Figure 76-14 should be modified to show a EOB after the last FEC codeword.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2886)]<CR>"Two consecutive XGMII transfers provide eight characters that are encoded into one 66-bit transmission block. The burst may occasionally be required to transmit an extra 4 bytes of data, causing the burst to extend into the next grant period."<CR>The first sentence does not provide any new information. It describes 64B/66B encoding and thus is out of place in the Data Detector section. The second sentence is technically incorrect. EPON cannot work with a burst extending into another grant period.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2798)]<CR>Terminology

SuggestedRemedy:
Change:<CR>"The FEC decoder provides a user option to indicate an uncorrectable FEC block (due to an excess of symbols containing errors) to the PCS layer."<CR>to:<CR>The FEC decoder provides a user option to indicate an uncorrectable FEC block (due to an excess of symbols containing errors) to the higher layers.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2887)]<CR>In Figure 76-23, timer should follow the notation defined in 64.1.5 or in 77.1.5

SuggestedRemedy:
1) add expiration interval to the timer in state START_TIMER<CR>2) add brackets around timer in state START_TIMER<CR>3) add underscore between "interval_timer" and "done" in 4 places


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2890)]<CR>"the ONU TX clock tracks the ONU RX clock and in turn locks to OLT TX clock" is better written as<CR>"the ONU TX clock tracks the ONU RX clock, which in turn locks to OLT TX clock"


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2807)]<CR>The alignmentCorrect variable also checks for the data (rather than parity) transmission region.<CR>This important function should be reflected in the name of the variable.za

SuggestedRemedy:
Change "alignmentCorrect" to either "alignmentAndTransmitRegionCorrect" or perhaps "DataTransmitOK"


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2881)]<CR>The equation of CheckGrantSize(length) is wrong.

SuggestedRemedy:
Add "- fecOffset" at the end of the current one.<CR>Correct equation is as below. See also 3av_0901_kozaki_1.pdf.<CR>FEC_Overhead(length) = ceiling((fecOffset + length) / FEC_PAYLOAD_SIZE) * FEC_CODEWORD_SIZE - fecOffset


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2805)]<CR>The FEC_Overhead() function duplicates logic already present elsewhere in the control multiplexer - consequently unneccessary IDLEs are appended following end-of-frame.<CR>This is one of three significant technical issues related to FEC handling in MPCP. The TF should evaluate these issues and resolve them in the current draft or the next one.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2804)]<CR>The OLT control multiplexer erroneously performs the check for the PCS Parity region before it receives permission for transmission from Multipoint Transmission Control.<CR>As a consequence there is no effective check for whether the PCS is transmitting parity - leading to transmit delay variation in excess of the maximum value of 1 TQ.<CR>A similar problem is found in the ONU control multiplexer.<CR>This is one of three serciou issues related to FEC handling in MPCP. The TF should evaluate these issues and resolve them in the current draft or the next one.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2879)]<CR>1. In the "Check Size" state of figure 77-14, when the result of the CheckGrantSize() function is divided by the tqSize, the quotient is rounded down rather than rounded up.<CR>2. It will sometimes happen that the result of CheckGrantSize (in octet times) is larger than the number of TQ left in the grant, whereas the result of division by TqSize (ie. Rounded down) is precisely equal to the number of TQ remaining in the grant.<CR>3. In such a case, MPCP will allow the packet to be transmitted, but the data detector in the PCS will continue to transmit data past the end of the grant. This can then cause a collision with the transmission of a subsequent ONU and a missed burst.<CR>This issue should be addressed by the TF and resolved in the current draft or the next one

SuggestedRemedy:
1. On page 186 line 4 Change:<CR>----- -----<CR>"CheckGrantSize(length) = | (fecOffset + length) / FEC_PAYLOAD_SIZE| x FEC_CODEWORD_SIZE"<CR>to:<CR>--- ----<CR>"CheckGrantSize(length) = | T / tqSize |<CR>where:<CR>----- -----<CR>T = | (fecOffset + length) / FEC_PAYLOAD_SIZE| x FEC_CODEWORD_SIZE"<CR>2. In the "Check Size" state of figure 77-14, modify the expression:<CR>"nextTxTime <= CheckGrantSize(sizeof(data_tx) + tailGuard))/tqSize"<CR>to:<CR>"nextTxTime <= CheckGrantSize(sizeof(data_tx) + tailGuard))"<CR>3.


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2888)]<CR>Message parameters should not have default values. The parameters are always set expicitly in generating state diagrams.

SuggestedRemedy:
Remove "This parameter has the default value of 0" from definitions for laserOnTime and laserOffTime


Comment:
[Resubmitted from January 2009 meeting (see D2.2 comment #2880)]<CR>In Draft 2.2, the 10GEPON Discovery State diagrams are instantiated on both the 10G and the 1G broadcast LLIDs.<CR>This breaks the ability for a 10G OLT to support 1G ONUs in "dual-rate mode".<CR>The cl77 state diagrams are supposed to be instantiated only on 7ffe and not 7fff.<CR>This issue should be addressed by the TF and resolved in the current draft or the next one.

SuggestedRemedy:
Change:<CR>"Instantiation of state diagrams as described in Figure 77-19, Figure 77-20, and Figure 77-21 is performed only at the Multipoint MAC Control instances attached to the appropriate broadcast LLID(s) (0x7FFF<CR>and/or 0x7FFE for 1G-EPON and 10G-EPON, respectively)."<CR>to:<CR>"Instantiation of state diagrams as described in Figure 77-19, Figure 77-20, and Figure 77-21 is performed only at the Multipoint MAC Control instances attached to the broadcast LLID (0x7FFE).


# TypeList

TypeList:
[CommentType] In ("TR", "ER", "GR", "T", "E", "G")


TypeList:
[CommentType] In ("TR", "ER", "GR") AND [ResponseStatus] Not In ("C", "Z")


TypeList:
[CommentType] In ("TR", "ER", "GR") AND [ResponseStatus] In ("C","Z")


TypeList:
[CommentStatus] In ("D") AND [ResponseStatus] In ("W")


