Appendix 4.2            Original and Modified Texts

 

Text A – Amplifier Noise (AN)

Text B – Security (Sec)

Text C – Broadcast Networks (BN)

Text D – The File Service Interface (FSI)

Text A – Amplifier Noise (AN)

Original Modified
7.1

In almost every area of measurement the ultimate limit of detectability of weak signals is set by noise - unwanted signals that obscure the desired signal. Even if the quantity being measured is not weak, the presence of noise degrades the accuracy of the measurement. Some forms of noise are unavoidable (e.g. real fluctuations in the quantity being measured), and they can be overcome only with the techniques of signal averaging and bandwidth narrowing, which we will discuss in chapter 15.
Other forms of noise (e.g. radiofrequency interference and "ground loops") can be reduced or eliminated by a variety of tricks, including filtering and careful attention to wiring configuration and parts location. Finally, there is noise that arises in the amplification itself, and it can be reduced by through the techniques of low-noise amplifier design. Although the techniques of signal averaging can often be used to rescue a signal buried in noise, it pays to begin with a system that is free of preventable interference and that possesses the lowest amplifier noise predictable.
We will begin by talking about the origins and characteristics of the different kinds of noise that afflict electronic circuits. Then we will launch into a discussion of transistor and FET noise, including methods for low-noise design with a given signal source, and will present some design examples. After a short discussion of noise in differential and feedback amplifiers, we will conclude with a section proper on grounding and shielding and the elimination of interference and pickup.

7.11 Origins and kinds of noise
Since the term noise can be applied to anything that obscures a desired signal, noise can itself be another signal ("interference"); most often, however, we use the term to describe "random" noise of a physical (often thermal) origin. Noise can be characterized by its frequency spectrum, its amplitude distribution, and the physical mechanism responsible for its generation.

7.10

In almost every area of measurement the ultimate limit of detectability of weak signals is set by unwanted signals - noise - that obscure the desired signal. The presence of noise degrades the accuracy of the measurement, even if the quantity being measured is not weak. Some forms of noise (e.g. real fluctuations in the quantity being measured) can be overcome only with the techniques of signal averaging and bandwidth narrowing, which we will discuss in chapter 15, and they are unavoidable.
Other forms of noise (e.g. radiofrequency interference and "ground loops") can be reduced or eliminated by a variety of tricks, including careful attention to wiring configuration and parts location, and filtering. Finally, there is noise that arises in the amplification itself, and it can be reduced by the techniques in designing low-noise amplifiers. It pays to begin with a system that is free of preventable interference and possesses the lowest amplifier noise predictable, although the techniques of signal averaging can often be used to rescue a signal buried in noise.
We will begin by talking about the origins and characteristics of the different kinds of electronic circuit-afflicting noise. Then we will launch into a discussion of transistor and FET noise, and some design examples including methods for low-noise design with a given signal source. We will conclude with a section on grounding and shielding and the elimination of interference and pickup, after a short discussion of noise in differential and feedback amplifiers.

7.11 Origins and kinds of noise
Since the term noise can be applied to a desired signal obscured by anything, noise can itself be another signal ("interference"); most often, however, we use the term to describe physical (often thermal) originated "random" noise. Noise can be characterized by the physical mechanism responsible for its generation, its frequency spectrum, and its amplitude distribution.

Top

Text B – Security (Sec)

Original Modified
7.1 Introduction

Security measures must be incorporated into computer systems whenever they are potential targets for malicious or mischievous attacks. This is especially so for systems that handle financial transactions or confidential, classified or other information whose secrecy and integrity are critical. In Figure 7.1, we summarize the evolution of security needs in computer systems since they first arose with the advent of shared data in multi-user timesharing systems of the 1960s and 70s. Today the advent of wide-area, open distributed systems has resulted in a wide range of security issues.
Figure 7.1 Historical context: the evolution of security needs

1965-75 1975-89 1990-99 Current
Platforms Multi-user timesharing computers networks Distributed systems based on local network The Internet, wide-area services The Internet + mobile devices
Shared resources Memory, files. Local services (e.g. NFS), local networks. Email, web sites, Internet commerce Distributed objects, mobile code
Security requirements User identification and authentication Protection of services Strong security for commercial transactions Access control for individual objects, secure mobile code
Security management environment Single authority, single authorization database (e.g. /etc/passwd) Single authority, delegation, replicated authorization databases (e.g. NIS) Many authorities, no network-wide authorities Per-activity authorities, groups with shared responsibilities

The need to protect the integrity and privacy of information and other resources belonging to individuals and organizations is pervasive in both the physical and the digital world. It arises from the desire to share resources. In the physical world, organizations adopt security policies that provide for the sharing of resources within specified limits. For example, a company may permit entry to its buildings for its employees and for accredited visitors. A security policy for documents may specify groups of employees who can access classes of documents or it may be defined for individual documents and users.
Security policies are enforced with the help of security mechanisms. For example, access to a building may be controlled by a reception clerk, who issues badges to accredited visitors, and enforced by a security guard or by electronic door locks. Access to paper documents is usually controlled by concealment and restricted distribution.
In the electronic world, the distinction between security policies and mechanisms remains important; without it, it would be difficult to determine whether a particular system was secure. Security policies are independent of the technology used, just as the provision of a lock on a door does not ensure the security of a building unless there is a policy for its use (for example, that the door will be locked whenever nobody is guarding the entrance). The security mechanisms that we shall describe do not in themselves ensure the security of a system. In Section 7.1.2, we outline the requirements for security in various simple electronic commerce scenarios, illustrating the need for policies in that context. As an initial example, consider the security of a networked file server whose interface is accessible to clients. To ensure that access control to files is maintained, there would need to be a policy that all requests must include an authenticated user identity.
The provision of mechanisms for the protection of data and other computer-based resources and for securing networked transactions is the concern of this chapter. We shall describe the mechanisms that enable security policies to be enforced in distributed systems. The mechanisms we shall describe are strong enough to resist the most determined attacks.
The distinction between security policies and security mechanisms is helpful when designing secure systems, but it is often difficult to be confident that a given set of security mechanisms fully implements the desired security policies. In Section 2.3.3, we introduced a security model that is designed to help in analysing the potential security threats in a distributed system.

7.1 Introduction

Security measures must be incorporated into computer systems whenever they are potential targets for attacks that are malicious or mischievous. This is especially so for systems that handle confidential, classified or other information whose secrecy and integrity are critical, or financial transactions. In Figure 7.1, we summarize the evolution of computer system security needs since they first arose in the 1960s and 70s with the advent of multi-user timesharing systems with shared data. Today the advent of wide-area, open distributed systems has resulted in a wide range of security issues.
Figure 7.1 Historical context: the evolution of security needs

1965-75 1975-89 1990-99 Current
Platforms Multi-user timesharing computers networks Distributed systems based on local network The Internet, wide-area services The Internet + mobile devices
Shared resources Memory, files. Local services (e.g. NFS), local networks. Email, web sites, Internet commerce Distributed objects, mobile code
Security requirements User identification and authentication Protection of services Strong security for commercial transactions Access control for individual objects, secure mobile code
Security management environment Single authority, single authorization database (e.g. /etc/passwd) Single authority, delegation, replicated authorization databases (e.g. NIS) Many authorities, no network-wide authorities Per-activity authorities, groups with shared responsibilities

The need to protect the integrity and privacy of information and other resources belonging to individuals and organizations is pervasive in both the digital and the physical world. It arises from the desire to share resources. In the physical world, organizations adopt security policies that provide specified limits for the sharing of resources. For example, a company may permit entry to its buildings for accredited visitors and for its employees. A security policy for documents may be defined for individual users and documents or it may specify groups of employees who can access classes of documents.
Security policies are enforced with the help of security mechanisms. For example, access to a building may be controlled by a reception clerk, who issues accredited visitors with badges and enforced by electronic door locks or by a security guard. Access to paper documents is usually controlled by restricted distribution and concealment.
In the electronic world, the distinction between security policies and mechanisms remains important; without it, it would be difficult to determine whether a particular system was secure. Security policies are independent of the use of technology, just as the provision of a lock on a door does not ensure building security unless there is a policy for its use (for example, that whenever nobody is guarding the entrance the door will be locked). The security mechanisms that we shall describe do not ensure the security of a system in themselves. In Section 7.1.2, we outline in various simple electronic commerce scenarios the requirements for security, illustrating in that context the need for policies. As an initial example, consider the security of a networked file server whose interface is accessible to clients. To ensure that access control to files is maintained, there would need to be a policy that all requests must include an authenticated user identity.
The provision of mechanisms for the protection of data and other computer-based resources and for securing networked transactions is the concern of this chapter. We shall describe the mechanisms that enable security policies in distributed systems to be enforced. The mechanisms we shall describe are strong enough to resist the most determined attacks.
It is often difficult to be confident that a given set of security mechanisms fully implements the desired security policies but the distinction between security policies and security mechanisms is helpful when designing secure systems. In Section 2.3.3, we introduced a security model that is designed to help in analysing the potential security threats in a distributed system.

Top

Text C – Broadcast Networks (BN)

Original (not seen by any respondents) Modified (seen by all respondents)

14.2 BROADCAST NETWORKS


Chapter 12 (section 12.3.2) introduced the concept of broadcast networks and the most common topologies. Remember that broadcast networks use a channel to which all the users are connected, so all the users receive any transmission made on the channel. The only wide area broadcast networks all use radio broadcast, either relatively local up to a few hundred kilometres or over much further distances using satellite transmission. Section 14.2.1 will examine this further. The most common examples of broadcast networks are local area networks. These may use twisted pair cables, coaxial cable or optical fibre cable as their transmission medium (see section 13.6). Comparison between twisted pair and coaxial cable is not helpful because there are many variants of each to meet the different requirements of bandwidth, loss, noise immunity, etc. In general, coaxial cable has higher noise immunity and bandwidth, but the cable is stiffer (which may or may not be helpful depending on whether it is being surface mounted or pushed through ducts). Both types can adequately serve most LAN environments, but coaxial cable has been dropping out of use. Optical fibre is particularly suited to environments which have high levels of electromagnetic radiation, or to meet demands for very high speeds of transmission. However, it is more difficult to tap into, which makes it more difficult and expensive for the installation of a LAN.
LAN protocols have developed into the following layers:
* physical layer identical to ISO layer 1
* medium access control (MAC) layer to manage communications over the link
* logical link control (LLC) layer, which provides a form of multiplexing to handle multiple-source data (a number of users attached to one host).
In addition, the LLC layer assembles the data into a frame complete with address and error checking bits and disassembles them on receipt.
For a particular LLC protocol there may be several different MAC options provided, since this is the protocol layer in which the differences in topology are involved.
The major standards activity for LAN networks has been developed by the US Institute of Electrical and Electronic Engineers (IEEE). Their work has been organised into a number of committees, of which some are as follows:
* 802.2 Logical link control (LLC)
* 802.3 CSMA/CD networks (Ethernet, etc.)
* 802.5 Token ring networks

14.2


Chapter 12 (section 12.3.2) introduced the concept of broadcast networks and the most common topologies. Remember that broadcast networks use a channel to which all the users are connected, so all the users receive any transmission made on the channel. The only wide area broadcast networks all use radio broadcast, either relatively local up to a few hundred kilometres or over much further distances using satellite transmission. Section 14.2.1 will examine this further. The most common examples of broadcast networks are local area networks. These may use twisted pair cables, coaxial cable or optical fibre cable as their transmission medium (see section 13.6). Comparison between twisted pair and coaxial cable is not helpful because there are many variants of each to meet the different requirements of bandwidth, loss, noise immunity, etc. In general, coaxial cable has higher noise immunity and bandwidth, but the cable is stiffer (which may or may not be helpful depending on whether it is being surface mounted or pushed through ducts). Both types can adequately serve most LAN environments, but coaxial cable has been dropping out of use. Optical fibre is particularly suited to environments which have high levels of electromagnetic radiation, or to meet demands for very high speeds of transmission. However, it is more difficult to tap into, which makes it more difficult and expensive for the installation of a LAN.
LAN protocols have developed into the following layers:

physical layer identical to ISO layer 1
medium access control (MAC) layer to manage communications over the link
logical link control (LLC) layer, which provides a form of multiplexing to handle multiple-source data (a number of users attached to one host)
In addition, the LLC layer assembles the data into a frame complete with address and error checking bits and disassembles them on receipt.
For a particular LLC protocol there may be several different MAC options provided, since this is the protocol layer in which the differences in topology are involved.
The major standards activity for LAN networks has been by the US Institute of Electrical and Electronic Engineers (IEEE). Their work has been organised into a number of committees, of which some are as follows:

802.2 Logical link control (LLC)
802.3 CSMA/CD networks (Ethernet, etc.)
802.5 Token ring networks

Top

Text D – The File Service Interface (FSI) (original version seen by all respondents)

5.1.1.
For any file service, whether for a single processor or for a distributed system, the most fundamental issue is: What is a file? In many systems, such as UNIX and MS-DOS, a file is an uninterpreted sequence of bytes. The meaning and structure of the information in the files is entirely up to the application programs; the operating system is not interested.

On mainframes, however, many types of files exist, each with different properties. A file can be structured, for example, as a sequence of records with operating system calls to write or read a particular record. The record can usually be specified by giving either the value of some field or its record number (i.e., position within the file). In the former case, the operating system either uses hash tables to locate records quickly, or maintains the file as a B-tree or other suitable data structure. Since most distributed systems are intended for environments in UNIX or MS-DOS, most file servers support the notion of a file as a sequence of bytes rather than as a sequence of keyed records.

A file can have attributes, which are pieces of information about the file but which are not part of the file itself. Typical attributes are the access permissions, owner, creation date, and size. The file service usually provides primitives to read and write some of the attributes. For example, it may be possible to change not the size (other than by appending data to the file), but the access permissions. In a few advanced systems, it may be possible to create and manipulate in addition to the standard attributes user-defined ones.

Another important aspect of the file model is whether files can be modified after they have been created. Normally, they can be, but in some distributed systems, the only file operations are CREATE and READ. Once a file has been created, it cannot be changed. Such a file is said to be immutable. Having files be immutable makes it much easier to support file replication and caching because it eliminates all the problems associated with having to update all copies of a file whenever it changes.

Protection in distributed systems uses essentially the same techniques as in single-processor systems: access control lists and capabilities. With capabilities, each user has a kind of ticket, called a capability, for each object to which it has access. The capability specifies which kinds of accesses are permitted (e.g., writing is not allowed but reading is).

All access control list schemes associate a list of users who may access the file and how with each file. The UNIX scheme, with bits for controlling reading, writing, and executing each file separately for the owner, owner’s group, and everyone else is a simplified access control list.

File services can be split into two types, depending on whether they support a remote access model or an upload/download model. In the upload/download model the file service provides only two major operations: read file and write file. The former operation transfers an entire file to the requesting client from one of the file servers. The latter operation transfers an entire file from client to server, the other way. Thus the conceptual model is moving whole files in either direction. The files can be stored as needed on a local disk or in memory.

The other kind of file service is the remote access model. In this model, the file service provides a large number of operations for moving around within files (LSEEK), opening and closing files, examining and changing file attributes, reading and writing parts of files, and so on. Whereas in the upload/download model, the file service merely provides transfer and physical storage, here the file system runs on the servers, not on the clients. As well as eliminating the need to pull in entire files when only small pieces are needed, it has the advantage of not requiring much space on the clients.

Top