[要約] RFC 8575は、Precision Time Protocol（PTP）のYANGデータモデルを定義しています。その目的は、ネットワークデバイスでPTPをサポートするための一貫性のあるデータモデルを提供することです。
Internet Engineering Task Force (IETF) Y. Jiang, Ed.
Request for Comments: 8575 Huawei
Category: Standards Track X. Liu
ISSN: 2070-1721 Independent
J. Xu
Huawei
R. Cummings, Ed.
National Instruments
May 2019
YANG Data Model for the Precision Time Protocol (PTP)
高精度時間プロトコル（PTP）のYANGデータモデル
Abstract
概要
This document defines a YANG data model for the configuration of devices and clocks using the Precision Time Protocol (PTP) as specified in IEEE Std 1588-2008. It also defines the retrieval of the configuration information, the data sets and the running states of PTP clocks. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA).
このドキュメントでは、IEEE Std 1588-2008で指定されているPrecision Time Protocol（PTP）を使用してデバイスとクロックを構成するためのYANGデータモデルを定義しています。また、構成情報、データセット、およびPTPクロックの実行状態の取得も定義します。このドキュメントのYANGモジュールは、ネットワーク管理データストアアーキテクチャ（NMDA）に準拠しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8575.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8575で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. IEEE Std 1588-2008 YANG Data Model Hierarchy . . . . . . . . 5
2.1. Interpretations from IEEE 1588 Working Group . . . . . . 7
2.2. Configuration and State . . . . . . . . . . . . . . . . . 8
3. IEEE Std 1588-2008 YANG Module . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Normative References . . . . . . . . . . . . . . . . . . 22
6.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Transferring YANG Work to the IEEE 1588 WG . . . . . 25
A.1. Assumptions for the Transfer . . . . . . . . . . . . . . 26
A.2. Intellectual Property Considerations . . . . . . . . . . 26
A.3. Namespace and Module Name . . . . . . . . . . . . . . . . 27
A.4. IEEE 1588 YANG Modules in ASCII Format . . . . . . . . . 28
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
As a synchronization protocol, IEEE Std 1588-2008 [IEEE1588] is widely supported in the carrier networks, industrial networks, automotive networks, and many other applications. It can provide high precision time synchronization as fine as nanoseconds. The protocol depends on a Precision Time Protocol (PTP) engine to decide its own state automatically, and a PTP transportation layer to carry the PTP timing and various quality messages. The configuration parameters and state data sets of IEEE Std 1588-2008 are numerous.
同期プロトコルとして、IEEE Std 1588-2008 [IEEE1588]は、キャリアネットワーク、産業用ネットワーク、自動車ネットワーク、および他の多くのアプリケーションで広くサポートされています。ナノ秒単位の高精度の時刻同期を提供できます。プロトコルは、Precision Time Protocol（PTP）エンジンに依存して自身の状態を自動的に決定し、PTPトランスポート層はPTPタイミングとさまざまな品質のメッセージを伝送します。 IEEE Std 1588-2008の構成パラメータと状態データセットは多数あります。
According to the concepts described in [RFC3444], IEEE Std 1588-2008 itself provides an information model in its normative specifications for the data sets (in IEEE Std 1588-2008 clause 8). Some standardization organizations, including the IETF, have specified data models in MIBs (Management Information Bases) for IEEE Std 1588-2008 data sets (e.g., [RFC8173] and [IEEE8021AS]). These MIBs are typically focused on retrieval of state data using the Simple Network Management Protocol (SNMP); furthermore, configuration of PTP data sets is not considered in [RFC8173].
[RFC3444]で説明されている概念によれば、IEEE Std 1588-2008自体が、データセットの標準仕様で情報モデルを提供しています（IEEE Std 1588-2008条項8）。 IETFを含む一部の標準化組織は、IEEE Std 1588-2008データセット（[RFC8173]や[IEEE8021AS]など）のMIB（管理情報ベース）でデータモデルを指定しています。これらのMIBは通常、Simple Network Management Protocol（SNMP）を使用した状態データの取得に重点が置かれています。さらに、PTPデータセットの構成は[RFC8173]では考慮されていません。
Some service providers and applications require that the management of the IEEE Std 1588-2008 synchronization network be flexible and more Internet based (typically overlaid on their transport networks). Software-Defined Networking (SDN) is another driving factor, which demands an improved configuration capability of synchronization networks.
一部のサービスプロバイダーおよびアプリケーションでは、IEEE Std 1588-2008同期ネットワークの管理が柔軟で、よりインターネットベースである必要があります（通常、トランスポートネットワークにオーバーレイされます）。 Software-Defined Networking（SDN）は、同期ネットワークの構成機能の向上を要求するもう1つの原動力です。
YANG [RFC7950] is a data modeling language used to model
configuration and state data manipulated by network management
protocols like the Network Configuration Protocol (NETCONF)
[RFC6241]. A small set of built-in data types is defined in
[RFC7950]; a collection of common data types is also defined in
[RFC6991]. Advantages of YANG include Internet-based configuration
capabilities, validation, rollback, and so on. All of these
characteristics make it attractive to become another candidate
modeling language for IEEE Std 1588-2008.
This document defines a YANG data model for the configuration of IEEE Std 1588-2008 devices and clocks as well as retrieval of the state data of IEEE Std 1588-2008 clocks. The data model is based on the PTP data sets as specified in [IEEE1588]. The technology-specific PTP information (e.g., those specifically implemented by a bridge, a router, or a telecom profile) is out of scope of this document.
このドキュメントは、IEEE Std 1588-2008デバイスとクロックの構成、およびIEEE Std 1588-2008クロックの状態データの取得のためのYANGデータモデルを定義します。データモデルは、[IEEE1588]で指定されているPTPデータセットに基づいています。テクノロジー固有のPTP情報（たとえば、ブリッジ、ルーター、またはテレコムプロファイルによって具体的に実装されたもの）は、このドキュメントの範囲外です。
The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA) [RFC8342].
このドキュメントのYANGモジュールは、ネットワーク管理データストアアーキテクチャ（NMDA）[RFC8342]に準拠しています。
When used in practice, network products in support of synchronization typically conform to one or more IEEE Std 1588-2008 profiles. Each profile specifies how IEEE Std 1588-2008 is used in a given industry (e.g., telecom or automotive) and application. A profile can require features that are optional in IEEE Std 1588-2008, and it can specify new features that use IEEE Std 1588-2008 as a foundation.
実際に使用する場合、同期をサポートするネットワーク製品は通常、1つ以上のIEEE Std 1588-2008プロファイルに準拠しています。各プロファイルは、IEEE Std 1588-2008が特定の業界（電気通信や自動車など）およびアプリケーションでどのように使用されるかを指定します。プロファイルには、IEEE Std 1588-2008でオプションの機能が必要な場合があり、IEEE Std 1588-2008を基盤として使用する新しい機能を指定できます。
The readers are assumed to be familiar with IEEE Std 1588-2008. It is expected that the IEEE Std 1588-2008 YANG module will be used as follows:
読者は、IEEE Std 1588-2008に精通していることを前提としています。 IEEE Std 1588-2008 YANGモジュールが次のように使用されることが予想されます。
- The IEEE Std 1588-2008 YANG module can be used as is for products that conform to one of the default profiles specified in IEEE Std 1588-2008.
- IEEE Std 1588-2008 YANGモジュールは、IEEE Std 1588-2008で指定されているデフォルトプロファイルの1つに準拠する製品にそのまま使用できます。
- When the IEEE Std 1588 standard is revised (e.g., the IEEE Std 1588 revision in progress at the time of writing this document), it will add some new optional features to its data sets. The YANG module of this document can be revised and extended to support these new features. Moreover, the YANG "revision" MUST be used to indicate changes to the YANG module under such a circumstance.
- IEEE Std 1588標準が改訂されると（このドキュメントの執筆時点で進行中のIEEE Std 1588改訂など）、データセットに新しいオプション機能がいくつか追加されます。このドキュメントのYANGモジュールは、これらの新機能をサポートするように修正および拡張できます。さらに、このような状況でのYANGモジュールの変更を示すために、YANGの「改訂」を使用する必要があります。
- A profile standard based on IEEE Std 1588-2008 may create a dedicated YANG module for its profile. The profile's YANG module SHOULD use YANG "import" to import the IEEE Std 1588-2008 YANG module as its foundation. Then the profile's YANG module SHOULD use YANG "augment" to add any profile-specific enhancements.
- IEEE Std 1588-2008に基づくプロファイル標準は、そのプロファイル専用のYANGモジュールを作成する場合があります。プロファイルのYANGモジュールは、YANG "import"を使用して、IEEE Std 1588-2008 YANGモジュールを基盤としてインポートする必要があります（SHOULD）。次に、プロファイルのYANGモジュールは、YANGの「拡張」を使用して、プロファイル固有の機能拡張を追加する必要があります（SHOULD）。
- A product that conforms to a profile standard may also create its own YANG module. The product's YANG module SHOULD "import" the profile's module, and then use YANG "augment" to add any product-specific enhancements.
- プロファイル標準に準拠する製品は、独自のYANGモジュールを作成することもできます。製品のYANGモジュールは、プロファイルのモジュールを「インポート」する必要があります（SHOULD）。次に、YANGの「拡張」を使用して、製品固有の機能拡張を追加します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Most terminology used in this document is extracted from [IEEE1588].
このドキュメントで使用されるほとんどの用語は、[IEEE1588]から抽出されます。
BC Boundary Clock, see Section 3.1.3 of [IEEE1588]
BC境界クロック、[IEEE1588]のセクション3.1.3を参照
DS Data Set, see Section 8.1.1 of [IEEE1588]
DSデータセット、[IEEE1588]のセクション8.1.1を参照
E2E End-to-End, see Section 3.2 of [IEEE1588]
E2Eエンドツーエンド、[IEEE1588]のセクション3.2を参照
IANA Internet Assigned Numbers Authority
IANA Internet Assigned Numbers Authority
OC Ordinary Clock, see Section 3.1.22 of [IEEE1588]
OC通常クロック、[IEEE1588]のセクション3.1.22を参照
P2P Peer-to-Peer, see Section 3.2 of [IEEE1588]
P2Pピアツーピア、[IEEE1588]のセクション3.2を参照
PTP Precision Time Protocol, see Section 3.1.28 of [IEEE1588]
PTP Precision Time Protocol、[IEEE1588]のセクション3.1.28を参照
TAI International Atomic Time, see Section 3.2 of [IEEE1588]
TAI International Atomic Time、[IEEE1588]のセクション3.2を参照
TC Transparent Clock, see Section 3.1.46 of [IEEE1588]
TC透過クロック、[IEEE1588]のセクション3.1.46を参照
UTC Coordinated Universal Time, see Section 3.2 of [IEEE1588]
UTC協定世界時、[IEEE1588]のセクション3.2を参照
PTP data set Structured attributes of clocks (an OC, BC, or TC) used for PTP decisions and for providing values for PTP message fields; see Section 8 of [IEEE1588].
PTPデータセットPTPの決定とPTPメッセージフィールドの値の提供に使用されるクロック（OC、BC、またはTC）の構造化属性。 [IEEE1588]のセクション8を参照してください。
PTP instance A PTP implementation in the device (i.e., an OC or BC) represented by a specific PTP data set.
PTPインスタンス特定のPTPデータセットによって表されるデバイス（つまり、OCまたはBC）のPTP実装。
This section describes the hierarchy of a YANG module for IEEE Std 1588-2008; specifically, query and configuration of device-wide or port-specific configuration information and clock data sets are described.
このセクションでは、IEEE Std 1588-2008のYANGモジュールの階層について説明します。具体的には、デバイス全体またはポート固有の構成情報とクロックデータセットのクエリと構成について説明します。
Query and configuration of clock information include:
クロック情報のクエリと設定には、次のものが含まれます。
(Note: The attribute names are consistent with IEEE Std 1588-2008, but changed to the YANG style, i.e., using all lowercase, with dashes between words.)
（注：属性名はIEEE Std 1588-2008に準拠していますが、YANGスタイルに変更されました。つまり、すべて小文字を使用し、単語間にダッシュを付けます。）
- Clock data set attributes in a clock node, including the following: current-ds, parent-ds, default-ds, time-properties-ds, and transparent-clock-default-ds.
- 次を含む、クロックノードのクロックデータセット属性：current-ds、parent-ds、default-ds、time-properties-ds、transparent-clock-default-ds。
- Port-specific data set attributes, including the following: port-ds and transparent-clock-port-ds.
- 次のものを含む、ポート固有のデータセット属性：port-dsおよびtransparent-clock-port-ds。
As all PTP terminology and PTP data set attributes are described in detail in IEEE Std 1588-2008, this document only outlines each of them in the YANG module.
すべてのPTP用語とPTPデータセットの属性はIEEE Std 1588-2008で詳細に説明されているため、このドキュメントでは、YANGモジュール内のそれぞれの概要のみを説明します。
A simplified YANG tree diagram [RFC8340] representing the data model is typically used by YANG modules. This document uses the same tree diagram syntax as described in [RFC8340].
データモデルを表す簡略化されたYANGツリー図[RFC8340]は、通常、YANGモジュールで使用されます。このドキュメントでは、[RFC8340]で説明されているのと同じツリー図の構文を使用します。
module: ietf-ptp
+--rw ptp
+--rw instance-list* [instance-number]
| +--rw instance-number uint32
| +--rw default-ds
| | +--rw two-step-flag? boolean
| | +--ro clock-identity? clock-identity-type
| | +--rw number-ports? uint16
| | +--rw clock-quality
| | | +--rw clock-class? uint8
| | | +--rw clock-accuracy? uint8
| | | +--rw offset-scaled-log-variance? uint16
| | +--rw priority1? uint8
| | +--rw priority2? uint8
| | +--rw domain-number? uint8
| | +--rw slave-only? boolean
| +--rw current-ds
| | +--rw steps-removed? uint16
| | +--rw offset-from-master? time-interval-type
| | +--rw mean-path-delay? time-interval-type
| +--rw parent-ds
| | +--rw parent-port-identity
| | | +--rw clock-identity? clock-identity-type
| | | +--rw port-number? uint16
| | +--rw parent-stats? boolean
| | +--rw observed-parent-offset-scaled-log-variance? uint16
| | +--rw observed-parent-clock-phase-change-rate? int32
| | +--rw grandmaster-identity? clock-identity-type
| | +--rw grandmaster-clock-quality
| | | +--rw clock-class? uint8
| | | +--rw clock-accuracy? uint8
| | | +--rw offset-scaled-log-variance? uint16
| | +--rw grandmaster-priority1? uint8
| | +--rw grandmaster-priority2? uint8
| +--rw time-properties-ds
| | +--rw current-utc-offset-valid? boolean
| | +--rw current-utc-offset? int16
| | +--rw leap59? boolean
| | +--rw leap61? boolean
| | +--rw time-traceable? boolean
| | +--rw frequency-traceable? boolean
| | +--rw ptp-timescale? boolean
| | +--rw time-source? uint8
| +--rw port-ds-list* [port-number]
| +--rw port-number uint16
| +--rw port-state? port-state-enumeration
| +--rw underlying-interface? if:interface-ref
| +--rw log-min-delay-req-interval? int8
| +--rw peer-mean-path-delay? time-interval-type
| +--rw log-announce-interval? int8
| +--rw announce-receipt-timeout? uint8
| +--rw log-sync-interval? int8
| +--rw delay-mechanism? delay-mechanism-enumeration
| +--rw log-min-pdelay-req-interval? int8
| +--rw version-number? uint8
+--rw transparent-clock-default-ds
| +--ro clock-identity? clock-identity-type
| +--rw number-ports? uint16
| +--rw delay-mechanism? delay-mechanism-enumeration
| +--rw primary-domain? uint8
+--rw transparent-clock-port-ds-list* [port-number]
+--rw port-number uint16
+--rw log-min-pdelay-req-interval? int8
+--rw faulty-flag? boolean
+--rw peer-mean-path-delay? time-interval-type
The preceding model and the associated YANG module have some subtle differences from the data set specifications of IEEE Std 1588-2008. These differences are based on interpretation from the IEEE 1588 Working Group, and they are intended to provide compatibility with future revisions of the IEEE Std 1588 standard.
上記のモデルと関連するYANGモジュールは、IEEE Std 1588-2008のデータセット仕様とは若干の違いがあります。これらの違いは、IEEE 1588ワーキンググループの解釈に基づいており、IEEE Std 1588標準の将来のリビジョンとの互換性を提供することを目的としています。
In IEEE Std 1588-2008, a physical product can implement multiple PTP clocks (i.e., an ordinary, boundary, or transparent clock). As specified in IEEE Std 1588-2008 subclause 7.1, each of the multiple clocks operates in an independent domain. However, the organization of multiple PTP domains was not clear in the data sets of IEEE Std 1588-2008. This document introduces the concept of a PTP instance, which is a PTP implementation in a device (i.e., an OC or BC) represented by a specific PTP data set. Each instance operates in exactly one domain. The instance concept is used exclusively to allow for optional support of multiple domains. The instance number has no usage within PTP messages.
IEEE Std 1588-2008では、物理製品は複数のPTPクロック（つまり、通常のクロック、境界クロック、または透過クロック）を実装できます。 IEEE Std 1588-2008の7.1節で指定されているように、複数のクロックはそれぞれ独立したドメインで動作します。ただし、IEEE Std 1588-2008のデータセットでは、複数のPTPドメインの編成が明確ではありませんでした。このドキュメントでは、特定のPTPデータセットで表されるデバイス（つまり、OCまたはBC）でのPTP実装であるPTPインスタンスの概念を紹介します。各インスタンスは正確に1つのドメインで動作します。インスタンスの概念は、複数のドメインのオプションのサポートを可能にするために排他的に使用されます。インスタンス番号は、PTPメッセージ内では使用されません。
Based on statements in IEEE Std 1588-2008 subclauses 8.3.1 and 10.1, most transparent clock products have interpreted the transparent clock data sets to reside as a singleton at the root level of the managed product, and this YANG data model reflects that location.
IEEE Std 1588-2008の8.3.1節と10.1節の記述に基づいて、ほとんどの透過クロック製品は透過クロックデータセットを管理対象製品のルートレベルのシングルトンとして常駐すると解釈し、このYANGデータモデルはその場所を反映しています。
The information model of IEEE Std 1588-2008 classifies each member in PTP data sets as one of the following:
IEEE Std 1588-2008の情報モデルは、PTPデータセットの各メンバーを次のいずれかに分類します。
Configurable: Writable by management.
構成可能：管理者が書き込み可能。
Dynamic: Read-only to management, and the value is changed by PTP protocol operation.
動的：管理に対して読み取り専用であり、値はPTPプロトコル操作によって変更されます。
Static: Read-only to management, and the value typically does not change.
静的：管理に対して読み取り専用であり、値は通常は変更されません。
For details on the classification of each PTP data set member, refer to the specification of that member in IEEE Std 1588-2008.
各PTPデータセットメンバーの分類の詳細については、IEEE Std 1588-2008のそのメンバーの仕様を参照してください。
Under certain circumstances, the classification of an IEEE Std 1588 data set member may change for a YANG implementation, for example, a configurable member needs to be changed to read-only. In such a case, an implementation SHOULD choose to return a warning upon writing to a read-only member or use the deviation mechanism to develop a new deviation model as described in Section 7.20.3 of [RFC7950].
特定の状況では、IEEE Std 1588データセットメンバーの分類がYANG実装で変更される場合があります。たとえば、構成可能なメンバーを読み取り専用に変更する必要があります。そのような場合、[SHOULD]実装は、読み取り専用メンバーへの書き込み時に警告を返すか、[RFC7950]のセクション7.20.3で説明されているように、偏差メカニズムを使用して新しい偏差モデルを開発することを選択する必要があります。
This module imports typedef "interface-ref" from [RFC8343]. Most attributes are based on the information model defined in [IEEE1588], but their names are adapted to the YANG style of naming.
このモジュールは、[RFC8343]からtypedef "interface-ref"をインポートします。ほとんどの属性は[IEEE1588]で定義された情報モデルに基づいていますが、それらの名前はYANGスタイルの命名に適合しています。
<CODE BEGINS> file "ietf-ptp@2019-05-07.yang"
module ietf-ptp {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ptp";
prefix ptp;
import ietf-interfaces {
prefix if;
reference
"RFC 8343: A YANG Data Model for Interface Management";
}
organization
"IETF TICTOC Working Group";
contact
"WG Web: https://datatracker.ietf.org/wg/tictoc/
WG List: <mailto:tictoc@ietf.org>
Editor: Yuanlong Jiang
<mailto:jiangyuanlong@huawei.com>
Editor: Rodney Cummings
<mailto:rodney.cummings@ni.com>";
description
"This YANG module defines a data model for the configuration
of IEEE Std 1588-2008 clocks, and also for retrieval of the state
data of IEEE Std 1588-2008 clocks.";
revision 2019-05-07 {
description
"Initial version";
reference
"RFC 8575: YANG Data Model for the Precision Time Protocol";
}
typedef delay-mechanism-enumeration {
type enumeration {
enum e2e {
value 1;
description
"The port uses the delay request-response mechanism.";
}
enum p2p {
value 2;
description
"The port uses the peer delay mechanism.";
}
enum disabled {
value 254;
description
"The port does not implement any delay mechanism.";
}
}
description
"The propagation-delay measuring option used by the
port. Values for this enumeration are specified
by the IEEE Std 1588 standard exclusively.";
reference
"IEEE Std 1588-2008: 8.2.5.4.4";
}
typedef port-state-enumeration {
type enumeration {
enum initializing {
value 1;
description
"The port is initializing its data sets, hardware, and
communication facilities.";
}
enum faulty {
value 2;
description
"The port is in the fault state.";
}
enum disabled {
value 3;
description
"The port is disabled and is not communicating PTP
messages (other than possibly PTP management
messages).";
}
enum listening {
value 4;
description
"The port is listening for an Announce message.";
}
enum pre-master {
value 5;
description
"The port is in the pre-master state.";
}
enum master {
value 6;
description
"The port is behaving as a master port.";
}
enum passive {
value 7;
description
"The port is in the passive state.";
}
enum uncalibrated {
value 8;
description
"A master port has been selected, but the port is still
in the uncalibrated state.";
}
enum slave {
value 9;
description
"The port is synchronizing to the selected master port.";
}
}
description
"The current state of the protocol engine associated
with the port. Values for this enumeration are specified
by the IEEE Std 1588 standard exclusively.";
reference
"IEEE Std 1588-2008: 8.2.5.3.1, 9.2.5";
}
typedef time-interval-type {
type int64;
description
"Derived data type for time interval, represented in units of
nanoseconds and multiplied by 2^16";
reference
"IEEE Std 1588-2008: 5.3.2";
}
typedef clock-identity-type {
type binary {
length "8";
}
description
"Derived data type to identify a clock";
reference
"IEEE Std 1588-2008: 5.3.4";
}
grouping clock-quality-grouping {
description
"Derived data type for quality of a clock, which contains
clockClass, clockAccuracy, and offsetScaledLogVariance.";
reference
"IEEE Std 1588-2008: 5.3.7";
leaf clock-class {
type uint8;
default "248";
description
"The clockClass denotes the traceability of the time
or frequency distributed by the clock.";
}
leaf clock-accuracy {
type uint8;
description
"The clockAccuracy indicates the expected accuracy
of the clock.";
}
leaf offset-scaled-log-variance {
type uint16;
description
"The offsetScaledLogVariance provides an estimate of
the variations of the clock from a linear timescale
when it is not synchronized to another clock
using the protocol.";
}
}
container ptp {
description
"The PTP struct containing all attributes of PTP data set,
other optional PTP attributes can be augmented as well.";
list instance-list {
key "instance-number";
description
"List of one or more PTP data sets in the device (see IEEE
Std 1588-2008 subclause 6.3).
Each PTP data set represents a distinct instance of
PTP implementation in the device (i.e., distinct
Ordinary Clock or Boundary Clock).";
leaf instance-number {
type uint32;
description
"The instance number of the current PTP instance.
This instance number is used for management purposes
only. This instance number does not represent the PTP
domain number and is not used in PTP messages.";
}
container default-ds {
description
"The default data set of the clock (see IEEE Std
1588-2008 subclause 8.2.1). This data set represents
the configuration/state required for operation
of Precision Time Protocol (PTP) state machines.";
reference
"IEEE Std 1588-2008: 8.2.1";
leaf two-step-flag {
type boolean;
description
"When set to true, the clock is a two-step clock;
otherwise,the clock is a one-step clock.";
}
leaf clock-identity {
type clock-identity-type;
config false;
description
"The clockIdentity of the local clock.";
}
leaf number-ports {
type uint16;
description
"The number of PTP ports on the instance.";
}
container clock-quality {
description
"The clockQuality of the local clock.";
uses clock-quality-grouping;
}
leaf priority1 {
type uint8;
description
"The priority1 attribute of the local clock.";
}
leaf priority2 {
type uint8;
description
"The priority2 attribute of the local clock.";
}
leaf domain-number {
type uint8;
description
"The domain number of the current syntonization
domain.";
}
leaf slave-only {
type boolean;
description
"When set to true, the clock is a slave-only clock.";
}
}
container current-ds {
description
"The current data set of the clock (see IEEE Std
1588-2008 subclause 8.2.2). This data set represents
local states learned from the exchange of
Precision Time Protocol (PTP) messages.";
reference
"IEEE Std 1588-2008: 8.2.2";
leaf steps-removed {
type uint16;
default "0";
description
"The number of communication paths traversed
between the local clock and the grandmaster clock.";
}
leaf offset-from-master {
type time-interval-type;
description
"The current value of the time difference between
a master and a slave clock as computed by the slave.";
}
leaf mean-path-delay {
type time-interval-type;
description
"The current value of the mean propagation time between
a master and a slave clock as computed by the slave.";
}
}
container parent-ds {
description
"The parent data set of the clock (see IEEE Std 1588-2008
subclause 8.2.3).";
reference
"IEEE Std 1588-2008: 8.2.3";
container parent-port-identity {
description
"The portIdentity of the port on the master, it
contains two members: clockIdentity and portNumber.";
reference
"IEEE Std 1588-2008: 5.3.5";
leaf clock-identity {
type clock-identity-type;
description
"Identity of the clock.";
}
leaf port-number {
type uint16;
description
"Port number.";
}
}
leaf parent-stats {
type boolean;
default "false";
description
"When set to true, the values of
observedParentOffsetScaledLogVariance and
observedParentClockPhaseChangeRate of parentDS
have been measured and are valid.";
}
leaf observed-parent-offset-scaled-log-variance {
type uint16;
default "65535";
description
"An estimate of the parent clock's PTP variance
as observed by the slave clock.";
}
leaf observed-parent-clock-phase-change-rate {
type int32;
description
"An estimate of the parent clock's phase change rate
as observed by the slave clock.";
}
leaf grandmaster-identity {
type clock-identity-type;
description
"The clockIdentity attribute of the grandmaster clock.";
}
container grandmaster-clock-quality {
description
"The clockQuality of the grandmaster clock.";
uses clock-quality-grouping;
}
leaf grandmaster-priority1 {
type uint8;
description
"The priority1 attribute of the grandmaster clock.";
}
leaf grandmaster-priority2 {
type uint8;
description
"The priority2 attribute of the grandmaster clock.";
}
}
container time-properties-ds {
description
"The timeProperties data set of the clock (see
IEEE Std 1588-2008 subclause 8.2.4).";
reference
"IEEE Std 1588-2008: 8.2.4";
leaf current-utc-offset-valid {
type boolean;
description
"When set to true, the current UTC offset is valid.";
}
leaf current-utc-offset {
when "../current-utc-offset-valid='true'";
type int16;
description
"The offset between TAI and UTC when the epoch of the
PTP system is the PTP epoch in units of seconds, i.e.,
when ptp-timescale is TRUE; otherwise, the value has
no meaning.";
}
leaf leap59 {
type boolean;
description
"When set to true, the last minute of the current UTC
day contains 59 seconds.";
}
leaf leap61 {
type boolean;
description
"When set to true, the last minute of the current UTC
day contains 61 seconds.";
}
leaf time-traceable {
type boolean;
description
"When set to true, the timescale and the
currentUtcOffset are traceable to a primary
reference.";
}
leaf frequency-traceable {
type boolean;
description
"When set to true, the frequency determining the
timescale is traceable to a primary reference.";
}
leaf ptp-timescale {
type boolean;
description
"When set to true, the clock timescale of the
grandmaster clock is PTP; otherwise, the timescale is
ARB (arbitrary).";
}
leaf time-source {
type uint8;
description
"The source of time used by the grandmaster clock.";
}
}
list port-ds-list {
key "port-number";
description
"List of port data sets of the clock (see IEEE Std
1588-2008 subclause 8.2.5).";
reference
"IEEE Std 1588-2008: 8.2.5";
leaf port-number {
type uint16;
description
"Port number.
The data sets (i.e., information model) of IEEE Std
1588-2008 specify a member portDS.portIdentity, which
uses a typed struct with members clockIdentity and
portNumber.
In this YANG data model, portIdentity is not modeled
in the port-ds-list. However, its members are provided
as follows:
portIdentity.portNumber is provided as this
port-number leaf in port-ds-list, and
portIdentity.clockIdentity is provided as the
clock-identity leaf in default-ds of the instance
(i.e., ../../default-ds/clock-identity).";
}
leaf port-state {
type port-state-enumeration;
default "initializing";
description
"Current state associated with the port.";
}
leaf underlying-interface {
type if:interface-ref;
description
"Reference to the configured underlying interface that
is used by this PTP port (see RFC 8343).";
reference
"RFC 8343: A YANG Data Model for Interface Management";
}
leaf log-min-delay-req-interval {
type int8;
description
"The base-2 logarithm of the minDelayReqInterval
(the minimum permitted mean time interval between
successive Delay_Req messages).";
}
leaf peer-mean-path-delay {
type time-interval-type;
default "0";
description
"An estimate of the current one-way propagation delay
on the link when the delayMechanism is P2P; otherwise,
it is zero.";
}
leaf log-announce-interval {
type int8;
description
"The base-2 logarithm of the mean
announceInterval (mean time interval between
successive Announce messages).";
}
leaf announce-receipt-timeout {
type uint8;
description
"The number of announceIntervals that have to pass
without receipt of an Announce message before the
occurrence of the event ANNOUNCE_RECEIPT_TIMEOUT_
EXPIRES.";
}
leaf log-sync-interval {
type int8;
description
"The base-2 logarithm of the mean SyncInterval
for multicast messages. The rates for unicast
transmissions are negotiated separately on a per-port
basis and are not constrained by this attribute.";
}
leaf delay-mechanism {
type delay-mechanism-enumeration;
description
"The propagation delay measuring option used by the
port in computing meanPathDelay.";
}
leaf log-min-pdelay-req-interval {
type int8;
description
"The base-2 logarithm of the
minPdelayReqInterval (minimum permitted mean time
interval between successive Pdelay_Req messages).";
}
leaf version-number {
type uint8;
description
"The PTP version in use on the port.";
}
}
}
container transparent-clock-default-ds {
description
"The members of the transparentClockDefault data set (see
IEEE Std 1588-2008 subclause 8.3.2).";
reference
"IEEE Std 1588-2008: 8.3.2";
leaf clock-identity {
type clock-identity-type;
config false;
description
"The clockIdentity of the transparent clock.";
}
leaf number-ports {
type uint16;
description
"The number of PTP ports on the transparent clock.";
}
leaf delay-mechanism {
type delay-mechanism-enumeration;
description
"The propagation delay measuring option
used by the transparent clock.";
}
leaf primary-domain {
type uint8;
default "0";
description
"The domainNumber of the primary syntonization domain (see
IEEE Std 1588-2008 subclause 10.1).";
reference
"IEEE Std 1588-2008: 10.1";
}
}
list transparent-clock-port-ds-list {
key "port-number";
description
"List of transparentClockPort data sets of the transparent
clock (see IEEE Std 1588-2008 subclause 8.3.3).";
reference
"IEEE Std 1588-2008: 8.3.3";
leaf port-number {
type uint16;
description
"Port number.
The data sets (i.e., information model) of IEEE Std
1588-2008 specify a member
transparentClockPortDS.portIdentity, which uses a typed
struct with members clockIdentity and portNumber.
In this YANG data model, portIdentity is not modeled in
the transparent-clock-port-ds-list. However, its
members are provided as follows:
portIdentity.portNumber is provided as this leaf member
in transparent-clock-port-ds-list and
portIdentity.clockIdentity is provided as the
clock-identity leaf in transparent-clock-default-ds
(i.e., ../../transparent-clock-default-ds/clock-
identity).";
}
leaf log-min-pdelay-req-interval {
type int8;
description
"The logarithm to the base 2 of the
minPdelayReqInterval (minimum permitted mean time
interval between successive Pdelay_Req messages).";
}
leaf faulty-flag {
type boolean;
default "false";
description
"When set to true, the port is faulty.";
}
leaf peer-mean-path-delay {
type time-interval-type;
default "0";
description
"An estimate of the current one-way propagation delay
on the link when the delayMechanism is P2P; otherwise,
it is zero.";
}
}
}
}
<CODE ENDS>
<コード終了>
The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. Furthermore, general security considerations of time protocols are discussed in [RFC7384].
このドキュメントで指定されているYANGモジュールは、NETCONF [RFC6241]やRESTCONF [RFC8040]などのネットワーク管理プロトコルを介してアクセスするように設計されたデータのスキーマを定義します。最下層のNETCONF層はセキュアなトランスポート層であり、実装に必須のセキュアなトランスポートはセキュアシェル（SSH）[RFC6242]です。最下位のRESTCONFレイヤーはHTTPSであり、実装に必須のセキュアなトランスポートはTLS [RFC8446]です。さらに、時間プロトコルの一般的なセキュリティの考慮事項は[RFC7384]で議論されています。
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
ネットワーク構成アクセス制御モデル（NACM）[RFC8341]は、特定のNETCONFまたはRESTCONFユーザーのアクセスを、利用可能なすべてのNETCONFまたはRESTCONFプロトコル操作およびコンテンツの事前構成されたサブセットに制限する手段を提供します。
There are a number of data nodes defined in this YANG module that are writable, and the involved subtrees that are sensitive include:
このYANGモジュールには、書き込み可能なデータノードがいくつか定義されており、機密性の高い関連するサブツリーには次のものがあります。
/ptp/instance-list specifies an instance (i.e., PTP data sets) for an OC or BC.
/ ptp / instance-listは、OCまたはBCのインスタンス（つまり、PTPデータセット）を指定します。
/ptp/transparent-clock-default-ds specifies a default data set for a TC.
/ ptp / transparent-clock-default-dsは、TCのデフォルトデータセットを指定します。
/ptp/transparent-clock-port-ds-list specifies a list of port data sets for a TC.
/ ptp / transparent-clock-port-ds-listは、TCのポートデータセットのリストを指定します。
Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. Specifically, an inappropriate configuration of them may adversely impact a PTP synchronization network. For example, loss of synchronization on a clock, accuracy degradation on a set of clocks, or even break down of a whole synchronization network.
適切な保護なしにこれらのデータノードに書き込み操作（edit-configなど）を行うと、ネットワーク操作に悪影響を与える可能性があります。特に、それらの不適切な構成は、PTP同期ネットワークに悪影響を与える可能性があります。たとえば、クロックの同期が失われたり、一連のクロックの精度が低下したり、同期ネットワーク全体が故障したりします。
This document registers the following URI in the "IETF XML Registry" [RFC3688]:
このドキュメントでは、「IETF XMLレジストリ」[RFC3688]に次のURIを登録しています。
URI: urn:ietf:params:xml:ns:yang:ietf-ptp
Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace
This document registers the following YANG module in the "YANG Module Names" registry [RFC6020]:
このドキュメントでは、「YANGモジュール名」レジストリ[RFC6020]に次のYANGモジュールを登録しています。
Name: ietf-ptp
Namespace: urn:ietf:params:xml:ns:yang:ietf-ptp
Prefix: ptp
Reference: RFC 8575
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC3688] Mealling、M。、「The IETF XML Registry」、BCP 81、RFC 3688、DOI 10.17487 / RFC3688、2004年1月、<https://www.rfc-editor.org/info/rfc3688>。
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.
[RFC6020] Bjorklund、M。、編、「YANG-ネットワーク構成プロトコル（NETCONF）のデータモデリング言語」、RFC 6020、DOI 10.17487 / RFC6020、2010年10月、<https：//www.rfc-editor。 org / info / rfc6020>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol（NETCONF）」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.
[RFC6242] Wasserman、M。、「Using the NETCONF Protocol over Secure Shell（SSH）」、RFC 6242、DOI 10.17487 / RFC6242、2011年6月、<https://www.rfc-editor.org/info/rfc6242>。
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC6991] Schoenwaelder、J。、編、「Common YANG Data Types」、RFC 6991、DOI 10.17487 / RFC6991、2013年7月、<https://www.rfc-editor.org/info/rfc6991>。
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC7950] Bjorklund、M。、編、「The YANG 1.1 Data Modeling Language」、RFC 7950、DOI 10.17487 / RFC7950、2016年8月、<https://www.rfc-editor.org/info/rfc7950>。
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8040] Bierman、A.、Bjorklund、M。、およびK. Watsen、「RESTCONFプロトコル」、RFC 8040、DOI 10.17487 / RFC8040、2017年1月、<https://www.rfc-editor.org/info/rfc8040 >。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.
[RFC8341] Bierman、A。およびM. Bjorklund、「Network Configuration Access Control Model」、STD 91、RFC 8341、DOI 10.17487 / RFC8341、2018年3月、<https://www.rfc-editor.org/info/rfc8341 >。
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.
[RFC8342] Bjorklund、M.、Schoenwaelder、J.、Shafer、P.、Watsen、K。、およびR. Wilton、「Network Management Datastore Architecture（NMDA）」、RFC 8342、DOI 10.17487 / RFC8342、2018年3月、< https://www.rfc-editor.org/info/rfc8342>。
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.
[RFC8343] Bjorklund、M。、「A YANG Data Model for Interface Management」、RFC 8343、DOI 10.17487 / RFC8343、March 2018、<https://www.rfc-editor.org/info/rfc8343>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。
[IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Std 1588-2008, DOI 10.1109/IEEESTD.2008.4579760, July 2008.
[IEEE1588] IEEE、「IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems」、IEEE Std 1588-2008、DOI 10.1109 / IEEESTD.2008.4579760、July 2008。
[IEEE8021AS] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Timing and Synchronizations for Time-Sensitive Applications in Bridged Local Area Networks", IEEE 802.1AS-2001.
[IEEE8021AS] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Timing and Synchronizations for Time-Sensitive Application in Bridged Local Area Networks」、IEEE 802.1AS-2001。
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003, <https://www.rfc-editor.org/info/rfc3444>.
[RFC3444] Pras、A。およびJ. Schoenwaelder、「情報モデルとデータモデルの違いについて」、RFC 3444、DOI 10.17487 / RFC3444、2003年1月、<https://www.rfc-editor.org/info/ rfc3444>。
[RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG", RFC 4663, DOI 10.17487/RFC4663, September 2006, <https://www.rfc-editor.org/info/rfc4663>.
[RFC4663]ハリントン、D。、「IETFブリッジMIB WGからIEEE 802.1 WGへのMIB作業の転送」、RFC 4663、DOI 10.17487 / RFC4663、2006年9月、<https://www.rfc-editor.org/info/rfc4663 >。
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC7384]ミズラヒ、T。、「パケット交換ネットワークにおけるタイムプロトコルのセキュリティ要件」、RFC 7384、DOI 10.17487 / RFC7384、2014年10月、<https://www.rfc-editor.org/info/rfc7384>。
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.
[RFC8340] Bjorklund、M。およびL. Berger、編、「YANGツリー図」、BCP 215、RFC 8340、DOI 10.17487 / RFC8340、2018年3月、<https://www.rfc-editor.org/info/ rfc8340>。
[RFC8173] Shankarkumar, V., Montini, L., Frost, T., and G. Dowd, "Precision Time Protocol Version 2 (PTPv2) Management Information Base", RFC 8173, DOI 10.17487/RFC8173, June 2017, <https://www.rfc-editor.org/info/rfc8173>.
[RFC8173] Shankarkumar、V.、Montini、L.、Frost、T。、およびG. Dowd、「Precision Time Protocol Version 2（PTPv2）Management Information Base」、RFC 8173、DOI 10.17487 / RFC8173、2017年6月、<https ：//www.rfc-editor.org/info/rfc8173>。
This Appendix is informational.
この付録は参考情報です。
This appendix describes a future plan to transition responsibility for IEEE Std 1588 YANG modules from the IETF TICTOC Working Group (WG) to the IEEE 1588 WG, which develops the time synchronization technology that the YANG modules are designed to manage.
この付録では、IEEE Std 1588 YANGモジュールの責任をIETF TICTOCワーキンググループ（WG）からIEEE 1588 WGに移行する将来の計画について説明します。IEEE1588 WGは、YANGモジュールが管理するように設計された時刻同期技術を開発しています。
This appendix is forward-looking with regard to future standardization roadmaps in the IETF and IEEE. Since those roadmaps cannot be predicted with significant accuracy, this appendix is informational, and it does not specify imperatives or normative specifications of any kind.
この付録は、IETFとIEEEの将来の標準化ロードマップに関して将来を見据えています。これらのロードマップは正確に予測できないため、この付録は参考情報であり、いかなる種類の命令や規範的な仕様も指定していません。
The IEEE Std 1588-2008 YANG module of this standard represents a cooperation between the IETF (for YANG) and IEEE (for 1588). For the initial standardization of IEEE-1588 YANG modules, the information model is relatively clear (i.e., IEEE Std 1588 data sets), but expertise in YANG is required, making IETF an appropriate location for the standards. The TICTOC WG has expertise with IEEE Std 1588, making it the appropriate location within the IETF.
この規格のIEEE Std 1588-2008 YANGモジュールは、IETF（YANGの場合）とIEEE（1588の場合）の間の連携を表しています。 IEEE-1588 YANGモジュールの初期標準化では、情報モデルは比較的明確です（つまり、IEEE Std 1588データセット）が、YANGの専門知識が必要であり、IETFを標準の適切な場所にしています。 TICTOC WGはIEEE Std 1588に関する専門知識を備えており、IETF内の適切な場所となっています。
The IEEE 1588 WG anticipates future changes to its standard on an ongoing basis. As IEEE 1588 WG members gain practical expertise with YANG, the IEEE 1588 WG will become more appropriate for standardization of its YANG modules. As the IEEE 1588 standard is revised and/or amended, IEEE 1588 members can more effectively synchronize the revision of this YANG module with future versions of the IEEE 1588 standard.
IEEE 1588 WGは、継続的にその標準の将来の変更を予測しています。 IEEE 1588 WGのメンバーがYANGに関する実践的な専門知識を得るにつれて、IEEE 1588 WGはそのYANGモジュールの標準化により適切になるでしょう。 IEEE 1588標準が改訂または修正された場合、IEEE 1588メンバーは、このYANGモジュールの改訂をIEEE 1588標準の将来のバージョンとより効果的に同期させることができます。
This appendix is meant to establish some clear expectations between IETF and IEEE about the future transfer of IEEE 1588 YANG modules to the IEEE 1588 WG. The goal is to assist in making the future transfer as smooth as possible. As the transfer takes place, some case-by-case situations are likely to arise, which can be handled by discussion on the IETF TICTOC WG mailing lists and/or appropriate liaisons.
この付録は、IEEE 1588 YANGモジュールのIEEE 1588 WGへの将来の転送について、IETFとIEEEの間の明確な期待を確立することを目的としています。目標は、将来の転送を可能な限りスムーズにすることを支援することです。転送が行われると、ケースバイケースの状況が発生する可能性が高く、これはIETF TICTOC WGメーリングリストおよび/または適切なリエゾンでの議論によって処理できます。
This appendix obtained insight from [RFC4663], an informational memo that described a similar transfer of MIB work from the IETF Bridge MIB WG to the IEEE 802.1 WG.
この付録は、IETF Bridge MIB WGからIEEE 802.1 WGへのMIB作業の同様の転送を説明する情報メモである[RFC4663]から洞察を得ました。
For the purposes of discussion in this appendix, assume that the IESG has approved the publication of an RFC containing a YANG module for a published IEEE 1588 standard. As of this writing, this is IEEE Std 1588-2008, but it is possible that YANG modules for subsequent 1588 revisions could be published from the IETF TICTOC WG. For discussion in this appendix, we use the phrase "last IETF 1588 YANG" to refer to the most recently published 1588 YANG module from the IETF TICTOC WG.
この付録での説明の目的で、IESGが公開されたIEEE 1588標準のYANGモジュールを含むRFCの公開を承認したと想定します。これを書いている時点では、これはIEEE Std 1588-2008ですが、その後の1588リビジョンのYANGモジュールがIETF TICTOC WGから公開される可能性があります。この付録での説明では、「最後のIETF 1588 YANG」というフレーズを使用して、IETF TICTOC WGから最近公開された1588 YANGモジュールを指します。
The IEEE-SA Standards Board New Standards Committee (NesCom) handles new Project Authorization Requests (PARs) (see <http://standards.ieee.org/board/nes/>). PARs are roughly the equivalent of IETF Working Group Charters and include information concerning the scope, purpose, and justification for standardization projects.
IEEE-SA規格委員会の新しい規格委員会（NesCom）は、新しいプロジェクト許可要求（PAR）を処理します（<http://standards.ieee.org/board/nes/>を参照）。 PARは、おおよそIETFワーキンググループチャーターに相当し、標準化プロジェクトの範囲、目的、および正当化に関する情報が含まれています。
Assume that IEEE 1588 has an approved PAR that explicitly specifies development of a YANG module. The transfer of YANG work will occur in the context of this IEEE 1588 PAR. For discussion in this appendix, we use the phrase "first IEEE 1588 YANG" to refer to the first IEEE 1588 standard for YANG.
IEEE 1588に、YANGモジュールの開発を明示的に指定する承認されたPARがあるとします。 YANG作業の転送は、このIEEE 1588 PARのコンテキストで行われます。この付録の説明では、「最初のIEEE 1588 YANG」というフレーズを使用して、YANGの最初のIEEE 1588標準を参照します。
Assume that as part of the transfer of YANG work, the IETF TICTOC WG agrees to cease all work on standard YANG modules for IEEE 1588.
YANG作業の転送の一部として、IETF TICTOC WGがIEEE 1588の標準YANGモジュールでのすべての作業を中止することに同意すると仮定します。
Assume that the IEEE 1588 WG has participated in the development of the last IETF 1588 YANG module, such that the first IEEE 1588 YANG module will effectively be a revision of it. In other words, the transfer of YANG work will be relatively clean.
IEEE 1588 WGが最後のIETF 1588 YANGモジュールの開発に参加し、最初のIEEE 1588 YANGモジュールが実質的にその改訂版になると仮定します。つまり、YANG作業の転送は比較的クリーンになります。
The actual conditions for the future transfer can be such that the preceding assumptions do not hold. Exceptions to the assumptions will need to be addressed on a case-by-case basis at the time of the transfer. This appendix describes topics that can be addressed based on the preceding assumptions.
将来の転送の実際の条件は、前述の仮定が成り立たない場合があります。前提条件の例外は、転送時にケースバイケースで対処する必要があります。この付録では、前述の前提に基づいて対処できるトピックについて説明します。
During review of the legal issues associated with transferring Bridge MIB WG documents to the IEEE 802.1 WG (Sections 3.1 and 9 of [RFC4663]), it was concluded that the IETF does not have sufficient legal authority to make the transfer to the IEEE without the consent of the document authors.
Bridge MIB WG文書をIEEE 802.1 WGに転送することに関連する法的問題（[RFC4663]のセクション3.1および9）のレビュー中に、IETFには、IEEEなしでIEEEに転送するための十分な法的権限がないと結論付けられました。ドキュメント作成者の同意。
If the last IETF 1588 YANG is published as an RFC, the work is required to be transferred from the IETF to the IEEE, so that IEEE 1588 WG can begin working on the first IEEE 1588 YANG.
最後のIETF 1588 YANGがRFCとして公開されている場合、IETFからIEEEに作業を転送して、IEEE 1588 WGが最初のIEEE 1588 YANGで作業を開始できるようにする必要があります。
When work on the first IEEE YANG module begins in the IEEE 1588 WG, that work derives from the last IETF YANG module of this RFC, requiring a transfer of that work from the IETF to the IEEE. In order to avoid having the transfer of that work be dependent on the availability of this RFC's authors at the time of its publication, the IEEE Standards Association department of Risk Management and Licensing provided the appropriate forms and mechanisms for this document's authors to assign a non-exclusive license for IEEE to create derivative works from this document. Those IEEE forms and mechanisms will be updated as needed for any future IETF YANG modules for IEEE 1588 (the signed forms are held by the IEEE Standards Association department of Risk Management and Licensing.). This will help to make the future transfer of work from the IETF to the IEEE occur as smoothly as possible.
最初のIEEE YANGモジュールでの作業がIEEE 1588 WGで始まる場合、その作業はこのRFCの最後のIETF YANGモジュールから派生しており、IETFからIEEEへのその作業の転送が必要です。その著作物の転送がこのRFCの作成者の公開時の利用可能性に依存することを回避するために、IEEE Standards AssociationのRisk Management and Licensing部門は、このドキュメントの作成者が非-このドキュメントから派生物を作成するためのIEEEの独占ライセンス。これらのIEEEフォームとメカニズムは、IEEE 1588の今後のIETF YANGモジュールで必要に応じて更新されます（署名付きフォームは、IEEE Standards AssociationのRisk Management and Licensing部門が保持しています）。これにより、IETFからIEEEへの将来の作業の転送が可能な限りスムーズに行われるようになります。
As stated in the initial "Status of this Memo", the YANG module in this document conforms to the provisions of BCP 78. The IETF will retain all the rights granted at the time of publication in the published RFCs.
最初の「このメモのステータス」で述べたように、このドキュメントのYANGモジュールはBCP 78の規定に準拠しています。IETFは、公開されたRFCでの公開時に付与されたすべての権利を保持します。
As specified in Section 5 "IANA Considerations", the YANG module in this document uses IETF as the root of its URN namespace and YANG module name.
セクション5「IANAに関する考慮事項」で指定されているように、このドキュメントのYANGモジュールは、URN名前空間のルートおよびYANGモジュール名としてIETFを使用しています。
Use of IETF as the root of these names implies that the YANG module is standardized in a Working Group of IETF, using the IETF processes. If the IEEE 1588 Working Group were to continue using these names rooted in IETF, the IEEE 1588 YANG standardization would need to continue in the IETF. The goal of transferring the YANG work is to avoid this sort of dependency between standards organizations.
IETFをこれらの名前のルートとして使用することは、YANGモジュールがIETFプロセスを使用してIETFのワーキンググループで標準化されていることを意味します。 IEEE 1588ワーキンググループがIETFに根ざしたこれらの名前を引き続き使用する場合、IEEE 1588 YANG標準化はIETFでも継続する必要があります。 YANGの作業を転送する目的は、標準化組織間のこの種の依存関係を回避することです。
IEEE 802 has an active PAR (IEEE P802d) for creating a URN namespace for IEEE use (see <http://standards.ieee.org/develop/ project/802d.html>). It is likely that this IEEE 802 PAR will be approved and published prior to the transfer of YANG work to the IEEE 1588 WG. If so, the IEEE 1588 WG can use the IEEE URN namespace for the first IEEE 1588 YANG module, such as:
IEEE 802には、IEEE用のURN名前空間を作成するためのアクティブなPAR（IEEE P802d）があります（<http://standards.ieee.org/develop/project/802d.html>を参照）。このIEEE 802 PARは、YANGの作業をIEEE 1588 WGに転送する前に承認および公開される可能性があります。その場合、IEEE 1588 WGは、次のような最初のIEEE 1588 YANGモジュールにIEEE URN名前空間を使用できます。
urn:ieee:Std:1588:yang:ieee1588-ptp
where "ieee1588-ptp" is the registered YANG module name in the IEEE.
「ieee1588-ptp」は、IEEEで登録されているYANGモジュール名です。
Under the assumptions of Appendix A.1, the first IEEE 1588 YANG module's prefix will be the same as the last IETF 1588 YANG module's prefix (i.e., "ptp"). Consequently, other YANG modules can preserve the same import prefix "ptp" to access PTP nodes during the migration from the last IETF 1588 YANG module to the first IEEE 1588 YANG module.
付録A.1の想定では、最初のIEEE 1588 YANGモジュールのプレフィックスは、最後のIETF 1588 YANGモジュールのプレフィックスと同じになります（つまり、「ptp」）。その結果、他のYANGモジュールは、最後のIETF 1588 YANGモジュールから最初のIEEE 1588 YANGモジュールへの移行中に、同じインポートプレフィックス「ptp」を保持してPTPノードにアクセスできます。
The result of these name changes are that for complete compatibility, a server (i.e., IEEE 1588 node) can choose to implement a YANG module for the last IETF 1588 YANG module (with IETF root) as well as the first IEEE 1588 YANG module (with IEEE root). Since the content of the YANG module transferred are the same, the server implementation is effectively common for both.
これらの名前変更の結果、完全な互換性のために、サーバー（IEEE 1588ノード）は、最後のIETF 1588 YANGモジュール（IETFルートを含む）および最初のIEEE 1588 YANGモジュール（ IEEEルート）。転送されるYANGモジュールの内容は同じであるため、サーバーの実装は両方で事実上共通です。
From a client's perspective, a client of the last IETF 1588 YANG module (or earlier) looks for the IETF-rooted module name; and a client of the first IEEE 1588 YANG module (or later) looks for the IEEE-rooted module name.
クライアントの観点から、最後のIETF 1588 YANGモジュール（またはそれ以前）のクライアントは、IETFをルートとするモジュール名を探します。また、最初のIEEE 1588 YANGモジュール（またはそれ以降）のクライアントは、IEEEをルートとするモジュール名を探します。
Although IEEE 1588 can certainly decide to publish YANG modules only in the PDF format that they use for their standard documents, without publishing an ASCII version, most network management systems cannot import the YANG module directly from the PDF. Thus, not publishing an ASCII version of the YANG module would negatively impact implementers and deployers of YANG modules and would make potential IETF reviews of YANG modules more difficult.
IEEE 1588は、ASCIIバージョンを公開せずに、標準ドキュメントに使用するPDF形式でのみYANGモジュールを公開することを決定できますが、ほとんどのネットワーク管理システムはPDFから直接YANGモジュールをインポートできません。したがって、YANGモジュールのASCIIバージョンを公開しないと、YANGモジュールの実装者と配備者に悪影響を及ぼし、YANGモジュールの潜在的なIETFレビューをより困難にします。
This appendix recommends that the IEEE 1588 WG consider future plans for:
この付録では、IEEE 1588 WGが以下の将来の計画を検討することを推奨しています。
- Public availability of the ASCII YANG modules during project development. These ASCII files allow IETF participants to access these documents for pre-standard review purposes.
- プロジェクト開発中のASCII YANGモジュールの公開。これらのASCIIファイルにより、IETFの参加者は、事前標準のレビュー目的でこれらのドキュメントにアクセスできます。
- Public availability of the YANG portion of published IEEE 1588 standards, provided as an ASCII file for each YANG module. These ASCII files are intended for use of the published IEEE 1588 standard.
- 公開されたIEEE 1588標準のYANG部分の公開。各YANGモジュールのASCIIファイルとして提供されます。これらのASCIIファイルは、公開されたIEEE 1588標準の使用を目的としています。
As an example of public availability during project development, IEEE 802 uses the same repository that IETF uses for YANG module development (see <https://github.com/YangModels/yang>). IEEE branches are provided for experimental work (i.e., pre-PAR) as well as standard work (post-PAR drafts). IEEE-SA has approved use of this repository for project development, but not for published standards.
プロジェクト開発中の公開の例として、IEEE 802はIETFがYANGモジュール開発に使用するのと同じリポジトリを使用します（<https://github.com/YangModels/yang>を参照）。 IEEEブランチは、標準的な作業（PAR後のドラフト）だけでなく実験的な作業（つまり、PAR以前）のために提供されています。 IEEE-SAは、このリポジトリをプロジェクト開発に使用することを承認していますが、公開されている標準には使用できません。
As an example of public availability of YANG modules for published standards, IEEE 802.1 provides a public list of ASCII files for MIB (see <http://www.ieee802.org/1/files/public/MIBs/> and <http://www.ieee802.org/1/pages/MIBS.html>), and analogous lists are planned for IEEE 802.1 YANG files.
公開された規格に対するYANGモジュールの公開の例として、IEEE 802.1はMIBのASCIIファイルの公開リストを提供しています（<http://www.ieee802.org/1/files/public/MIBs/>および<http： //www.ieee802.org/1/pages/MIBS.html>）、および類似のリストがIEEE 802.1 YANGファイル用に計画されています。
Acknowledgments
謝辞
The authors would like to thank Tom Petch, Radek Krejci, Mahesh Jethanandani, Tal Mizrahi, Opher Ronen, Liang Geng, Alex Campbell, Joe Gwinn, John Fletcher, William Zhao, and Dave Thaler for their valuable reviews and suggestions. They would like to thank Benoit Claise and Radek Krejci for their validation of the YANG module, and thank Jingfei Lv and Zitao Wang for their discussions on IEEE 1588 and YANG, respectively.
著者は、貴重なレビューと提案をしてくれたトム・ペッチ、ラデク・クレイチ、マヘシュ・ジェタナンダニ、タル・ミズラヒ、オーファー・ローネン、リャン・ゲン、アレックス・キャンベル、ジョー・グウィン、ジョン・フレッチャー、ウィリアム・チャオ、デイブ・ターラーに感謝します。彼らは、YANGモジュールの検証についてBenoit ClaiseとRadek Krejciに感謝し、IEEE 1588とYANGについての議論についてそれぞれJingfei LvとZitao Wangに感謝します。
Authors' Addresses
著者のアドレス
Yuanlong Jiang (editor) Huawei Bantian, Longgang district Shenzhen 518129 China
人民元Long Jiang（編集者）hu AはBであり、長いGang地区は非常に現実的です518129中国
Email: jiangyuanlong@huawei.com
Xian Liu Independent Shenzhen 518129 China
LはL IUの独立者518129中国に当てはまる
Email: lene.liuxian@foxmail.com
Jinchun Xu Huawei Bantian, Longgang district Shenzhen 518129 China
金春XええとUAは日によってB、長いギャング地区は非常に現実的です518129中国
Email: xujinchun@huawei.com
Rodney Cummings (editor) National Instruments 11500 N. Mopac Expwy Bldg. C Austin, TX 78759-3504 United States of America
Rodney Cummings（編集者）National Instruments 11500 N. Mopac Expwy Bldg。 Cオースティン、テキサス州78759-3504アメリカ合衆国
Email: Rodney.Cummings@ni.com