storage capacity: clarify autoscaler design

As discussed during PR review, the section was focused on local storage without
explicitly saying that. Network attached storage needs to be dealt with
differently and has a different problem (scale from zero and lacking
capacity information).

Author: pohly

keps/sig-storage/1472-storage-capacity-tracking/README.md

@@ -1200,7 +1200,7 @@ This problem can be solved by the cluster administrator. They can find out how
 much storage will be made available by new nodes, for example by running
 experiments, and then configure the cluster so that this information is
 available to the autoscaler. This can be done with the existing
-CSIStorageCapacity API as follows:
+CSIStorageCapacity API for node-local storage as follows:
 
 - When creating a fictional Node object from an existing Node in
   a node group, autoscaler must modify the topology labels of the CSI
@@ -1238,6 +1238,14 @@ components. Simpler solutions may be possible by adding support for specific
 CSI drivers into custom autoscaler binaries or into operators that control the
 cluster setup.
 
+Network attached storage doesn't need renaming of labels when cloning an
+existing Node. The information published for that Node is also valid for the
+fictional one. Scale up from zero however is problematic: the CSI specification
+does not support listing topology segments that don't have some actual Nodes
+with a running CSI driver on them. Either a CSI specification change or manual
+configuration of the external-provisioner sidecar will be needed to close this
+gap.
+
 ### Alternative solutions
 
 At the moment, storage vendor can already achieve the same goals