The way CLI NEDs work is that they contain a yang model that enables the storing parsing, generation of the config for a particular operating system. For CLI NEDs the model contains all the config we have ever been asked to support for that operating system, so for any device and any version.
The resulting yang model typically can parse combinations of features that exist in multiple versions or for example will let you attempt to configure combinations of features that do not exist on any specific device. However it also does not support every configuration option on any specific device, because all we develop is what is requested from us. So we do not have full coverage of all config of any specific device or version.
Because the NED supports a mixture of configuration options from many devices and versions we don't call out a specific set of devices or specific software versions that are supported.
The big advantage for the customer is that they have not bought a NED for version X of device Y, so if they decide to use a new software version or change to a different device model, we still support them, and if they need support for any line of config not currently supported they simply open a TAC case and we add it.
To determine all the options that are supported, the best way is to look at the yang files for the NED. The model defines those options, although its not so easy to read. Another way is to look through the CHANGES file, since everything we support was added via a a change
Usually though its more interesting to find out which parts of an existing configuration file of a router are not supported by the NED. This is easy. You set the device trace mode to raw
#set devices device mydevice trace raw
#commit
and do a sync-from operation. The logs for the device (llook for logs/*mydevice*) will contain messages for all lines of config which were not parsed (look for 'ignore')
