les are. What were "established" OO principles back in 1984 are unfortunately no longer SO. The statement also indicates that the OSI application-layer architecture is not suitable as a general architecture for control layers, unless you choose to implement them in software. These conclusions indicates the danger with letting implementation concerns direct the way system architectures are defined. Furthermore, in order to support this specification technique, and as an effort to create a common residence for all types of encoding algorithms (an objective that concerns only software realization and management of network functions), RM defines encoding of ASN.1 data as a layer of its own (the presentation layer), instead of what it actually is: encoding algorithms for ASN.1-typed data (the exist- ence of other data types and alternative algorithms were initially assumed, but never realized in any network system). If the creators of the OSI RM had realized that, network designers would never have been exposed to the strange layer serv- ices, such as those offered by the OSI presentation layer. Thus, the OSI upper-layer architecture is the result of an engineering approach that aims at code generation of software implementation of control functions in networks, based on a complicated specification technique. It does not reveal neces- sary insights in network systems and how to model them. For network system mod- eling, we prefer a technique that is applicable in all cases, i.e., whether network control functions will be implemented in software or hardware, and whether the ROSE specification technique (ASN. macron) or some other technique is used. Furthermore, the technique must be useful for all types of control layers, not just for what OSI regards as "application layers." 6.2.2 ACSE, the Association Control Service Element The OSI RM approach to association handling is defined by the ACSE standard. ACSE is one of the common ASEs that are defined in the OSI application layer. If we use ACSE in AMLn, it would become 