tself. The descriptions of AMLn models in the present chapter cannot therefore give full justice to real AMLn models and to AMLn as a mod- elling language. 1 2. The shortages of today's standards. The models behind these case studies belong to a set of models that were initially produced as the author's private means for verifying AMLn as a language. An effect was that many common shortages of today's standards became revealed. When describing these case- studies in the present chapter it is unavoidable that these shortages become exposed, since the actual purpose with this chapter is to demonstrate the useful- ness of AMLn as a modeling and analyzing tool. The reader should, however, bear in mind that AMLn was not known when these standards were produced, and that no modeling approach was available to the creators of standards at the time. Standards could only be produced as natural lan- guage descriptions, more or less enforced by pictures. 2 Therefore, model descriptions in this chapter reveal many shortages in existing standards should not be taken as a criticism that standard workers have been doing an inferior job, and that all standards are poorly written. There are many standards that are well written with the readers' needs in mind (although there are as many that are not). Having said that, let's summarize all kinds of problems that were encountered when browsing through standards with AMLn as a torch: 1. No common terminology: This problem refers primarily ITU-T standards, since ITU-T deals with a large set of different network systems. IETF and OMG are better off since they each deal with a single architecture (the Internet and CORBA, respectively). The complete absence of common network terminology (already commented on in Chap. 1) is probably the most annoying thing with ITU-T standards. It makes Real AMLn models will be published on the Internet as soon as an AMLn modeling tool becomes available. In an upcoming book (expected to be published in 2006) the author will also focus on AMLn modeling in p