ISO/IEC 24775-2:2021

Information technology - Storage management - Part 2: Common Architecture

Storage Management Technical Specification, Part 2 Common Architecture, 1.8.0 Rev 4 defines the core architecture and protocols in SMI-S. The components of SMI-S architecture include: Transport - communicating management information between constituents of the management system Health and fault management - detecting failures through monitoring the state of storage components General information about the object model Names - how SMI-S uses names to allow applications to correlate across SMI-S and to other standards Standard messages - how exceptions are presented to client applications Service discovery - techniques clients use to discover SMI-S services Installation and upgrade - recommendations for implementations Compliance - requirement for compliance to the standard

Technologie de l'information — Management du stockage — Partie 2: Titre manque

General Information

• Status: Published
• Publication Date: 06-Apr-2021
• ICS: 35.200 - Interface and interconnection equipment
• Technical Committee: ISO/IEC JTC 1 - Information technology
• Drafting Committee: ISO/IEC JTC 1 - Information technology
• Current Stage: 6060 - International Standard published
• Start Date: 07-Apr-2021
• Due Date: 15-Nov-2021
• Completion Date: 23-Mar-2021

Relations

• Revises: ISO/IEC 24775-2:2014 - Information technology - Storage management - Part 2: Common Architecture
• Effective Date: 14-Oct-2020

Overview

ISO/IEC 24775-2:2021 - "Information technology - Storage management - Part 2: Common Architecture" defines the core architecture and protocols used by the SMI-S (Storage Management Initiative Specification) API. Published jointly by ISO and IEC and prepared by SNIA, this standard specifies the transport model, object model conventions, messaging and service-discovery approaches, health and fault management, installation/upgrade guidance, and compliance requirements for interoperable multi‑vendor SAN and storage-management solutions.

Key Topics and Requirements

• Transport and Reference Model: Defines the transport stack, communication requirements and XML message syntax (CIM-XML) used to exchange management information between SMI-S constituents.
• Object Model and Naming: Describes the common object model (including CIM schema updates, e.g., CIM version 2.51 in recent revisions) and naming conventions that allow applications to correlate objects across SMI‑S and other standards.
• Health and Fault Management: Specifies monitoring mechanisms and operational status reporting used to detect failures and manage storage component health.
• Standard Messages and Indications: Provides standardized exception/alert messages and references the DMTF Indications Profile (e.g., DSP 1054) so clients receive consistent event/alert semantics.
• Service Discovery: Techniques for clients to discover SMI‑S services in a multi‑vendor environment.
• Installation, Upgrade and Compliance: Recommendations for implementation, versioning policy (major/minor/update), maturity levels (Experimental, Implemented, Stable, Finalized) and compliance rules to ensure interoperability.
• Security and Transport Links: References to related security guidance (e.g., SNIA TLS specification) and network transport considerations for secure management traffic.

Applications and Who Uses It

ISO/IEC 24775-2:2021 is intended for:

• Storage vendors building SMI‑S compliant arrays, controllers and software.
• Management software developers (enterprise storage managers, orchestration and monitoring tools) that integrate multi-vendor SANs.
• System integrators and architects designing interoperable storage ecosystems.
• Storage administrators who rely on standardized alerts, health monitoring and service discovery across heterogeneous storage environments.

Practical uses include vendor-neutral storage monitoring, automated provisioning, fault detection and cross‑vendor orchestration in SANs and data centers.

Related Standards

• ISO/IEC 24775 series (other parts of Storage Management)
• SNIA SMI‑S specification (Storage Management Technical Specification)
• DMTF Indications Profile (DSP 1054) - used for standardized event/indication handling
• CIM/CIM‑XML schema references (CIM schema updates referenced in the specification)
• SNIA TLS Spec for secure management transport

Keywords: ISO/IEC 24775-2:2021, SMI‑S, storage management, SAN interoperability, storage architecture, CIM-XML, DMTF Indications, SNIA, storage compliance.

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 24775-2
Second edition
2021-03
Information technology — Storage
management —
Part 2:
Common Architecture
Reference number
©
ISO/IEC 2021
© ISO/IEC 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2021 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of document should be noted (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details
of any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents) or the IEC list of patent
declarations received (see http://patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the World
Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT),
see www.iso.org/iso/foreword.html.
This document was prepared by SNIA (as Storage Management Technical Specification, Part 2 Common
Architecture, Version 1.8.0, Revision 5) and drafted in accordance with its editorial rules. It was adopted,
under the JTC 1 PAS procedure, by Joint Technical Committee ISO/IEC JTC 1, Information technology.
This second edition cancels and replaces the first edition (ISO/IEC 24775-2:2014), which has been
technically revised.
The main changes compared to the previous edition are as follows:
— USAGE text was revised to address code (now included in the front matter for all SNIA specifications)
— All recipes and their references were deleted.
— Instances of subprofile were changed to profile. In the annex, instances of subprofile were changed
to component profile (TSG meeting voice vote).
— Profile versions and related text were updated. (TSG meeting voice vote).
— Indications have been replaced by DMTF Indications, and all affected clauses updated. (TSG meeting
voice vote).
— Instances of Experimental within profiles already labeled as Experimental were removed to avoid
confusion and redundancy. (Editorial change)
— CIM/XML was changed to CIM-XML (Response to ballot comments).
© ISO/IEC 2021 – All rights reserved iii

— Annex: SMI-S Information Model.
— The CIM schema version was changed to 2.51 for V1.8.0 Rev3.
— Health and Fault Management
— Table 1: OperationalStatus for Disk Drive, revised re operational status.
— Revised Array example and other text (CORE-SMIS-SCR-00084).
— Indications
— Added as Clause 10, includes some material previously in Annex C (normative) Indication
Filter Strings.
— References the DMTF Indications Profile, DSP 1054, version 1.2.2.
— References
— Five references were added to DMTF references (Final) section (to indicate most recent
versions). One reference was added to References under development section.
— Added link to the SNIA TLS Specification.
— Deleted "V.1.0" from all references to the SNIA TLS Specification for Storage Systems in SMI-S
v1.6.1 and later versions of SMI-S (TSG ballot).
— Security
— Removed Experimental material in the Securityclause per voice vote in TSG.
— Standard Messages
— Standard messages (in table format) remain in the document (after being removed in a
previous revision, TSG meeting voice vote).
— Changes applied to the Standard Message tables:
— Promoted to experimental new alert standard messages for diagnostic tests on storage pools
(SMIS-170-Draft-SCR00003).
— Resolved duplicate use of standard messages in the Block Storage Messages section (TSG-
SMISSCR00316.001).
— Added alerts in Common Profile-Related Messages section (TSG-SMIS-SCR00315.001, SMIS-
170-Draft-SCR00008).
— Promoted the maturity level from DRAFT to EXPERIMENTAL for these revisions: Updated
profiles to remove SNIA_ classes and use DMTF CIM_ classes. (TSG-SMIS-SCR00315.001, SMIS-
170-Draft- SCR00008) in Common Profile-Related Messages section and Filesystem Messages
section.
— Annex A (informative) Mapping CIM Objects to SNMP MIB Structure removed.
— Annex B (normative) Compliance with the SNIA SMI Specification changed to Annex A.
— Annex C (normative) Indication Filter Strings removed. Some material moved to new Indications
profile.
A list of all parts in the ISO/IEC 24775 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
iv © ISO/IEC 2021 – All rights reserved

1 INTENDED AUDIENCE
2 This document is intended for use by individuals and companies engaged in developing, deploying, and
3 promoting interoperable multi-vendor SANs through the Storage Networking Industry Association (SNIA)
4 organization.
5 CHANGES TO THE SPECIFICATION
6 Each publication of this specification is uniquely identified by a three-level identifier, comprised of a
7 version number, a release number and an update number. The current identifier for this specification is
8 version 1.8.0. Future publications of this specification are subject to specific constraints on the scope of
9 change that is permissible from one publication to the next and the degree of interoperability and
10 backward compatibility that should be assumed between products designed to different publications of
this standard. The SNIA has defined three levels of change to a specification:
• Major Revision: A major revision of the specification represents a substantial change to the underlying scope
or architecture of the SMI-S API. A major revision results in an increase in the version number of the version
identifier (e.g., from version 1.x.x to version 2.x.x). There is no assurance of interoperability or backward
compatibility between releases with different version numbers.
• Minor Revision: A minor revision of the specification represents a technical change to existing content or an
adjustment to the scope of the SMI-S API. A minor revision results in an increase in the release number of
the specification’s identifier (e.g., from x.1.x to x.2.x). Minor revisions with the same version number preserve
interoperability and backward compatibility.
• Update: An update to the specification is limited to minor corrections or clarifications of existing specification
content. An update will result in an increase in the third component of the release identifier (e.g., from x.x.1 to
x.x.2). Updates with the same version and minor release levels preserve interoperability and backward
compatibility.
TYPOGRAPHICAL CONVENTIONS
Maturity Level
In addition to informative and normative content, this specification includes guidance about the maturity
of emerging material that has completed a rigorous design review but has limited implementation in
commercial products. This material is clearly delineated as described in the following sections. The
typographical convention is intended to provide a sense of the maturity of the affected material, without
29 altering its normative content. By recognizing the relative maturity of different sections of the standard, an
30 implementer should be able to make more informed decisions about the adoption and deployment of
31 different portions of the standard in a commercial product.
This specification has been structured to convey both the formal requirements and assumptions of the
33 SMI-S API and its emerging implementation and deployment lifecycle. Over time, the intent is that all
34 content in the specification will represent a mature and stable design, be verified by extensive
35 implementation experience, assure consistent support for backward compatibility, and rely solely on
36 content material that has reached a similar level of maturity. Unless explicitly labeled with one of the
subordinate maturity levels defined for this specification, content is assumed to satisfy these
37 requirements and is referred to as “Finalized”. Since much of the evolving specification
38 content in any given release will not have matured to that level, this specification defines three
subordinate levels of implementation maturity that identify important aspects of the content’s increasing
maturity and stability. Each subordinate maturity level is defined by its level of implementation
experience, its stability and its reliance on other emerging standards. Each subordinate maturity level is
identified by a unique typographical tagging convention that clearly distinguishes content at one maturity
model from content at another level.
© ISO/IEC 2021 – All rights reserved

46 Experimental Maturity Level
No material is included in this document unless its initial architecture has been completed and reviewed.
Some content included in this document has complete and reviewed design, but lacks implementation
experience and the maturity gained through implementation experience. This content is included in order
to gain wider review and to gain implementation experience. This material is referred to as
“Experimental”. It is presented here as an aid to implementers who are interested in likely future
developments within the SMI specification. The contents of an Experimental profile may change as
implementation experience is gained. There is a high likelihood that the changed content will be included
in an upcoming revision of the specification. Experimental material can advance to a higher maturity level
as soon as implementations are available. Figure 1 is a sample of the typographical convention for
Experimental content.
EXPERIMENTAL
Experimental content appears here.
EXPERIMENTAL
Figure 1 - Experimental Maturity Level Tag
Implemented Maturity Level
Profiles for which initial implementations have been completed are classified as “Implemented”. This
indicates that at least two different vendors have implemented the profile, including at least one provider
implementation. At this maturity level, the underlying architecture and modeling are stable, and changes
in future revisions will be limited to the correction of deficiencies identified through additional
implementation experience. Should the material become obsolete in the future, it must be deprecated in a
minor revision of the specification prior to its removal from subsequent releases. Figure 2 is a sample of
the typographical convention for Implemented content.
IMPLEMENTED
Implemented content appears here.
IMPLEMENTED
Figure 2 - Implemented Maturity Level Tag
Stable Maturity Level
Once content at the Implemented maturity level has garnered additional implementation experience, it
can be tagged at the Stable maturity level. Material at this maturity level has been implemented by three
different vendors, including both a provider and a client. Should material that has reached this maturity
level become obsolete, it may only be deprecated as part of a minor revision to the specification. Material
at this maturity level that has been deprecated may only be removed from the specification as part of a
major revision. A profile that has reached this maturity level is guaranteed to preserve backward
compatibility from one minor specification revision to the next. As a result, Profiles at or above the Stable
© ISO/IEC 2021 – All rights reserved

76 maturity level shall not rely on any content that is Experimental. Figure 3 is a sample of the typographical
77 convention for Implemented content.
STABLE
Stable content appears here.
STABLE
Figure 3 - Stable Maturity Level Tag
78 Finalized Maturity Level
79 Content that has reached the highest maturity level is referred to as “Finalized.” In addition to satisfying
80 the requirements for the Stable maturity level, content at the Finalized maturity level must solely depend
81 upon or refine material that has also reached the Finalized level. If specification content depends upon
82 material that is not under the control of the SNIA, and therefore not subject to its maturity level
83 definitions, then the external content is evaluated by the SNIA to assure that it has achieved a
84 comparable level of completion, stability, and implementation experience. Should material that has
85 reached this maturity level become obsolete, it may only be deprecated as part of a major revision to the
86 specification. A profile that has reached this maturity level is guaranteed to preserve backward
87 compatibility from one minor specification revision to the next. Over time, it is hoped that all specification
content will attain this maturity level. Accordingly, there is no special typographical convention, as there is
with the other, subordinate maturity levels. Unless content in the specification is marked with one of the
typographical conventions defined for the subordinate maturity levels, it should be assumed to have
reached the Finalized maturity level.
Deprecated Material
Non-Experimental material can be deprecated in a subsequent revision of the specification. Sections
identified as “Deprecated” contain material that is obsolete and not recommended for use in new
development efforts. Existing and new implementations may still use this material, but shall move to the
newer approach as soon as possible. The maturity level of the material being deprecated determines how
long it will continue to appear in the specification. Implemented content shall be retained at least until the
next revision of the specialization, while Stable and Finalized material shall be retained until the next
major revision of the specification. Providers shall implement the deprecated elements as long as it
appears in the specification in order to achieve backward compatibility. Clients may rely on deprecated
elements, but are encouraged to use non-deprecated alternatives when possible.
Deprecated sections are documented with a reference to the last published version to include the
deprecated section as normative material and to the section in the current specification with the
replacement. Figure 4 contains a sample of the typographical convention for deprecated content.
DEPRECATED
Content that has been deprecated appears here.
DEPRECATED
Figure 4 - Deprecated Tag
© ISO/IEC 2021 – All rights reserved

© ISO/IEC 2021 – All rights reserved

Contents
List of Figures . 15
List of Tables . 17
Foreword . 23
1 Scope . 25
2 Normative references . 27
2.1 General . 27
2.2 Approved references. 27
2.3 DMTF references (Final) . 27
2.4 IETF references . 28
2.5 References under development . 29
2.6 Other references . 29
3 Terms, definitions, symbols, abbreviations, and conventions . 31
3.1 Terms and definitions. 31
3.2 Acronyms and abbreviations. 37
3.3 Keywords . 37
3.4 Conventions . 38
4 Transport and Reference Model. 41
4.1 Introduction . 41
4.1.1 Overview. 41
4.1.2 Language Requirements . 41
4.1.3 Communications Requirements . 41
4.1.4 XML Message Syntax and Semantics. 41
4.2 Transport Stack. 42
4.3 Reference Model. 42
4.3.1 Overview. 42
4.3.2 Roles for Interface Constituents . 43
4.3.3 Cascaded Agents . 43
5 Health and Fault Management . 45
5.1 Objectives . 45
5.2 Overview . 45
5.3 Terms . 45
5.4 Description of Health and Fault Management. 46
5.4.1 Operational Status and Health State (Polling). 46
5.4.2 Standard Errors and Events . 47
5.4.3 Indications . 47
5.4.4 Event Correlation and Fault Containment . 47
5.4.5 Fault Regions . 50
5.4.6 Examples. 52
6 Object Model General Information. 55
6.1 Model Overview (Key Resources). 55
6.1.1 Overview. 55
6.1.2 Introduction to CIM UML Notation . 55
6.2 Techniques. 56
6.2.1 CIM Fundamentals . 56
6.2.2 Modeling Profiles. 58
6.2.3 CIM Naming. 58
7 Correlatable and Durable Names . 59
© ISO/IEC 2021 – All rights reserved

7.1 Overview . 59
7.2 Guidelines for SCSI Logical Unit Names . 60
7.3 Guidelines for FC-SB-2 Device Names. 60
7.4 Guidelines for Port Names . 61
7.5 Guidelines for Storage System Names . 61
7.6 Standard Formats for Correlatable Names . 62
7.6.1 General.62
7.6.2 Standard Formats for Logical Unit Names . 63
7.6.3 Standard Formats for Port Names. 64
7.6.4 Standard Formats for Fabric Names . 65
7.6.5 Standard Formats for Storage System Names. 65
7.6.6 Operating System Device Names . 67
7.6.7 Case Sensitivity. 68
7.7 Testing Equality of correlatable Names . 68
7.8 iSCSI Names. 69
8 Standard Messages. 71
8.1 Overview . 71
8.2 Registries for Standard Messages . 71
8.3 SNIA Standard Messages. 71
8.3.1 Common Profile-related Messages . 71
8.3.2 Block Storage Messages. 85
8.3.3 Fabric Messages . 118
8.3.4 Filesystem Messages. 123
8.3.5 Host Messages. 135
8.3.6 Media Library Messages . 138
9 Service Discovery. 171
9.1 Objectives . 171
9.2 Overview . 171
9.3 SLP Messages . 173
9.4 Scopes . 174
9.5 Services Definition . 175
9.5.1 SLP Terms. 175
9.5.2 Service Type. 175
9.5.3 Service Attributes . 175
9.6 User Agents (UA) . 175
9.7 Service Agents (SAs) . 176
9.8 Directory Agents (DAs) . 177
9.9 Service Agent Server (SA Server) . 177
9.9.1 General Information. 177
9.9.2 SA Server (SAS) Implementation. 177
9.9.3 SA Server (SAS) Clients. 178
9.9.4 SA Server Configuration. 178
9.9.5 SA Server Discovery . 180
9.9.6 SAS Client Registration. 180
9.10 Configurations . 180
9.10.1 Overview. 180
9.10.2 Multicast Configurations . 180
9.10.3 No Multicast configuration . 181
9.10.4 Multicast Islands. 182
10 Indications . 185
© ISO/IEC 2021 – All rights reserved

10.1 Indications profile . 185
10.1.1 Profile Support. 185
10.1.2 Creating a client defined indication and subscription . 185
10.1.3 ListenerDestination. 185
10.2 Indication Filter Strings. 185
10.2.1 Definition Syntax. 185
10.2.2 Instance Creation . 186
10.2.3 Instance Deletion. 186
10.2.4 Modification of any value in an array property. 186
10.2.5 Modification to either of Two Specific values in an Array Property. 186
10.2.6 Alert . 187
11 SMI-S Roles . 189
11.1 Introduction . 189
11.2 SMI-S Client . 190
11.2.1 Overview. 190
11.2.2 SLP Functions . 190
11.2.3 Generic Operations . 190
11.2.4 Security Considerations. 190
11.2.5 Lock Management Functions . 190
11.3 Dedicated SMI-S Server . 190
11.3.1 Overview. 190
11.3.2 SLP Functions . 191
11.3.3 Generic Operations . 191
11.3.4 Security Considerations. 192
11.3.5 Lock Management Functions . 192
11.4 General Purpose SMI-S Server . 192
11.4.1 Overview. 192
11.4.2 SLP Functions . 192
11.4.3 Generic Operations . 193
11.4.4 Lock Management Functions . 193
11.4.5 Provider Sub-role. 193
11.5 Directory Server . 193
11.5.1 SLP Functions . 193
11.5.2 Generic Operations . 193
11.5.3 Security Considerations. 193
11.5.4 Lock Management Functions . 194
11.6 Combined Roles on a Single System. 194
11.6.1 Overview. 194
11.6.2 General Purpose SMI-S Server as a Profile Aggregator. 194
12 Installation and Upgrade. 195
12.1 Introduction . 195
12.2 Role of the Administrator.195
12.3 Goals. 195
12.3.1 Non-Disruptive Installation and De-installation. 195
12.3.2 Plug-and-Play. 195
12.4 Server Deployment .196
12.4.1 General. 196
12.4.2 Controlled Environment. 196
12.4.3 Multiple WBEM Server systems . 196
12.4.4 Shared WBEM Server . 197
12.4.5 Uninstallation. 198
© ISO/IEC 2021 – All rights reserved

12.4.6 Update. 198
12.4.7 Reconfiguration . 198
12.5 WBEM Service Support & Related Functions . 198
12.5.1 Installation . 198
12.5.2 Multiple WBEM Servers on a Single Server System. 199
12.5.3 Uninstallation/Upgrade . 199
12.5.4 Reconfiguration . 199
12.5.5 Failure. 199
12.6 Client . 199
12.6.1 Uninstallation. 199
12.6.2 Reconfiguration . 199
12.7 Directory Service. 199
12.7.1 Installation . 199
12.7.2 Uninstallation/Failure. 200
12.8 Issues with Discovery Mechanisms . 200
13 Security. 201
13.1 Requirements. 201
13.1.1 Overview. 201
13.1.2 General Requirements for HTTP Implementations . 202
13.2 Description of SMI-S Security . 202
13.2.1 Security Scope . 202
13.2.2 Transport Security . 203
13.2.3 Authentication. 203
13.2.4 Service Discovery. 204
Annex A (informative) SMI-S Information Model. 207
Annex B (normative) Compliance with the SNIA SMI Specification. 209
© ISO/IEC 2021 – All rights reserved

LIST OF FIGURES
Figure 1 - Experimental Maturity Level Tag . 8
Figure 2 - Implemented Maturity Level Tag . 8
Figure 3 - Stable Maturity Level Tag. 9
Figure 4 - Deprecated Tag. 9
Figure 5 - Reference Model. . 42
Figure 6 - Basic Fault Detection. 46
Figure 7 - Health Lifecycle . 49
Figure 8 - Continuum . 50
Figure 9 - Application Fault Region. 51
Figure 10 - Switch Example . 53
Figure 11 - Lines that Connect Classes. 55
Figure 12 - iSCSI Qualified Names (iqn) Examples. 69
Figure 13 - iSCSI EUI Name Example. 69
Figure 14 - iSCSI 64-bit NAA Name Example. 70
Figure 15 - iSCSI 128-bit NAA Name Example. 70
Figure 16 - SA Server Configuration. 180
Figure 17 - Multicast Configuration . 181
Figure 18 - No Multicast configuration . 182
Figure 19 - Multicast Islands . 183
Figure 20 - SMI-S Roles . 189
Figure B.1 Provider Migration 211
© ISO/IEC 2021 – All rights reserved

© ISO/IEC 2021 – All rights reserved

LIST OF TABLES
Table 1 - OperationalStatus for Disk Drive .46
Table 2 - Standard Formats for StorageVolume Names .63
Table 3 - Standard Formats for Port Names.64
Table 4 - Standard Formats for Storage System Names.66
Table 5 - Standard Operating System Names for Tape Devices.67
Table 6 - LogicalDisk.Name for disk partitions .68
Table 7 - GenericDiskParittion.Name for disk partitions .68
Table 8 - Standard Operating System Names for Unpartitioned DIsks .68
Table 9 - Redundancy Message Arguments .71
Table 10 - Redundancy Alert Information.72
Table 11 - Environmental Message Arguments.72
Table 12 - Environmental Alert Information .73
Table 13 - FRU Operation Message Arguments .73
Table 14 - FRU Operation Alert Information .
...