Packetizer Logo
Understanding OSI

1 Organizational matters

1.1 The subject

OSI (Open Systems Interconnection) represents the totality of protocol definitions and associated additional texts which provide international standardization of many aspects of computer-to-computer communication. In theory it extends from the lowest level of signalling techniques to high-level interactions in support of specific applications.

The work on OSI was initiated in the late 1970s, and came to a level of maturity in the late 1980s and early 1990s. At the time of writing this text, there are many OSI standards in place, and implementations of the more popular standards are available as commercial products. Wide-scale purchase and use of a wide-range of OSI products is still however not yet a reality, with the free Internet (TCP/IP-based) software still having the greater market share.

It is important to recognise that the main focus of the early OSI work was largely on autonomous computer systems, performing general-purpose stand-alone computing functions, and occasionally using communications with other systems to support some application task. In the 1990's, however, we increasingly see a client-server approach to computing, with highly specialised systems performing one or a small number of functions which could not be performed without the use of communications. Some of the OSI products, especially the X.400 electronic mail relay systems and the X.500 Directory systems will also be specialised server systems. Even in these cases, however, the host computer systems would normally run as stand-alone systems, with the communications function used solely to support the X.400 or X.500 activity that the product implements.

A new area of international standardization of computer communication was established in the late 1980s and began to show some of its initial shape in the early 1990s. This is standardization of Open Distributed Processing (ODP). The ODP work has a slightly different emphasis from the OSI work, and is sometimes (perhaps incorrectly, perhaps not) seen to be either an advance on OSI or in competition with OSI. It is beyond the scope of this text to give a detailed treatment of ODP and of its relationship to OSI. All that can be done here is to warn the reader to "Watch this space." It is at least possible that the ODP work will merely build on OSI, with new application layer protocols for distributed processing (whatever that comes to mean) using the lower layers of OSI in the normal way. It is also possible that ODP will produce different (perhaps better, perhaps not) ways of doing what has already been standardised in OSI. There is no detailed treatment of ODP in this text, the focus of which is OSI, but there is a further brief mention in chapter 11.

This Chapter would not be complete without some discussion of the authoritative "root" document that provides a pointer to all the standards that make up OSI. Such a document does not exist! There is a broad consensus on what standards can sensibly be regarded as in line with the OSI work and effectively part of OSI, but nowhere is there even a definition of the properties of such a standard, still less is there a definitive index. One could almost argue that OSI is in the eye of the beholder, and has no independent existence!

1.2 The actors

1.2.1 Collaboration

The work on OSI progressed, largely independently, in both CCITT and ISO (see following sections on CCITT and ISO) in the late 1970s and early 1980s. This came to a head in late 1983 when there existed two very large documents, one an ISO working draft and one a CCITT working draft, both called (roughly) The Basic Reference Model for Open Systems Interconnection, and both describing a seven-layer "architecture" (the 7-layer model). But ... they were completely different texts. The technical similarities (once differences of wording and style were eliminated) were greater than the technical differences, but important differences did exist.

In 1983, CCITT said to ISO: "The world does not need two (different) Reference Models for OSI. We will tear up the CCITT draft and adopt the ISO text. But, please, ISO, would you make one or two minor technical changes to your text to accommodate the needs of CCITT." And that is how the world got the CCITT Reference Model for Open Systems Interconnection!

1984 was the watershed, and from that point on collaboration between ISO and CCITT on OSI (and latterly on ODP) has become increasingly strong, reaching the point in the early 1990s where almost all international meetings on collaborative work are at least formally (and often in practice) joint meetings of the two organizations, with a single text being progressed by a single Editor, and in due course a single document being published under the logos of the two organizations. At the time of writing this text, we have yet to see the first joint publication, the tradition in the 1980s being separately published texts, always with separate editorial style, often separately typeset and hence with different errors introduced, and sometimes with actual technical differences (usually identified in an annex), particularly in relation to conformance statements.

The situation was aggravated by different balloting processes in the two organizations, and by CCITT's tradition of publishing its Recommendations at the end of four year Study Periods, and generally at no other time, as opposed to the ISO approach of publishing when and only when the work was considered to be complete. This led in the early 1980s to the publication of CCITT Recommendations that were often immature, and underwent significant corrections and extensions in the next study period, against a very long gestation period for ISO Standards, but with a somewhat better quality in the initial publication. The charge was made: "Anything ISO can do, CCITT can do quicker: Anything CCITT can do, ISO can do slower but better: CCITT does the work, ISO rubber stamps." With the increasing collaboration in the late 1980s and the early 1990s, and finally with the publication of joint texts, these charges are likely to be things of the past, with the strengths of both organizations being brought into play.

1.2.2 The club of the PTTs

CCITT is The International Telegraph and Telephone Consultative Committee (CCITT comes from the spelling of the title in French). In crude terms, it was, in the 1980s and early 1990s, the club of the providers of the public telephone and telegraph systems of the world, including both the PTTs (arms of government providing postal and telephone services) and the RPOAs (Registered Private Operating Authorities) - private organizations such as Bell Telephone, or AT&T, providing telephone services in countries allowing private operators in this area. It is entirely due to the activities of CCITT in agreeing technical standards that world-wide telephone and facsimile communication has become a reality.

The name CCITT ceased to exist at the end of 1992, with a major reorganization of the ITU, but this book talks predominantly about CCITT, for that was the name used in the formative years of OSI.

Formally, CCITT was a sister organization to the CCIR (The International Radio Consultative Committee) that allocated radio frequencies, both being part of the International Telecommunications Union (ITU), which is itself an agency of the United Nations.

A major reorganization of ITU at the end of 1992 replaced CCITT and CCIR with new organizational structures. The corresponding organization to CCITT was called The Telecommunications Standardization Sector of the ITU. This was initially abbreviated for a short time to ITU-TS, but shortly after the current abbreviation of ITU-T was adopted. There is also a Radiocommunication Sector (ITU-R) and a Telecommunication Development Sector (ITU-D), but these are not treated further in this book.

CCITT (and its successor ITU-T) only claimed to provide Recommendations, whilst ISO produces International Standards. However, because CCITT is within the UN structure, CCITT Recommendations were binding on members of the UN wishing to provide international public services in areas covered by CCITT Recommendations. This in some ways made CCITT Recommendations more powerful than ISO Standards, whose take-up is entirely voluntary.

The major subdivision of CCITT was into Study Groups identified by roman numerals (Study Group VII is one of the more important for OSI work). (ITU-T has similar divisions, but arabic numerals are now used, so Study Group VII has become Study Group 7). The Study Groups tend to have a relatively permanent existence, while lower-level structures (Rapporteur Groups) are more transient. It is the Study Group that forms the basis for most international meetings (almost all at the headquarters of CCITT/ITU-T in Geneva), with all the Rapporteur Groups (and their subdivisions) of the Study Group meeting together over a period of two to three weeks.

In the past (up to the 1988 Blue Books - the last of the series), CCITT worked to a strict 4-year schedule (in particular, 1976 to 1980, 1980 to 1984, and finally 1984 to 1988). At the start of these four year Study Periods a set of Questions would be formulated and agreed by a CCITT plenary meeting. These Questions were assigned to the Study Groups, and formed the programme of work for each Group in the coming Study Period. Roughly speaking, each Question would give rise to a new or amended Recommendation on completion of the four year Study Period. Following the end of the Study Period, the entire set of CCITT Recommendations (whether changed or not) was republished as a set of volumes in bindings whose colour changed with each Study Period. Thus people spoke of "the Yellow Books" (published after the 1980 plenary which approved the 1980 Recommendations), or "the Yellow Book Era" (1980 to 1984), "the Red Books" published after the 1984 plenary, and finally "the Blue Books" published after the 1988 plenary, the last of the set. From 1990 onwards, CCITT/ITU-T will publish Recommendations only when necessary. Complete publication every four years has ceased.

Collectors take note. Nostalgia is in order! If you have a complete set of Blue Books in mint condition, keep them!

The above approach had a lot of advantages in controlling and progressing the work, but had significant disadvantages too, not least the costs of republishing every four years. It also gave rise to what was often rudely termed "the CCITT hibernation period" - there was about a twelve to fifteen month period at the Study Period boundaries when it was almost impossible to progress any technical work within CCITT. This gave rise to a lot of problems in collaborative work with ISO.

There were procedures in CCITT for the appointment of Interim Rapporteurs to try to progress work across the hibernation period, and towards the end of the 1980s these became increasingly effective. There were also Accelerated Procedures to permit the publication of new Recommendations at the two-year mid-point in a Study Period for particularly important work. These procedures were most notably used for the first version of X.25 in 1978, and for the EDI (Electronic Data Interchange) extensions to X.400 in 1990.

The precise working of ITU-T during the 1990s, particularly in the areas of joint work with ISO, remains to be seen at the time of writing this text, but the expectation is of joint work progressing smoothly without regard to Study Period boundaries, and with a single joint publication at the end of the work.

This discussion of CCITT/ITU-T would not be complete without some mention of the critical differences of emphasis between CCITT and ISO in the 1980s (see the next section for more discussion of ISO), as an understanding of these differences of emphasis is important to an understanding of some of the technical differences appearing between CCITT Recommendations and ISO Standards.

CCITT was, as mentioned earlier, largely the "club" of the PTTs and the RPOAs. One of the unwritten agenda items is to produce Recommendations that will maximise the effectiveness and profitability of these organizations. ISO, by contrast, is much more concerned with the development of international standards for use by a wide variety of public and private organizations, and whilst the computer manufacturers provide significant input into the work of ISO, there is formally only a very tenuous link between these corporations and the standards-making bodies. Notwithstanding that, one can occasionally (but only occasionally) see the international standards process dominated by and/or unduly influenced by a large multinational computer vendor.

Examples showing the effect of these differences of emphasis between ISO and CCITT can be seen in the early versions of the Network Service specifications, where the CCITT Recommendation text placed more emphasis on X.25 compatibility than the ISO text. Again, for X.400, the CCITT text mandated the use of so-called Transport Class 0, which is effectively a synonym for X.25, whilst the ISO text allows much more flexibility on the underlying carrier. Yet another example is in the body of X.400, where the CCITT text and diagram envisaged electronic mail crossing international boundaries only through relays provided by PTTs or RPOAs (see figure 1.1: CCITT view of X.400 transfers), whilst the corresponding text and diagram in the ISO version recognise direct communication between private systems in different countries (see figure 1.2: ISO view of X.400 transfers).

CCITT workers would not necessarily deny that such more general communications will occur - they would merely assert that CCITT Recommendations were intended for the use of PTTs and RPOAs, and hence that description of such communications has no place in a CCITT Recommendation!

1.2.3 The club of computer vendors

The International Organization for Standardization (always abbreviated to ISO) is a loose federation of Standards Institutes (National Bodies) from countries around the world, including the USSR, China, and so on. It has a long (but, as far as I can discover, undocumented) history going back into the last century. Most of the Standards Institutes have some support from or links with their corresponding Governments, but are generally largely autonomous bodies. Examples include BSI (British Standards Institute), AFNOR (Association Française de Normalisation), DIN (Deutsches Institut für Normung), ANSI (American National Standards Institute), JISC (Japanese Industrial Standards Committee), and NNI (Nederlands Normalisatie-Instituut).

The major subdivision of ISO (see figure 1.3: Structure of ISO committees) is into Technical Committees (TCs), each covering a major division of standardization. The division into TCs is relatively stable; there were 172 Technical Committees in 1991. TCs of interest for OSI include TC 68 (Banking and related financial services), TC154 (Documents and data elements in administration, commerce and industry), TC 184 (Industrial automation systems and integration), but most particularly TC97 (Information Technology), responsible for all computer-related standardization, and the parent of OSI. Despite their name, Technical Committees do very little technical work. They are largely administrative, determining the programme of work and the structure of Sub-Committees (SCs) within the TC.

Whilst SCs do break down into Working Groups and below that into Rapporteur Groups, it is the Sub-Committee that is the main unit for ISO meetings - all parts of the Sub-Committee meeting in roughly the same geographical location over a period of two to three weeks. The international meetings of the main OSI-related SCs are now (1990s) annual, and typically rotate round locations in North America, Europe, and the Pacific Basin on a three-yearly cycle. The SC structure within TC97 has undergone a number of quite radical changes since TC97 was first established, and can be expected to undergo further changes in the future.

In the mid-1980s, ISO recognised that the work of TC97 overlapped the remit of the International Electrotechnical Commission (IEC). Despite the theoretical overlap, in practice all the work on computer standards had been done in ISO, and there was no overlap of real technical work. Nonetheless, in the mid-1980s, TC97 was renamed Joint Technical Committee 1 (JTC1), and became a Technical Committee reporting to both IEC and to ISO. (There is still no JTC 2). This change was not noticed at the grass roots. The Sub-Committee structure of TC97 was copied unchanged to JTC1, the Secretariat and Officers were unchanged, and the work proceeded without a hiccough. The only difference was that OSI Standards started to be published with both the ISO logo and the IEC logo on the front cover. (Soon - mid 1990s - as discussed earlier, these logos will be joined by the ITU-T logo.)

TC97, in the late 1970s, had three main Sub-Committees which were extremely active in computer standardization, and still existed in the 1990's as SCs within JTC1. These were:

SC2 Responsible for character set standards.
SC5 Responsible for programming language standards.
SC6 Responsible for low-level data communication standards.

It was in discussions in SC6 and TC97 itself that OSI was born, with the establishment in the late 1970s of a new SC, SC16, responsible for progressing the OSI concept. SC16 developed the Reference Model for OSI, but responsibility for the production of standards in the bottom three layers of that model was given to SC6. Despite some early tensions, there was a lot of cross-membership between SC6 and SC16, and generally a very fruitful and close collaboration.

In the mid-1980s, TC97 reorganised its Sub-Committees. In particular, responsibility for the fourth layer of OSI (the so-called Transport Layer) was passed from SC16 to SC6, and a significant part of the SC5 work (database and graphics languages) was removed and added to the remaining work of SC16 (which was disbanded) to produce work for a new SC21. Despite the removal of encryption responsibility to SC20, and the later removal of the graphics work to SC24, SC21 remains one of the largest SCs (probably the largest) in the whole of ISO, making the hosting of meetings with many hundreds of attendees a major event requiring a complete small holiday resort, a University campus, or some similar facility. Its future into the late 1990s is again the subject of discussion, and further reorganizations of the work by JTC1 are likely.

1.3 Document names and progression

Understanding OSI, and particularly requesting documents and tracking their status requires some understanding of the terminology used to describe documents, and of the procedure for progressing drafts towards International Standard (IS) status (IS0/IEC) or Recommendation status (CCITT/ITU-T).

Neither ISO nor ITU/T yet make documents available electronically (compare the widespread and easy availability of the RFC - Request For Comment - documents of the USA DARPA Internet - the TCP/IP community, discussed briefly at the end of chapter two). This situation is expected to change in the late 1990s, with a move by ISO towards electronic document distribution, but the precise form of this is still uncertain at the time of writing (1995).

Generally, obtaining published CCITT/ITU-T Recommendations or ISO Standards (often reprinted as identical text by National Bodies and sold at somewhat lesser prices than those of ISO itself) is easily achieved by paying money to buy the published version.

Getting earlier drafts in advance of an agreed Standard or Recommendation is more difficult. ISO National Bodies normally make publicly available (at a price, and copyrighted) the text of Draft International Standards (DIS text), and invite comments from the public. Prior to this, documents are formally only available for private circulation to those contributing to the work, but are not copyrighted. There is, however, at least one commercial organization, operating from the USA but with a strong European presence, that will provide copies of almost all CCITT/ITU-T and ISO documents prior to the copyrighting stage (and, with permission from ISO and CCITT/ITU-T, sometimes after) at little more than photocopying and distribution costs. For many, however, the simplest way to track the work is to attend at least national meetings of the relevant ISO feeder committees, membership of which in most countries is open to anyone showing interest in the work.

In the case of CCITT, the document procedures were relatively informal, with any attendee at a meeting being entitled to submit an input paper, and with papers usually containing the name of the author. Drafts of Recommendations had no official status until finally approved for publication as Recommendations, first by the Study Group, and then by a full CCITT plenary (at the end of the Study Period in the past). Once approved by the CCITT plenary, the documents input to that plenary were often widely but unofficially circulated as "white documents" prior to the publication of the "coloured books". The editorial process often gave rise, however, to minor differences between the whites and the official coloured book version.

In the case of ISO/IEC, the procedures are somewhat more formalised and drawn out. Different Technical Committees in ISO have different rules on the categorization of documents, and on the timing of document submission and circulation, JTC1 being perhaps more formal than most ISO TCs. The following discussions relate specifically to JTC1, but variants on the theme apply to all ISO work.

Input documents to meetings can only be submitted by ISO National Bodies. These documents may, however, have a variety of semi-formally-defined statuses, the most used ones being:

Even the latter category usually bears only the identification of the National Body concerned, not of the "Expert" who authored it. It should usually have been vetted by other Experts in the National Body at least sufficiently to be sure that it does not contradict any National Body position.

The ISO equivalent of a CCITT/ITU-T Question is a New Work Item Proposal (NWI). During the 1980s, the NWI procedures evolved into quite formal mechanisms so that today an NWI involves a substantial amount of work and discussion in its preparation, and is often accompanied by a substantial technical document to form an initial base document for the work. The TC secretariat (provided by one of the National Bodies - ANSI in the case of JTC1) circulates by post to all National Bodies a hard-copy of an NWI for a Letter Ballot. The Letter Ballot was at the heart of ISO procedures in the 1970s, 1980s, and into the 1990s, and whilst it was sometimes replaced by votes at meetings, this has become increasingly uncommon for major document progression. In the case of an NWI proposal, there is a three-month ballot period in which National Bodies are asked to address and answer a number of questions, the most important being:

Generally, approval of a New Work Item and its allocation to a Sub-Committee to progress (almost always the SC proposing it) is critically dependent on whether at least five National Bodies answer "YES" to the last of these questions.

Once approved, the work continues through the cycle of input to international meetings, the production of output documents (usually including a revised base document) for consideration by National Bodies, and then input to the next international meeting, and so on. (See figure 1.4: Progression of an ISO standard). Eventually there is a consensus that the work is now complete, and a good document is available. In the case of collaborative work with CCITT in the past, this might be quite close to the final text of a Recommendation. At this stage the document is registered by the ISO Central Secretariat as what used to be called a Draft Proposal (DP), but which is now called a Committee Draft (CD). At this time it receives a number which (if it is eventually approved as an IS) is the number of the International Standard. (The number sequence at the end of the 1980s was around the 10000 mark). Registration as a CD (which is distinct from the ballot to approve or disapprove of the CD) is normally based on a simple vote of the National Bodies represented at an international meeting. In the early 1980s in SC16 this was a very traumatic time, with frequent surprises and upsets. Today, the work is generally time-tabled, and progression to CD registration is generally expected at a particular meeting, and moves smoothly. Once registered as a CD, there is another formal Letter Ballot in which National Bodies are asked if they approve or disapprove (in which case comments are required saying why) of the CD. Usually the volume of comments from each of the National Bodies active in the work exceeds the size of the base document, and this is where the fun starts!

The ISO process is a consensus process. And ISO has a definition of "consensus". Consensus has been achieved when "none of the major participants is extremely unhappy with the outcome." What this means in practice is that every effort is made to resolve NO votes, produced by the Letter Ballot, by changing the text. There is a phrase engraved on the heart of every person attending an ISO meeting: "The aim is to produce Standards. If you can't agree, make it optional, or better still, another Standard!" This can easily be justified, for after all: "If one Standard is good, many Standards must surely be better!" When I lecture on OSI, I usually try to redress the balance with a quotation from the Encyclopedia Galactica - 20085 version, which is shown in figure 1.5: Encyclopedia Galactica, p10945 .

Humour is only useful if it contains a grain of truth. ISO Standards and CCITT/ITU-T Recommendations often have multiple options and ways of doing things that result from failure to agree on one single standard way. This is both a strength and a weakness of the process. It has, however, given rise to work on Functional Profiles within the USA, Europe, and the Pacific Basin, latterly leading to Internationally Standardised Profiles produced by ISO. These Functional Profiles attempt to resolve options which were left in the base standards, often by defining a number of Functional Profiles each of which groups options into what are thought to be useful groupings for the market-place. The success or otherwise of this approach cannot yet (mid 1990s) be determined, as many profiles today do little more than record the minimum subset of the published base Standard, or provide guidance on implementation parameters. The reader should note also that there are documents recording Implementor's Agreements and there are documents recording Functional Profiles, sometimes from the same source. These have a somewhat different emphasis, but are quite similar in what they are doing, and are often confused.

Returning to the progression of documents: the early work in ISO is usually dominated by a Rapporteur who chairs the meetings and attempts to ensure that the work progresses. Identify the Rapporteur, and you can often (but not always) identify the source of the key ideas, or of the integration of ideas. The Rapporteur is assisted by an Editor who, in the early work, is little more than an unpaid secretary who takes notes of decisions and produces new base documents. It is following registration as a CD, however, that the role of the Editor becomes the dominant one, and the Rapporteur has little formal responsibility (often moving onto other work). Following the CD letter ballot, an Editing Meeting is called, sometimes end-on to a main SC meeting, sometimes totally separate in time. This is chaired by the Editor, who is responsible for "resolving NO votes", gaining consensus, producing a revised document, and producing a further document entitled "Resolution of National Body Comments on CD... ballot" which describes the way in which each National Body comment has been dealt with and how "NO" votes have been resolved.

Frequently the Resolution of Comments produces a sufficient volume of technical change to the CD text that there is a second CD ballot (and sometimes a third, and a fourth ...!). Given a good following wind, however, a skilled Editor, and a not too controversial area (or one with a strong "lobby" for rapid progression), it is possible (but generally still fairly unusual) for the text coming out of the first CD editing meeting to be registered as a Draft International Standard (DIS). In theory, technical issues have now all been resolved, and any future comments on the text will be concerned with clarity and editorial matters. The theory is not always the practice, however!

It is following registration as a DIS that National Bodies make the document publicly available, and invite public comments. It is also at this stage that the document is translated into French (assuming, as is the case with OSI work, that the original was in English). As an aside: although common CCITT and ISO English Language text (with agreed differences) was agreed for the original Reference Model, we narrowly avoided totally independent French versions: one produced by ISO translation of the jointly-agreed English, and one produced by CCITT translation of the jointly-agreed English! (Maybe it is a pity this was avoided - comparison of the two translations could have produced years of fun for linguistic students!).

On the main theme, following registration as a DIS text, there is again a formal Letter Ballot on the text, and a DIS Editing Meeting (which might result in a second DIS ballot), and then, with luck, registration as an International Standard and finally publication (usually about a year later).

Most of these steps take about twelve months, so that one can often see a period of up to four or five years from the first registered CD text to a published Standard.

Given these procedures in ISO, and the somewhat simpler CCITT procedures linked to a four-year cycle (at least in the 1980s), it is hardly surprising that CCITT Recommendation text and ISO International Standard text often diverged in detail, even where there were no real technical disagreements. The text approved by CCITT and eventually published as a Recommendation has often been the text input into the DIS ballot in ISO, with later changes handled by informal Implementor's Guides, or by simply waiting until the end of the next Study Period to publish a revised version!

Finally, it is important to know about the procedures for extending or amending ISO Standards and CCITT Recommendations. Again, in CCITT, there were no formal procedures. Once published, a Recommendation was the authoritative text, warts and all, for that Study Period, and defects were corrected in the next set of Recommendations. Recently, however, Implementor's Guides for major Recommendations have been regularly published to record known defects. The procedures for approving the contents of such Guides are, however, relatively informal.

In the case of ISO, a published Standard is formally reviewed, and amended or withdrawn or reaffirmed, every five years, but for OSI we have seen during the 1980s a steady stream of addenda to published Standards. The procedure for addenda progression is very similar to that for a base Standard, involving the production and registration of a Proposed Draft Amendment (PDAM) text (equivalent in status to a CD), progressing in due course (following a Letter Ballot and Editing Meeting) to a Draft Amendment (DAM) (equivalent in status to a DIS), and after a further Letter Ballot and Editing Meeting to a revised or extended Standard. This process is usually used to progress new work in collaboration with CCITT/ITU-T, and it is quite common to find the first amendment nearing the PDAM stage before the base standard is a full IS!

This procedure was recognised as being somewhat cumbersome for correcting actual errors in specifications, and JTC1 has put in place Rapid Amendment Procedures which require simple agreement of the Editor and an Expert from each interested National Body to informally agree on resolution of a Defect Report which then undergoes a single letter ballot (almost invariably approved) to become a Technical Corrigendum to the Standard. These procedures are intended to mend simple bugs (often in the semi-formal description of protocol exchanges using State Tables - see the end of chapter 3), not major technical defects or new work. The procedures have generated tens of (and sometimes topping one hundred) Defect Reports and associated Technical Corrigenda to most OSI Standards. Keeping track of all published Defect Reports and their status is a major exercise, and only implementors or those very closely involved in the work trouble to track these items.