EFM-CU-MIB - issues
Edward Beili <[email protected]>
| Newsgroups | gmane.ietf.hubmib |
|---|---|
| Message-ID | <[email protected]> |
Hi,
Below are some issues I ran into while working on EFM-CU-MIB. I would
appreciate any feedback.
Regards,
-Edward
Issues list for the EFM-CU-MIB
---------------------------------------------
1. Is current use of ifStackTable for actual cross-connects between
PMEs and PCSs (read-write) and efmCuAvailableStackTable for cross-connect
capability (read only), the right choice?
An alternative would be to use ifStackTable to describe cross-connect
capability
and efmCuAvailableStackTable to describe actual connections, so that the
cross-connect
action would be done in the EFM-CU-MIB by modifying the
efmCuAvailableStackTable
(and not in IF-MIB).
2. I've decided not to reference HDSL2-SHDSL-LINE-MIB and
VDSL-LINE-MIB but to define all the relevant objects in this MIB
(because of the differences between SHDSL/VDSL versions described in
those MIBs and DSL versions used in EFM, and for the purposes of
simplicity and name consistency). Again, is it the right choice?
3. Notifications - should we add more and which ones?
Currently defined are:
- efmCuPmeLineDefect,
- efmCuPmeLineAtnCrossing,
- efmCuPmeRemoteLineAtnCrossing,
- efmCuPmeSnrMgnCrossing,
- efmCuPmeRemoteSnrMgnCrossing
Additional ones could be:
- efmCuPmePerfES,
- efmCuPmePerfSES,
- efmCuPmePerfCRCanomalies,
- efmCuPmePerfLOSWS,
- efmCuPmePerfUAS,
- efmCuPmeDeviceFault,
- efmCuPmeLocalPowerLoss
4. MAU-MIB shall be augmented to include the following new values for
ifMauType (instances of dot2MauType):
- dot3MauType2BaseTL - voice grade UTP Phy specified in Clause 61
and 63
- dot3MauType10PassTS - voice grade UTP Phy specified in Clause 61
and 62
Question: Should we include -O/-R subtype?
5. I would like to have both possibilities for EFMCu PME configuration:
- A single profile for 10PassTS/Up to 5 profiles for 2BaseTL
(each profile is a specific set of values for parameters
comprising a profile, e.g. DataRate, Region, PSD, Constellation
for 2BaseTL)
- Set each parameter separately.
For the meantime I've defined a profile variable in addition to
parameter variables.
Questions:
- Should we have only one possibility?
- Should we have both? Some error handling is needed when both
Profile and parameters are specified, could be as simple as
precedence rules.
6. In EFM Draft D3.1 a new layer at the PME is defined called TC, with
corresponding error counters. Should we define a new Sequence in
the MIB for TC or put all these counters under current
efmCuPmeEntry Sequence (I'm leaning toward 2nd option).