This is a really important point, and a great subject for discussion here in the forum.
First, the answer to your question is "yes". You can, in fact, parameterize some of these properties. (If you see a little "f" beside a field in the session properties, you can use field substitutions to fetch those values.) Note that substitution is going to happen when you start a new session using that profile -- either interactively or as part of a test case execution. But be careful because when you are using this session profile (or testbed) for starting an interactive session, some of these substitutions might not make sense. (For this reason, you may want to take advantage of the fact that some substitution commands like [get], [profile], and [param] take additional optional arguments for default values when the requested information is not available.)
However, you should really pause here and reflect. In essence, you are asking to parameterize what are effectively a set of parameters to your test case. The session profile is nothing other than a little XML file on disk containing a bunch of parameters (in the more general sense) that will be used during execution. If you want to parameterize the session properties, where are these parameters going to come from? You're probably thinking that you will pass in these parameters when you execute the test. But why not just pass in a different file appropriately? Or maybe you want to generate this file on the fly just before execution. (This is done commonly by customers with automated regression systems that decide this kind of stuff at runtime.) If your system is just choosing a testbed (or device) at runtime, then it can also just choose which file to use at runtime.
I've seen another situation where users are using iTest as not just a test case development tool, but also as a mini-regression testing tool -- meaning that you create an iTest "test case" that is really a system for running other test cases. You then want to be able to tell each test case what parameters to use on the fly when running one of these tests. And, yes, you can do the work to set up the parameters appropriately in this case.
iTest is built on the model that a testbed file represents a real physical testbed. It may use another generic testbed file as a "reference" -- meaning that the reference testbed represents a generic arrangement of equipment, and the IP addresses (and other specifics) go into the final testbed, leaving the rest of the common properties in a single file. If you are creating testbeds dynamically on the fly, then you probably also want to consider creating testbed files on the fly. But you can also dynamically choose an appropriate session profile file directly, on the fly, if you prefer. A session profile represents the information about a specific device. It may be based on a reference session profile containing more generic information about a device. Again, if you want to work at the device level, you could choose to generate a session profile file on the fly, as well.
Bottom line: You can definitely do what you are asking about. But I recommend that you proceed with caution. It might feel good to parameterize everything. But you may find that there is a much cleaner overall architecture to consider.
