Technical | Yes | 390 | 14.4.11.3 | 1 | This comment addresses Action Item #36, i.e., "Not clear what specific difference this attribute makes at the ONU. Can it be set in conflict with aPhyType (0x07/0x00-20)? The attribute purpose and function need to be clarified." | I examined the use case for the original DPoE amendment request that resulted in the aMediaType attribute.
In certain implementations, a single service port is connected to an Ethernet switch, exposing two UNI ports: one implemented as an RJ45 interface and another one implemented as an SFP/SFP+ pluggable cage. Only one is expected to be active at any time. From the ONU perspective, it can see only a single service port, but an operator needs a way to *identify and control* which UNI port is being used: the RJ45 one or the pluggable one. The purpose of the aMediaType is to achieve precisely that operator required function, allowing the operator to identify and enable specific UNI port type on this service port. This achieves maximum implementation flexibility.
On the other hand, the aPhyType attribute is derived from the IEEE Std 802.3, 30.3.2.1.2 attribute and it is a read-only attribute, which identifies only the UNI port PHY type connected to the given service port. There is no mechanism to switch between BASE-X and BASE-T (for example) to achieve the functionality addressed by the aMediaType attribute. As such, I recommend for the attribute *not* to be removed.
There are a couple of improvements to the aMediaType attribute (14.4.11.3) that could be done, though:
- Add the missing space in "This attribute represents themedia type for a media-selectable" (note "themedia")
- Rename "sfp" to "pluggable" (since implementations can easily use sfp+ cage) |