tees an early inconsistent and erroneous view, as the specification of the network system as a whole is concerned. 5. Too many functions in a single layer or standard document; Some standard doc- uments represent a reasonably sized part of a whole network system, no matter which conceptual modeling view is applied. There are however too many that do not, resulting in single documents that may contain several hundreds pages each. An examples of this is the SCCP standard. This layer comprises a functionality that, compared to the Internet architecture, integrates DNS, TCP, and UDP func- tionality in a single layer. Another example is the V5.1 standard that manages to describe six layers in a single document. 6. Creating implementation models as explanation models: The lack of intelligibil- ity in many standards is sometimes dealt with by describing a possible imple- mentation model (sometimes, but not always, using SDL as the modeling language). However, such models are not substitutes for anything in the stand- ard. In the author's opinion they merely increase the complexity of already com- plex standards, and should be taken as a sign of that an added-value modeling language is badly needed. In this chapter, the TCAP sublayer model is such an example (see Sect. 6.3). Block diagrams are used for the same purpose in, e.g., SS7 standards (e.g., MTP L2 and MTP L3) and ATM standards (e.g., SSCOP). For example, an AMLn model of MTP reveals that this architecture comprises two traffic layers (MTP L2 and MTP L3) and two (related) management layers. The architecture is described by two documents. This looks acceptable until one realizes that the description of the layers is almost randomly spread over the two documents (which is the result of the L2/L3 layer interface not being specified). The authors of these document obviously realized the problem, but, instead of break- ing up the document into a number of separate documents for the layers and layer interface specifications, they produced extensive diagrams of an assum