comments on draft-ietf-hubmib-efm-cu-mib-02.txt

Hi Ed - 

Had some old and new comments on the EFM CU MIB draft.  

First, some old ones.  I submitted these against the -01 version and am not sure what decision was made with respect to them and why.  They don't look to be addressed in the new draft but I might have missed something.  A couple were discussed at the August(?) meeting and were supposed to go to the list, but nothing was ever discussed on the list.  

- Matt

<start old comments>

P17, efmCuPAFDiscoveryCode.  Why is this read-write?  Seems like this should be generated by the system rather than provisioned by management.  E.g. the system can select a unique code based on MAC addresses, OUIs, etc.  Setting this via management seems more problematic than beneficial.  Its probably nice as read-only for troubleshooting reasons, but I don't get the r/w.

P17, efmCuAdminProfile. Why do we say "current operating Subtype of the PCS" instead of just "the subtype of the PCS"?.  Can that subtype change?  Also, given we're having profiles on the EFMCu and PME level, would it be better to have the PME level override the EFMCu level?  If we switched precedence order (PME wins over EFMCu), we don't lose any management function, but we allow the manager to set a default for all PMEs with the ability to override speicfic PMEs with something else.  So we get more function, and don't lose anything.  

P8, 3.1.5.  On ifAdminStatus for the PAF, we say setting it to "up" re-initializes all PMEs associated with it.  Does setting the ifAdminStatus of the PCS to "down" take down all PMEs as well, or does it just stop aggregation from occuring?  Does the ifAdminStatus of the PMEs automatically change with that of the EFMCu port?  There's still some more clarity needed here.  I guess I don't really care which way it ends up, but we need to say one way or the other.  

P21, efmCuPeerPAFSupported.  Seems like it might be worthwhile to have a third value (unknown) given thats whats in 30.11.1.1.9.  Makes the mapping easier:)

P29, PME Notifications.  Many of the notifications (DeviceFault, ConfigInitFailure, ProtocolInitFailure) seem like they could be handled by one notification- e.g. there was a failure and a reason for the failure.  You're including the FltStatus anyway - do we need multiple notifications?  I know in some you include more info (for example, the profile index), but does getting an integer index into a profile table help the notification receiver to know what happened?  Also, are there any rules/guidelines on using these with the standard linkDown ifTable notification?  Can/should someone send both, one or the other, does it matter, etc.?

P39, efmCuPmeFltStatus.  Should this be zero'd when the link is up or initializing (there's no current faults in these oper states).  Or is this intended to hold the last fault?

P44, EfmCu2BConfProfileEntry.  The definitions here allow a completely rate adaptive profile (set data rate to 0), but not a restricted data rate profile (e.g. between 2 and 4 Mbps).  Supporting min/max rates would be good.

</end old comments>





Now for some new comments.

General.  There's a ton of Editors notes scattered throughout indicating that certain parts aren't finished.  I guess the draft isn't really ready for last call?

General.  Should reference final EFM doc not D3.3.  

P4, 3.1.1.  What is the "configured bit-rate for a pre-activated modem"?  What is the ifSpeed of a PME when it is in a rate adaptive mode?  

P4, 3.1.1.  There are a couple definitions of the ifSpeed of the PCS
 a) ifSpeed is "rate across the MII" (in 3.1.5)
 b) ifSpeed is "sum of the current operating data rates of all modemsn in the aggregation group without the 64/65B encapsulation overhead and PAF overhead but accounting for the interframe gap"
I'd prefer we just go with the first one consistently.  If you want to state somewhere what goes across the MII, thats fine, but it seems like there are two definitions laying out there.

P4, 3.1.1.  On the examples ("the following configuration shall have no frame loss..."), it would seem preferable to eliminate the "shall" as we're not really dicating anything.  Maybe more along the lines of: "When using the stated definition of ifSpeed for the PCS, there would be no packet loss in the following configurations..."

P29-30, Notifications.  Some of the defined notifications are events, others are threshold crossing.  For the threshold crossing, is the notification to be generated when the threshold is crossed in each direction, only when its exceeded, etc.?  E.g. there are linkUp/linkDown notifications defined in other MIBs for when things go up and down, its not clear if the threshold notifications should be sent on clear as well.  I think they should be, but the text doesn't really indicate one way or another.  

P42, status table. In the efmCuPmeStatusTable, its not clear what should be returned for some of the objects when the link is down or initializing.  Some of the objects have text (efmCuPmeOperProfile) while others don't (efmCuPmeSnrMargin, etc.).  Should probably consistently say what to return when the PME is down.  



Editorial

P10 3.4:  "most of the MAU characteristics is not" => "are not"

P38 efmCuPmeStatsuTable - description indicates its the configuration not the status (cut & paste error)

P44, efmCuPme2BConfProfileEntry (ditto for the 10P version) - Another cut&paste error?  Reads like the profile entry for the PCS not the PME.