[要約] RFC 9254はYANGデータをCBORでエンコードするための規則を定義しており、YANGモデルを効率的に表現することを目的としています。

Internet Engineering Task Force (IETF)                 M. Veillette, Ed.
Request for Comments: 9254                       Trilliant Networks Inc.
Category: Standards Track                                 I. Petrov, Ed.
ISSN: 2070-1721                                  Google Switzerland GmbH
                                                                A. Pelov
                                                                  Acklio
                                                              C. Bormann
                                                  Universität Bremen TZI
                                                           M. Richardson
                                                Sandelman Software Works
                                                               July 2022
        

Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR)

簡潔なバイナリオブジェクト表現(CBOR)でYangでモデル化されたデータのエンコード

Abstract

概要

YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, and notifications.

Yang(RFC 7950)は、構成データ、状態データ、パラメーター、およびリモートプロシージャコール(RPC)操作またはアクションの結果をモデル化するために使用されるデータモデリング言語です。

This document defines encoding rules for YANG in the Concise Binary Object Representation (CBOR) (RFC 8949).

このドキュメントでは、簡潔なバイナリオブジェクト表現(CBOR)(RFC 8949)のYangのエンコーディングルールを定義しています。

Status of This Memo

本文書の位置付け

This is an Internet Standards Track document.

これは、インターネット標準トラックドキュメントです。

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)の製品です。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/rfc9254.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9254で取得できます。

Copyright Notice

著作権表示

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(c)2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

このドキュメントは、BCP 78およびIETFドキュメント(https://trustee.ietf.org/license-info)に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。

Table of Contents

目次

   1.  Introduction
   2.  Terminology and Notation
   3.  Properties of the CBOR Encoding
     3.1.  CBOR Diagnostic Notation
     3.2.  YANG Schema Item iDentifier
     3.3.  Name
   4.  Encoding of Representation Nodes
     4.1.  The 'leaf'
       4.1.1.  Using SIDs in Keys
       4.1.2.  Using Names in Keys
     4.2.  The 'container' and Other Nodes from the Data Tree
       4.2.1.  Using SIDs in Keys
       4.2.2.  Using Names in Keys
     4.3.  The 'leaf-list'
       4.3.1.  Using SIDs in Keys
       4.3.2.  Using Names in Keys
     4.4.  The 'list' and the 'list' Entries
       4.4.1.  Using SIDs in Keys
       4.4.2.  Using Names in Keys
     4.5.  The 'anydata'
       4.5.1.  Using SIDs in Keys
       4.5.2.  Using Names in Keys
     4.6.  The 'anyxml'
       4.6.1.  Using SIDs in Keys
       4.6.2.  Using Names in Keys
   5.  Encoding of the 'yang-data' Extension
     5.1.  Using SIDs in Keys
     5.2.  Using Names in Keys
   6.  Representing YANG Data Types in CBOR
     6.1.  The Unsigned Integer Types
     6.2.  The Integer Types
     6.3.  The 'decimal64' Type
     6.4.  The 'string' Type
     6.5.  The 'boolean' Type
     6.6.  The 'enumeration' Type
     6.7.  The 'bits' Type
     6.8.  The 'binary' Type
     6.9.  The 'leafref' Type
     6.10. The 'identityref' Type
       6.10.1.  SIDs as 'identityref'
       6.10.2.  Name as 'identityref'
     6.11. The 'empty' Type
     6.12. The 'union' Type
     6.13. The 'instance-identifier' Type
       6.13.1.  SIDs as 'instance-identifier'
       6.13.2.  Names as 'instance-identifier'
   7.  Content-Types
   8.  Security Considerations
   9.  IANA Considerations
     9.1.  Media Types Registry
     9.2.  CoAP Content-Formats Registry
     9.3.  CBOR Tags Registry
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Acknowledgments
   Authors' Addresses
        
1. Introduction
1. はじめに

The specification of the YANG 1.1 data modeling language [RFC7950] defines an XML encoding for data instances, i.e., contents of configuration datastores, state data, RPC inputs and outputs, action inputs and outputs, and event notifications.

Yang 1.1データモデリング言語[RFC7950]の仕様は、データインスタンスのXMLエンコード、つまり構成データストア、状態データ、RPC入力と出力、アクション入力と出力、イベント通知の内容を定義します。

An additional set of encoding rules has been defined in [RFC7951] based on "The JavaScript Object Notation (JSON) Data Interchange Format" [RFC8259].

「JavaScriptオブジェクト表記(JSON)インターチェンジ形式」[RFC8259]に基づいて、[RFC7951]でエンコードルールの追加セットが定義されています。

The aim of this document is to define a set of encoding rules for the Concise Binary Object Representation (CBOR) [RFC8949], collectively called "YANG-CBOR". The resulting encoding is more compact compared to XML and JSON and more suitable for constrained nodes and/or constrained networks, as defined by [RFC7228].

このドキュメントの目的は、「Yang-Cbor」と集合的に呼ばれる簡潔なバイナリオブジェクト表現(CBOR)[RFC8949]のエンコードルールのセットを定義することです。結果のエンコードは、XMLおよびJSONと比較してよりコンパクトであり、[RFC7228]で定義されているように、制約されたノードおよび/または制約されたネットワークに適しています。

2. Terminology and Notation
2. 用語と表記

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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

SID values (and the SID deltas computed from them) shown in the examples are example values; these examples do not allocate the SIDs shown for specific items in the modules.

例に示されているSID値(およびそれらから計算されたSIDデルタ)は例の値です。これらの例は、モジュール内の特定のアイテムに表示されているSIDを割り当てません。

The following terms are defined in [RFC7950]:

次の用語は[RFC7950]で定義されています。

* action

* アクション

* anydata

* anydata

* anyxml

* anyxml

* data node

* データノード

* data tree

* データツリー

* datastore

* データストア

* feature

* 特徴

* identity

* 身元

* module

* モジュール

* notification

* 通知

* RPC

* RPC

* schema node

* スキーマノード

* submodule

* サブモジュール

The following term is defined in [RFC8040]:

次の用語は[RFC8040]で定義されています。

* yang-data extension

* ヤンダタ拡張機能

The following term is defined in [RFC8791]:

次の用語は[RFC8791]で定義されています。

* YANG data structure

* ヤンデータ構造

This specification also makes use of the following terminology:

この仕様では、次の用語も使用します。

YANG Schema Item iDentifier (or "YANG SID" or simply "SID"): 63-bit unsigned integer used to identify different YANG items.

Yang Schemaアイテム識別子(または「Yang Sid」または単に「SID」):63ビットの署名されていない整数は、異なるYangアイテムを識別するために使用されます。

delta: Difference between the current YANG SID and a reference YANG SID. A reference YANG SID is defined for each context for which deltas are used.

デルタ:現在のヤンシドとリファレンスヤンシドの違い。デルタが使用される各コンテキストに対して、参照ヤンシドが定義されます。

absolute SID: A YANG SID that is not encoded as a delta. This is usually called out explicitly only in positions where normally a delta would be found.

Absolute Sid:デルタとしてエンコードされていないヤンシド。これは通常、通常デルタが見つかる位置でのみ明示的に呼ばれます。

representation tree: A YANG data tree, possibly enclosed by a representation of a schema node, such as a YANG data structure, a notification, an RPC, or an action.

表現ツリー:ヤンデータ構造、通知、RPC、アクションなど、スキーマノードの表現によって囲まれたヤンデータツリー。

representation node: A node in a representation tree, i.e., a data tree node, or a representation of a schema node, such as a YANG data structure, a notification, an RPC, or an action.

表現ノード:表現ツリーのノード、つまりデータツリーノード、またはヤンデータ構造、通知、RPC、アクションなどのスキーマノードの表現。

item: A schema node, an identity, a module, or a feature defined using the YANG modeling language.

アイテム:スキーマノード、ID、モジュール、またはYangモデリング言語を使用して定義された機能。

list entry: The data associated with a single entry of a list (see Section 7.8 of [RFC7950]).

リストエントリ:リストの単一のエントリに関連付けられたデータ([RFC7950]のセクション7.8を参照)。

container-like instance: An instance of a container, a YANG data structure, notification contents, RPC input, RPC output, action input, or action output (Section 4.2); a list entry in a list (Section 4.4); or an anydata node (Section 4.5).

コンテナのようなインスタンス:コンテナのインスタンス、ヤンデータ構造、通知コンテンツ、RPC入力、RPC出力、アクション入力、またはアクション出力(セクション4.2)。リストのリストエントリ(セクション4.4);またはanyDataノード(セクション4.5)。

parent (of a representation node): The schema node of the closest enclosing representation node in which a given representation node is defined.

親(表現ノードの):特定の表現ノードが定義されている最も近い囲まれた表現ノードのスキーマノード。

3. Properties of the CBOR Encoding
3. CBORエンコーディングのプロパティ

This document defines CBOR encoding rules for YANG data trees and their subtrees.

このドキュメントでは、YangデータツリーとそのサブツリーのCBORエンコードルールを定義しています。

A YANG data tree can be enclosed by a representation of a schema node, such as a YANG data structure, a notification, an RPC, or an action; this is called a representation tree. The data tree nodes and the enclosing schema node representation, if any, are collectively called the representation nodes.

Yangデータツリーは、Yangデータ構造、通知、RPC、アクションなどのスキーマノードの表現によって囲むことができます。これは表現ツリーと呼ばれます。データツリーノードと囲まれたスキーマノード表現は、あれば、表現ノードと集合的に呼ばれます。

A representation node, such as a container, list entry, YANG data structure, notification, RPC input, RPC output, action input, action output, or anydata node, is serialized using a CBOR map in which each schema node defined within is encoded using a key and a value. This specification supports two types of CBOR keys: YANG Schema Item iDentifier (YANG SID), as defined in Section 3.2, and names, as defined in Section 3.3. Each of these key types is encoded using a specific CBOR type that allows their interpretation during the deserialization process. Protocols or mechanisms implementing this specification can mandate the use of a specific key type or allow the generator to choose freely per key.

コンテナ、リストエントリ、Yangデータ構造、通知、RPC入力、RPC出力、アクション入力、アクション出力、またはanyDataノードなどの表現ノードは、内部で定義された各スキーマノードが使用されているCBORマップを使用してシリアル化されます。キーと値。この仕様は、セクション3.2で定義されているように、セクション3.3で定義されているように、2種類のCBORキー:Yangスキーマアイテム識別子(Yang SID)と名前をサポートしています。これらの各キータイプは、脱出プロセス中に解釈を可能にする特定のCBORタイプを使用してエンコードされます。この仕様を実装するプロトコルまたはメカニズムは、特定のキータイプの使用を義務付けるか、キーごとにジェネレーターが自由に選択できるようにすることができます。

In order to minimize the size of the encoded data, the mapping avoids any unnecessary meta-information beyond that directly provided by the CBOR basic generic data model (Section 2 of [RFC8949]). For instance, CBOR tags are used solely in the case of an absolute SID, anyxml data nodes, or the union datatype to explicitly distinguish the use of different YANG datatypes encoded using the same CBOR major type.

エンコードされたデータのサイズを最小限に抑えるために、マッピングは、CBOR基本汎用データモデル([RFC8949]のセクション2)によって直接提供されるものを超えて不必要なメタ情報を回避します。たとえば、CBORタグは、絶対SID、anyXMLデータノード、またはユニオンデータタイプの場合にのみ使用され、同じCBORメジャータイプを使用してエンコードされた異なるYangデータタイプの使用を明示的に区別します。

Unless specified otherwise by the protocol or mechanism implementing this specification, the indefinite length encoding, as defined in Section 3.2 of [RFC8949], SHALL be supported by the CBOR decoders employed with YANG-CBOR. (This enables an implementation to begin emitting an array or map before the number of entries in that structure is known, possibly also avoiding excessive locking or race conditions. On the other hand, it deprives the receiver of the encoded data from advance announcement about some size information, so a generator should choose indefinite length encoding only when these benefits do accrue.)

この仕様を実装するプロトコルまたはメカニズムによって特に指定されていない限り、[RFC8949]のセクション3.2で定義されている不定の長さエンコードは、Yang-Cborで使用されるCBORデコーダーによってサポートされます。(これにより、その構造内のエントリの数がわかっている前に、アレイまたはマップの放出を開始し、過度のロックまたは人種条件を回避する可能性があります。一方、エンコードされたデータの受信者が事前発表から受信者から奪われます。サイズ情報なので、ジェネレーターは、これらの利点が発生した場合にのみ、無期限の長さエンコードを選択する必要があります。

Data nodes implemented using a CBOR array, map, byte string, or text string can be instantiated but empty. In this case, they are encoded with a length of zero.

CBORアレイ、マップ、バイト文字列、またはテキスト文字列を使用して実装されたデータノードは、インスタンス化されますが空です。この場合、それらはゼロの長さでエンコードされます。

When representation nodes are serialized using the rules defined by this specification as part of an application payload, the payload SHOULD include information that would allow each node to be identified in a stateless way, for instance, the SID number associated with the node, the SID delta from another SID in the application payload, the namespace-qualified name, or the instance-identifier.

表現ノードがアプリケーションペイロードの一部としてこの仕様で定義されたルールを使用してシリアル化されている場合、ペイロードには、各ノードをステートレスの方法で識別できるようにする情報を含める必要があります。たとえば、ノードに関連付けられたSID番号、SIDアプリケーションペイロード、名前空間認定名、またはインスタンスIDENTIFIERの別のSIDのデルタ。

Examples in Section 4 include a root CBOR map with a single entry having a key set to either a namespace-qualified name or a SID. This root CBOR map is provided only as a typical usage example and is not part of the present encoding rules. Only the value within this CBOR map is compulsory.

セクション4の例には、名前空間認定名またはSIDのいずれかにキーセットを備えた単一のエントリを持つルートCBORマップが含まれます。このルートCBORマップは、典型的な使用例としてのみ提供され、現在のエンコードルールの一部ではありません。このCborマップ内の値のみが義務付けられています。

3.1. CBOR Diagnostic Notation
3.1. CBOR診断表記

Within this document, CBOR binary contents are represented using an equivalent textual form called CBOR diagnostic notation, as defined in Section 8 of [RFC8949]. This notation is used strictly for documentation purposes and is never used in the data serialization. Table 1 below provides a summary of this notation.

このドキュメント内では、CBORバイナリの内容は、[RFC8949]のセクション8で定義されているように、CBOR診断表記と呼ばれる同等のテキストフォームを使用して表されます。この表記法は、ドキュメントの目的で厳密に使用され、データシリアル化では使用されません。以下の表1に、この表記の概要を示します。

      +==========+======+====================+===========+==========+
      | CBOR     | CBOR | Diagnostic         | Example   | CBOR     |
      | Content  | Type | Notation           |           | Encoding |
      +==========+======+====================+===========+==========+
      | Unsigned | 0    | Decimal digits     | 123       | 18 7B    |
      | integer  |      |                    |           |          |
      +----------+------+--------------------+-----------+----------+
      | Negative | 1    | Decimal digits     | -123      | 38 7A    |
      | integer  |      | prefixed by a      |           |          |
      |          |      | minus sign         |           |          |
      +----------+------+--------------------+-----------+----------+
      | Byte     | 2    | Hexadecimal value  | h'F15C'   | 42 F15C  |
      | string   |      | enclosed between   |           |          |
      |          |      | single quotes and  |           |          |
      |          |      | prefixed by an 'h' |           |          |
      +----------+------+--------------------+-----------+----------+
      | Text     | 3    | String of Unicode  | "txt"     | 63       |
      | string   |      | characters         |           | 747874   |
      |          |      | enclosed between   |           |          |
      |          |      | double quotes      |           |          |
      +----------+------+--------------------+-----------+----------+
      | Array    | 4    | Comma-separated    | [ 1, 2 ]  | 82 01 02 |
      |          |      | list of values     |           |          |
      |          |      | within square      |           |          |
      |          |      | brackets           |           |          |
      +----------+------+--------------------+-----------+----------+
      | Map      | 5    | Comma-separated    | { 1: 123, | A2       |
      |          |      | list of key :      | 2: 456 }  | 01187B   |
      |          |      | value pairs within |           | 021901C8 |
      |          |      | curly braces       |           |          |
      +----------+------+--------------------+-----------+----------+
      | Boolean  | 7/20 | false              | false     | F4       |
      +----------+------+--------------------+-----------+----------+
      |          | 7/21 | true               | true      | F5       |
      +----------+------+--------------------+-----------+----------+
      | Null     | 7/22 | null               | null      | F6       |
      +----------+------+--------------------+-----------+----------+
      | Not      | 7/23 | undefined          | undefined | F7       |
      | assigned |      |                    |           |          |
      +----------+------+--------------------+-----------+----------+
        

Table 1: CBOR Diagnostic Notation Summary

表1:CBOR診断表記の概要

Note: CBOR binary contents shown in this specification are annotated with comments. These comments are delimited by slashes ("/"), as defined in Appendix G.6 of [RFC8610].

注:この仕様に示されているCBORバイナリの内容には、コメントが注釈が付けられています。これらのコメントは、[RFC8610]の付録G.6で定義されているように、スラッシュ( "/")によって区切られています。

3.2. YANG Schema Item iDentifier
3.2. ヤンスキーマアイテム識別子

Some of the items defined in YANG [RFC7950] require the use of a unique identifier. In both the Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF [RFC8040], these identifiers are implemented using text strings. To allow the implementation of data models defined in YANG in constrained devices and constrained networks, a more compact method to identify YANG items is required. This compact identifier, called "YANG Schema Item iDentifier", is an unsigned integer limited to 63 bits of range (i.e., 0..9223372036854775807 or 0..0x7fffffffffffffff). The following items are identified using YANG SIDs (often shortened to SIDs):

Yang [RFC7950]で定義されているアイテムの一部は、一意の識別子を使用する必要があります。ネットワーク構成プロトコル(NetConf)[RFC6241]とRestConf [RFC8040]の両方で、これらの識別子はテキスト文字列を使用して実装されています。Yangで定義されたデータモデルの実装を制約されたデバイスと制約されたネットワークで実装できるようにするには、Yangアイテムを識別するためのよりコンパクトな方法が必要です。「Yang Schema Item Identifier」と呼ばれるこのコンパクトな識別子は、63ビットの範囲に制限されていない署名されていない整数です(つまり、0..922372036854775807または0..0x7ffffffffffffffffff)。次の項目は、Yang Sidsを使用して識別されます(多くの場合、SIDSに短縮されます):

* identities

* アイデンティティ

* data nodes

* データノード

* RPCs and associated input(s) and output(s)

* RPCおよび関連する入力と出力

* actions and associated input(s) and output(s)

* アクションと関連する入力と出力

* YANG data structures

* ヤンデータ構造

* notifications and associated information

* 通知と関連情報

* YANG modules and features

* Yangモジュールと機能

      |  Note that any structuring of modules into submodules is
      |  transparent to YANG-CBOR: SIDs are not allocated for the names
      |  of submodules, and any items within a submodule are effectively
      |  allocated SIDs as part of processing the module that includes
      |  them.
        

To minimize their size, SIDs used as keys in CBOR maps are encoded using deltas, i.e., signed (negative or unsigned) integers that are added to the reference SID applying to the map. The reference SID of an outermost map is zero, unless a different reference SID is unambiguously conferred from the environment in which the outermost map is used. The reference SID of a map that is most directly embedded in a map entry with a name-based key is zero. For all other maps, the reference SID is the SID computed for the map entry it is most directly embedded in. (The embedding may be indirect if an array intervenes, e.g., in a YANG list.) Where absolute SIDs are desired in map key positions (where a bare integer implies a delta), they need to be identified as absolute SID values by using CBOR tag number 47 (as defined in Section 4.2.1).

サイズを最小限に抑えるために、CBORマップのキーとして使用されるSIDは、デルタ、つまりマップに適用される参照SIDに追加される署名(負または署名されていない)整数を使用してエンコードされます。別の参照SIDが最も外側のマップが使用されている環境から明確に付与されない限り、最も外側のマップの参照SIDはゼロです。名前ベースのキーを備えたマップエントリに最も直接埋め込まれているマップの参照SIDはゼロです。他のすべてのマップの場合、参照SIDは、最も直接埋め込まれているマップエントリ用に計算されたSIDです。(アレイがヤンリストに介入する場合、埋め込みは間接的である場合があります。位置(裸の整数がデルタを暗示する場合)は、CBORタグ番号47を使用して絶対SID値として識別する必要があります(セクション4.2.1で定義)。

Thus, conversion from SIDs to deltas and back to SIDs is a stateless process solely based on the data serialized or deserialized combined with, potentially, an outermost reference SID unambiguously conferred by the environment.

したがって、SIDSからDeltasへの変換、およびSIDSへのバックは、環境によって明確に付与された最も外側の参照SIDと組み合わせたシリアル化または脱必要なデータのみに基づいて、ステートレスプロセスです。

Mechanisms and processes used to assign SIDs to YANG items and to guarantee their uniqueness are outside the scope of the present specification. If SIDs are to be used, the present specification is used in conjunction with a specification defining this management. A related document, i.e., [CORE-SID], is intended to serve as the definitive way to assign SID values for YANG modules managed by the IETF and recommends itself for YANG modules managed by non-IETF entities, as well. The present specification has been designed to allow different methods of assignment to be used within separate domains.

SIDをYangアイテムに割り当て、それらの独自性を保証するために使用されるメカニズムとプロセスは、現在の仕様の範囲外です。SIDを使用する場合、現在の仕様は、この管理を定義する仕様と組み合わせて使用されます。関連するドキュメント、つまり[Core-SID]は、IETFが管理するYangモジュールにSID値を割り当てる決定的な方法として機能することを目的としており、非ITETFエンティティによって管理されたYangモジュールにも推奨されます。現在の仕様は、別のドメイン内でさまざまな割り当て方法を使用できるように設計されています。

To provide implementations with a way to internally indicate the absence of a SID, the SID value 0 is reserved and will not be allocated; it is not used in interchange.

SIDの不在を内部的に示す方法を実装するために、SID値0は予約されており、割り当てられません。インターチェンジには使用されません。

3.3. Name
3.3. 名前

This specification also supports the encoding of YANG item identifiers as text strings, similar to those used by the JSON encoding of data modeled with YANG [RFC7951]. This approach can be used to avoid the management overhead associated with SID allocation. The main drawback is the significant increase in size of the encoded data.

この仕様は、Yang [RFC7951]でモデル化されたデータのJSONエンコードで使用されるものと同様に、Yangアイテム識別子のテキスト文字列としてのエンコードをサポートしています。このアプローチは、SIDの割り当てに関連する管理オーバーヘッドを回避するために使用できます。主な欠点は、エンコードされたデータのサイズが大幅に増加することです。

YANG item identifiers implemented using names MUST be in one of the following forms:

名前を使用して実装されたYangアイテム識別子は、次のフォームのいずれかにある必要があります。

* simple -- the identifier of the YANG item (i.e., schema node or identity).

* シンプル - ヤンアイテムの識別子(つまり、スキーマノードまたはアイデンティティ)。

* namespace-qualified -- the identifier of the YANG item is prefixed with the name of the module in which this item is defined, separated by the colon character (":").

* 名前空間適格 - Yangアイテムの識別子には、このアイテムが定義されているモジュールの名前が付いており、コロン文字( ":")が分離されています。

The name of a module determines the namespace of all YANG items defined in that module. If an item is defined in a submodule, then the namespace-qualified name uses the name of the main module to which the submodule belongs.

モジュールの名前は、そのモジュールで定義されているすべてのヤンアイテムの名前空間を決定します。アイテムがサブモジュールで定義されている場合、名前空間認定名は、サブモジュールが属するメインモジュールの名前を使用します。

ABNF syntax [RFC5234] of a name is shown in Figure 1, where the production for "identifier" is defined in Section 14 of [RFC7950].

名前のABNF構文[RFC5234]を図1に示します。ここで、「識別子」の生産は[RFC7950]のセクション14で定義されています。

   name = [identifier ":"] identifier
        

Figure 1: ABNF Production for a Simple or Namespace-Qualified Name

図1:シンプルまたは名前空間資格のある名前のABNFプロダクション

A namespace-qualified name MUST be used for all members of a top-level CBOR map and then also whenever the namespaces of the representation node and its parent node are different. In all other cases, the simple form of the name MUST be used.

上位レベルのCBORマップのすべてのメンバーには、名前空間認定名を使用する必要があります。また、表現ノードとその親ノードの名前空間が異なる場合はいつでも。他のすべての場合、名前の単純な形式を使用する必要があります。

Definition example:

定義例:

   module example-foomod {
     container top {
       leaf foo {
         type uint8;
       }
     }
   }
        
   module example-barmod {
     import example-foomod {
       prefix "foomod";
     }
     augment "/foomod:top" {
       leaf bar {
         type boolean;
       }
     }
   }
        

A valid CBOR encoding of the 'top' container is as follows.

「上」コンテナの有効なCBORエンコードは次のとおりです。

CBOR diagnostic notation:

CBOR診断表記:

   {
     "example-foomod:top": {
       "foo": 54,
       "example-barmod:bar": true
     }
   }
        

Both the 'top' container and the 'bar' leaf defined in a different YANG module as its parent container are encoded as namespace-qualified names. The 'foo' leaf defined in the same YANG module as its parent container is encoded as a simple name.

親コンテナが名前空間資格のある名前としてエンコードされているため、別のYangモジュールで定義された「上」コンテナと「バー」葉の両方が異なるYangモジュールで定義されています。親コンテナと同じヤンモジュールで定義された「フー」葉は、単純な名前としてエンコードされています。

4. Encoding of Representation Nodes
4. 表現ノードのエンコード

Representation nodes defined using the YANG modeling language are encoded using CBOR [RFC8949], based on the rules defined in this section. We assume that the reader is already familiar with both YANG [RFC7950] and CBOR [RFC8949].

Yangモデリング言語を使用して定義された表現ノードは、このセクションで定義されているルールに基づいて、CBOR [RFC8949]を使用してエンコードされます。読者はすでにYang [RFC7950]とCbor [RFC8949]の両方に精通していると仮定しています。

4.1. The 'leaf'
4.1. 「葉」

A 'leaf' MUST be encoded accordingly to its datatype using one of the encoding rules specified in Section 6.

「リーフ」は、セクション6で指定されたエンコードルールのいずれかを使用して、そのデータ型にそれに応じてエンコードする必要があります。

The following examples show the encoding of a 'hostname' leaf using a SID or a name.

次の例は、SIDまたは名前を使用した「ホスト名」リーフのエンコードを示しています。

Definition example adapted from [RFC6991] and [RFC7317]:

[RFC6991]および[RFC7317]から適応した定義例:

   typedef domain-name {
     type string {
       pattern
         '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'
       + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'
       + '|\.';
       length "1..253";
     }
   }
        
   leaf hostname {
     type inet:domain-name;
   }
        
4.1.1. Using SIDs in Keys
4.1.1. キーでsidsを使用します

As with all examples below, the delta in the outermost map assumes a reference YANG SID (current schema node) of 0.

以下のすべての例と同様に、最も外側のマップのデルタは、0の参照Yang Sid(現在のスキーマノード)を想定しています。

CBOR diagnostic notation:

CBOR診断表記:

   {
     1752 : "myhost.example.com"     / hostname (SID 1752) /
   }
        

CBOR encoding:

CBORエンコーディング:

   A1                                         # map(1)
      19 06D8                                 # unsigned(1752)
      72                                      # text(18)
         6D79686F73742E6578616D706C652E636F6D # "myhost.example.com"
        
4.1.2. Using Names in Keys
4.1.2. キーで名前を使用します

CBOR diagnostic notation:

CBOR診断表記:

   {
     "ietf-system:hostname" : "myhost.example.com"
   }
        

CBOR encoding:

CBORエンコーディング:

   A1                                         # map(1)
      74                                      # text(20)
         696574662D73797374656D3A686F73746E616D65
      72                                      # text(18)
         6D79686F73742E6578616D706C652E636F6D
        
4.2. The 'container' and Other Nodes from the Data Tree
4.2. データツリーからの「コンテナ」およびその他のノード

Instances of containers, YANG data structures, notification contents, RPC inputs, RPC outputs, action inputs, and action outputs MUST be encoded using a CBOR map data item (major type 5). The same encoding is also used for the list entries in a list (Section 4.4) and for anydata nodes (Section 4.5). Collectively, we speak of these instances as "container-like instances".

コンテナ、Yangデータ構造、通知コンテンツ、RPC入力、RPC出力、アクション入力、およびアクション出力のインスタンスは、CBORマップデータ項目(メジャータイプ5)を使用してエンコードする必要があります。同じエンコードは、リスト(セクション4.4)のリストエントリと任意のDataノード(セクション4.5)にも使用されます。総称して、これらのインスタンスを「コンテナのようなインスタンス」として語っています。

A map consists of pairs of data items, with each pair consisting of a key and a value. Each key within the CBOR map is set to a schema node identifier, and each value is set to the value of this representation node according to the instance datatype.

マップはデータ項目のペアで構成され、各ペアはキーと値で構成されています。CBORマップ内の各キーはスキーマノード識別子に設定され、各値はインスタンスデータタイプに従ってこの表現ノードの値に設定されます。

This specification supports two types of CBOR map keys: SID, as defined in Section 3.2, and names, as defined in Section 3.3.

この仕様は、セクション3.2で定義されているSIDと、セクション3.3で定義されている2種類のCBORマップキーの2種類のCBORマップキーをサポートしています。

The following examples show the encoding of a 'system-state' container representation instance using SIDs or names.

次の例は、SIDまたは名前を使用した「システム状態」コンテナ表現インスタンスのエンコードを示しています。

Definition example adapted from [RFC6991] and [RFC7317]:

[RFC6991]および[RFC7317]から適応した定義例:

   typedef date-and-time {
     type string {
       pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?'
             + '(Z|[\+\-]\d{2}:\d{2})';
     }
   }
        

container system-state {

コンテナシステムステート{

     container clock {
       leaf current-datetime {
         type date-and-time;
       }
        
       leaf boot-datetime {
         type date-and-time;
       }
     }
   }
        
4.2.1. Using SIDs in Keys
4.2.1. キーでsidsを使用します

In the context of containers and other nodes from the data tree, CBOR map keys within inner CBOR maps can be encoded using deltas (bare integers) or absolute SIDs (tagged with tag number 47).

データツリーからのコンテナやその他のノードのコンテキストでは、内側のCBORマップ内のCBORマップキーは、デルタ(裸の整数)または絶対的なSID(タグ番号47でタグ付け)を使用してエンコードできます。

Delta values are computed as follows:

デルタ値は次のように計算されます。

* In the case of a 'container', deltas are equal to the SID of the current representation node minus the SID of the parent 'container'.

* 「コンテナ」の場合、デルタは現在の表現ノードのsidと等しく、親「コンテナ」のsidを差し引いています。

* In the case of a 'list', deltas are equal to the SID of the current representation node minus the SID of the parent 'list'.

* 「リスト」の場合、デルタは現在の表現ノードのSIDから親「リスト」のSIDから等しくなります。

* In the case of an 'RPC input' or 'RPC output', deltas are equal to the SID of the current representation node minus the SID of the 'RPC'.

* 「RPC入力」または「RPC出力」の場合、デルタは現在の表現ノードのSIDから「RPC」のSIDから等しくなります。

* In the case of an 'action input' or 'action output', deltas are equal to the SID of the current representation node minus the SID of the 'action'.

* 「アクション入力」または「アクション出力」の場合、デルタは現在の表現ノードのSIDから「アクション」のSIDから等しくなります。

* In the case of a 'notification content', deltas are equal to the SID of the current representation node minus the SID of the 'notification'.

* 「通知コンテンツ」の場合、デルタは現在の表現ノードのSIDと等しく、「通知」のSIDを差し引いています。

CBOR diagnostic notation:

CBOR診断表記:

   {
     1720 : {                              / system-state (SID 1720) /
       1 : {                               / clock  (SID 1721) /
         2 : "2015-10-02T14:47:24Z-05:00", / current-datetime(SID 1723)/
         1 : "2015-09-15T09:12:58Z-05:00"  / boot-datetime (SID 1722) /
       }
     }
   }
        

CBOR encoding:

CBORエンコーディング:

   A1                                      # map(1)
      19 06B8                              # unsigned(1720)
      A1                                   # map(1)
         01                                # unsigned(1)
         A2                                # map(2)
            02                             # unsigned(2)
            78 1A                          # text(26)
               323031352D31302D30325431343A34373A32345A2D30353A3030
            01                             # unsigned(1)
            78 1A                          # text(26)
               323031352D30392D31355430393A31323A35385A2D30353A3030
        

Figure 2: System State Clock Encoding

図2:システム状態クロックエンコーディング

4.2.2. Using Names in Keys
4.2.2. キーで名前を使用します

CBOR map keys implemented using names MUST be encoded using a CBOR text string data item (major type 3). A namespace-qualified name MUST be used each time the namespace of a representation node and its parent differ. In all other cases, the simple form of the name MUST be used. Names and namespaces are defined in Section 4 of [RFC7951].

名前を使用して実装されたCBORマップキーは、CBORテキスト文字列データ項目(メジャータイプ3)を使用してエンコードする必要があります。表現ノードの名前空間とその親が異なる場合、名前空間認定名を使用する必要があります。他のすべての場合、名前の単純な形式を使用する必要があります。名前と名前空間は、[RFC7951]のセクション4で定義されています。

The following example shows the encoding of a 'system' container representation node instance using names.

次の例は、名前を使用した「システム」コンテナ表現ノードインスタンスのエンコードを示しています。

CBOR diagnostic notation:

CBOR診断表記:

   {
     "ietf-system:system-state" : {
       "clock" : {
         "current-datetime" : "2015-10-02T14:47:24Z-05:00",
         "boot-datetime" : "2015-09-15T09:12:58Z-05:00"
       }
     }
   }
        

CBOR encoding:

CBORエンコーディング:

   A1                                      # map(1)
      78 18                                # text(24)
         696574662D73797374656D3A73797374656D2D7374617465
      A1                                   # map(1)
         65                                # text(5)
            636C6F636B                     # "clock"
         A2                                # map(2)
            70                             # text(16)
               63757272656E742D6461746574696D65
            78 1A                          # text(26)
               323031352D31302D30325431343A34373A32345A2D30353A3030
            6D                             # text(13)
               626F6F742D6461746574696D65
            78 1A                          # text(26)
               323031352D30392D31355430393A31323A35385A2D30353A3030
        
4.3. The 'leaf-list'
4.3. 「リーフリスト」

A leaf-list MUST be encoded using a CBOR array data item (major type 4). Each entry of this array MUST be encoded accordingly to its datatype using one of the encoding rules specified in Section 6.

リーフリストは、CBORアレイデータ項目(メジャータイプ4)を使用してエンコードする必要があります。この配列の各エントリは、セクション6で指定されたエンコードルールのいずれかを使用して、そのデータ型にそれに応じてエンコードする必要があります。

The following example shows the encoding of the 'search' leaf-list representation node instance containing two entries: "ietf.org" and "ieee.org".

次の例は、「ietf.org」と「ieee.org」という2つのエントリを含む「検索」リーフリスト表現ノードインスタンスのエンコードを示しています。

Definition example adapted from [RFC6991] and [RFC7317]:

[RFC6991]および[RFC7317]から適応した定義例:

   typedef domain-name {
     type string {
       pattern
         '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'
       + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'
       + '|\.';
       length "1..253";
     }
   }
        
   leaf-list search {
     type domain-name;
     ordered-by user;
   }
        
4.3.1. Using SIDs in Keys
4.3.1. キーでsidsを使用します

CBOR diagnostic notation:

CBOR診断表記:

   {
     1746 : [ "ietf.org", "ieee.org" ]     / search (SID 1746) /
   }
        

CBOR encoding:

CBORエンコーディング:

   A1                        # map(1)
      19 06D2                # unsigned(1746)
      82                     # array(2)
         68                  # text(8)
            696574662E6F7267 # "ietf.org"
         68                  # text(8)
            696565652E6F7267 # "ieee.org"
        
4.3.2. Using Names in Keys
4.3.2. キーで名前を使用します

CBOR diagnostic notation:

CBOR診断表記:

   {
     "ietf-system:search" : [ "ietf.org", "ieee.org" ]
   }
        

CBOR encoding:

CBORエンコーディング:

   A1                                         # map(1)
      72                                      # text(18)
         696574662D73797374656D3A736561726368 # "ietf-system:search"
      82                                      # array(2)
         68                                   # text(8)
            696574662E6F7267                  # "ietf.org"
         68                                   # text(8)
            696565652E6F7267                  # "ieee.org"
        
4.4. The 'list' and the 'list' Entries
4.4. 「リスト」と「リスト」エントリ

A list or a subset of a list MUST be encoded using a CBOR array data item (major type 4). Each list entry within this CBOR array is encoded using a CBOR map data item (major type 5) based on the encoding rules of a container-like instance, as defined in Section 4.2.

リストのリストまたはサブセットは、CBORアレイデータ項目(メジャータイプ4)を使用してエンコードする必要があります。このCBORアレイ内の各リストエントリは、セクション4.2で定義されているように、コンテナのようなインスタンスのエンコードルールに基づいて、CBORマップデータ項目(メジャータイプ5)を使用してエンコードされます。

It is important to note that this encoding rule also applies to a 'list' representation node instance that has a single entry.

このエンコードルールは、単一のエントリがある「リスト」表現ノードインスタンスにも適用されることに注意することが重要です。

The following examples show the encoding of a 'server' list using SIDs or names.

次の例は、SIDまたは名前を使用した「サーバー」リストのエンコードを示しています。

Definition example adapted from [RFC7317]:

[RFC7317]から編集された定義例:

   list server {
     key name;
        
     leaf name {
       type string;
     }
     choice transport {
       case udp {
         container udp {
           leaf address {
             type host;
             mandatory true;
           }
           leaf port {
             type port-number;
           }
         }
       }
     }
     leaf association-type {
       type enumeration {
         enum server;
         enum peer;
         enum pool;
       }
       default server;
     }
     leaf iburst {
       type boolean;
       default false;
     }
     leaf prefer {
       type boolean;
       default false;
     }
   }
        
4.4.1. Using SIDs in Keys
4.4.1. キーでsidsを使用します

The encoding rules of each 'list' entry are defined in Section 4.2.1.

各「リスト」エントリのエンコードルールは、セクション4.2.1で定義されています。

CBOR diagnostic notation:

CBOR診断表記:

   {
     1756 : [                      / server (SID 1756) /
       {
         3 : "NRC TIC server",     / name (SID 1759) /
         5 : {                     / udp (SID 1761) /
           1 : "tic.nrc.ca",       / address (SID 1762) /
           2 : 123                 / port (SID 1763) /
         },
         1 : 0,                    / association-type (SID 1757) /
         2 : false,                / iburst (SID 1758) /
         4 : true                  / prefer (SID 1760) /
       },
       {
         3 : "NRC TAC server",     / name (SID 1759) /
         5 : {                     / udp (SID 1761) /
           1 : "tac.nrc.ca"        / address (SID 1762) /
         }
       }
     ]
   }
        

CBOR encoding:

CBORエンコーディング:

   A1                                      # map(1)
      19 06DC                              # unsigned(1756)
      82                                   # array(2)
         A5                                # map(5)
            03                             # unsigned(3)
            6E                             # text(14)
               4E52432054494320736572766572 # "NRC TIC server"
            05                             # unsigned(5)
            A2                             # map(2)
               01                          # unsigned(1)
               6A                          # text(10)
                  7469632E6E72632E6361     # "tic.nrc.ca"
               02                          # unsigned(2)
               18 7B                       # unsigned(123)
            01                             # unsigned(1)
            00                             # unsigned(0)
            02                             # unsigned(2)
            F4                             # primitive(20)
            04                             # unsigned(4)
            F5                             # primitive(21)
         A2                                # map(2)
            03                             # unsigned(3)
            6E                             # text(14)
               4E52432054414320736572766572 # "NRC TAC server"
            05                             # unsigned(5)
            A1                             # map(1)
               01                          # unsigned(1)
               6A                          # text(10)
                  7461632E6E72632E6361     # "tac.nrc.ca"
        
4.4.2. Using Names in Keys
4.4.2. キーで名前を使用します

The encoding rules of each 'list' entry are defined in Section 4.2.2.

各「リスト」エントリのエンコードルールは、セクション4.2.2で定義されています。

CBOR diagnostic notation:

CBOR診断表記:

   {
     "ietf-system:server" : [
       {
         "name" : "NRC TIC server",
         "udp" : {
           "address" : "tic.nrc.ca",
           "port" : 123
         },
         "association-type" : 0,
         "iburst" : false,
         "prefer" : true
       },
       {
         "name" : "NRC TAC server",
         "udp" : {
           "address" : "tac.nrc.ca"
         }
       }
     ]
   }
        

CBOR encoding:

CBORエンコーディング:

   A1                                      # map(1)
      72                                   # text(18)
         696574662D73797374656D3A736572766572
      82                                   # array(2)
         A5                                # map(5)
            64                             # text(4)
               6E616D65                    # "name"
            6E                             # text(14)
               4E52432054494320736572766572
            63                             # text(3)
               756470                      # "udp"
            A2                             # map(2)
               67                          # text(7)
                  61646472657373           # "address"
               6A                          # text(10)
                  7469632E6E72632E6361     # "tic.nrc.ca"
               64                          # text(4)
                  706F7274                 # "port"
               18 7B                       # unsigned(123)
            70                             # text(16)
               6173736F63696174696F6E2D74797065
            00                             # unsigned(0)
            66                             # text(6)
               696275727374                # "iburst"
            F4                             # primitive(20)
            66                             # text(6)
               707265666572                # "prefer"
            F5                             # primitive(21)
         A2                                # map(2)
            64                             # text(4)
               6E616D65                    # "name"
            6E                             # text(14)
               4E52432054414320736572766572
            63                             # text(3)
               756470                      # "udp"
            A1                             # map(1)
               67                          # text(7)
                  61646472657373           # "address"
               6A                          # text(10)
                  7461632E6E72632E6361     # "tac.nrc.ca"
        
4.5. The 'anydata'
4.5. 「anydata」

An anydata node serves as a container for an arbitrary set of representation nodes that otherwise appear as normal YANG-modeled data. An anydata representation node instance is encoded using the same rules as a container, i.e., using a CBOR map data item (major type 5) based on the encoding rules of a container-like instance, as defined in Section 4.2.

AnyDataノードは、通常のYangモデルデータとして表示される任意の表現ノードのコンテナとして機能します。AnyData表現ノードインスタンスは、コンテナと同じルールを使用してエンコードされます。つまり、セクション4.2で定義されているように、コンテナのようなインスタンスのエンコーディングルールに基づいて、CBORマップデータ項目(メジャータイプ5)を使用します。

The following example shows a possible use of an anydata node. In this example, an anydata node is used to define a representation node containing a notification event; this representation node can be part of a YANG list to create an event logger.

次の例は、anyDataノードの使用の可能性を示しています。この例では、anyDataノードを使用して、通知イベントを含む表現ノードを定義します。この表現ノードは、イベントロガーを作成するためのYangリストの一部になります。

Definition example:

定義例:

   module event-log {
     ...
     anydata last-event;                // SID 60123
   }
        

This example also assumes the assistance of the following notification.

この例では、次の通知の支援も想定しています。

module example-port { ...

モジュールExample-port {...

     notification example-port-fault {  // SID 60200
       leaf port-name {                 // SID 60201
         type string;
       }
       leaf port-fault {                // SID 60202
         type string;
       }
     }
   }
        
4.5.1. Using SIDs in Keys
4.5.1. キーでsidsを使用します

CBOR diagnostic notation:

CBOR診断表記:

   {
     60123 : {                   / last-event (SID 60123) /
       77 : {                    / example-port-fault (SID 60200) /
         1 : "0/4/21",           / port-name (SID 60201) /
         2 : "Open pin 2"        / port-fault (SID 60202) /
       }
     }
   }
        

CBOR encoding:

CBORエンコーディング:

   A1                               # map(1)
      19 EADB                       # unsigned(60123)
      A1                            # map(1)
         18 4D                      # unsigned(77)
         A2                         # map(2)
            01                      # unsigned(1)
            66                      # text(6)
               302F342F3231         # "0/4/21"
            02                      # unsigned(2)
            6A                      # text(10)
               4F70656E2070696E2032 # "Open pin 2"
        

In some implementations, it might be simpler to use the absolute SID encoding (tag number 47) for the anydata root element. CBOR diagnostic notation:

いくつかの実装では、anyDataルート要素に絶対SIDエンコード(タグ番号47)を使用する方が簡単かもしれません。CBOR診断表記:

   {
     60123 : {                   / last-event (SID 60123) /
       47(60200) : {             / event-port-fault (SID 60200) /
         1 : "0/4/21",           / port-name (SID 60201) /
         2 : "Open pin 2"        / port-fault (SID 60202) /
       }
     }
   }
        
4.5.2. Using Names in Keys
4.5.2. キーで名前を使用します

CBOR diagnostic notation:

CBOR診断表記:

   {
     "event-log:last-event" : {
       "example-port:example-port-fault" : {
         "port-name" : "0/4/21",
         "port-fault" : "Open pin 2"
       }
     }
   }
        

CBOR encoding:

CBORエンコーディング:

   A1                                      # map(1)
      74                                   # text(20)
         6576656E742D6C6F673A6C6173742D6576656E74
      A1                                   # map(1)
         78 1F                             # text(31)
            6578616D706C652D706F72743A
            6578616D706C652D706F72742D6661756C74
         A2                                # map(2)
            69                             # text(9)
               706F72742D6E616D65          # "port-name"
            66                             # text(6)
               302F342F3231                # "0/4/21"
            6A                             # text(10)
               706F72742D6661756C74        # "port-fault"
            6A                             # text(10)
               4F70656E2070696E2032        # "Open pin 2"
        
4.6. The 'anyxml'
4.6. 「anyxml」

An anyxml representation node is used to serialize an arbitrary CBOR content, i.e., its value can be any CBOR binary object. (The "xml" in the name is a misnomer that only applied to YANG-XML [RFC7950].) An anyxml value MAY contain CBOR data items tagged with one of the tags listed in Section 9.3. The tags listed in Section 9.3 SHALL be supported.

anyXML表現ノードは、任意のCBORコンテンツをシリアル化するために使用されます。つまり、その値は任意のCBORバイナリオブジェクトにすることができます。(名前の「XML」は、Yang-XML [RFC7950]にのみ適用される誤称です。)anyXML値には、セクション9.3にリストされているタグの1つでタグ付けされたCBORデータ項目が含まれている場合があります。セクション9.3にリストされているタグをサポートするものとします。

The following example shows a valid CBOR-encoded anyxml representation node instance consisting of a CBOR array containing the CBOR simple values 'true', 'null', and 'true'.

次の例は、CBORの単純な値「true」、「null」、および「true」を含むCBORアレイで構成される有効なCBORエンコードANYXML表現ノードインスタンスを示しています。

Definition example adapted from [RFC7951]:

[RFC7951]から編集された定義例:

   module bar-module {
     ...
     anyxml bar;      // SID 60000
   }
        
4.6.1. Using SIDs in Keys
4.6.1. キーでsidsを使用します

CBOR diagnostic notation:

CBOR診断表記:

   {
     60000 : [true, null, true]   / bar (SID 60000) /
   }
        

CBOR encoding:

CBORエンコーディング:

   A1         # map(1)
      19 EA60 # unsigned(60000)
      83      # array(3)
         F5   # primitive(21)
         F6   # primitive(22)
         F5   # primitive(21)
        
4.6.2. Using Names in Keys
4.6.2. キーで名前を使用します

CBOR diagnostic notation:

CBOR診断表記:

   {
     "bar-module:bar" : [true, null, true]   / bar (SID 60000) /
   }
        

CBOR encoding:

CBORエンコーディング:

   A1                                 # map(1)
      6E                              # text(14)
         6261722D6D6F64756C653A626172 # "bar-module:bar"
      83                              # array(3)
         F5                           # primitive(21)
         F6                           # primitive(22)
         F5                           # primitive(21)
        
5. Encoding of the 'yang-data' Extension
5. 「Yang-Data」拡張機能のエンコード

The yang-data extension [RFC8040] is used to define data structures in YANG that are not intended to be implemented as part of a datastore.

Yang-Data Extension [RFC8040]は、データストアの一部として実装されていないYangのデータ構造を定義するために使用されます。

The yang-data extension will specify a container that MUST be encoded using the encoding rules of nodes of data trees, as defined in Section 4.2.

Yang-Data拡張子は、セクション4.2で定義されているように、データツリーのノードのエンコードルールを使用してエンコードする必要があるコンテナを指定します。

Just like YANG containers, the yang-data extension can be encoded using either SIDs or names.

ヤンコンテナと同様に、ヤンダタ拡張機能は、SIDSまたは名前のいずれかを使用してエンコードできます。

Definition example adapted from Appendix A of [CORE-COMI]:

[Core-comi]の付録Aから編集された定義例:

module ietf-coreconf { ...

モジュールIETF-CORECONF {...

     import ietf-restconf {
       prefix rc;
     }
        
     rc:yang-data yang-errors {
       container error {
         leaf error-tag {
           type identityref {
             base error-tag;
           }
         }
         leaf error-app-tag {
           type identityref {
             base error-app-tag;
           }
         }
         leaf error-data-node {
           type instance-identifier;
         }
         leaf error-message {
           type string;
         }
       }
     }
   }
        
5.1. Using SIDs in Keys
5.1. キーでsidsを使用します

The yang-data extensions encoded using SIDs are carried in a CBOR map containing a single item pair. The key of this item is set to the SID assigned to the yang-data extension container; the value is set to the CBOR encoding of this container, as defined in Section 4.2.

SIDSを使用してエンコードされたYang-Data拡張機能は、単一のアイテムペアを含むCBORマップで運ばれます。このアイテムのキーは、Yang-Data拡張コンテナに割り当てられたSIDに設定されています。この値は、セクション4.2で定義されているように、このコンテナのCBORエンコードに設定されています。

This example shows a serialization example of the yang-errors yang-data extension, as defined in [CORE-COMI], using SIDs, as defined in Section 3.2.

この例は、セクション3.2で定義されているように、SIDSを使用して[Core-comi]で定義されているYang-Errors Yang-Data拡張のシリアル化の例を示しています。

CBOR diagnostic notation:

CBOR診断表記:

   {
     1024 : {                      / error  (SID 1024) /
       4 : 1011,                   / error-tag (SID 1028) /
                                   / = invalid-value (SID 1011) /
       1 : 1018,                   / error-app-tag (SID 1025) /
                                   / = not-in-range (SID 1018) /
       2 : 1740,                   / error-data-node (SID 1026) /
                                   / = timezone-utc-offset (SID 1740) /
       3 : "Maximum exceeded"      / error-message (SID 1027) /
     }
   }
        

CBOR encoding:

CBORエンコーディング:

   A1                                      # map(1)
      19 0400                              # unsigned(1024)
      A4                                   # map(4)
         04                                # unsigned(4)
         19 03F3                           # unsigned(1011)
         01                                # unsigned(1)
         19 03FA                           # unsigned(1018)
         02                                # unsigned(2)
         19 06CC                           # unsigned(1740)
         03                                # unsigned(3)
         70                                # text(16)
            4D6178696D756D206578636565646564 # "Maximum exceeded"
        
5.2. Using Names in Keys
5.2. キーで名前を使用します

The yang-data extensions encoded using names are carried in a CBOR map containing a single item pair. The key of this item is set to the namespace-qualified name of the yang-data extension container; the value is set to the CBOR encoding of this container, as defined in Section 4.2.

名前を使用してエンコードされたYang-Data拡張機能は、単一のアイテムペアを含むCBORマップで運ばれます。このアイテムのキーは、Yang-Data拡張コンテナの名前空間資格のある名前に設定されています。この値は、セクション4.2で定義されているように、このコンテナのCBORエンコードに設定されています。

This example shows a serialization example of the yang-errors yang-data extension, as defined in [CORE-COMI], using names, as defined Section 3.3.

この例は、[Core-comi]で定義されているYang-Errors Yang-Data拡張のシリアル化の例を示しています。

CBOR diagnostic notation:

CBOR診断表記:

   {
     "ietf-coreconf:error" : {
       "error-tag" : "invalid-value",
       "error-app-tag" : "not-in-range",
       "error-data-node" : "timezone-utc-offset",
       "error-message" : "Maximum exceeded"
     }
   }
        

CBOR encoding:

CBORエンコーディング:

   A1                                           # map(1)
      73                                        # text(19)
         696574662D636F7265636F6E663A6572726F72 # "ietf-coreconf:error"
      A4                                        # map(4)
         69                                     # text(9)
            6572726F722D746167                  # "error-tag"
         6D                                     # text(13)
            696E76616C69642D76616C7565          # "invalid-value"
         6D                                     # text(13)
            6572726F722D6170702D746167          # "error-app-tag"
         6C                                     # text(12)
            6E6F742D696E2D72616E6765            # "not-in-range"
         6F                                     # text(15)
            6572726F722D646174612D6E6F6465      # "error-data-node"
         73                                     # text(19)
            74696D657A6F6E652D7574632D6F6666736574
                                                # "timezone-utc-offset"
         6D                                     # text(13)
            6572726F722D6D657373616765          # "error-message"
         70                                     # text(16)
            4D6178696D756D206578636565646564    # "Maximum exceeded"
        
6. Representing YANG Data Types in CBOR
6. CBORのヤンデータ型を表す

The CBOR encoding of an instance of a leaf or leaf-list representation node depends on the built-in type of that representation node. The following subsection defines the CBOR encoding of each built-in type supported by YANG, as listed in Section 4.2.4 of [RFC7950]. Each subsection shows an example value assigned to a representation node instance of the discussed built-in type.

葉または葉のリスト表現ノードのインスタンスのCBORエンコードは、その表現ノードの組み込みタイプに依存します。次のサブセクションでは、[RFC7950]のセクション4.2.4にリストされているように、Yangがサポートする各組み込みタイプのCBORエンコードを定義しています。各サブセクションは、議論された組み込み型の表現ノードインスタンスに割り当てられた例の値を示しています。

6.1. The Unsigned Integer Types
6.1. 署名されていない整数タイプ

Leafs of type uint8, uint16, uint32, and uint64 MUST be encoded using a CBOR unsigned integer data item (major type 0).

型UINT8、UINT16、UINT32、およびUINT64の葉は、CBORの非署名整数データ項目(メジャータイプ0)を使用してエンコードする必要があります。

The following example shows the encoding of an 'mtu' leaf representation node instance set to 1280 bytes.

次の例は、1280バイトに設定された「MTU」リーフ表現ノードインスタンスのエンコードを示しています。

Definition example adapted from [RFC8344]:

[RFC8344]から編集された定義例:

   leaf mtu {
     type uint16 {
       range "68..max";
     }
   }
        

CBOR diagnostic notation: 1280

CBOR診断表記:1280

CBOR encoding: 19 0500

CBORエンコーディング:19 0500

6.2. The Integer Types
6.2. 整数タイプ

Leafs of type int8, int16, int32, and int64 MUST be encoded using either a CBOR unsigned integer (major type 0) or a CBOR negative integer (major type 1), depending on the actual value.

タイプINT8、INT16、INT32、およびINT64の葉は、実際の値に応じて、CBOR未署名整数(メジャータイプ0)またはCBORネガティブ整数(メジャータイプ1)のいずれかを使用してエンコードする必要があります。

The following example shows the encoding of a 'timezone-utc-offset' leaf representation node instance set to -300 minutes.

次の例は、-300分に設定された「TimeZone-UTCオフセット」リーフ表現ノードインスタンスのエンコードを示しています。

Definition example adapted from [RFC7317]:

[RFC7317]から編集された定義例:

   leaf timezone-utc-offset {
     type int16 {
       range "-1500 .. 1500";
     }
   }
        

CBOR diagnostic notation: -300

CBOR診断表記:-300

CBOR encoding: 39 012B

CBORエンコーディング:39 012B

6.3. The 'decimal64' Type
6.3. 「Decimal64」タイプ

Leafs of type decimal64 MUST be encoded using a decimal fraction, as defined in Section 3.4.4 of [RFC8949].

[RFC8949]のセクション3.4.4で定義されているように、10進数型の葉は小数画分を使用してエンコードする必要があります。

The following example shows the encoding of a 'my-decimal' leaf representation node instance set to 2.57.

次の例は、2.57に設定された「my-decimal」葉表現ノードインスタンスのエンコードを示しています。

Definition example adapted from [RFC7317]:

[RFC7317]から編集された定義例:

   leaf my-decimal {
     type decimal64 {
       fraction-digits 2;
       range "1 .. 3.14 | 10 | 20..max";
     }
   }
        

CBOR diagnostic notation: 4([-2, 257])

CBOR診断表記:4([-2、257])

CBOR encoding: C4 82 21 19 0101

CBORエンコーディング:C4 82 21 19 0101

6.4. The 'string' Type
6.4. 「文字列」タイプ

Leafs of type string MUST be encoded using a CBOR text string data item (major type 3).

型文字列の葉は、CBORテキスト文字列データ項目(メジャータイプ3)を使用してエンコードする必要があります。

The following example shows the encoding of a 'name' leaf representation node instance set to "eth0".

次の例は、「eth0」に設定された「名前」葉表現ノードインスタンスのエンコードを示しています。

Definition example adapted from [RFC8343]:

[RFC8343]から編集された定義例:

   leaf name {
     type string;
   }
        

CBOR diagnostic notation: "eth0"

CBOR診断表記:「ETH0」

CBOR encoding: 64 65746830

CBORエンコーディング:64 65746830

6.5. The 'boolean' Type
6.5. 「ブール」タイプ

Leafs of type boolean MUST be encoded using a CBOR simple value 'true' (major type 7, additional information 21) or 'false' (major type 7, additional information 20).

タイプのブール値の葉は、CBORの単純な値「真」(メジャータイプ7、追加情報21)または「偽」(メジャータイプ7、追加情報20)を使用してエンコードする必要があります。

The following example shows the encoding of an 'enabled' leaf representation node instance set to 'true'.

次の例は、「True」に設定された「有効な」葉表現ノードインスタンスのエンコードを示しています。

Definition example adapted from [RFC7317]:

[RFC7317]から編集された定義例:

   leaf enabled {
     type boolean;
   }
        

CBOR diagnostic notation: true

CBOR診断表記:TRUE

CBOR encoding: F5

CBORエンコーディング:F5

6.6. The 'enumeration' Type
6.6. 「列挙」タイプ

Leafs of type enumeration MUST be encoded using a CBOR unsigned integer (major type 0) or CBOR negative integer (major type 1), depending on the actual value, or exceptionally as a tagged text string (see below). Enumeration values are either explicitly assigned using the YANG statement 'value' or automatically assigned based on the algorithm defined in Section 9.6.4.2 of [RFC7950].

タイプの列挙の葉は、実際の値に応じて、またはタグ付きのテキスト文字列として例外的に、CBORの非署名整数(メジャータイプ0)またはCBORネガティブ整数(メジャータイプ1)を使用してエンコードする必要があります(以下を参照)。列挙値は、Yangステートメント「値」を使用して明示的に割り当てられるか、[RFC7950]のセクション9.6.4.2で定義されているアルゴリズムに基づいて自動的に割り当てられます。

The following example shows the encoding of an 'oper-status' leaf representation node instance set to 'testing'.

次の例は、「テスト」に設定された「オペレーション」リーフ表現ノードインスタンスのエンコードを示しています。

Definition example adapted from [RFC7317]:

[RFC7317]から編集された定義例:

   leaf oper-status {
     type enumeration {
       enum up { value 1; }
       enum down { value 2; }
       enum testing { value 3; }
       enum unknown { value 4; }
       enum dormant { value 5; }
       enum not-present { value 6; }
       enum lower-layer-down { value 7; }
     }
   }
        

CBOR diagnostic notation: 3

CBOR診断表記:3

CBOR encoding: 03

CBORエンコーディング:03

Values of 'enumeration' types defined in a 'union' type MUST be encoded using a CBOR text string data item (major type 3) and MUST contain one of the names assigned by 'enum' statements in YANG (see also Section 6.12). The encoding MUST be enclosed by the enumeration CBOR tag, as specified in Section 9.3.

「ユニオン」タイプで定義された「列挙」タイプの値は、CBORテキスト文字列データ項目(メジャータイプ3)を使用してエンコードする必要があり、Yangの「Enum」ステートメントで割り当てられた名前の1つを含める必要があります(セクション6.12も参照)。エンコードは、セクション9.3で指定されているように、列挙CBORタグによって囲まれている必要があります。

Definition example adapted from [RFC7950]:

[RFC7950]から編集された定義例:

   type union {
     type int32;
     type enumeration {
       enum unbounded;
     }
   }
        

CBOR diagnostic notation: 44("unbounded")

CBOR診断表記:44( "Unbounded")

CBOR encoding: D8 2C 69 756E626F756E646564

CBORエンコーディング:D8 2C 69 756E626F756E646564

6.7. The 'bits' Type
6.7. 「ビット」タイプ

Keeping in mind that bit positions are either explicitly assigned using the YANG statement 'position' or automatically assigned based on the algorithm defined in Section 9.7.4.2 of [RFC7950], each element of type bits could be seen as a set of bit positions (or offsets from position 0) that have a value of either 1, which represents the bit being set, or 0, which represents that the bit is not set.

ビット位置は、Yangステートメント「位置」を使用して明示的に割り当てられるか、[RFC7950]のセクション9.7.4.2で定義されているアルゴリズムに基づいて自動的に割り当てられていることに留意してください。タイプビットの各要素はビット位置のセットとして見ることができます(または、1の値を持つ位置0からのオフセットは、設定されているビットまたは0を表します。これは、ビットが設定されていないことを表します。

Leafs of type bits MUST be encoded either using a CBOR array (major type 4) or byte string (major type 2) or exceptionally as a tagged text string (see below). In case CBOR array representation is used, each element is either (1) a positive integer (major type 0 with value 0 being disallowed) that can be used to calculate the offset of the next byte string or (2) a byte string (major type 2) that carries the information regarding whether certain bits are set or not. The initial offset value is 0, and each unsigned integer modifies the offset value of the next byte string by the integer value multiplied by 8. For example, if the bit offset is 0 and there is an integer with value 5, the first byte of the byte string that follows will represent bit positions 40 to 47, with both ends included. If the byte string has a second byte, it will carry information about bits 48 to 55, and so on. Within each byte, bits are assigned from least to most significant. After the byte string, the offset is modified by the number of bytes in the byte string multiplied by 8. Bytes with no bits set (zero bytes) at the end of the byte string are never generated. If they occur at the end of the array, the zero bytes are simply omitted; if they occur at the end of a byte string preceding an integer, the zero bytes are removed and the integer is adjusted upwards by the number of zero bytes that were removed. An example follows.

タイプビットの葉は、CBORアレイ(メジャータイプ4)またはバイト文字列(メジャータイプ2)を使用して、またはタグ付きテキスト文字列として例外的にエンコードする必要があります(以下を参照)。 CBORアレイ表現が使用される場合、各要素は(1)次のバイト文字列のオフセットを計算するために使用できる正の整数(値0が許可されていない)または(2)バイト文字列(メジャー)のいずれかです。タイプ2)特定のビットが設定されているかどうかに関する情報が届きます。初期オフセット値は0であり、各符号なしの整数は、次のバイト文字列のオフセット値を整数値に変更します。たとえば、ビットオフセットが0であり、値5の整数がある場合、最初のバイトがあります。次のバイト文字列は、ビット位置40〜47を表し、両端が含まれます。バイト文字列に2番目のバイトがある場合、ビット48〜55などの情報が含まれます。各バイト内で、ビットは最低から最も重要なものに割り当てられます。バイト文字列の後、オフセットはバイト文字列のバイト数に8を掛けたものに変更されます。バイト文字列の端にビットセット(ゼロバイト)のないバイトが生成されません。配列の端で発生する場合、ゼロバイトは単に省略されます。整数の前のバイト文字列の端で発生すると、ゼロバイトが削除され、整数が削除されたゼロバイトの数によって上方に調整されます。例が続きます。

The following example shows the encoding of an 'alarm-state' leaf representation node instance with the 'critical' (position 2), 'warning' (position 8), and 'indeterminate' (position 128) flags set.

次の例は、「クリティカル」(位置2)、「警告」(位置8)、および「不定」(位置128)のフラグを備えた「アラーム状態」葉表現ノードインスタンスのエンコードを示しています。

   typedef alarm-state {
     type bits {
       bit unknown;
       bit under-repair;
       bit critical;
       bit major;
       bit minor;
       bit warning {
         position 8;
       }
       bit indeterminate {
         position 128;
       }
     }
   }
        
   leaf alarm-state {
     type alarm-state;
   }
        

CBOR diagnostic notation: [h'0401', 14, h'01']

CBOR診断表記:[H'0401 '、14、H'01']

CBOR encoding: 83 42 0401 0E 41 01

CBORエンコーディング:83 42 0401 0E 41 01

In a number of cases, the array would only need to have one element -- a byte string with a few bytes inside. For this case, it is REQUIRED to omit the array element and have only the byte array that would have been inside. To illustrate this, let us consider the same example YANG definition but this time encoding only 'under-repair' and 'critical' flags. The result would be

多くの場合、アレイには1つの要素が必要なだけです。数バイトの内部のバイト文字列です。この場合、配列要素を省略し、内部にあったバイト配列のみを持つ必要があります。これを説明するために、Yangの定義と同じ例について考えてみましょうが、今回は「過小評価」と「重要な」フラグのみをエンコードしてください。結果は次のとおりです

CBOR diagnostic notation: h'06'

CBOR診断表記:H'06 '

CBOR encoding: 41 06

CBORエンコーディング:41 06

Elements in the array MUST be either byte strings that do not end in a zero byte or positive unsigned integers, where byte strings and integers MUST alternate, i.e., adjacent byte strings or adjacent integers are an error. An array with a single byte string MUST instead be encoded as just that byte string. An array with a single positive integer is an error. Note that a recipient can handle trailing zero bytes in the byte strings using the normal rules without any issue, so an implementation MAY silently accept them.

配列内の要素は、ゼロバイトで終了しないバイト文字列または正の符号なし整数である必要があります。ここでは、バイト文字列と整数、つまり隣接するバイト文字列または隣接する整数がエラーです。代わりに、単一のバイト文字列を備えた配列は、そのバイト文字列としてエンコードする必要があります。単一の正の整数を備えた配列はエラーです。受信者は、問題なしに通常のルールを使用してバイト文字列のトレーリングゼロバイトを処理できるため、実装が静かに受け入れる可能性があることに注意してください。

Values of 'bits' types defined in a 'union' type MUST be encoded using a CBOR text string data item (major type 3) and MUST contain a space-separated sequence of names of 'bits' that are set (see also Section 6.12). The encoding MUST be enclosed by the bits CBOR tag, as specified in Section 9.3.

「ユニオン」タイプで定義された「ビット」タイプの値は、CBORテキスト文字列データ項目(メジャータイプ3)を使用してエンコードする必要があり、設定された「ビット」の名前のスペース分離されたシーケンスを含める必要があります(セクション6.12も参照してください。)。エンコードは、セクション9.3で指定されているように、BITS CBORタグで囲まれている必要があります。

The following example shows the encoding of an 'alarm-state' leaf representation node instance defined using a union type with the 'under-repair' and 'critical' flags set.

次の例は、「アラーム状態」葉表現ノードインスタンスのエンコードを示しています。

Definition example:

定義例:

   leaf alarm-state-2 {
     type union {
       type alarm-state;
       type bits {
         bit extra-flag;
       }
     }
   }
        

CBOR diagnostic notation: 43("under-repair critical")

CBOR診断表記:43( "アンダーレペアクリティカル")

   CBOR encoding: D8 2B 75 756E6465722D72657061697220637269746963616C
        
6.8. The 'binary' Type
6.8. 「バイナリ」タイプ

Leafs of type binary MUST be encoded using a CBOR byte string data item (major type 2).

タイプのバイナリの葉は、CBORバイト文字列データ項目(メジャータイプ2)を使用してエンコードする必要があります。

The following example shows the encoding of an 'aes128-key' leaf representation node instance set to 0x1f1ce6a3f42660d888d92a4d8030476e.

次の例は、0x1f1ce6a3f42660d88888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888Dのエンコードを示しています。

Definition example:

定義例:

   leaf aes128-key {
     type binary {
       length 16;
     }
   }
        

CBOR diagnostic notation: h'1F1CE6A3F42660D888D92A4D8030476E'

CBOR診断表記:H'1F1CE6A3F42660D888D92A4D8030476E '

   CBOR encoding: 50 1F1CE6A3F42660D888D92A4D8030476E
        
6.9. The 'leafref' Type
6.9. 「Leafref」タイプ

Leafs of type leafref MUST be encoded using the rules of the representation node referenced by the 'path' YANG statement.

タイプの葉の葉は、「パス」ヤンステートメントで参照される表現ノードのルールを使用してエンコードする必要があります。

The following example shows the encoding of an 'interface-state-ref' leaf representation node instance set to "eth1".

次の例は、「eTh1」に設定された「インターフェイス状-ref」リーフ表現ノードインスタンスのエンコードを示しています。

Definition example adapted from [RFC8343]:

[RFC8343]から編集された定義例:

   typedef interface-state-ref {
     type leafref {
       path "/interfaces-state/interface/name";
     }
   }
        
   container interfaces-state {
     list interface {
       key "name";
       leaf name {
         type string;
       }
       leaf-list higher-layer-if {
         type interface-state-ref;
       }
     }
   }
        

CBOR diagnostic notation: "eth1"

CBOR診断表記:「ETH1」

CBOR encoding: 64 65746831

CBORエンコーディング:64 65746831

6.10. The 'identityref' Type
6.10. 「IdentityRef」タイプ

This specification supports two approaches for encoding identityref: as a YANG Schema Item iDentifier, as defined in Section 3.2, or as a name, as defined in Section 6.8 of [RFC7951]. See Section 6.12 for an exceptional case when this representation needs to be tagged.

この仕様は、セクション3.2で定義されているように、[RFC7951]のセクション6.8で定義されているように、Yangスキーマアイテム識別子として、Yangスキーマアイテム識別子としての2つのアプローチをサポートしています。この表現にタグ付けする必要がある場合の例外的なケースについては、セクション6.12を参照してください。

6.10.1. SIDs as 'identityref'
6.10.1. 「アイデンティティレフ」としてのsids

When representation nodes of type identityref are implemented using SIDs, they MUST be encoded using a CBOR unsigned integer data item (major type 0). (Note that, as they are not used in the position of CBOR map keys, no delta mechanism is employed for SIDs used for identityref.)

タイプIDREFの表現ノードがSIDSを使用して実装される場合、CBORの非署名整数データ項目(メジャータイプ0)を使用してエンコードする必要があります。(CBORマップキーの位置で使用されていないため、IDREFに使用されるSIDにはデルタメカニズムが使用されていないことに注意してください。)

The following example shows the encoding of a 'type' leaf representation node instance set to the value 'iana-if-type:ethernetCsmacd' (SID 1880).

次の例は、値に設定された「タイプ」リーフ表現ノードインスタンスのエンコードを示しています。

Definition example adapted from [RFC7317]:

[RFC7317]から編集された定義例:

   identity interface-type {
   }
        
   identity iana-interface-type {
     base interface-type;
   }
        
   identity ethernetCsmacd {
     base iana-interface-type;
   }
        
   leaf type {
     type identityref {
       base interface-type;
     }
   }
        

CBOR diagnostic notation: 1880

CBOR診断表記:1880

CBOR encoding: 19 0758

CBORエンコーディング:19 0758

6.10.2. Name as 'identityref'
6.10.2. 「IdentityRef」という名前

Alternatively, an identityref MAY be encoded using a name, as defined in Section 3.3. When names are used, identityref MUST be encoded using a CBOR text string data item (major type 3). If the identity is defined in a different module than the leaf node containing the identityref data node, the namespace-qualified form MUST be used. Otherwise, both the simple and namespace-qualified forms are permitted. Names and namespaces are defined in Section 3.3.

あるいは、セクション3.3で定義されているように、名前を使用してIDREFをエンコードすることもできます。名前が使用される場合、IdentityRefはCBORテキスト文字列データ項目(メジャータイプ3)を使用してエンコードする必要があります。IDEFREFデータノードを含むリーフノードとは異なるモジュールでIDが定義されている場合、名前空間認定フォームを使用する必要があります。それ以外の場合、単純なフォームと名前空間認定フォームの両方が許可されています。名前と名前空間は、セクション3.3で定義されています。

The following example shows the encoding of the identity 'iana-if-type:ethernetCsmacd' using its namespace-qualified name. This example is described in Section 6.10.1.

次の例は、その名前空間認定名を使用して、アイデンティティ「iANA-if-type:ethernetcsmacd」のエンコードを示しています。この例については、セクション6.10.1で説明しています。

CBOR diagnostic notation: "iana-if-type:ethernetCsmacd"

CBOR診断表記:「IANA-IF-Type:EthernetCSMACD」

   CBOR encoding: 78 1B
   69616E612D69662D747970653A65746865726E657443736D616364
        
6.11. The 'empty' Type
6.11. 「空」タイプ

Leafs of type empty MUST be encoded using the CBOR null value (major type 7, additional information 22).

空のタイプの葉は、Cbor null値(メジャータイプ7、追加情報22)を使用してエンコードする必要があります。

The following example shows the encoding of an 'is-router' leaf representation node instance when present.

次の例は、存在するときの「isルーター」葉表現ノードインスタンスのエンコードを示しています。

Definition example adapted from [RFC8344]:

[RFC8344]から編集された定義例:

   leaf is-router {
     type empty;
   }
        

CBOR diagnostic notation: null

CBOR診断表記:null

CBOR encoding: F6

CBORエンコーディング:F6

6.12. The 'union' Type
6.12. 「ユニオン」タイプ

Leafs of type union MUST be encoded using the rules associated with one of the types listed. When used in a union, the following YANG datatypes are enclosed by a CBOR tag to avoid confusion between different YANG datatypes encoded using the same CBOR major type.

タイプユニオンの葉は、リストされているタイプのいずれかに関連付けられたルールを使用してエンコードする必要があります。組合で使用する場合、次のYangデータ型はCBORタグで囲まれており、同じCBORメジャータイプを使用してエンコードされた異なるYangデータ型間の混乱を避けます。

* bits

* ビット

* enumeration

* 列挙

* identityref

* IDREF

* instance-identifier

* Instance-Identifier

See Section 9.3 for the assigned value of these CBOR tags.

これらのCBORタグの割り当てられた値については、セクション9.3を参照してください。

As mentioned in Sections 6.6 and in 6.7, 'enumeration' and 'bits' are encoded as a CBOR text string data item (major type 3) when defined within a 'union' type. (This adds considerable complexity but is necessary because of an idiosyncrasy of the YANG data model for unions; the work-around allows compatibility to be maintained with the encoding of overlapping unions in XML and JSON. See also Section 9.12 of [RFC7950].)

セクション6.6および6.7で述べたように、「列挙」と「ビット」は、「ユニオン」タイプ内で定義された場合、CBORテキスト文字列データ項目(メジャータイプ3)としてエンコードされます。(これはかなりの複雑さを追加しますが、組合のYangデータモデルの特異性のために必要です。XMLとJSONの重複する組合のエンコードとの互換性を維持することができます。[RFC7950]のセクション9.12も参照してください。)

The following example shows the encoding of an 'ip-address' leaf representation node instance when set to "2001:db8:a0b:12f0::1".

次の例は、「2001:DB8:A0B:12F0 :: 1」に設定したときの「IPアドレス」リーフ表現ノードインスタンスのエンコードを示しています。

Definition example adapted from [RFC6991]:

[RFC6991]から編集された定義例:

   typedef ipv4-address {
     type string {
       pattern
         '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
       +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
       + '(%[\p{N}\p{L}]+)?';
     }
   }
        
   typedef ipv6-address {
     type string {
       pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
             + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
             + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
             + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
             + '(%[\p{N}\p{L}]+)?';
       pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
             + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
             + '(%.+)?';
     }
   }
        
   typedef ip-address {
     type union {
       type ipv4-address;
       type ipv6-address;
     }
   }
        
   leaf address {
     type ip-address;
   }
        
   CBOR diagnostic notation: "2001:db8:a0b:12f0::1"
        
   CBOR encoding: 74 323030313A6462383A6130623A313266303A3A31
        
6.13. The 'instance-identifier' Type
6.13. 「Instance-Identifier」タイプ

This specification supports two approaches for encoding an instance-identifier: one based on YANG Schema Item iDentifier, as defined in Section 3.2, and one based on names, as defined in Section 3.3. See Section 6.12 for an exceptional case when this representation needs to be tagged.

この仕様は、インスタンスIDENTIFIERをエンコードするための2つのアプローチをサポートしています。1つは、セクション3.2で定義されているYangスキーマアイテム識別子に基づいており、セクション3.3で定義されている名前に基づいています。この表現にタグ付けする必要がある場合の例外的なケースについては、セクション6.12を参照してください。

6.13.1. SIDs as 'instance-identifier'
6.13.1. 「Instance-Identifier」としてのsids

SIDs uniquely identify a schema node. In the case of a single instance schema node, i.e., a schema node defined at the root of a YANG module or submodule or schema nodes defined within a container, the SID is sufficient to identify this instance (representation node). (Note that no delta mechanism is employed for SIDs used for identityref, see Section 6.10.1.)

SIDSはスキーマノードを一意に識別します。単一のインスタンススキーマノード、つまりヤンモジュールまたはサブモジュールまたはサブモジュールまたはスキーマノードで定義されたスキーマノードがコンテナ内で定義されている場合、SIDはこのインスタンス(表現ノード)を識別するのに十分です。(IdentityRefに使用されるSIDにはデルタメカニズムが使用されていないことに注意してください。セクション6.10.1を参照してください。)

In the case of a representation node that is an entry of a YANG list, a SID is combined with the list key(s) to identify each instance within the YANG list(s).

Yangリストのエントリである表現ノードの場合、SIDはリストキーと組み合わされて、Yangリスト内の各インスタンスを識別します。

Instance-identifiers of single instance schema nodes MUST be encoded using a CBOR unsigned integer data item (major type 0) and set to the targeted schema node SID.

単一のインスタンススキーマノードのインスタンス識別子は、CBORの非署名整数データ項目(メジャータイプ0)を使用してエンコードし、ターゲットスキーマノードSIDに設定する必要があります。

Instance-identifiers of representation node entries of a YANG list MUST be encoded using a CBOR array data item (major type 4) containing the following entries:

Yangリストの表現ノードエントリのインスタンス識別子は、次のエントリを含むCBORアレイデータ項目(メジャータイプ4)を使用してエンコードする必要があります。

* The first entry MUST be encoded as a CBOR unsigned integer data item (major type 0) and set to the targeted schema node SID.

* 最初のエントリは、CBORの符号なし整数データ項目(メジャータイプ0)としてエンコードし、ターゲットを絞ったスキーマノードSIDに設定する必要があります。

* The following entries MUST contain the value of each key required to identify the instance of the targeted schema node. These keys MUST be ordered as defined in the 'key' YANG statement, starting from the top-level list, and followed by each subordinate list(s).

* 次のエントリには、ターゲットスキーマノードのインスタンスを識別するために必要な各キーの値を含める必要があります。これらのキーは、「キー」ヤンステートメントで定義され、トップレベルのリストから始まり、各下位リストが続くように順序付けられる必要があります。

Examples within this section assume the definition of a schema node of type 'instance-identifier':

このセクション内の例は、「Instance-Identifier」タイプのスキーマノードの定義を想定しています。

Definition example adapted from [RFC7950]:

[RFC7950]から編集された定義例:

   container system {
     ...
     leaf reporting-entity {
       type instance-identifier;
     }
        
   *First example:*
        

The following example shows the encoding of the 'reporting-entity' value referencing data node instance "/system/contact" (SID 1741).

次の例は、データノードインスタンスを参照する「レポートエンティティ」値のエンコード "/system/contact"(SID 1741)を示しています。

Definition example adapted from [RFC7317]:

[RFC7317]から編集された定義例:

container system {

コンテナシステム{

     leaf contact {
       type string;
     }
        
     leaf hostname {
       type inet:domain-name;
     }
   }
        

CBOR diagnostic notation: 1741

CBOR診断表記:1741

CBOR encoding: 19 06CD

CBORエンコーディング:19 06cd

   *Second example:*
        

This example aims to show how a representation node entry of a YANG list is identified. It uses a somewhat arbitrarily modified YANG module version from [RFC7317] by adding country to the leafs and keys of authorized-key.

この例は、Yangリストの表現ノードエントリがどのように識別されるかを示すことを目的としています。[RFC7317]のやや任意に変更されたYangモジュールバージョンを使用して、認定キーの葉と鍵に国を追加します。

The following example shows the encoding of the 'reporting-entity' value referencing list instance "/system/authentication/user/ authorized-key/key-data" (which is assumed to have SID 1734) for username "bob" and authorized-key with name "admin" and country "france".

次の例は、「レポートエンティティ」値を参照するリストインスタンスのエンコード "/system/authentication/user/autherized-key/key-data"(sid 1734があると想定されている)の「bob」および承認 - 承認 - のエンコードを示しています。「管理者」と「国」という名前のキー。

   list user {
     key name;
        
     leaf name {
       type string;
     }
        
     leaf password {
       type ianach:crypt-hash;
     }
        
     list authorized-key {
       key "name country";
        
       leaf country {
         type string;
       }
        
       leaf name {
         type string;
       }
        
       leaf algorithm {
         type string;
       }
        
       leaf key-data {
         type binary;
       }
     }
   }
        

CBOR diagnostic notation: [1734, "bob", "admin", "france"]

CBOR診断表記:[1734、「ボブ」、「管理者」、「フランス」]

CBOR encoding:

CBORエンコーディング:

   84                 # array(4)
      19 06C6         # unsigned(1734)
      63              # text(3)
         626F62       # "bob"
      65              # text(5)
         61646D696E   # "admin"
      66              # text(6)
         6672616E6365 # "france"
        
   *Third example:*
        

The following example shows the encoding of the 'reporting-entity' value referencing the list instance "/system/authentication/user" (SID 1730), corresponding to username "jack".

次の例は、ユーザー名「ジャック」に対応するリストインスタンス「/システム/認証/ユーザー」(SID 1730)を参照する「レポートエンティティ」値のエンコードを示しています。

CBOR diagnostic notation: [1730, "jack"]

CBOR診断表記:[1730、 "Jack"]

CBOR encoding:

CBORエンコーディング:

   82             # array(2)
      19 06C2     # unsigned(1730)
      64          # text(4)
         6A61636B # "jack"
        
6.13.2. Names as 'instance-identifier'
6.13.2. 「Instance-Identifier」としての名前

An 'instance-identifier' value is encoded as a text string that is analogous to the lexical representation in XML encoding; see Section 9.13.2 of [RFC7950]. However, the encoding of namespaces in instance-identifier values follows the rules stated in Section 3.3, namely:

'instance-identifier'値は、XMLエンコーディングの語彙表現に類似したテキスト文字列としてエンコードされます。[RFC7950]のセクション9.13.2を参照してください。ただし、インスタンスIDENTIFIER値の名前空間のエンコードは、セクション3.3、つまり、次のようなルールに従います。

* The leftmost (top-level) data node name is always in the namespace-qualified form.

* 左端(上位レベル)のデータノード名は、常に名前空間認定フォームにあります。

* Any subsequent data node name is in the namespace-qualified form if the node is defined in a module other than its parent node; otherwise, the simple form is used. This rule also holds for node names appearing in predicates.

* ノードが親ノード以外のモジュールで定義されている場合、後続のデータノード名は名前空間認定フォームにあります。それ以外の場合、単純なフォームが使用されます。このルールは、述語に表示されるノード名にも保持されます。

For example,

例えば、

   /ietf-interfaces:interfaces/interface[name='eth0']/ietf-ip:ipv4/ip
        

is a valid instance-identifier value because the data nodes "interfaces", "interface", and "name" are defined in the module "ietf-interfaces", whereas "ipv4" and "ip" are defined in "ietf-ip".

データノードは「インターフェイス」、「インターフェイス」、および「名前」がモジュール「IETFインターフェイス」で定義され、「IPv4」と「IP」が「IETF-IP」で定義されているため、有効なインスタンス識別子値です。。

The resulting XML Path Language (XPath) MUST be encoded using a CBOR text string data item (major type 3).

結果のXMLパス言語(XPath)は、CBORテキスト文字列データ項目(メジャータイプ3)を使用してエンコードする必要があります。

   *First example:*
        

This example is described in Section 6.13.1.

この例については、セクション6.13.1で説明しています。

   CBOR diagnostic notation: "/ietf-system:system/contact"
        

CBOR encoding:

CBORエンコーディング:

   78 1B 2F696574662D73797374656D3A73797374656D2F636F6E74616374
        
   *Second example:*
        

This example is described in Section 6.13.1.

この例については、セクション6.13.1で説明しています。

CBOR diagnostic notation (the line break is inserted for exposition only):

CBOR診断表記(博覧会のみのためにラインブレークが挿入されます):

   "/ietf-system:system/authentication/user[name='bob']/
   authorized-key[name='admin'][country='france']/key-data"
        

CBOR encoding:

CBORエンコーディング:

   78 6B
      2F696574662D73797374656D3A73797374656D2F61757468656E74696361
      74696F6E2F757365725B6E616D653D27626F62275D2F617574686F72697A
      65642D6B65795B6E616D653D2761646D696E275D5B636F756E7472793D27
      6672616E6365275D2F6B65792D64617461
        
   *Third example:*
        

This example is described in Section 6.13.1.

この例については、セクション6.13.1で説明しています。

CBOR diagnostic notation:

CBOR診断表記:

   "/ietf-system:system/authentication/user[name='jack']"
        

CBOR encoding:

CBORエンコーディング:

   78 34                                   # text(52)
      2F696574662D73797374656D3A73797374656D2F61757468656E74696361
      74696F6E2F757365725B6E616D653D276A61636B275D
        
7. Content-Types
7. コンテンツタイプ

This specification defines the media type application/yang-data+cbor, which can be used without parameters or with the id parameter set to either name or sid.

この仕様では、メディアタイプアプリケーション/Yang-Data Cborを定義します。これは、パラメーターなしで、または名前またはSIDに設定されているIDパラメーターを使用できます。

This media type represents a YANG-CBOR document containing a representation tree. If the media type parameter id is present, depending on its value, each representation node is identified by its associated namespace-qualified name, as defined in Section 3.3 (id=name), or by its associated YANG SID (represented, e.g., in CBOR map keys as a SID delta or via tag number 47), as defined in Section 3.2 (id=sid), respectively. If no id parameter is given, both forms may be present.

このメディアタイプは、表現ツリーを含むYang-Corのドキュメントを表します。メディアタイプのパラメーターIDがその値に応じて存在する場合、各表現ノードは、セクション3.3(ID =名前)で定義されている関連する名前空間認定名によって識別されます。それぞれセクション3.2(ID = SID)で定義されているように、Cborマップキーまたはタグ番号47を介して)。IDパラメーターが指定されていない場合、両方のフォームが存在する場合があります。

The format of an application/yang-data+cbor representation is that of a CBOR map, mapping names, and/or SIDs (as defined above) into instance values (using the rules defined in Section 4).

アプリケーション/Yang-Data CBOR表現の形式は、CBORマップ、マッピング名、および/またはSID(上記で定義されている)の形式(セクション4で定義されているルールを使用)になります。

It is not foreseen at this point that the valid set of values for the id parameter will extend beyond name, sid, or being unset; if that does happen, any new value is foreseen to be of the form [a-z][a-z0-9]*(-[a-z0-9]+)*.

この時点で、IDパラメーターの有効な値のセットが名前、SID、または設定されていることを超えて拡張されることは予見されていません。それが発生した場合、新しい値は[a-z] [a-z0-9]*( - [a-z0-9])の形式であると予測されています。

In summary, this document defines three content-types, which are intended for use by different classes of applications:

要約すると、このドキュメントでは、さまざまなクラスのアプリケーションで使用することを目的とした3つのコンテンツタイプを定義しています。

* application/yang-data+cbor; id=sid -- for use by applications that need to be frugal with encoding space and text string processing (e.g., applications running on constrained nodes [RFC7228] or applications with particular performance requirements);

* アプリケーション/Yang-Data Cbor;ID = SID-エンコードスペースとテキスト文字列処理(たとえば、制約付きノード[RFC7228]で実行されるアプリケーションまたは特定のパフォーマンス要件を持つアプリケーション)で質素である必要があるアプリケーションで使用するため。

* application/yang-data+cbor; id=name -- for use by applications that do not want to engage in SID management and that have ample resources to manage text-string-based item identifiers (e.g., applications that directly want to substitute application/ yang.data+json with a more efficient representation without any other changes); and

* アプリケーション/Yang-Data Cbor;id = name- SID管理に従事したくないアプリケーションで使用し、テキストストリングベースのアイテム識別子を管理するための十分なリソース(たとえば、アプリケーション/ yang.data jsonをより詳細に置き換えるアプリケーション他の変更なしの効率的な表現);と

* application/yang-data+cbor -- for use by more complex applications that can benefit from the increased efficiency of SID identifiers but also need to integrate databases of YANG modules before SID mappings are defined for them.

* Application/Yang-Data Cbor- SID識別子の効率の向上から利益を得ることができるより複雑なアプリケーションで使用するために、SIDマッピングが定義される前にYangモジュールのデータベースを統合する必要もあります。

All three content-types are based on the same representation mechanisms, parts of which are simply not used in the first and second cases.

3つのコンテンツタイプはすべて、同じ表現メカニズムに基づいており、その一部は最初と2番目のケースでは単に使用されていません。

How the use of one of these content-types is selected in a transfer protocol is outside the scope of this specification. The last paragraph of Section 5.2 of [RFC8040] discusses how to indicate and request the usage of specific content-types in RESTCONF. Similar mechanisms are available in the Constrained Application Protocol (CoAP) [RFC7252] using the Content-Format and Accept Options; [CORE-COMI] demonstrates specifics on how Content-Format may be used to indicate the id=sid case.

これらのコンテンツタイプのいずれかの使用が転送プロトコルで選択される方法は、この仕様の範囲外です。[RFC8040]のセクション5.2の最後の段落では、RestConfの特定のコンテンツタイプの使用方法を示して要求する方法について説明します。コンテンツフォーマットと受け入れオプションを使用して、制約付きアプリケーションプロトコル(COAP)[RFC7252]で同様のメカニズムが利用可能です。[Core-comi]は、ID = SIDケースを示すためにコンテンツフォーマットを使用する方法に関する詳細を示しています。

8. Security Considerations
8. セキュリティ上の考慮事項

The security considerations of [RFC8949] and [RFC7950] apply.

[RFC8949]および[RFC7950]のセキュリティ上の考慮事項が適用されます。

This document defines an alternative encoding for data modeled in the YANG data modeling language. As such, this encoding does not contribute any new security issues in addition to those identified for the specific protocol or context for which it is used.

このドキュメントでは、Yangデータモデリング言語でモデル化されたデータの代替エンコードを定義します。そのため、このエンコードは、特定のプロトコルまたはそれが使用されているコンテキストで特定されたものに加えて、新しいセキュリティの問題に貢献しません。

To minimize security risks, software on the receiving side SHOULD reject all messages that do not comply to the rules of this document and reply with an appropriate error message to the sender.

セキュリティリスクを最小限に抑えるために、受信側のソフトウェアは、このドキュメントのルールに準拠していないすべてのメッセージを拒否し、送信者への適切なエラーメッセージで返信する必要があります。

For instance, when the id parameter to the media type is used, it is important to properly reject identifiers of the other type to avoid scenarios where different implementations interpret a given content in different ways.

たとえば、メディアタイプへのIDパラメーターを使用する場合、異なる実装が特定のコンテンツをさまざまな方法で解釈するシナリオを回避するために、他のタイプの識別子を適切に拒否することが重要です。

When SIDs are in use, the interpretation of encoded data not only relies on having the right YANG modules but also on having the right SID mapping information. Management and evolution of that mapping information therefore requires the same care as the management and evolution of the YANG modules themselves. The procedures in [CORE-SID] are being defined with this in mind.

SIDSが使用されている場合、エンコードされたデータの解釈は、適切なYangモジュールを持つだけでなく、適切なSIDマッピング情報を持つことにも依存しています。したがって、そのマッピング情報の管理と進化には、Yangモジュール自体の管理と進化と同じケアが必要です。[Core-SID]の手順は、これを念頭に置いて定義されています。

9. IANA Considerations
9. IANAの考慮事項
9.1. Media Types Registry
9.1. メディアタイプのレジストリ

IANA has added the following media type to the "Media Types" registry [IANA.media-types].

IANAは、次のメディアタイプを「メディアタイプ」レジストリ[iana.media-types]に追加しました。

   +================+============================+===========+
   | Name           | Template                   | Reference |
   +================+============================+===========+
   | yang-data+cbor | application/yang-data+cbor | RFC 9254  |
   +----------------+----------------------------+-----------+
        

Table 2: Media Types Registry

表2:メディアタイプレジストリ

Type name: application

タイプ名:アプリケーション

Subtype name: yang-data+cbor

サブタイプ名:Yang-Data Cbor

Required parameters: N/A

必要なパラメーター:n/a

Optional parameters: id (see Section 7 of RFC 9254)

オプションのパラメーター:ID(RFC 9254のセクション7を参照)

Encoding considerations: binary (CBOR)

考慮事項のエンコード:バイナリ(CBOR)

Security considerations: see Section 8 of RFC 9254

セキュリティ上の考慮事項:RFC 9254のセクション8を参照してください

Interoperability considerations: N/A

相互運用性の考慮事項:n/a

Published specification: RFC 9254

公開された仕様:RFC 9254

Applications that use this media type: applications that need a concise and efficient representation of YANG-modeled data

このメディアタイプを使用するアプリケーション:Yangモデリングデータの簡潔で効率的な表現が必要なアプリケーション

Fragment identifier considerations: The syntax and semantics of fragment identifiers specified for "application/yang-data+cbor" is as specified for "application/cbor". (At publication of this document, there is no fragment identification syntax defined for "application/cbor".)

フラグメント識別子の考慮事項:「Application/Yang-Data Cbor」に指定されたフラグメント識別子の構文とセマンティクスは、「アプリケーション/CBOR」で指定されています。(このドキュメントの公開時には、「アプリケーション/CBOR」に対して定義されたフラグメント識別構文はありません。)

Additional information:

追加情報:

   Magic number(s):  N/A
        
   File extension(s):  N/A
        
   Macintosh file type code(s):  N/A
        

Person & email address to contact for further information: CORE WG mailing list (core@ietf.org) or IETF Applications and Real-Time Area (art@ietf.org)

詳細については、連絡先への個人およびメールアドレス:コアWGメーリングリスト(core@ietf.org)またはIETFアプリケーションとリアルタイムエリア(art@ietf.org)

Intended usage: COMMON

意図された使用法:共通

Restrictions on usage: N/A

使用に関する制限:n/a

Author: CoRE WG

著者:Core WG

Change controller: IETF

Change Controller:IETF

9.2. CoAP Content-Formats Registry
9.2. Coap Content-Formatsレジストリ

IANA has added the following Content-Formats to the "CoAP Content-Formats" subregistry, within the "Constrained RESTful Environments (CoRE) Parameters" registry [IANA.core-parameters]. The registration procedure is "Expert Review" for the 0-255 range and "IETF Review" for the 256-9999 range.

IANAは、「COAPコンテンツフォーマット」サブレジストリに次のコンテンツフォーマットを追加しました。登録手順は、0-255範囲の「専門家のレビュー」、256-9999範囲の「IETFレビュー」です。

   +=====================================+==========+=====+===========+
   | Media Type                          | Encoding | ID  | Reference |
   +=====================================+==========+=====+===========+
   | application/yang-data+cbor          | -        | 340 | RFC 9254  |
   +-------------------------------------+----------+-----+-----------+
   | application/yang-data+cbor; id=name | -        | 341 | RFC 9254  |
   +-------------------------------------+----------+-----+-----------+
   | application/yang-data+cbor; id=sid  | -        | 140 | RFC 9254  |
   +-------------------------------------+----------+-----+-----------+
        

Table 3: CoAP Content-Format Registry

表3:COAPコンテンツフォーマットレジストリ

9.3. CBOR Tags Registry
9.3. Cborタグレジストリ

IANA has allocated the following CBOR tag numbers in the "CBOR Tags" registry [IANA.cbor-tags] defined in Section 9.2 of [RFC8949].

IANAは、[RFC8949]のセクション9.2で定義されている「CBORタグ」レジストリ[IANA.CBOR-TAGS]に次のCBORタグ番号を割り当てました。

    +=====+==================+============================+===========+
    | Tag | Data Item        | Semantics                  | Reference |
    +=====+==================+============================+===========+
    | 43  | text string      | YANG bits datatype; see    | RFC 9254  |
    |     |                  | Section 6.7.               |           |
    +-----+------------------+----------------------------+-----------+
    | 44  | text string      | YANG enumeration datatype; | RFC 9254  |
    |     |                  | see Section 6.6.           |           |
    +-----+------------------+----------------------------+-----------+
    | 45  | unsigned integer | YANG identityref datatype; | RFC 9254  |
    |     | or text string   | see Section 6.10.          |           |
    +-----+------------------+----------------------------+-----------+
    | 46  | unsigned integer | YANG instance-identifier   | RFC 9254  |
    |     | or text string   | datatype; see              |           |
    |     | or array         | Section 6.13.              |           |
    +-----+------------------+----------------------------+-----------+
    | 47  | unsigned integer | YANG Schema Item           | RFC 9254  |
    |     |                  | iDentifier (SID); see      |           |
    |     |                  | Section 3.2.               |           |
    +-----+------------------+----------------------------+-----------+
        

Table 4: CBOR Tags Registry

表4:Cborタグレジストリ

10. References
10. 参考文献
10.1. Normative References
10.1. 引用文献

[IANA.cbor-tags] IANA, "Concise Binary Object Representation (CBOR) Tags", <https://www.iana.org/assignments/cbor-tags>.

[iana.cbor-tags] iana、 "Concise binary Object Lespressation(CBOR)Tags"、<https://www.iana.org/assignments/cbor-tags>。

[IANA.core-parameters] IANA, "Constrained RESTful Environments (CoRE) Parameters", <https://www.iana.org/assignments/core-parameters/>.

[iana.core-parameters] iana、「制約付きの安らかな環境(コア)パラメーター」、<https://www.iana.org/assignments/core-parameters/>。

[IANA.media-types] IANA, "Media Types", <https://www.iana.org/assignments/media-types/>.

[iana.media-types] iana、 "Media Types"、<https://www.iana.org/assignments/media-types/>。

[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>。

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC5234] Crocker、D.、ed。P. Overell、「構文仕様のためのBNFの増強:ABNF:STD 68、RFC 5234、DOI 10.17487/RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。

[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.、ed。、「Yang 1.1 Data Modeling Language」、RFC 7950、DOI 10.17487/RFC7950、2016年8月、<https://www.rfc-editor.org/info/rfc7950>。

[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>.

[RFC7951] Lhotka、L。、「Yangでモデル化されたデータのJSONエンコード」、RFC 7951、DOI 10.17487/RFC7951、2016年8月、<https://www.rfc-editor.org/info/rfc7951>。

[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 Protocol」、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>。

[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.

[RFC8259] Bray、T.、ed。、「JavaScriptオブジェクト表記(JSON)データインターチェンジ形式」、STD 90、RFC 8259、DOI 10.17487/RFC8259、2017年12月、<https://www.rfc-editor.org/info/rfc8259>。

[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>.

[RFC8610] Birkholz、H.、Vigano、C。、およびC. Bormann、「Scise Data Definition Language(CDDL):簡潔なバイナリオブジェクト表現(CBOR)およびJSONデータ構造を表現する表記規則」、RFC 8610、DOI 10.17487/RFC8610、2019年6月、<https://www.rfc-editor.org/info/rfc8610>。

[RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, June 2020, <https://www.rfc-editor.org/info/rfc8791>.

[RFC8791] Bierman、A.、Björklund、M.、およびK. Watsen、「Yang Data Structure Extensions」、RFC 8791、DOI 10.17487/RFC8791、2020年6月、<https://www.rfc-editor.org/info/rfc8791>。

[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.

[RFC8949] Bormann、C。and P. Hoffman、「Concise binary Object Lepressation(CBOR)」、STD 94、RFC 8949、DOI 10.17487/RFC8949、2020年12月、<https://www.rfc-editor.org/info/RFC8949>。

10.2. Informative References
10.2. 参考引用

[CORE-COMI] Veillette, M., Ed., van der Stok, P., Ed., Pelov, A., Bierman, A., and I. Petrov, Ed., "CoAP Management Interface (CORECONF)", Work in Progress, Internet-Draft, draft-ietf-core-comi-11, 17 January 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-11>.

[Core-comi] Veillette、M.、ed。、van der Stok、P.、ed。、Pelov、A.、Bierman、A。、およびI. Petrov、ed。、「Coap Management Interface(CoreConf)」、進行中の作業、インターネットドラフト、ドラフト-ITEF-CORE-COMI-11、2021年1月17日、<https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-11>。

[CORE-SID] Veillette, M., Ed., Pelov, A., Ed., Petrov, I., Ed., Bormann, C., and M. Richardson, "YANG Schema Item iDentifier (YANG SID)", Work in Progress, Internet-Draft, draft-ietf-core-sid-18, 18 November 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-core-sid-18>.

[Core-SID] Veillette、M.、Ed。、Pelov、A.、Ed。、Petrov、I.、Ed。、Bormann、C。、およびM. Richardson、「Yang Schema Item Identifier(Yang Sid)」、進行中の作業、インターネットドラフト、ドラフト-ITEF-CORE-SID-18、2021年11月18日、<https://datatracker.ietf.org/doc/html/draft-ietf-core-sid-18>。

[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.、ed。、ed。、Bjorklund、M.、ed。、Schoenwaelder、J.、ed。、およびA. Bierman、ed。、「ネットワーク構成プロトコル(NetConf)」、RFC 6241、DOI 10.17487/RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。

[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.、ed。、 "Common Yang Data型"、RFC 6991、DOI 10.17487/RFC6991、2013年7月、<https://www.rfc-editor.org/info/rfc6991>。

[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.

[RFC7228] Bormann、C.、Ersue、M。、およびA. Keranen、「制約ノードネットワークの用語」、RFC 7228、DOI 10.17487/RFC7228、2014年5月、<https://www.rfc-editor.org/info/rfc7228>。

[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.

[RFC7252] Shelby、Z.、Hartke、K。、およびC. Bormann、「制約付きアプリケーションプロトコル(COAP)」、RFC 7252、DOI 10.17487/RFC7252、2014年6月、<https://www.rfc-editor。org/info/rfc7252>。

[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for System Management", RFC 7317, DOI 10.17487/RFC7317, August 2014, <https://www.rfc-editor.org/info/rfc7317>.

[RFC7317] Bierman、A。およびM. Bjorklund、「システム管理のためのYangデータモデル」、RFC 7317、DOI 10.17487/RFC7317、2014年8月、<https://www.rfc-editor.org/info/rfc7317>。

[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。、「インターフェイス管理のためのYangデータモデル」、RFC 8343、DOI 10.17487/RFC8343、2018年3月、<https://www.rfc-editor.org/info/rfc8343>。

[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", RFC 8344, DOI 10.17487/RFC8344, March 2018, <https://www.rfc-editor.org/info/rfc8344>.

[RFC8344] Bjorklund、M。、「IP管理のためのYangデータモデル」、RFC 8344、DOI 10.17487/RFC8344、2018年3月、<https://www.rfc-editor.org/info/rfc8344>。

Acknowledgments

謝辞

This document has been largely inspired by the extensive work done by Andy Bierman and Peter van der Stok on [CORE-COMI]. [RFC7951] has also been a critical input to this work. The authors would like to thank the authors and contributors of these two documents.

この文書は、[Core-Comi]でAndy BiermanとPeter van Der Stokが行った広範な作業に大きく触発されています。[RFC7951]は、この作業への重要なインプットでもあります。著者は、これら2つの文書の著者と貢献者に感謝したいと思います。

The authors would also like to acknowledge the review, feedback, and comments from Ladislav Lhotka and Jürgen Schönwälder and from the Document Shepherd Marco Tiloca. Extensive comments helped us further improve the document in the IESG review process; the authors would like to call out specifically the feedback and guidance by the responsible AD Francesca Palombini and the significant improvements suggested by IESG members Benjamin Kaduk and Rob Wilton.

著者はまた、Ladislav LhotkaとJürgenSchönwälderからのレビュー、フィードバック、およびコメントを、文書羊飼いのMarco Tilocaから認めたいと考えています。広範なコメントは、IESGレビュープロセスのドキュメントをさらに改善するのに役立ちました。著者は、責任ある広告のフランチェスカ・パロビニによるフィードバックとガイダンスと、IESGメンバーのベンジャミン・カドックとロブ・ウィルトンが提案した大幅な改善を具体的に呼びたいと考えています。

Authors' Addresses

著者のアドレス

Michel Veillette (editor) Trilliant Networks Inc. 610 Rue du Luxembourg Granby Quebec J2J 2V2 Canada Email: michel.veillette@trilliantinc.com

Michel Veillette(編集者)Trilliant Networks Inc. 610 Rue du Luxembourg Granby Quebec J2J 2v2 Canada:michel.veillette@trilliantinc.com

Ivaylo Petrov (editor) Google Switzerland GmbH Brandschenkestrasse 110 CH-8002 Zurich Switzerland Email: ivaylopetrov@google.com

Ivaylo Petrov(編集者)Google Switzerland GmbH Brandschenkestrasse 110 CH-8002チューリッヒスイスメール:ivaylopetrov@google.com

Alexander Pelov Acklio 1137A avenue des Champs Blancs 35510 Cesson-Sevigne Cedex France Email: a@ackl.io

アレクサンダー・ペロフ・アックリオ1137Aアベニュー・デ・チャンピオン・ブランズ35510セッソン・セビン・セデックス・フランスメール:a@ackl.io

Carsten Bormann Universität Bremen TZI Postfach 330440 D-28359 Bremen Germany Phone: +49-421-218-63921 Email: cabo@tzi.org

Carsten BormannUniversitätBremenTziPostfach 330440 D-28359 Bremen Germany電話:49-421-218-63921メール:cabo@tzi.org

Michael Richardson Sandelman Software Works Canada Email: mcr+ietf@sandelman.ca

マイケルリチャードソンサンデルマンソフトウェアワークカナダメール:mcr ietf@sandelman.ca