e-primitive defines all possible negative out- comes. A more flexible method is to define two operations, checkCapREQ and serv2REQ. The user (i.e. TEC) first uses checkCapRequest(...), and the TEPC responds with a list of the capabilities of the called party. If there is a match between the parties, TEC then uses the serv2REQ. The benefit of this method is that no network resources are reserved if the calling TEC finds that the two ter- minal systems cannot support the same teleservice. This means less network load and higher probability for success when the calling party requests a call. The drawback is longer setup time. Both operation alternatives are based on the same service resource model. Thus, the bottom line with this example is that a given service resource model can be used for creating many alternative sets of operations. Thus, do not confuse a serv- ice resource model with the set of operations that are defined for a service relation. Service resource models and operation specifications are separate specifica- tion items. Thus, for any given service resource model, there are many possible sets of operations that could be defined. Operations can be more or less complex. A sim- ple operation operates on a single or a few entities, relations or properties of the service resource model, and has a more general applicability than a complex opera- tion that operates over many entities, relations or properties. On the other hand, if only a set of simple operations are defined, there will be many operations, and the service might not be perceived as user-friendly. Therefore, two recommendations are worth making: Keep service resource models simple, i.e. comprising few entities, relations and properties. A major purpose of creating the service network model is to support the creation of simple service resource models. This requirement is well-satis- fied by the service resource models in our case study. For complex service resource models, AML recommends two levels of opera- tions: basic operations (simple ope