Hi Could you be explicit on if the is a last call comment on the drafts (if so, it is best to reply to the last call announcement)? If this is not a comment on the last call, please keep in mind - our process is (document) contribution driven.
Thanks, Lou ________________________________ On September 23, 2024 8:10:30 AM Joey Boyd <[email protected]> wrote: All, The management specification for ONUs, ITU-T G.988 (OMCI), defines a managed entity for Ethernet Extended PM in clause 9.3.34. A subset of those counters includes the following: Frames 64 octets: The total number of received frames (including bad frames) that were 64 octets long, excluding framing bits, but including FCS. (R) (mandatory) (8 bytes) Frames 65 to 127 octets: The total number of received frames (including bad frames) that were 65..127 octets long, excluding framing bits but including FCS. (R) (mandatory) (8 bytes) Frames 128 to 255 octets: The total number of frames (including bad frames) received that were 128..255 octets long, excluding framing bits but including FCS. (R) (mandatory) (8 bytes) Frames 256 to 511 octets: The total number of frames (including bad frames) received that were 256..511 octets long, excluding framing bits but including FCS. (R) (mandatory) (8 bytes) Frames 512 to 1023 octets: The total number of frames (including bad frames) received that were 512..1023 octets long, excluding framing bits but including FCS. (R) (mandatory) (8 bytes) Frames 1024 to 1518 octets: The total number of frames (including bad frames) received that were 1024..1518 octets long, excluding framing bits but including FCS. (R) (mandatory) (8 bytes) These were taken from the histogram counters in the RMON-MIB. etherStatsPkts64Octets Counter32, etherStatsPkts65to127Octets Counter32, etherStatsPkts128to255Octets Counter32, etherStatsPkts256to511Octets Counter32, etherStatsPkts512to1023Octets Counter32, etherStatsPkts1024to1518Octets Counter32, Looking back through the list archive, I see some discussions where IEEE decided to model the counters from the RMON-MIB that corresponded with managed objects in 802.3 while leaving the remainder of the etherStats to IETF. In the earlier work on the interface extension models, there were some discussions about adding these but, at the time, it was pushed to future work as to not block progress on the draft. Is there still interest in adding these? I know that the interface extensions models are in WGLC, so the timing of this question is unfortunately the same as it was before. Best regards, Joey General Business
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
