Yong, thanks for the clarification. I wasn’t sure what you meant on #1 – that whole discussion of ‘system’ had me thinking you were blurring the MAC/PHY lines, and I have to think about a mod to the MAC parameter table in a PHY project.
(if you have thoughts on this, contact me offline). My comments on scope were relevant to at least #2 and #3.

I think my inconsistent use of delimiters (numbering) caused some confusion.

Three choices that I outlined.

1. CSMA/CD MAC but with the random back-off parameter limited to always {0, 1}. No changes to MAC, except for the MAC parameter table, because these are all parameterized.
PLCA changes (minor, already suggested by the contributor) to introduce a small delay and a gap on RX. I don't believe there needs any other changes. 16 collision retry means max # of stations to be 16.

2. EPON-like P2MP, and this would NOT be covered by current PAR -- my suggestion was to move PLCA access control function (so significant change to current proposal) to
MAC control sublayer. No detail nor proposal nor any victim/contributor on the table.

3. 802.11 CSMA/CA MAC -- with 802.3cg PHY, conceptually. Would work. Would not be 802.3 project as George pointed out.

Before we get too deep into this, I need to remind everyone of scope. (I think Yong understands this well, and intends properly – just trying to gauge interest). 802.3cg is an
802.3 PHY project. This means that we need to stay at the PHY layer (which includes the stretch to the Reconciliation Sublayer), but stop short of the MAC.

This means, as we discussed early on that multidrop needed to live with the 802.3 MAC.

As we discussed at earlier stages of our project, within 802.3 we have the CSMA/CD MAC, half-duplex and full-duplex (which is often not even discussed as CSMA/CD anymore), and the
variation known as EPON. For information on EPON, please see the excellent discussion Marek gave us at
http://www.ieee802.org/3/10SPE/public/adhoc/Multiaccess%20in%20Ethernet%20Passive%20Optical%20Networks.pdf . I believe the general consensus was that the EPON MAC was more complexity than our applications would bear – however, it appears Yong disagrees
with this. We adopted the Reconciliation Sublayer known as PLCA to address some of the issues with just raw half-duplex CSMA/CD.

I would like to emphasize that we are at a point in our project where we are reasonably close to a working group ballot. We have adopted baselines. Please try to be specific (and
actionable) when you make suggestions, and try to keep them in scope.

Discussions of an 802.11 MAC or 802.11-like MAC or modifications to the 802.3 MAC would be outside our scope. Please take them offline to Yong.

And if you are still on disagreeing with my concern, this message would not be relevant to you.

1. RX good while TX with COL. And while you are at it, RX [from other nodes, so more of "full-duplex" like operation] while TX
with or without COL. <== CL4 and CL2 is COMPLETELY consistent with this, BUT my assertion is that this is not guaranteed (understatement) with broad set of installed base.

Discussion: If we could distinguish this CSMA/CD 10 Mbps *SYSTEM* that is to be used with PLCA from the legacy CSMA/CD 10
Mbps *SYSTEM*, clearly enough, then we don't have any confusion WRT to PLCA PHY working with systems with old MAC. "System" is the keyword here, not "MAC". EPON has the respective MAC control sublayer and other sublayers, and when you see those, you know
you need to augment your system with Ethernet MAC with new capabilities. So the suggestion is to create new MAC parameter entry associated with this PLCA-like [set of] PHYs that has random back-off limit of 1, so MAC will retry up to 16 times (so hard limit
of 16 nodes in PLCA network) and always select between 0 and 1. This preserves the 1) intent of PLCA, which also eliminates capture effect 2) does not change the MAC (all nicely parameterized already.​)

Oh, and we need to fix the inconsistencies in the standard in 802.1AC -- maintenance request.

Alternatively, EPON-like optimization would work just as well, and I do not believe will be too complex, and all of the PLCA (TDMA
with a master) objectives would be met and also provide clearer way to manage nodes AND provide additional access-priority related QoS.

And 3rd alternative would be to use 802.11 CSMA/CA access method with our PHY. The access method DOES work, has statistical access
metrics well-studied, and mature. I do not recommend this -- too high implementation cost relative to Ethernet MAC and you get little in deterministic access. There may be other options.

The intent of this message is to gather interests in the corrective next steps (i.e. MAC parameter method). Let me know (reply),
or let us know (reply-all). Thanks!