draft-ietf-hubmib-efm-cu-01 comments

Hi Ed - 

Well, you were asking for comments, so here's a bunch.  I tried to give it a good read.  Sorry it took so long to get them to you.

- Matt

====================
Architectural things

1) There's this open issue of using the vdsl/shdsl MIB or duplicating things in this draft.  I know there have been a few opinions expressed recently that we should use the vdsl/shdsl MIBs instead of duplicating, but I'm on the other side of the argument.  Although there is some agreement between the two MIBs now, the IEEE and ITU are in no way tied to manage the technologies the same.  As you point out in your draft, there are some significant functional differences between IEEE 2BASE-TL/10PASS-TS and ITU shdsl/vdsl.  I'm not clear how the differences between the two technologies can effectively be conveyed in a single MIB.  Especially as things go foward, where the ITU is likely to be much more dynamic than the IEEE in copper evolution.  

2) On the issue of separating the bonding available cross-connect into a second MIB document and generalizing it, its an interesting idea and I'm not against it.  Given the plethora of multi-pair technologies being worked on, all of which could use this function, it make sense if we successfully focus it on the broader application.   


====================
Technical things

General.  There are multiple references to C45 registers rather than the C30 attributes that control them.  I'm guessing this was started before the C30 attributes were created late in the .3ah cycle, but when a parameter exists as both a C45 register and as a C30 attribute, personal opinion is that the C30 attribute should be referenced instead of the C45 register.  

P6, 3.1.3.  The example algorithm on P6 for discovery, though I don't think is wrong, I question if its useful.  Given discovery happens only during initialization, a more useful algorithm might be to assume a PME is initializing, and to exemplify how one determines to which PAF that PME should be associated.  The algorithm as written implicitly re-initializes or holds up initialization with all of the embedded for loops.  Anyway, its not wrong, but does it help?

P8, 3.1.5.  The ifSpeed parameter is defined as the "net data rate as seen across the MII".  This definition is different than is there for any other Ethernet interface.  Generally, Ethernet interface are identified by the physical line rates, not the data rate at the MII.  E.g. you can't really send 10 Mbps worth of data on an 10BASE-T Ethernet link.  Also, by calling it "actual net data rate", it changes depending on how much data is being sent, which is probably not what you mean.  Suggestion would be to make the ifSpeed the sum of the ifSpeeds of the PMEs that are operationally "up" in the EFMCu port.  Also, the MIB doesn't say what ifSpeed should be for PMEs (assume its the data rate of the PME?).  

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.  

P9, 3.4. Says "Information on the particular flavor of EFMCu that an interface is running available from ifSpeed in the IF-MIB...".  How does the speed tell you the type?  

P9, 3.4.  Editor's note asks if we need different Mau types for -O and -R.  My response would be no because the aMauType of C30 doesn't list multiple Maus for -O/-R on EFMCu ports, and I don't think the MIB should add MAU types that don't exist in 802.3.  However, given the meaning of some parameters differs based on -O and -R (e.g. efmCuAdminProfile, for example), it seems we need the information somewhere in the EFMCu table.  

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.  

P18, efmCuTargetDataRate.  This is an interesting parameter that I don't know how to intepret.  Upstream data rate?  Downstream data rate?  Using what traffic to measure "net" rate (e.g. the Kbps rate changes depending on packet sizes)?   Seems like using the sum of the physical data rates might be less problematic from an interpretation point of view.   And if a max target is important, I would assume that a min target would be important, as would upstream and downstream.  

P19, efmCuTargetSnrMgn.  Do you think we should treat this like profiles, with a value at the EFMCu level and another at the PME level, and with a precedence defined if they're both set?  In other MIBs, target margins are often included as part of the profile, so it might be helpful to have the same override capability.  

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:)

P24, efmCuFltStatus.  On the subtype mismatch, its written as "PMEs in the aggregation group are not of the same sub-type".  Is this supposed to be that on the local device, some are -O and some are -R, or is this supposed to be that you tried to connect two -Os together?

P25, PAF counters.  Seems like it might be better to zero the counters when PAF is reset/disabled.  E.g. You can disable the PAF, change out the whole set of PMEs, re-enable it, and it look like there's been a lot of problems on that PAF because the counters weren't reset, even though those counters have nothing to do with the current PMEs.  

P28, EdNote on notifications asks if you should add more notifications from the vdsl/shdsl MIBs.  If you're looking for feedback, I'm ok either way, but if we're going the path of making this standalone w/o the vdsl/shdsl MIBs, we should probably add them here as well.  

P29, PME Notifications.  Many of the notifications (DeviceFault, ConfigInitFailure, ProtocolInitFailure) seem like they could be handled by one notification.  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.?

P37, efmCuPmeSubTypesSupported.  You say "actual mode of operation is determined by efmCuPmeAdminSubType".  Do you mean efmCuPmeOperSubType?

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?

General.  There's some inconsistency with the "Peer" attributes.  In some "Peer" attributes (e.g. efmCuPmePeerSnrMgn) you say they're not supported by -R subtypes, but in others (e.g. efmCuPeerPAFCapacity) the same wording isn't included.  You might take a pass looking for inconsistencies here.  

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.


====================
Editorial things

General.  The use of 10Pass vs 10PASS, etc. is inconsistent - might want to do a quick search & replace for one or the other.

P1, abstract: "nternets" should be "Internets"

P4, 3.1.1.  "An generic" -> "A generic"

P4, 3.1.1. "PME comprising an aggregated EFMCU port".  I think this should be "composing" (e.g. a part composes its whole, a whole comprises its parts).  

P5, 3.1.1.  Partial sentence "The efmCuAvaialbleStackTable allows to define new entries" (not sure where you're going with it or I'd make a suggestion).  

P5, 3.1.2. "is OPTIONAL and MAY not be supported."  I think the "and MAY not..." is redundant. 

P5, 3.1.3.  Might insert intro paragraph into 3.1.3 to say what discovery is.  Maybe along the lines of "EFMCu ports support a discovery operation whereby PMEs, during initialization, exchange information that can help automatically identify the PAF to which the PMEs belong (rather than pre-configuring that information).  Thus, for example, during PME initialization, a PAF entity may discover that an initializing PME should be connected to an already existing PAF, rather than being incorporated into its own PAF. "   

P7, 3.1.4.  "suceed" -> "succeed"

P8, 3.2.  "PMES" -> "PMEs"

P10, 4.2.  "comes handy" -> "comes in handy"

P13, Description.  When pointing out sections of interest, we might mention 62A and 63A as these contain the profile information.  

P15, efmCuLowBandwidth notification.  "ifINdex" -> "ifIndex", "droped"->"dropped"

P19, efmCuTargetDataRate.  efmCiPmeAdminProfile -> efmCuPmeAdminProfile

P22, efmCuPAFCapacity.  particluar->particular

P32, efmCuPAFDiscoveryCode.  Looks like a cut & paste error (you have this earlier at the EFMCu port table).  

P36, efmCuPmeCapabilityEntry.  Cut & paste error, says this is an entry in the PME Configuration table (rather than capability table).  

P37, efmCuPmeStatusEntry.  Cut & paste error, says this is an entry in the PME Configuration table (rather than status table).