The cssd resource within /etc/VRTSvcs/conf/config/main.cf serves a very simple purpose that is succinctly fulfilled by using the application agent.  If this placeholder resource is properly linked to depend on all of your OCR, VOTE, and datafile mountpoints -- its existence will achieve the desired result of pausing the startup of CRS until those critical mountpoints are fully online.  

The CRS start scripts invoke /opt/ORCLcluster/bin/clsinfo which is supplied by SFRAC.  That script blocks until all dependent resources of cssd are brought online.  If no cssd resource exists in VCS, clsinfo immediately returns.  As soon as clsinfo returns, CRS starts a 10 minute timer for ocssd to be up and running properly, and will reboot the system if its unsuccessful.  Without the cssd resource, VCS is essentially racing to get the mounts mounted within the 10 minute timeout.  This seemingly works when you first install a cluster, but over time of adding more disks to the system -- eventually you will find that it may take more than 10 minutes for the OS to start VCS and VCS to subsequently to get the CVM diskgroups imported and CFS filesystems mounted.  

Another common manifestation is when one particular resource faults on startup, preventing the remainder of the group from coming online.  CRS' 10 minute timeout expires and reboots the system, and that cycle repeats over and again until you manage to get logged in long enough to set the CRS entries in /etc/inittab from respawn to off.  

Similarly, running "hastop -all" will properly first shutdown CRS only if this same cssd resource is in position.  If the cssd resource is not in position, the first attempt to unmount the OCR and VOTE filesystem(s) will fail, which is immediately followed by a "umount -f".  Because CRS is still up and running but loses its access to the OCR and VOTE, it panics the system.

From the above justification, one can appreciate why we state that the cssd placeholder resource is an essential required component of your configuration.  The cssd resource isn't controlling CRS per se; its simply a glue-type resource for CRS to have visibility on when to start its 10 minute time, and for VCS to know when it's safe to unmount the CFS filesystems.

The cssd resource should also be dependent on the datafile mountpoints for any database(s) that CRS is managing.  The OCR and VOTE devices are enough to get CRS up and running, but immediately upon starting up, CRS then tries to start up the database(s) it is managing.  If the datafile mountpoints are not yet online, CRS will fail to start the database(s), requiring a manual "srvctl start database -d dbname" after those datafile mounts become available. Properly linking in all of the required dependencies to the cssd resource is therefore essential for proper CRS/SFRAC integration.