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

 



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.   

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

T2. No need to define a new TC for Dot3OamUnsigned64. The CounterBasedGauge64 can be IMPORT-ed from RFC 2856. 

Will fix.  

T3. What is the initialization value of objects with a SYNTAX of Dot3OamEventTLVData TC, before a first TLV was sent/received?  

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?  

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 

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.  

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. 

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.  

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. 

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?  

T9. Use the TruthValue TC for the SYNTAX of dot3OamErrFramePeriodEvNotifEnable, dot3OamErrFrameEvNotifEnable, dot3OamErrFrameSecsEvNotifEnable 

Fine w/me, will do.  

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. 

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.  

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. 

Not a problem to add.    


Editorial Comments



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

- Matt

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