ractice by including more full scale and complete example mod- This statement is correct as far as architecture descriptions are concerned. Certain formalisms are sometimes used, primarily for message specification (ASN.) defined by ITU-T), for inter- face specification (ROSE, defined by ITU-T; IDL defined by OMG) and for protocol test spec- ifications (TTCN, defined by ITU-T). Functional structures and behaviors are sometimes described as SDL models and MSC diagrams, both defined by ITU-T. SDL is, however, a com- mon-value language, not an added-value language. When used in standards, it is not for substi- tuting the text and pictures by a model, but to create realization models as a means for explaining features of the standard (which in reality increases the complexity of already-com- plex standards). 6.1 Introduction it extremely difficult to apply one's knowledge of one network system on to another (or in other words, knowledge management is not a part of ITU-T activ- ities). In reality, almost every single standard reinvents the same concepts, and, probably in order to be semantically accurate, provides definitions and names of its own. AMLn proves that a rather small set of concepts can be used for describing any network system on the added-value level. When using AMLn as an analysis tool, it will therefore be implacably revealed that, e.g., TCAP describes an AMLn common agent layer but defines no actor layer identifier (which creates transparency problems on the SCCP level), that MTP L3 use the term "signaling point code" for network address, that SCCP use the term "subsystem number" for access-point identifier, while MTP L3 prefers to call it "service indicator". We could go on like this and create a large list of synonyms for the few concepts that AMLn defines. 2. No common notation: ITU-T standards in particular contain quite a few pic- tures. Some basic common graphical notations could have supported the needs of users who must read and work with many standards. With the exception of efforts in the tr