Hi JC,
Thank you for sharing. I have a few comments on the proposed text.
item 20: aLlidForwardState : LLIDs don’t combine user traffic, MPCP, and OAM anymore.
1) I think for this attribute we need to clarify whether in blocked state, both upstream and downstream traffic is blocked or only upstream.
2) In 1904.1, L-ONU was analogous to LLID, since 802.3 only allowed a single LLID per ONU. So, multi-LLID ONU was defined as a C-ONU that comprised multiple L-ONUs. But with 802.3ca, this is not the case anymore. There is always a single L-ONU, but it supports multiple LLIDs. So, I think everywhere where this attribute says L-ONU, it should say LLID or ULID
3) Whether this attribute says LLID or ULID depends on whether we want to be able to put PLID and MLID into a blocked state. This seems very dangerous to me, so I’d say no. This means that blocking and forwarding states should only be applicable to ULIDs.
4) I suggest clarifying the applicable context object as follows: “The aLlidForwardState attribute is associated with the LLID objects (see 14.2.1) that represent ULIDs.”
item 21: aLlidOamFrameRate : OAM rate is per ONU now.
The only comment here is that we don’t have the MLID object defined under the Identification branch 0xDA. We only have LLID objects. So, I’d suggest wording similar to the above: “The aLlidOamFrameRate attribute is associated with the LLID object (see 14.2.1) that represents the primary MLID.”
(Primary MLID is the one assigned during registration and is the only one ONU can use to transmit OAMPDUs. There can also be a number of unidirectional (downstream only MLIDs) assed by OAM, but this attribute does not apply to them.)