ISO/TS 20684-7:2022

Intelligent transport systems - Roadside modules SNMP data interface - Part 7: Support features

Field devices are a key component in intelligent transport systems (ITS). Field devices include traffic signals, message signs, weather stations, traffic sensors, roadside equipment for connected ITS (C-ITS) environments, etc. Field devices often need to exchange information with other external entities (managers). Field devices can be quite complex, necessitating the standardization of many data concepts for exchange. As such, the ISO 20684 series is divided several individual parts. This document specifies user needs, requirements and design elements that are normatively used by other parts of the ISO 20684 series. Specifically, it defines an internal field device clock, a mechanism for grouping object values together to provide for more efficient transfer of data, and it provides formal requirements for the SNMP target and target parameters as defined in IETF RFC 3413. NOTE 1 There are similarities between certain portions of NTCIP 1103 and NTCIP 1201 and this document. NOTE 2 ISO 20684-1 provides additional details about how the ISO 20684 series relates to the overall ITS architecture.

Systèmes de transport intelligents — Interface de données SNMP pour les modules en bord de route — Partie 7: Service de support

General Information

• Status: Published
• Publication Date: 02-Oct-2022
• ICS: 03.220.20 - Road transport
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 9 - Integrated transport information, management and control
• Current Stage: 9020 - International Standard under periodical review
• Start Date: 15-Oct-2025
• Completion Date: 15-Oct-2025

Overview

ISO/TS 20684-7:2022 - Intelligent transport systems - Roadside modules SNMP data interface - Part 7: Support features - defines support-level data, services and interfaces used by ITS field devices to exchange management and operational data using SNMP conventions. It is part of the ISO 20684 series and specifies normative user needs, requirements and design elements used across the series (clocks, grouped object transfers, SNMP target configuration and parameters). Annex A contains the Management Information Base (MIB) and Annex B provides a requirements traceability matrix (RTM).

Key topics and technical requirements

• Clock management
  • Internal local clock and UTC clock definitions, data exchange and capability requirements.
  • Daylight saving time (DST) definitions, scheduling, capability and exchange requirements.
• Object grouping
  • Mechanism to group multiple object values (simple and complex object groups) for efficient transfer, with capabilities for retrieval, set operations, statistics, toggling and clearing.
• SNMP target and parameters
  • Formal requirements for SNMP targets and target parameters as defined in IETF RFC 3413.
  • Conformance profiles list mandatory and optional features (for example, SNMPv3 support is mandatory, while SNMPv1/v2c are optional).
  • Transport/security support expectations (DTLS/IP support is mandatory; TCP/TLS, UDP are indicated as optional in the conformance matrix).
• Protocol artifacts
  • Normative MIB definitions (Annex A) to implement the defined objects and operations.
  • Dialogues and operation flows for object group retrieval and configuration (Clause 7).
• Conformance and security
  • Conformance clauses and tables linking user needs to features and requirements.
  • Clause on security vulnerabilities and considerations relevant to roadside SNMP interfaces.

Applications and who should use it

ISO/TS 20684-7 is intended for organizations and professionals involved with ITS field devices and roadside modules, including:

• Traffic control device manufacturers (signals, message signs, sensors)
• ITS system integrators and software developers building SNMP management systems
• Network and operations managers responsible for remote device monitoring and configuration
• Procurement agencies and standards architects seeking interoperable, non‑proprietary ITS solutions
• C-ITS and roadside equipment vendors implementing secure, standardized management interfaces

Practical uses include standardized time synchronization and DST handling, efficient bulk telemetry via object groups, consistent SNMP target configuration for secure remote management, and providing MIBs for interoperable monitoring and control.

Related standards & notes

• Part of the ISO 20684 series; see ISO 20684-1 for series overview and ITS architecture context.
• References IETF RFC 3413 (SNMP applications) and SMIv2 (RFC 2578–2580).
• The document notes similarities with parts of NTCIP 1103 and NTCIP 1201.

Standards Content (Sample)

TECHNICAL ISO/TS
SPECIFICATION 20684-7
First edition
2022-10
Intelligent transport systems —
Roadside modules SNMP data
interface —
Part 7:
Support features
Systèmes de transport intelligents — Interface de données SNMP pour
les modules en bord de route —
Partie 7: Service de support
Reference number
© ISO 2022
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
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Conformance . 2
5 User needs . 4
5.1 Efficient exchange of data . 4
5.1.1 Object group user need . 4
6 Requirements . 4
6.1 Local clock . 4
6.1.1 Local clock definition . 4
6.1.2 Local clock data exchange requirements . 4
6.2 UTC clock . 4
6.2.1 UTC clock definition . 4
6.2.2 UTC clock data exchange requirements . 4
6.2.3 UTC clock capabilities . 5
6.3 Daylight saving time . 6
6.3.1 Daylight saving time definition . 6
6.3.2 Daylight saving time data exchange requirements . 6
6.3.3 Daylight saving time capability requirements . 7
6.4 Object group . 7
6.4.1 Object group definition . 7
6.4.2 Object group data exchange . 7
6.4.3 Object group capabilities . 8
6.5 SNMP target . 9
6.5.1 Target definition . 9
6.5.2 Target data exchange requirements . 9
6.5.3 Target capabilities . 9
6.6 SNMP target parameters . 10
6.6.1 SNMP target parameters definition . 10
6.6.2 SNMP target parameters data exchange requirements . 10
7 Dialogues .11
7.1 Retrieve a complex object group . 11
7.2 Set an object group value . 11
7.3 Clear an object group list . 12
8 Security vulnerabilities .12
Annex A (normative) Management information base (MIB) .13
Annex B (normative) Requirements traceability matrix (RTM) .37
Bibliography .43
iii
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
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 ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (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 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).
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 Technical Committee ISO/TC 204, Intelligent transport systems.
A list of all parts in the ISO 20684 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
Introduction
0.1  Background
The need for standardized communication with ITS field devices is growing around the world.
Several countries have adopted Simple Network Management Protocol (SNMP) based field device
communication standards.
There is a growing view and empirical evidence that standardizing this activity will result in improved
ITS performance, reduced cost, reduced deployment time, and improved maintainability. The ISO 20684
series extends ISO 15784-2 by defining the management information necessary to monitor, configure
and control features of field devices. The data elements defined in all parts of ISO 20684 series may be
used with any protocol but were designed with an expectation that they would be used with one of the
ISO 15784-2 protocols.
By using this approach, agencies can specify open procurements and systems can be expanded
geographically in an open and non-proprietary manner, which reduces costs, speeds up deployment,
and simplifies integration.
0.2  Overview
SNMP is a collection of well-thought-out and well-proven concepts and principles. SNMP employs the
sound principles of abstraction and standardization. This has led to SNMP being widely accepted as the
prime choice for communication between management systems and devices on the internet and other
communications networks.
The original implementation of SNMP was used to manage network devices such as routers and
switches. Since then, the use of SNMP has grown into many areas of application on the internet and has
also been used successfully over various serial communications networks.
This document defines management information for ITS field devices following the SNMP conventions.
0.3  Document approach and layout
This document defines:
a) the conformance requirements for this document (Clause 4);
b) a set of user needs for user-defined trigger conditions that can “fire” to initiate actions (Clause 5);
c) a set of detailed requirements for the identified user needs (Clause 6);
d) custom dialogues for the logging feature (Clause 7);
e) security considerations for the information defined in this document (Clause 8);
f) the management information bases that define the data for the defined requirements (Annex A);
g) the requirements traceability matrix (RTM) that traces the requirements to the design elements
(Annex B).
v
TECHNICAL SPECIFICATION ISO/TS 20684-7:2022(E)
Intelligent transport systems — Roadside modules SNMP
data interface —
Part 7:
Support features
1 Scope
Field devices are a key component in intelligent transport systems (ITS). Field devices include traffic
signals, message signs, weather stations, traffic sensors, roadside equipment for connected ITS (C-ITS)
environments, etc.
Field devices often need to exchange information with other external entities (managers). Field devices
can be quite complex, necessitating the standardization of many data concepts for exchange. As such,
the ISO 20684 series is divided several individual parts.
This document specifies user needs, requirements and design elements that are normatively used by
other parts of the ISO 20684 series. Specifically, it defines an internal field device clock, a mechanism
for grouping object values together to provide for more efficient transfer of data, and it provides formal
requirements for the SNMP target and target parameters as defined in IETF RFC 3413.
NOTE 1 There are similarities between certain portions of NTCIP 1103 and NTCIP 1201 and this document.
NOTE 2 ISO 20684-1 provides additional details about how the ISO 20684 series relates to the overall ITS
architecture.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 8825-1, Information technology — ASN.1 encoding rules — Part 1: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)
ISO/IEC 8825-7, Information technology — ASN.1 encoding rules — Part 7: Specification of Octet Encoding
Rules (OER)
ISO 20684-1:2021, Intelligent transport systems — Roadside modules SNMP data interface — Part 1:
Overview
IETF RFC 2578, Structure of Management Information Version 2 (SMIv2), April 1999.
IETF RFC 2579, Textual Conventions for SMIv2, April 1999.
IETF RFC 2580, Conformance Statements for SMIv2, April 1999.
IETF RFC 3411, An Architecture for Describing Simple Network Management Protocol (SNMP) Management
Frameworks, December 2002.
IETF RFC 3413, Simple Network Management Protocol (SNMP) Applications, December 2002.
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 20684-1 apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
4 Conformance
This clause follows the rules defined in ISO 20684-1. Table 1 traces each user need to a set of software
features. Table 2 traces each feature to a set of requirements. Table 3 defines terms that are used as
predicates in the conformance codes listed in Tables 1 and 2. For a full understanding of these tables
and codes, see ISO 20684-1.
Table 1 — User need and feature conformance
Need Requirement Conformance
5.1: Efficient exchange of data O
6.4: Object group M
Table 2 — Requirement conformance
Feature Requirement Conformance
6.1: Local clock
6.1.2.1: Configure local clock M
6.1.2.2: Confirm local clock configuration M
6.1.2.3: Determine local clock time M
6.2: UTC clock
6.2.2.1: Discover UTC clock capabilities M
6.2.2.2: Configure UTC clock M
6.2.2.3: Confirm UTC clock configuration M
6.2.2.4: Determine UTC clock status M
6.2.2.5: Determine UTC time source status M
6.2.2.6: Set UTC time snmp_time:M
6.2.2.7: Retrieve UTC time M
6.2.2.8: Determine time discontinuity information M
6.2.3.1.1: Support for SNMP time configuration O.1 (1.*)
6.2.3.1.2: Support for network time protocol O.1 (1.*)
6.2.3.1.3: Support for radio time broadcast O.1 (1.*)
6.2.3.1.4: Support for satellite time signal O.1 (1.*)
6.2.3.2.1: Line frequency O.2 (1.*)
6.2.3.2.2: Crystal O.2 (1.*)
6.3: Daylight saving time
6.3.2.1: Determine daylight saving time capabilities M
6.3.2.2: Configure daylight savings schedule M
6.3.2.3: Confirm daylight savings schedule configuration M
6.3.2.4: Determine daylight savings time active M
6.3.2.5: Determine daylight savings time adjustment M
TTabablele 2 2 ((ccoonnttiinnueuedd))
Feature Requirement Conformance
6.3.3.1: Number of daylight saving entries M
6.4: Object group
6.4.2.1: Determine object group capabilities M
6.4.2.2: Configure object group M
6.4.2.3: Confirm object group configuration M
6.4.2.4: Retrieve simple object group data M
6.4.2.5: Retrieve complex object group data O
6.4.2.6: Set new value for the object group set:M
6.4.2.7: Retrieve the last object group value set set:M
6.4.2.8: Retrieve object group statistics M
6.4.2.9: Clear object group M
6.4.2.10: Toggle object group M
6.4.2.11: Retrieve object group status M
6.4.3.1: Number of referenced objects M
6.4.3.2: Object group variable bindings size M
6.4.3.3: Object group basic encoding M
6.4.3.4: Object group octet encoding O
6.4.3.5: Support of set operations on object groups O
6.4.3.6: Support for complex object groups O
6.5: SNMP target
6.5.2.1: Configure a target M
6.5.2.2: Confirm a target configuration M
6.5.2.3: Delete a target configuration M
6.5.2.4: Toggle a target M
6.5.2.5: Retrieve target row status M
6.5.2.6: Retrieve target statistics M
6.5.3.1.1: Support for SNMPv1 targets O
6.5.3.1.2: Support for SNMPv2c targets O
6.5.3.1.3: Support for SNMPv3 targets M
6.5.3.1.4: Support for STMP targets O
6.5.3.2.1: Support for UDP/IP targets O
6.5.3.2.2: Support for TCP/IP targets O
6.5.3.2.3: Support for DTLS/IP targets M
6.5.3.2.4: Support for TLS/IP targets O
6.5.3.3: Security profiles M
6.6: SNMP target parameters
6.6.2.1: Configure SNMP target parameters M
6.6.2.2: Confirm configuration of SNMP target parameters M
6.6.2.3: Delete SNMP target parameters M
Table 3 — External standard reference
Predicate Clause
snmp_time 6.2.3.1.1
set 6.4.3.5
5 User needs
5.1 Efficient exchange of data
5.1.1 Object group user need
It is not uncommon for an SNMP manager to perform requests on the same group of managed object
values from an SNMP agent multiple times. For example, an SNMP manager can potentially be configured
to request a specific group of objects periodically to monitor the status of a device or when a certain
set of predefined conditions occur. Normal SNMP operations require the complete object identifier
(OID) of every object value to be specified in each request. These OIDs are often 10-20 octets in length,
which can significantly increase communications overhead when the values being retrieved are small
(e.g. one-octet INTEGERs). This document defines a mechanism to allow a manager to configure object
groups, which can then be used to interact with multiple managed objects via a single OID.
6 Requirements
6.1 Local clock
6.1.1 Local clock definition
The local clock feature allows a field device to be aware of the local time as adjusted from the UTC clock
by the local time zone and any daylight saving algorithms in effect, if the daylight saving feature is
supported.
6.1.2 Local clock data exchange requirements
6.1.2.1 Configure local clock
The field device shall allow a manager to configure the local time zone for the clock.
6.1.2.2 Confirm local clock configuration
The field device shall allow a manager to confirm the configuration of the local clock.
6.1.2.3 Determine local clock time
The field device shall allow a manager to determine the local date and time.
6.2 UTC clock
6.2.1 UTC clock definition
The UTC clock feature allows a field device to maintain awareness of passing time; it represents the
UTC time within the field device. However, there is no formal requirement as to the exact time source or
accuracy. Ideally, it should be synchronized with a reliable and accurate time source in a secure manner.
6.2.2 UTC clock data exchange requirements
6.2.2.1 Discover UTC clock capabilities
The field device shall allow a manager to determine the capabilities of the UTC clock, including which
time source and time-keeping options are available.
6.2.2.2 Configure UTC clock
The field device shall allow a manager to configure which available time source and time-keeping
option to use as well as the frequency for synchronizing the clock and when to report discontinuities in
time synchronization.
6.2.2.3 Confirm UTC clock configuration
The field device shall allow a manager to determine the configuration of the UTC clock.
6.2.2.4 Determine UTC clock status
The field device shall allow a manager to determine the time source and time-keeping option actually
being used and the last time the clock was synchronized with the configured time source.
6.2.2.5 Determine UTC time source status
The field device shall allow a manager to determine the status of each supported time source.
6.2.2.6 Set UTC time
If a field device supports the configured time capability of the UTC clock feature, the field device shall
allow a manager to set the current UTC time using SNMP.
NOTE This is perhaps the easiest time synchronization to implement, but also the least accurate. Variable
multi-second communication network delays can occur between the time the manager initiates the set operation
and the time the field device receives the command, especially when the command has to traverse a complex
communications network.
6.2.2.7 Retrieve UTC time
The field device shall allow a manager to retrieve the current time in UTC.
NOTE Variable multi-second communication network delays can occur between the field device transmitting
the time and the manager receiving it, especially when the command has to traverse a complex communications
network.
6.2.2.8 Determine time discontinuity information
The field device shall allow a manager to determine information about discontinuities in its UTC time to
enable to the detection of unusual behaviour in the clock.
NOTE The UTC time is expected to consistently increment its value. However, resynchronizing with an
outside time source can result in an adjustment, known as a discontinuity.
6.2.3 UTC clock capabilities
6.2.3.1 Time source
6.2.3.1.1 Support for SNMP time configuration
The field device shall allow a manager to configure the time by SNMP.
6.2.3.1.2 Support for network time protocol
The field device allows the time to be set using the Network Time Protocol version 4 (NTPv4).
NOTE NTPv4 does not have any security. Devices that support NTPv4 are encouraged to provide mechanisms
to physically disable access to this protocol and thereby close a potential security threat for systems that choose
not to use this feature.
6.2.3.1.3 Support for radio time broadcast
The field device is able to set its time using a time signal broadcast over land-based radio waves.
6.2.3.1.4 Support for satellite time signal
The field device shall allow setting the time in the device based on satellite time signals.
6.2.3.2 Time-keeping
6.2.3.2.1 Line frequency
The field device shall allow time-keeping by monitoring the local electrical line frequency.
6.2.3.2.2 Crystal
The field device shall allow time-keeping with the use of an on-board time crystal.
6.3 Daylight saving time
6.3.1 Daylight saving time definition
The daylight saving time (DST) feature allows a manager to define when the local clock should spring
forward and fall backwards to conform to local time customs. In addition to defining when the events
occur, the design also allows the manager to specify how large of a shift is required. Finally, the design
allows for multi-stage daylight savings adjustments (e.g. spring a half hour forward and then spring
another half hour forward before falling back half an hour twice), but only requires support for a single
stage. A procurement specification can require support for multi-stage changes, if deemed necessary.
6.3.2 Daylight saving time data exchange requirements
6.3.2.1 Determine daylight saving time capabilities
The field device shall allow a manager to determine the number of daylight saving time event pairs that
the device supports.
NOTE A daylight saving time event pair consists of the spring forward and fall back events.
6.3.2.2 Configure daylight savings schedule
The field device shall allow a manager to configure the start and end times for daylight saving time as
well as the amount of time that the local time should shift.
6.3.2.3 Confirm daylight savings schedule configuration
The field device shall allow a manager to confirm the configuration of the daylight savings schedule.
6.3.2.4 Determine daylight savings time active
The field device shall allow a manager to determine the status of each daylight savings time rule.
6.3.2.5 Determine daylight savings time adjustment
The field device shall allow a manager to determine the total of the current daylight savings time
adjustments.
6.3.3 Daylight saving time capability requirements
6.3.3.1 Number of daylight saving entries
If a field device supports the local clock feature, the field device shall support at least one annual
daylight saving adjustment.
6.4 Object group
6.4.1 Object group definition
An object group can minimize the amount of communications overhead for requests that will be
regularly repeated. Each object group value is a user-configured sequence of data elements from the
device. The data can be stored or retrieved without including the OID for each individual field within
the object group while also using the more efficient octet encoding rules (OER) rather than the normal
basic encoding rules.
6.4.2 Object group data exchange
6.4.2.1 Determine object group capabilities
6.4.2.2 Configure object group
A field device shall allow a manager to configure the objects to be contained within an object group.
6.4.2.3 Confirm object group configuration
A field device shall allow a manager to determine the configuration of an object group.
6.4.2.4 Retrieve simple object group data
A field device shall allow a manager to retrieve the values of each object within an object group through
a simple request.
6.4.2.5 Retrieve complex object group data
A field device shall allow a manager to retrieve the values of each object within an object group using a
two-step process, designed to prevent timeouts for requests that require significant processing time.
6.4.2.6 Set new value for the object group
A field device shall allow a manager to perform a set operation on the object group.
6.4.2.7 Retrieve the last object group value set
A field device shall allow a manager to retrieve the last value submitted in a set request for the object
group.
6.4.2.8 Retrieve object group statistics
A field device shall allow a manager to retrieve statistics about when the last retrieval operation was
made and the estimated duration for requests.
6.4.2.9 Clear object group
The field device shall allow a manager to clear the definition of an object group.
6.4.2.10 Toggle object group
The field device shall allow a manager to enable/disable an object group.
6.4.2.11 Retrieve object group status
The field device shall allow a manager to retrieve the status of an object group.
6.4.3 Object group capabilities
6.4.3.1 Number of referenced objects
The field device shall support at least two referenced objects for each object group.
NOTE An object group only offers a significant benefit if it compresses at least two objects. A device can
perhaps want to establish limits on the number of objects within a group to prevent unreasonably complex
requests.
6.4.3.2 Object group variable bindings size
The field device shall support values of the object group data up to a maximum size, which is required
to be at least 400 octets.
NOTE The 400-octet limit is based on the standard conformant SNMP data packet size minus adequate room
for an SNMP header.
6.4.3.3 Object group basic encoding
The field device shall support encoding object groups as per the basic encoding rules (ISO 8825-1).
6.4.3.4 Object group octet encoding
A field device shall support encoding object groups as per the octet encoding rules (ISO 8825-7).
6.4.3.5 Support of set operations on object groups
The field device shall support set operations on all object groups that only contain writable objects.
6.4.3.6 Support for complex object groups
The field device shall support a two-step request process.
NOTE Otherwise, any object group defined can potentially use the one-step process and complex definitions.
If allowed, this can potentially require a significant amount of processing time before a response is generated.
6.5 SNMP target
6.5.1 Target definition
A target represents a remote SNMP entity that can receive messages from the field device. The remote
SNMP entity can be a manager that can receive SNMP notifications or can be a remote field device that
can receive SNMP requests.
6.5.2 Target data exchange requirements
6.5.2.1 Configure a target
The field device shall allow a manager to configure a target, including its address, security and
communication parameters.
6.5.2.2 Confirm a target configuration
The field device shall allow a manager to determine the configuration of a target.
6.5.2.3 Delete a target configuration
The field device shall allow a manager to clear the configuration of a target.
6.5.2.4 Toggle a target
The field device shall allow a manager to enable/disable a target.
6.5.2.5 Retrieve target row status
The field device shall allow a manager to retrieve the status of a target entry row.
6.5.2.6 Retrieve target statistics
The field device shall allow a manager to retrieve statistics about the targets.
6.5.3 Target capabilities
6.5.3.1 Application profiles
6.5.3.1.1 Support for SNMPv1 targets
The field device shall support the SNMPv1 application profile when sending information to targets.
6.5.3.1.2 Support for SNMPv2c targets
The field device shall support the SNMPv2c application profile when sending information to targets.
6.5.3.1.3 Support for SNMPv3 targets
The field device shall support the SNMPv3 application profile when sending information to targets.
6.5.3.1.4 Support for STMP targets
The field device shall support the STMP application profile when sending information to targets.
6.5.3.2 Transport profiles
6.5.3.2.1 Support for UDP/IP targets
The field device shall support the UDP/IP transport profile when sending information to targets.
6.5.3.2.2 Support for TCP/IP targets
The field device shall support the TCP/IP transport profile when sending information to targets.
6.5.3.2.3 Support for DTLS/IP targets
The field device shall support the DTLS/UDP/IP transport profile when sending information to targets.
6.5.3.2.4 Support for TLS/IP targets
The field device shall support the TLS/TCP/IP transport profile when sending information to targets.
6.5.3.3 Security profiles
The field device shall support the following security profiles when sending messages to targets:
a) AES encryption,
b) SHA-2 Authentication.
NOTE The configuration of the SNMP Target Parameters table defines the rules on whether authentication
and/or encryption is required to access data. For example, one set of access parameters can potentially be
defined to access some subset of data without any authentication or encryption while another set of parameters
can potentially provide full read-write access, but only with authentication and encryption.
6.6 SNMP target parameters
6.6.1 SNMP target parameters definition
The SNMP target parameters define a set of communication parameters for communicating with SNMP
targets.
6.6.2 SNMP target parameters data exchange requirements
6.6.2.1 Configure SNMP target parameters
The field device shall allow a manager to configure an SNMP target parameters entry, including the
message model and security settings.
6.6.2.2 Confirm configuration of SNMP target parameters
The field device shall allow a manager to confirm the configuration of an SNMP target parameters entry.
6.6.2.3 Delete SNMP target parameters
The field device shall allow a manager to delete an SNMP target parameters entry.
7 Dialogues
7.1 Retrieve a complex object group
The retrieval of a complex object group can require more time than a normal SNMP operation; this
dialogue provides a two-step process by which data can be retrieved where each step can be more
responsive. The standardized dialogue shall be as follows.
a) The dialogue shall be initiated by the manager. The logic used by the manager to initiate the
dialogue is outside the scope of this document. Prior to initiating the dialogue, the manager shall be
aware of which entry (x) in the table it wishes to retrieve.
b) The manager shall send a GetRequest-PDU for fdObjectGroupRowStatus.x and
fdObjectGroupRefresh.x.
1) If the value returned for fdObjectGroupRowStatus.x is not 'active', the dialogue shall terminate.
2) If the value returned for fdObjectGroupRefesh.x is 'oneStep', the dialogue shall terminate and
the manager shall use the one-step method for retrieving the object value.
3) If the value returned for fdObjectGroupRefesh.x is 'ready', the dialogue shall continue to step c).
4) If the value returned for fdObjectGroupRefesh.x is anything else, the dialogue shall terminate.
c) The manager shall send a SetRequest-PDU to set fdObjectGroupRefresh.x to 'refresh'.
d) The manager shall send a GetRequest-PDU for fdObjectGroupRefresh.x. If the value returned is
'pending', the manager will repeat this step (unless the manager decides to abort the operation). If
the value returned is 'ready', the manager shall proceed to step e); if the value returned is anything
else, the manager shall terminate the dialogue.
e) The manager shall send a GetRequest-PDU for fObjectGroupCurrentValue.x. The returned value
represents the value of the object group.
7.2 Set an object group value
This dialogue provides a process by which data values for multiple objects can be stored in the device
using a single object group. The standardized dialogue shall be as follows.
a) The dialogue shall be initiated by the manager. The logic used by the manager to initiate the
dialogue is outside the scope of this document. Prior to initiating the dialogue, the manager shall be
aware of which entry (x) in the table it wishes to use.
b) The manager shall send a GetRequest-PDU for fdObjectGroupRowStatus.x, fdObjectGroupRefresh.x,
and fdObjectGroupLastError.x.
1) If the value returned for fdObjectGroupRowStatus.x is not 'active', the dialogue shall terminate.
2) If the value returned for fdObjectGroupRefesh.x is not 'oneStep' or 'ready', the dialogue shall
terminate.
3) If the value returned for fdObjectGroupLastError is 'pending' the dialogue shall terminate.
4) Otherwise, the dialogue shall continue to step c).
c) The manager shall send a SetRequest-PDU to set fdObjectGroupNewValue.x to the desired value.
1) If the value returned for fdObjectGroupRefesh.x in step b) was 'oneStep', the dialogue has
completed and the result of the set request is contained within the response to step c).
2) If the value returned for fdObjectGroupRefesh.x in step b) was 'ready' and the result from
step c) indicates an error, the dialogue shall terminate. This condition indicates that the field
device was unable to decode the object group as per the current configuration.
3) If the value returned for fdObjectGroupRefesh.x in step b) was 'ready' and the result from step
c) did not indicate an error, proceed to step d).
d) The manager shall send a GetRequest-PDU for fdObjectGroupLastError.x and
fdObjectGroupLastErrorIndex.x. These objects will indicate the success or failure of the request
with an indication of which field within the object group caused any error.
7.3 Clear an object group list
This dialogue provides a process by which the fields within an object group can be cleared. The
standardized dialogue shall be as follows.
a) The dialogue shall be initiated by the manager. The logic used by the manager to initiate the
dialogue is outside the scope of this document. Prior to initiating the dialogue, the manager shall be
aware of which entry (x) in the table it wishes to use.
b) The manager shall send a GetRequest-PDU for fdObjectGroupRowStatus.x.
1) If the response indicates that fdObjectGroupRowStatus.x does not exist, the dialogue shall
terminate (i.e. the object group is already cleared).
2) If the response value for fdObjectGroupRowStatus.x is 'active', the manager shall send a
SetRequest-PDU to set fdObjectGroupRowStatus.x to 'notInService'. If this results in an error,
the dialogue shall terminate.
c) The manager shall send a SetRequest-PDU to set fdObjectGroupClear.x to 'true'.
NOTE At the end of this process, the object group entry will be in the 'notReady' state since the entry will
not contain valid information to be used.
8 Security vulnerabilities
There are data elements defined in this document with a MAX-ACCESS clause of read-write and/or
read-create. These and other data elements are sensitive and need to be protected from malicious and
inadvertent manipulation and/or disclosure. The support for requests in a non-secure environment
without proper protection can have a negative effect on network operations. A sampling of the
vulnerabilities includes:
a) the ability to change the time, information within object groups, and/or the remote agents that the
field device will connect to;
b) the ability to delete object groups, or remote devices;
c) the ability to create additional object groups and other remote devices that can receive information;
and
d) the ability to monitor current configurations.
To overcome these vulnerabilities, it is highly recommended that SNMPv3 with TLS support, as defined
in RFC 6353, is used to exchange the data.
Annex A
(normative)
Management information base (MIB)
This annex provides definitions which it is useful to import into other management information base
(MIB) modules of this document.
A.1 Clock MIB
-- *****************************************************************************
-- A.1.1 Clock Header
-- *****************************************************************************

-- ASN1START
CLOCK-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, Integer32, TimeTicks,
Unsigned32
FROM SNMPv2-SMI
-- RFC 2578
TruthValue, StorageType, RowStatus
FROM SNMPv2-TC
-- RFC 2579
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
-- RFC 2580
ITSUnsigned8, ITSInteger16, ITSUnsigned16, ITSDayOfWeek, ITSDayOfMonth,
ITSMonth, ITSDailyTimeStamp, ITSDateStamp, fieldDevice, iso20684p7
FROM FIELD-DEVICE-TC-MIB
-- ISO 20684-1 Annex A
;
fdClockMIB MODULE-IDENTITY
LAST-UPDATED "202001082121Z"
ORGANIZATION "ISO TC 204 WG 9"
CONTACT-INFO
"name: Kenneth Vaughn
phone: [phone]
email: [e-mail]
postal: 6606 FM 1488 RD STE 148-503
Magnolia, TX 77354
USA"
DESCRIPTION
"This MIB defines a generalized clock that can be used within a field device
to track time, including an optional local time with a time zone and
daylight saving time (a.k.a., 'summer time') offsets."

REVISION "202001082121Z"
DESCRIPTION
"Initial revision of the document as proposed for CD ballot"

::= {iso20684p7 1}
-- *****************************************************************************
-- A.1.2 Node Definitions
-- *****************************************************************************

fdClockConformance OBJECT-IDENTITY
STATUS   current
DESCRIPTION
"A node containing conformance statements related to the fdClockMIB, as
defined in ISO/TS 20684-7."
::= {fdClockMIB 2}
fdClockCompliances OBJECT-IDENTITY
STATUS   current
DESCRIPTION
"A node for compliance statements for the fdClockMIB."
::= {fdClockConformance 1}
fdClockGroups OBJECT-IDENTITY
STATUS   current
DESCRIPTION
"A node for group definitions related to fdClockMIB."
::= {fdClockConformance 2}
fdClock OBJECT-IDENTITY
STATUS   current
DESCRIPTION
"A node defining management information related to the field device's
Clock."
::= {fieldDevice 9}
fdClockUtcTime OBJECT-TYPE
SYNTAX   ITSDailyTimeStamp
MAX-ACCESS read-write
STATUS   current
DESCRIPTION
"The number of milliseconds that have elapsed since 00:00:00.000 (midnight)
Coordinated Universal Time (UTC). Exactly one second past midnight UTC
would be represented as 1000."
REFERENCE "NTCIP 1201 Clause 2.4.1"

DEFVAL   {0}
::= {fdClock 1}
-- NTCIP violated standard SNMP conventions when it defined time as a
-- read-writable Counter; Counters are supposed to be read-only. The
-- NTCIP object also does not support the millisecond resolution that
-- is increasingly needed for field systems. To provide millisecond
-- resolution with a viable time range, the time object would need to
-- be more than a 4-byte integer, but SNMP does not natively support
-- such values. Thus, another mechanism is needed. The standard SNMPv3
-- TimeStamp textual Convention also fails to provide
...