Keeping the analogy of renting physical infrastructure in mind, I think it is completely sufficient to expose operations in the API for defining network membership (which clearly sets up virtual networks between VMs) and static IP addresses or "acquire via DHCP" for the actual interfaces. This is like specifying which cables to connect to which interface, which is a pure infrastructure-related issue.
This is very much where I was heading - all we need is identifiers for the virtual networks ('red', 'blue'), etc, not any verbs or configuration of these themselves.
VM1: eth0 connected to "blue" network, static IP 192.168.0.1 eth1 connected to "red" network, DHCP
VM2: eth0 connected to "blue" network, DHCP
VM3: eth0 connected to "red" network, static IP 123.123.123.123
Note that the static IPs and DHCP are configuration of the servers' network interfaces, not of the network itself. The _only_ reference to the network itself is the identifier "red" or "blue" - so it needs only a noun, not any verbs or attributes. 'Active' networks with actual behaviours in the network object (e.g. a DHCP server in the network, attributes to configure that server, verbs to control the server) might also be possible as vendor extensions, but aren't the base case. Richard.