At some point, the grouping of attributes was supposed to reflect their grouping in Clause 30. There, the aMediaAvailable attribute is shown as part of the oMAU managed object class. The grouping of branch 0x07 in 1904.1/1904.4 now somewhat diverged. For example, there is no OAM management group in the 802.3. So I guess it is ok to rename this group.
Please, also note that each group has a distinct range of leaf values. I don’t know if this is critical to maintain, but if we move aMediaAvailable to another existing group, this dependency will break.
Glen
From: Marek Hajduczenia <mxhaj79@xxxxxxxxx>
Sent: Tuesday, January 17, 2023 12:02 PM
To: Glen Kramer <glen.kramer@xxxxxxxxxxxx>;
Curtis Knittle <C.Knittle@xxxxxxxxxxxxx>;
STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: Re: [1904.4 TF] 1904.4 Open action items
Hi Glen,
Attribute aPhyType (0x07/0x00-20) would have to go, indeed (together with PICS U-ME28 and T-ME28). I wonder, though, if there is much point to keep 14.3.3 MAU management as a section with just one attribute i.e., aMediaAvailable (0x07/0x00-47). The association between MAU and media is somewhat questionable. Perhaps we can rename "MAU management" to something more media related, perhaps "Medium management"?
Regards
Marek
On 1/17/23 10:30, Glen Kramer wrote:
Thank you, Marek. Are you planning to submit a comment to remove the aPhyType attribute?
From: Marek Hajduczenia <mxhaj79@xxxxxxxxx>
Sent: Monday, January 16, 2023 1:36 PM
To: Glen Kramer <glen.kramer@xxxxxxxxxxxx>; Curtis Knittle <C.Knittle@xxxxxxxxxxxxx>; STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: Re: [1904.4 TF] 1904.4 Open action items
Hi Glen,
I did review the thread you pointed out and agree with your summary. We do not need to import any MAU attributes.
As far as your question is concerned ("So, I think first we should answer whether there is any value in ONU reporting a generic class of PHY as opposed to a specific module connected to it?"), I personally do not see much value in that. A generic class could be derived from specific class that is reported, while the inverse is not possible, i.e., we cannot figure out whether it is D/U and 1/2/3 power class knowing only it is PQ type. Given that aMediaTypeCapability (RO) and aMediaType (RW) are already using specific rather than generic values, I think we're covered with the draft as it is today.
It seems to me that unless there is a valid reason to make changes, we are covered today and could simply close this AI without further changes to the draft.
Regards
Marek
On 12/16/22 13:16, Glen Kramer wrote:
I searched our past discussions on the reflector archive and it turned out we already had a very extensive discussion about the aMauType attribute back in July 2021.
The discussion started with a proposal to add aMauType to 1904.4 (we never had this attribute in 1904.1) because the 802.3ca has updated this attribute with a lot of new optical module types.
The aMauType attribute is defined in 802.3 as a RW attribute that is used for selecting a particular MAU type. There is a RO attribute aMauTypeList that shows all supported MAU types (this is what we call a “capability attribute”).
The problem with simply reusing these attributes as defined in 802.3 was that they also contained a lot of MAU types that were old, obsolete, or had no relevance to EPON.
I suggest all to review this thread: https://www.ieee1904.org/4/email/msg00147.html
As a result of this discussion, we added to D0.5 two extended attributes: aMediaTypeCapability (RO) and aMediaType (RW).
(see the contribution https://www.ieee1904.org/4/meeting_archive/2021/08/tf4_2108_hajduczenia_5b.pdf)
These attributes replace the aMauType and aMauTypeList attributes.
But the 802.3 also has these two attributes: a PhyType and aPhyTypeList – both a RO.
The 802.3 aPhyType description says “A read-only value that identifies the PHY type. The value of this attribute maps to the value of aMAUType.” But while the MAU type identifies the specific type of optical module (i.e., 50/25GBASE-PQX-D3), the aPhyType lists it as a generic class “50/25GBASE-PQ” that includes all coexistence options {G or X}, all directions {D or U}, and all power classes {1, 2, or 3}.
So, I think first we should answer whether there is any value in ONU reporting a generic class of PHY as opposed to a specific module connected to it?
If we decide to keep aPhyType, we need to bring all new PHY codepoints over to 1904.4. And we probably also need to import aPhyTypeList in this case.
But if aPhyType does not add anything useful beyond what aMediaTypeCapability and aMediaType attributes can report, maybe we should just delete it.
In either case, no need to import any MAU attributes.
Glen
From: Marek Hajduczenia <mxhaj79@xxxxxxxxx>
Sent: Thursday, December 15, 2022 6:54 PM
To: Curtis Knittle <C.Knittle@xxxxxxxxxxxxx>; STDS-1904-4-TF@xxxxxxxxxxxxxxxxx; Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Subject: Re: [1904.4 TF] 1904.4 Open action items
The first option, i.e., update both MAU and PHY attributes to match whatever combination of devices we plan to support. I am still checking to see why we would even care about MAU to begin with (I have conflicting statements being made for now)
Marek
On 12/15/22 18:41, Glen Kramer wrote:
Hi Marek,
Not exactly clear what you are proposing. Is it to update both aMauType and aPhyType tables to bring in all the latest MAU and PHY types? Or is it something else?
Glen
From: Curtis Knittle <C.Knittle@xxxxxxxxxxxxx>
Sent: Thursday, December 15, 2022 3:54 PM
To: STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: Re: [1904.4 TF] 1904.4 Open action items
Marek,
Your plan sounds reasonable to me.
Curtis
From: Marek Hajduczenia <mxhaj79@xxxxxxxxx>
Sent: Thursday, December 15, 2022 2:39 PM
To: Curtis Knittle <C.Knittle@xxxxxxxxxxxxx>; stds-1904-4-tf@xxxxxxxxxxxxxxxxx
Subject: Re: 1904.4 Open action items
Good morning, colleagues,
On item #45, which I took upon myself as Ryan's substitute, I have been looking at the way aPHY and aMAU are used in IEEE Std 802.3 and I cannot find any clear reason why we would need to even care about MAU value apart from some of legacy management attributes. Neither the MAU nor the AUI interfaces exist (apart, perhaps as notional entities for the purposes of thinking about layering the interface) in our modern PHYs and everything following Fast Ethernet is built around the MAC and PHY separation, with xMII in the middle. I think it might be one of these cases of having to just do it because of legacy reasons, closing the eyes and moving on
if we have consensus on just getting this done, i am happy to update the relevant table(s) via a comment on D1.2
Marek
On 12/14/22 09:07, Curtis Knittle wrote:
Colleagues,
Below you will find the current list of assigned and open action items.
Curtis
Curtis Knittle
VP Wired Technologies – R&D
CableLabs
desk: +1-303-661-3851
mobile: +1-303-589-6869
Stay up to date with CableLabs: Read the blog and follow us on Twitter
#whosaysicant
To unsubscribe from the STDS-1904-4-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1
To unsubscribe from the STDS-1904-4-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1
To unsubscribe from the STDS-1904-4-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1
