Subject: [Hubmib] Lat Call Comments on draft-ietf-hubmib-efm-mib-01.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 28 Jul 2004 20:57:32 +0300

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-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: "Matt Squire" <[email-masked]>
Date: Fri, 30 Jul 2004 11:26:24 -0400

Technical Comments

I'm not sure why this is needed, or even good.  At the last meeting (or sometime in the last cycle), it was decided to make what used to be "EFM Common MIB" into "EFM OAM MIB".  By doing so, we significantly reduced the scope from the MIB that pulls things together, to just another MIB.  Note that I think that was the right thing to do, but then when it came to interdependencies and relationships between this and the EFM Cu MIB or this and the EFM PON MIB, there aren't many.  EFM OAM has some general assumptions on the underlying Ethernet interface (full duplex), and some EFM functions have some specific requirements on the PHYs (e.g. unidirectional operation), but thats not a relationship with either of the other EFM technologies directly, only indirectly.  

These assumptions/requirements of OAM are talked about in the MIB definition. I can certainly try to better bring them out in the introductory text.  

OAM, from my perspective anyway, is a single protocol that can be enabled on an Ethernet interface.  Like all other protocols, it does what it does.  Its not specific to any interface (e.g. works on non-EFM interfaces), its not a complete management solution for EFM or non-EFM interfaces.  It seems more logical, from my perspective anyway, to have the interfaces each talk about whats needed to manage them - because they're very different.  

And thats not just me being lazy:)

Will fix.  

Good point.  I guess what I'll do is tie the validity of the TLV values back to the timestamp of when they were received.  So that if the timestamp isn't valid, you must return all zeros.  Otherwise, you're ok.  

Would that address your concern?  

You're right, they don't need a RowStatus as they're automatically created by the system.   I thought I zapped this during the last revision, but I must have missed it.  I think you had this comment on the earlier rev.  

This is not an OAM specific issue.  EPON, to any protocol operating over it, must have the ability to look like a collection of p2p links (e.g. applies to STP, to OSPF, etc.).  There should be some function in the EPON MIB related to point-to-point emulation, which addresses the issues that make EPON different than other Ethernet-like interfaces for OAM and anything else.  

I'm not sure where you're going with this. When OAM is enabled, one end of a link has the capability to put the other end of the link in loopback mode (under certain conditions).  That can be a good thing, or a bad thing, but its a thing, an ability that exists. 

This object is an attempt to put controls on that ability.  It is used to tell one end of a link not to listen to attempts by the other end of a link to put itself in loopback mode.  So its an attempt to give management controls that can prevent bad things from happening under administrative control.  

I can certainly delete the object, but that makes the problem worse, not better, as there are no longer administrative controls on the function.  As to multiple managers problem, I don't see how thats different for this parameter than any other - multiple managers can always lead to conflict/contention.  And I don't understand the DoS attack part - what are you getting at with that?  

So I guess I'm not understanding where you would like to see this go.  Deleted?  Improved?  How?  

Fine w/me, will do.  

Will add.   Note that these events can happen at most once a second by definition of the 802.3ah, but I didn't correctly describe the bounds on thresholds in the descriptions in this draft.  

Not a problem to add.    

Editorial Comments

I'll run thru all the editorials.  I'm sure they're fine.  

- Matt