behavioral aspects of interest are defined by abstract protocols of LSMs. The behavior that an AMLn abstract protocol exhibits can be simple or show any degree of complexity. The general method for behavior specification that is This concept reveals a strong (but misguided) ambition to create interface definitions that can support software code generation, once the behaviour is known! The author had preferred an approach that could support network designers in actually specifying the behaviour of control layers (which inevitably requires a state machine approach). 6 Applying AMLn applied in AMLn is therefore state-machine-oriented, e.g., the one that is defined by AMLs. Through the definition of meta-primitives, the AMLn LPM need, and has no knowledge of this behavior. The LPM has of course a behavior of its own, but that does not interfere with the behaviour of the LSMs it sup- ports. This is not SO in the OSI application layer, however. When an operation is defined in ROSE (by an ASN.1 operation macro, included in an ASN.1 applica- tion context macro), it can define other operations as child operations, regarding itself as a parent operation. The idea was to support behavior descriptions of "peer relations" between application layer elements. By recursively applying this principle, one assumed that all possible sequences of operations in an appli- cation layer protocol could be defined in an application context specification (an approach that is as far from OO as you can get). There are two major flaws with this approach: 1. There is no way to define behavior in terms of the states of the LSM. 2. It can give a correct description of behavior only for positive responses, i.e., only if the response of an RO-INVOKErequest is an RO-RESULT Tconfirmation that carries a positive response (which, due to the way OSI defines its primitive types, is only apparent if you scrutinize the LSM event that is carried). Since in reality layer behavior is completely centred around the state of a layer, and since negative responses