This is probably a bit overdue, but I was just chatting with a customer who can make this switch:
DII has two Brocade FOS Fibre Channel Switch data collector options:
"Fibre Channel Switches" - this collector type uses SSH for inventory data, and SNMP for performance. This collector type supports an ABSURD range of FOS firmware (yay!), back to 4.something, but there can be substantial complexities with configuring SNMP (boo!) on FOS. You may be forced into using SNMPv3 for performance by any of:
What FOS firmware you are running
Whether you actively use Virtual Fabrics (have ports assigned to > 1 VF on a physical asset)
"FOS REST" - this collector type uses HTTP(S) REST API calls for both inventory and performance data - this basically means if you get inventory working, performance will magically Just Work
So, why are we having this discussion?
FOS introduced their REST API with FOS 8.2.... but there are a few gaps that only got filled with 9.0 - XISL visibility, and routing. So, the DII FOS REST collector supports 8.2+, but we are blind to XISLs and routing unless you get to 9+.
So:
If your entire environment is 9.0+ -> you can switch entirely to FOS REST
If your environment is a mix of 8.2+ -> you have to assess if you use XISLs OR routing. If you use either, you should use the CLI+SNMP collector. You can, however, think about the various islands in your environment - if you have no routing/XISLs in your branch offices, you COULD use FOS REST there. Where you could have pain is trying to mix+match collector types inside of an interconnected environment using XISLs or routing - if you are using our FOS REST collector against a 8.2.x device that cannot tell us about the full extent of the logical configuration, sadness may result - DII may not be able to understand in the interrelationships due to the lack of source data inherent with 8.2
FOS 8.1 or earlier - you need to stay with the CLI+SNMP based collector
