Understanding IEC 10164-6-95 (2003): The Log Control Function in OSI Systems Management

1. Scope and Overview

IEC 10164-6-95 (2003) — formally titled Information technology – Open Systems Interconnection – Systems Management: Log Control Function — defines the systems management function that controls the operation of logging within an OSI environment. It forms part of the broader ISO/IEC 10164 series (System Management Functions) and is aligned with the management framework described in ISO/IEC 7498-4.

The primary purpose of this standard is to specify the behaviour of a managed object class called the log, along with its associated attributes, operations, notifications, and relationships. It enables applications and management systems to create, configure, and control logs that record events (system notifications) for later analysis, auditing, or troubleshooting.

Key scope elements include:

Definition of the log managed object class and its inheritance hierarchy.
Specification of log record structures and the criteria for triggering log entries.
Operations for creating, suspending, resuming, and deleting logs.
Interaction between the log control function and other systems management functions (e.g., alarm reporting, event report management).
Conformance requirements for implementations claiming compliance with this standard.

Originally published in 1995 (with a 2003 edition reaffirming and clarifying the technical content), the standard remains a foundational reference for logging architectures in telecommunications, industrial control, and enterprise network management systems.

Note: IEC 10164-6-95 is technically identical to ISO/IEC 10164-6. The “95” in the identifier refers to the initial publication year; the parentheses “(2003)” indicate the revision or reaffirmation cycle that confirmed its applicability in modern management frameworks.

2. Technical Requirements

2.1 The Log Managed Object Class

The core of IEC 10164-6-95 is the log managed object. It inherits from the top object class defined in ISO/IEC 10165-1 (Structure of Management Information). Each log instance represents a collection of log records, together with the control attributes that govern its behaviour.

Attribute	Type	Description
logId	GraphicString	Uniquely identifies a log instance within a management domain.
administrativeState	ENUMERATED { unlocked, locked, shutting-down }	Controls whether the log is operational, disabled, or in a graceful shutdown.
operationalState	ENUMERATED { disabled, enabled }	Reflects the actual ability of the log to accept new records.
availabilityStatus	SET OF Enumeration	Additional status indications (e.g., “in test”, “failed”, “power off”).
logRecordCapacity	Integer32 or UNBOUNDED	Maximum number of records the log can hold (0 means no limit).
currentLogSize	Integer32	Current number of records stored in the log.
logFullAction	ENUMERATED { wrap, halt }	Behaviour when the log reaches capacity: overwrite oldest records (=wrap) or stop accepting new ones (=halt).
logCriteria	SET OF Criteria	Conditions that cause a log record to be created.
logSchedule	Schedule (optional)	Temporal triggering of log creation or archiving operations.

2.2 Log Records and Criteria

Each log record encapsulates a single event (or group of events) together with contextual information. Log records are generated when the event information matches at least one of the log criteria defined for that log instance. The criteria can be based on:

Discriminator: a complex expression (similar to an event forwarding discriminator) that filters on event type, source object, perceived severity, or time.
Attribute value changes: any state or attribute change in managed objects.
Creation or deletion of managed objects.
Interaction with other management functions: e.g., alarm reports, state change notifications, security audit trail events.

The standard also defines the logRecord managed object class. Each log record contains:

recordId (GraphicString) – unique identifier within the log.
loggingTime (GeneralizedTime) – timestamp of when the record was created.
eventData (AbstractSyntax) – the encoded event content (e.g., an alarm notification or attribute change report).
additionalInformation (SET OF Attribute-ValueAssertion) – optional extensions such as operator comments or correlation tags.

Implementation Tip: The logCriteria attribute can be enhanced with discriminator construct logic similar to that in ISO/IEC 10164-5 (Event Report Management). Many real-world implementations reuse the same discriminator grammar to achieve consistent filtering across event forwarding and logging subsystems.

2.3 Operations and Notifications

IEC 10164-6-95 specifies the following CMIS operations on the log managed object:

CREATE and DELETE – to instantiate or remove log instances.
GET and SET – to read or modify log attributes (e.g., change logFullAction, update criteria).
ACTION – several standard actions, including suspendLog and resumeLog for temporary stops, and archiveLog for exporting records to an external storage (implementation-specific).
EVENT-REPORT – the log can emit notifications such as logFull, logRecordsLost, and logOperationalChange.

Notification	Cause	Typical Use
logFull	Log reaches its capacity (if action is halt).	Alert operator to archive or increase capacity.
logRecordsLost	Records discarded due to buffer overflow or resource constraints.	Data integrity monitoring.
logOperationalChange	Transition in administrative or operational state.	Audit trail for log management actions.
logCriteriaNotMet	No criteria matched an incoming event (optional).	Debug logging filters.

3. Implementation Highlights

Implementing a conformant log control function involves more than merely storing events in a file. The standard demands adherence to the information model, the defined operations, and the notification mechanisms. Key implementation considerations include:

Interoperability: Because the standard relies on CMISE (Common Management Information Service Element), the log managed object and its records must be accessible via GDMO/ASN.1 frameworks. The log must be fully visible and controllable through a standard CMIS interface (or through a mapping, e.g., SNMP if proxy conversion is provided).
Performance: High-frequency event logging requires careful tuning of the log criteria to avoid overwhelming the log capacity. Use of the discriminator construct with efficient matching algorithms is recommended. Many products pre‑compile criteria into finite‑state machines.
Storage Management: The logFullAction set to wrap is often chosen to avoid blocking management operations, but it can result in loss of critical historical data. Commercial implementations typically augment the standard with configurable auto‑archiving to secondary storage (e.g., a database or file system).
Security: The log control function itself must be protected against unauthorised modifications (e.g., deletion of records, disabling logging). The standard allows access control policies to be applied to log objects, aligning with the OSI security model (ISO/IEC 10181 series).

Potential Pitfall: IEC 10164-6-95 does not define a specific format for log records stored on disk; it only defines the abstract syntax of records as they appear in CMIS responses. Implementers must provide their own serialisation strategy (e.g., BER, XML, or binary) while ensuring that the abstract content is preserved and can be retrieved as specified.

4. Compliance and Conformance

Conformance to IEC 10164-6-95 is a key requirement for any systems management platform that claims support for OSI management logging. The standard defines two levels of conformance:

Mandatory conformance: An implementation must support the log managed object class with all mandatory attributes (logId, administrativeState, operationalState, logFullAction, currentLogSize, logCriteria), the CREATE/DELETE/GET/SET/ACTION operations relevant to logs, and the generation of the logFull notification.
Conditional conformance: Other features (e.g., logSchedule, the logRecordsLost notification, support for specific log record extensions) must be implemented if the implementation claims support for the corresponding optional packages defined in the GDMO.

During conformance testing, the implementer should provide a Protocol Implementation Conformance Statement (PICS) in the format specified by ISO/IEC 9646-2 (OSI conformance testing framework). The PICS must clearly indicate which functional units, attributes, and operations are supported. The standard also references the System Management Overview (ISO/IEC 10040) and the Structure of Management Information (ISO/IEC 10165-1); thus, conformance to those parent standards is implicitly required where the log object depends on them.

Compliance Note: An implementation that fully conforms to IEC 10164-6-95 (2003) can be certified for use in environments requiring interoperable management logging, such as TMN (Telecommunications Management Network) systems conforming to ITU-T M.3010. The standard’s alignment with the broader ISO/IEC 10164 series ensures that logging can be integrated seamlessly with alarm management, event report management, and trust administration functions.

Frequently Asked Questions

Q: What is the difference between a “log” and an “event forwarding discriminator”?
A: A log records events locally for later retrieval, while an event forwarding discriminator (ISO/IEC 10164-5) transmits a filtered event report to a remote managing system. Both can use similar filtering criteria, but the log control function persists the data and allows for operations like suspend, archive, and wrap. In many management architectures, events pass through a discriminator to a log as a dual path: forwarding to remote systems and archiving locally.

Q: Must a conforming implementation use the full CMIS stack, or can it be adapted to other protocols?
A: The standard is defined within the OSI management framework and assumes CMIS/CMIP at its base. However, many modern deployments map the log managed object to SNMP MIBs (e.g., via an SNMP-OSI proxy). The conformance can still be claimed if the abstract semantics (the log attributes, operations, and notifications) are preserved. The PICS document should describe such mappings explicitly.

Q: Does IEC 10164-6-95 (2003) define log file formats for external storage (e.g., CSV, JSON)?
A: No. The standard only defines the abstract syntax of log records as they are exchanged using CMIS (ASN.1 encoded). Any transformation to a platform-specific file format (including XML, JSON, or plain text) is an implementation decision. When doing so, the implementer must ensure that all attributes of the logRecord managed object class can be reconstructed from the stored data if required by the conformance claims.

Q: How does the logFullAction attribute affect compliance?
A: Both wrap and halt are mandatory to support. The implementer must allow an administrator to configure which action is taken when the log reaches its capacity. The choice does not affect conformance, but the logFull notification must be generated whenever the log transition to a full state occurs (for either action) and records are discarded or logging stops.

Article written for educational and reference purposes. Standard title and designation as specified by the user: IEC 10164-6-95 (2003). For authoritative specifications, refer to the official ISO/IEC publication. Updated 2026.

📥 Standard Documents Download

🔒

Please wait 10 seconds, the download links will appear after the ad loads