ansport network area (see ITU-T G.805) and the frequent use of SDL for implementation models (see bullet 6 below), no common notation is used. At best, an explanation is given for notations used in a particular standard document. 3. WHAT but not WHY: Each single standard describes, down to the bit level, how network functions and elements are supposed to function. This is fine (and nec- essary), but for everybody trying to understand a network system (or part of it), the first question is "Why?", i.e., what problem does this function solve, and why is this particular solution needed (especially if solutions to the particular problem exist in older systems, which is most likely the case)? As ITU-T stand- ards are concerned, they give, almost without exception, no answers to such questions. For others who are not the inventors of a standard, this implies that other sources of information have to be searched for in order to acquire the deep knowledge that makes it possible to understand the standard (a profitable busi- ness for many authors of tutorial books, including the author of this book). 4. Fragmentation but no overview: In the absence of a modeling technique that can help in managing the complexity of network systems, its complete specification is normally broken down to a large number of standard documents (not always according to the picture of layer and network structures that, e.g., OSI RM and AMLn support). Over the years, the author has also noticed a tendency to break down a single document into a large and deep paragraph structure, where some paragraphs may be as small as a single sentence. Behind this approach lies probably a mis- guided expectation that system's complexity can be managed by fragmenting text. Fragmentation of a whole requires defined relations between the parts, however. Regarding standards, this means that they are crowded with references between paragraphs and between documents, which is rather annoying for the 6 Applying AMLn reader (to say the least), and almost certainly guaran