Lat Call Comments on draft-ietf-hubmib-efm-mib-01.txt

Here are my Last Call comments on draft-ietf-hubmib-efm-mib-01.txt. I am looking forward for the discussions in San  Diego.

Technical Comments

T1. I expected 4.1 to be more explicit about the relationship between the EFM OAM MIB module, and the other EFM modules, beyond saying that there is no direct dependency. What it takes to manage a fully EFM interface. As we do not have a 'EFM management by SNMP framework document', some verbiage here will help.  
T2. No need to define a new TC for Dot3OamUnsigned64. The CounterBasedGauge64 can be IMPORT-ed from RFC 2856.
T3. What is the initialization value of objects with a SYNTAX of Dot3OamEventTLVData TC, before a first TLV was sent/received? 
T4. Do we need a RowStatus object in the dot3OamTable? Why are these rows created by a manager, and not automatically by the agent for an EFM OAM interface?
T5. Same question about dot3OamPeerTable
T6. However, if the dynamic row creation stays, there either MUST be one columnar object with a SYNTAX value of StorageType [RFC2579] and a MAX-ACCESS value of read-create, or else the row object (table entry) DESCRIPTION clause MUST specify what happens to dynamically-created rows after an agent restart.
T7.  DESCRIPTION clause of dot3OamPeerTable says: 'Note that there is at most one OAM peer for each Ethernet like interface'. How is the EPON case working? Is each connection considered an interface? If so the model needs to be detailed.
T8. The object dot3OamLoopbackIgnoreRx is problematic. I understand it is intended to act as some kind of security lock, but the problem is that this does not work well in multiple managers environment, where it is prone to hazards, and even DoS attacks.
T9. Use the TruthValue TC for the SYNTAX of dot3OamErrFramePeriodEvNotifEnable, dot3OamErrFrameEvNotifEnable, dot3OamErrFrameSecsEvNotifEnable
T10. The notification mechanisms defined in this MIB module (incorrectly named traps - see E21) lack a notification throttling mechanism. This needs to be defined and described, so that DoS attacks are being avoided.
T11. The Security Consideration section is incomplete. See the guidelines for security sections in MIB documents at http://www.ops.ietf.org/mib-security.html. For example, read-write or read-create objects need to be listed together with the associated security hazards created by their intentional or non-intentional mis-manipulation. 
T12. Another type of security threat that needs to be mentioned is the one caused by mis-configuring thresholds, which can be used as a DoS attack by notification flooding.




Editorial Comments

E1. There is a lack of consistency in writing 'Ethernet-like'. The first such instance is in the Introduction section, where it shows up as 'Ethernet like'. I would suggest to make the edits consistent all over with the Hub MIB practical convention.
E2. The second phrase in the first paragraph of the overview section is un-clear, partially because of the repetition of the verb 'to address'.
E3. page 3, Section 3, paragraph 4 
replace: Each optional functional group is controlled by a separate MIB table(s)
by: Each optional functional group is controlled by (a) separate MIB table(s)
E4. It is recommended to avoid using the term MIBs. Replace it by MIB modules. For example in the title, and in the text of Section 4.1
E5. page 7 at the bottom of the mapping table - dot3OamFramesLostDueToOam should be placed one line higher, so that it maps into aOAMRemoteErrFramePeriodEvent.
E6. There are still left-over instances of 'common MIB' which we decided to replace by 'OAM MIB'. For example the beginning of Section 5
E7. No need to copy the full references title in the DESCRIPTION clause of the MIB module, as they are already listed in the References section
E8. Fix the English (and Latin) in the DESCRIPTION clause of Dot3OamEventTLVData. 'The datas is interpreted ...'
E9. Many of the DESCRPTION clauses of enumerated or BITS objects do not list the significance of each enumerated value, or bit. Some of these (but maybe not all) are: dot3oamAdminState, dot3OamMode, dot3OamFucntionsSupported, dot3OamPeerMode, dot3OamPeerFunctionsSupported, dot3OamRmtErrEventFlagsData, 
E10. Many MIB object definitions of objects with a read-write, or read-create MAX_ACCESS miss a DEFAULT clause. Describing default behavior in the DESCRIPTION clauses is not enough. Some (but maybe not all) of the instances are: dot3OamAdminState, dot3oamLoopbackIgnoreRx, all objects in dot3OamEventConfigEntry
E11. There is no need to include REFERENCE "N/A" clauses. If there is no reference, there is no reference :-)
E12 In the DESCRIPTION clause of dot3OamPeerMacAddress - 'The MAC address is derived from the most recently received OAMPDU.' Does this intent to say 'Source address of the most recently...'
E13. There are a lot of definitions of different types of OAMPDU repeated again and again in the Description Clauses. There is no need to repeat these definitions, just mention them at one place.
E14. The definition of dot3OamPeerVendorInfo seems incomplete. According to [802.3ah] Section 57.11, this object has a semantics of model/version which is not mentioned here. I suggest to add this, as well as 57.11 to the REFERENCE clause
E15. DESCRIPTION clause of dot3OamLoopbackCommand - say operational(9) instead of operational.
E16. I suggest to add DISPLAY-HINT clauses where applicable, especially for counter objects
E17. DESCRIPTION clause of dot3OamLoopbackControlRx - in the first paragraph replace 'transmitted' by 'received'.
E18. DESCRIPTION clause of dot3OamErrFramePeriodThreshold - add 'during the frame period defined by the value of dot3OamErrFramePeriodWindow'.
E19. Similar for dot3OamErrFrameThreshold
E20. Eliminate repeated text between DESCRIPTION clauses in dot3OamErrFrameSecsSSummaryWindow and dot3OamErrFrameSecsSummaryThreshold
E21. Replace all 'traps' language with 'notifications' - which is the current standard SNMP and SMI terminology
E22. DESCRIPTION clauses in some of the compliance groups definitions seem to have been cut-and-pasted one from the other.
E23. in the DESCRIPTION clause of dot3OamStatsBaseGroup 'must' MUST be 'MUST'.
E24. The dates of the normative reference to the 802.3ah standard are mis-aligned. Some places it is April 2004, in the References Section it is May 2004. 




Regards,

Dan

_______________________________________________
Hubmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/hubmib