Internet Engineering Task Force (IETF) M. Veillette, Ed.
Request for Comments: 9595 Trilliant Networks Inc.
Category: Standards Track A. Pelov, Ed.
ISSN: 2070-1721 IMT Atlantique
I. Petrov, Ed.
Google Switzerland GmbH
C. Bormann
Universität Bremen TZI
M. Richardson
Sandelman Software Works
July 2024
YANG Schema Item iDentifiers (YANG SIDs) are globally unique 63-bit unsigned integers used to identify YANG items. SIDs provide a more compact method for identifying those YANG items that can be used efficiently, notably in constrained environments (RFC 7228). This document defines the semantics, registration processes, and assignment processes for YANG SIDs for IETF-managed YANG modules. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned YANG SIDs.
Yang Schemaアイテム識別子（Yang Sids）は、Yangアイテムを識別するために使用されるグローバルにユニークな63ビットの署名されていない整数です。SIDSは、特に制約された環境で効率的に使用できるヤンアイテムを識別するためのよりコンパクトな方法を提供します（RFC 7228）。このドキュメントでは、IETFが管理したYangモジュールのYang Sidsのセマンティクス、登録プロセス、および割り当てプロセスを定義します。これらのプロセスの実装を有効にするために、このドキュメントは、割り当てられたYang Sidsの持続および公開に使用されるファイル形式も定義します。
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/rfc9595.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9595で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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ライセンステキストを含める必要があります。
1. Introduction
1.1. Terminology and Notation
2. Objectives
2.1. Technical Objectives
2.2. Module Evolution and Versioning
2.3. Solution Components and Derived Objectives
2.4. Parties and Roles
3. ".sid" File Lifecycle
4. ".sid" File Format
5. Security Considerations
6. IANA Considerations
6.1. YANG Namespace Registration
6.2. ".sid" File Format Module Registration
6.3. New IANA Registry: YANG-SID Mega-Ranges
6.3.1. Structure
6.3.2. Allocation Policy
6.3.2.1. First Allocation
6.3.2.2. Consecutive Allocations
6.3.3. Initial Contents of the Registry
6.4. New IANA Registry: IETF YANG-SID Ranges
6.4.1. Structure
6.4.2. Allocation Policy
6.4.3. Publication of the ".sid" File
6.4.4. Initial Contents of the Registry
6.5. New IANA Registry: IETF YANG-SID Modules
6.5.1. Structure
6.5.2. Allocation Policy
6.5.3. Recursive Allocation of YANG SIDs at Document Adoption
6.5.4. Initial Contents of the Registry
6.6. Media Type and Content-Format Registration
6.6.1. Media Type application/yang-sid+json
6.6.2. CoAP Content-Format
7. References
7.1. Normative References
7.2. Informative References
Appendix A. ".sid" File Example
Appendix B. SID Autogeneration
Appendix C. ".sid" File Lifecycle
C.1. ".sid" File Creation
C.2. ".sid" File Update
Appendix D. Keeping a ".sid" File in a YANG Instance Data File
Acknowledgments
Contributors
Authors' Addresses
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 names. To allow the implementation of data models defined in YANG in constrained devices [RFC7228] and constrained networks, a more compact method to identify YANG items is required. This compact identifier, called the YANG Schema Item iDentifier or YANG SID (or simply SID in this document and when the context is clear), is encoded using a 63-bit unsigned integer. The limitation to 63-bit unsigned integers allows SIDs to be manipulated more easily on platforms that might otherwise lack 64-bit unsigned arithmetic. The loss of a single bit of range is not significant, given the size of the remaining space.
Yang [RFC7950]で定義されているアイテムの一部は、一意の識別子の使用を必要とします。ネットワーク構成プロトコル（NetConf）[RFC6241]とRestConf [RFC8040]の両方で、これらの識別子は名前を使用して実装されています。制約付きデバイス[RFC7228]および制約されたネットワークでYangで定義されたデータモデルの実装を許可するには、Yangアイテムを識別するためのよりコンパクトな方法が必要です。Yang Schemaアイテム識別子またはYang Sidと呼ばれるこのコンパクト識別子（または、このドキュメントの単にSIDおよびコンテキストが明確な場合）は、63ビットの符号なし整数を使用してエンコードされます。63ビットの署名されていない整数への制限により、SIDは、64ビットの符号なし算術を欠く可能性のあるプラットフォームでより簡単に操作できます。残りのスペースのサイズを考えると、単一のビットの範囲の損失は有意ではありません。
The following items are identified using SIDs:
次の項目は、SIDSを使用して識別されます。
* identities
* アイデンティティ
* data nodes (note: including those nodes defined by the 'rc:yang-data' extension [RFC8040] and the 'sx:structure' extension [RFC8791])
* データノード（注：「rc：yang-data」拡張[RFC8040]および「SX：構造」拡張[RFC8791]によって定義されたノードを含む））
* remote procedure calls (RPCs) and associated input(s) and output(s)
* リモートプロシージャコール（RPC）および関連する入力と出力
* actions and associated input(s) and output(s)
* アクションと関連する入力と出力
* notifications and associated information
* 通知と関連情報
* YANG modules and features
* Yangモジュールと機能
It is possible that some protocols will use only a subset of the assigned SIDs; for example, for protocols other than NETCONF [RFC6241] that provide access to YANG-modeled data, such as [CORE-COMI], the transport of YANG module SIDs might be unnecessary. Other protocols might need to be able to transport this information -- for example, protocols related to discovery such as the Constrained YANG Module Library [YANG-LIBRARY].
一部のプロトコルでは、割り当てられたSIDのサブセットのみを使用する可能性があります。たとえば、[Core-Comi]などのYangモデルのデータへのアクセスを提供するNetConf [RFC6241]以外のプロトコルの場合、YangモジュールSIDの輸送は不要です。他のプロトコルでは、この情報を輸送できる必要がある場合があります。たとえば、制約付きYangモジュールライブラリ[Yang-Library]などの発見に関連するプロトコルなどです。
SIDs are globally unique integers. A registration system is used in order to guarantee their uniqueness. SIDs are registered in blocks called "SID ranges". Once they are considered "stable", SIDs are assigned permanently. Items introduced by a new revision of a YANG module are added to the list of SIDs already assigned. This is discussed in more detail in Section 2.
SIDはグローバルにユニークな整数です。登録システムは、独自性を保証するために使用されます。SIDは、「Sid Ranges」と呼ばれるブロックに登録されています。それらが「安定」と見なされると、SIDは永続的に割り当てられます。Yangモジュールの新しい改訂によって導入されたアイテムは、すでに割り当てられているSIDのリストに追加されます。これについては、セクション2で詳しく説明します。
The assignment of SIDs to YANG items is usually automated as discussed in Appendix B, which also discusses some cases where manual interventions may be appropriate.
YangアイテムへのSIDの割り当ては、通常、付録Bで説明したように自動化されます。これについては、手動介入が適切である場合もあります。
Section 3 provides more details about the registration processes for YANG modules and associated SIDs. To enable the implementation of these processes, Section 4 defines a standard file format used to store and publish SIDs.
セクション3では、Yangモジュールと関連するSIDの登録プロセスの詳細について説明します。これらのプロセスの実装を有効にするために、セクション4では、SIDSの保存と公開に使用される標準ファイル形式を定義します。
IETF-managed YANG modules that need to allocate SIDs will use the IANA mechanisms specified in this document. See Section 6 for details. YANG modules created by other parties allocate SID ranges using the IANA allocation mechanisms via Mega-Ranges (see Section 6.3); within the Mega-Range allocation, those other parties are free to make up their own mechanism.
SIDを割り当てる必要があるIETF管理Yangモジュールは、このドキュメントで指定されたIANAメカニズムを使用します。詳細については、セクション6を参照してください。他の当事者によって作成されたYangモジュールは、メガレンジを介してIANA割り当てメカニズムを使用してSID範囲を割り当てます（セクション6.3を参照）。メガレンジの割り当ての中で、他の関係者は自由に独自のメカニズムを補うことができます。
Among other uses, YANG SIDs are particularly useful for obtaining a compact encoding for YANG-CBOR [RFC9254]. At the time of writing, a tool for automated ".sid" file generation is available as part of the open-source project PYANG [PYANG].
他の用途の中でも、Yang Sidsは、Yang-Cbor [RFC9254]のコンパクトなエンコードを取得するのに特に役立ちます。執筆時点では、自動化された「.SID」ファイル生成のツールは、オープンソースプロジェクトPyang [Pyang]の一部として利用できます。
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 [BCP14] (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、[BCP14]（RFC 2119）（RFC 8174）で説明されているように解釈されます。
The following terms are defined in [RFC7950]:
次の用語は[RFC7950]で定義されています。
* action
* アクション作用動作行動活動働き行い仕業仕草立ち回り仕打ち
* feature
* 特徴フィーチャ特集特色本領面相似る
* module
* モジュールモデュール
* notification
* 通知お知らせ届出通達届申告届け催告告達禀告
* RPC
* RPC
* schema node
* スキーマノード
* schema tree
* スキーマツリー
* submodule
* サブモジュール
This specification also makes use of the following terminology:
この仕様では、次の用語も使用します。
item:
アイテム：
A schema node, an identity, a module, or a feature defined using the YANG modeling language.
Yangモデリング言語を使用して定義されたスキーマノード、ID、モジュール、または機能。
YANG Schema Item iDentifier (YANG SID or simply SID):
Yangスキーマアイテム識別子（Yang Sidまたは単にSID）：
Unsigned integer used to identify different YANG items (cf. Section 3.2 of [RFC9254]).
異なるYangアイテムを識別するために使用される署名のない整数（[RFC9254]のセクション3.2を参照）。
YANG name:
ヤン名：
Text string used to identify different YANG items (cf. Section 3.3 of [RFC9254]).
さまざまなヤンアイテムを識別するために使用されるテキスト文字列（[RFC9254]のセクション3.3を参照）。
The overriding objective of the SID assignment and registration system is to ensure global interoperability of protocols that employ SIDs in order to communicate about data modeled in YANG. This objective poses certain requirements on the stability of SIDs while at the same time not hindering active evolution of the YANG modules the SIDs are intended to support.
SIDの割り当ておよび登録システムの最優先の目的は、Yangでモデル化されたデータについて通信するためにSIDを使用するプロトコルのグローバルな相互運用性を確保することです。この目的は、SIDの安定性に特定の要件を提起しますが、同時にSIDSがサポートすることを目的としているYangモジュールの積極的な進化を妨げません。
Additional objectives include:
追加の目的は次のとおりです。
* enabling the developer of a YANG module to also be the originating entity for the SIDs pertaining to that module.
* Yangモジュールの開発者が、そのモジュールに関連するSIDの発信元のエンティティでもあることを可能にします。
* making it easy for YANG developers to obtain SIDs.
* Yang開発者がSIDを簡単に入手できるようにします。
* enabling other developers to define SIDs for a module where the developer of the module is not interested in assigning the SIDs.
* 他の開発者がモジュールの開発者がSIDSの割り当てに関心がないモジュールのSIDを定義できるようにします。
* keeping an assignment regime that keeps short SIDs (2..4 bytes) readily available for the applications that would benefit from them while at the same time employing the vast 63-bit SID space to facilitate permissionless actions.
* 短いSID（2..4バイト）を維持する課題体制を維持し、それらの恩恵を受けると同時に、広大な63ビットSIDスペースを採用して、許可のないアクションを促進します。
* enabling multiple entities to provide services that support the assignment of SIDs.
* 複数のエンティティがSIDの割り当てをサポートするサービスを提供できるようにします。
* maintaining some locality in the assignment of SIDs so the efficiencies of the SID delta mechanism can be fully employed.
* SIDの割り当てにある程度の地域を維持するため、SIDデルタメカニズムの効率を完全に採用できるようにします。
* enabling various software components to operate in terms of SIDs without having complete information about other parties in the communication process.
* コミュニケーションプロセスの他の関係者に関する完全な情報を持たずに、さまざまなソフトウェアコンポーネントがSIDの観点から動作できるようにします。
While IANA ultimately maintains the registries that govern SIDs for IETF-defined modules, various support tools (such as, at the time of writing, the YANG Catalog [yangcatalog]) need to provide the support to enable SID assignment and use for modules still in IETF development. Developers of open-source or proprietary YANG modules also need to be able to serve as such entities autonomously, possibly forming alliances independent of the IETF, while still fitting in the overall SID number space managed by IANA. Obviously, this process has a number of parallels to the management of IP addresses but is also very different.
IANAは最終的にIETF定義モジュールのSIDSを管理するレジストリを維持していますが、さまざまなサポートツール（執筆時点で、Yangカタログ[Yangcatalog]など）は、SIDの割り当てとモジュールの使用を可能にするためのサポートを提供する必要があります。IETF開発。オープンソースまたは独自のYangモジュールの開発者は、IETFとは無関係にアライアンスを形成しながら、IANAが管理する全体的なSID番号スペースにまだ適合しながら、自律的にそのようなエンティティとして機能することができる必要があります。明らかに、このプロセスにはIPアドレスの管理と多くの類似点がありますが、非常に異なっています。
As discussed in the Introduction, SIDs are intended as globally unique (unsigned) integers.
紹介で説明したように、SIDSはグローバルにユニークな（署名されていない）整数として意図されています。
Specifically, this means that:
具体的には、これは次のことを意味します。
*Objective 1* (MUST):
*目的1*（必須）：
Any 63-bit unsigned integer either (1) is unassigned as a SID or (2) immutably maps to EXACTLY one YANG name. Only the transition from unassigned to that immutable mapping is defined.
（1）の63ビットの符号なし整数は、SIDとして割り当てられていません。未割り当てから不変のマッピングへの移行のみが定義されています。
This enables a recipient of a data structure employing SIDs to translate them into the globally meaningful YANG names that the existing encodings of YANG data such as YANG-XML [RFC7950] and YANG-JSON [RFC7951] employ today.
これにより、SIDSを使用しているデータ構造の受信者が、Yang-XML [RFC7950]やYang-Json [RFC7951]などのYangデータの既存のエンコーディングが今日採用されているYangデータの既存のエンコーディングに変換できるようになります。
The term "YANG name" is not defined outside this document, and YANG has a complex system of names and entities that can have those names. Instead of defining the term technically, this set of objectives uses it in such a way that the overall objectives of YANG SID can be achieved.
「Yang Name」という用語は、このドキュメントの外で定義されていません。Yangには、それらの名前を持つことができる複雑な名前とエンティティのシステムがあります。この用語を技術的に定義する代わりに、この一連の目的は、ヤンシドの全体的な目的を達成できるようにそれを使用します。
A desirable objective is that:
望ましい目的は次のとおりです。
*Objective 2* (SHOULD):
*目的2*（必要）：
Any YANG name in active use has one SID assigned.
アクティブに使用しているYangの名前には、1つのSIDが割り当てられています。
This means that:
この意味は：
1. There should not be YANG names without SIDs assigned.
1. シドが割り当てられていないヤンの名前はありません。
2. YANG names should not have multiple SIDs assigned.
2. Yangの名前には、複数のSIDが割り当てられてはいけません。
These objectives are unattainable in full, because YANG names are not necessarily born with a SID assignment and because entirely autonomous entities might decide to assign SIDs for the same YANG name without communicating ("like ships in the night"). Note that as long as this autonomy is maintained, any single observer will have the impression that Objective 2 is attained. Only when entities that have acted autonomously start communicating will a deviation be observed.
ヤンの名前は必ずしもSIDの割り当てで生まれているわけではなく、完全に自律的なエンティティがコミュニケーションせずに同じヤン名にSIDを割り当てることを決定する可能性があるため、これらの目的は完全に達成できません。この自律性が維持されている限り、単一のオブザーバーは目的2が達成されるという印象を受けることに注意してください。自律的に行動し始めたエンティティが通信を開始した場合にのみ、偏差が観察されます。
YANG modules evolve (see Section 11 of [RFC7950] and Section 4.27 of RFC 8407 [BCP216]). The technical objectives listed above are stated in terms that are independent of this evolution.
Yangモジュールは進化します（[RFC7950]のセクション11を参照し、RFC 8407 [BCP216]のセクション4.27を参照）。上記の技術的な目的は、この進化に依存しない用語で述べられています。
However, some modules are still in a very fluid state, and the assignment of permanent SIDs to the YANG names created in them is less desirable. This is true not only for new modules but also for emerging new revisions of existing stable modules.
ただし、一部のモジュールはまだ非常に流動的な状態にあり、それらに作成されたヤン名への永続的なSIDの割り当てはあまり望ましくありません。これは、新しいモジュールだけでなく、既存の安定したモジュールの新たな新しい改訂にも当てはまります。
*Objective 3* (MUST):
*目的3*（必須）：
The SID management system is independent of any module versioning.
SID管理システムは、モジュールのバージョンに依存しないものです。
A registration system is used in order to guarantee the uniqueness of SIDs. To be able to provide some autonomy in allocation (and avoid information disclosure where it is not desirable), SIDs are registered in blocks called "SID ranges".
SIDの独自性を保証するために、登録システムが使用されます。割り当てに何らかの自律性を提供できる（そして、それが望ましくない場合は情報の開示を避ける）ために、SIDは「Sid Ranges」と呼ばれるブロックに登録されます。
SIDs are assigned permanently.
SIDは永久に割り当てられます。
Items introduced by a new revision of a YANG module are added to the list of SIDs already assigned.
Yangモジュールの新しい改訂によって導入されたアイテムは、すでに割り当てられているSIDのリストに追加されます。
In the YANG development process, we can discern a number of parties that are concerned with a YANG module:
ヤン開発プロセスでは、ヤンモジュールに関心のある多くの関係者を識別できます。
module controller:
モジュールコントローラー：
The owner of the YANG module, i.e., the controller of the module's evolution.
Yangモジュールの所有者、つまりモジュールの進化のコントローラー。
registration entity:
登録エンティティ：
The controller of the module namespace, specifically also of the prefixes that are in common use. (This is not a required party.)
モジュール名空間のコントローラー、特に一般的に使用されているプレフィックスのコントローラー。（これは必須の当事者ではありません。）
module repository:
モジュールリポジトリ：
An entity that supplies modules to module users. This can be an "official" entity (e.g., IANA for IETF modules) or an "unofficial" entity (e.g., the YANG Catalog [yangcatalog]). Not all repositories are in a position to act as a registry, i.e., as a permanent record for the information they supply; these repositories need to recur to module owners as a stable source.
モジュールユーザーにモジュールを提供するエンティティ。これは、「公式」エンティティ（IETFモジュールなどのIANA）または「非公式」エンティティ（Yangカタログ[Yangcatalog]など）です。すべてのリポジトリがレジストリとして行動する立場にあるわけではありません。つまり、彼らが提供する情報の恒久的な記録として。これらのリポジトリは、安定したソースとしてモジュール所有者に再発する必要があります。
module user:
モジュールユーザー：
An entity that uses a module, after obtaining it from the module controller or a module repository.
モジュールコントローラーまたはモジュールリポジトリから取得した後、モジュールを使用するエンティティ。
This set of parties needs to evolve to take on the additional roles that the SID assignment process requires:
この一連の当事者は、SIDの割り当てプロセスに必要な追加の役割を引き受けるために進化する必要があります。
SID assigner:
sid割り当て：
An entity that assigns SIDs for a module. Objective 2 aims at having only one SID assigner for each module. SID assigners preferably stay the same over a module development process; however, this specification provides ".sid" files to ensure an organized handover.
モジュールにSIDSを割り当てるエンティティ。目的2は、各モジュールにSID割り当て者が1つしかないことを目的としています。SIDの割り当て者は、モジュール開発プロセスを介して同じままであることが望ましい。ただし、この仕様は、整理されたハンドオーバーを確保するための「.SID」ファイルを提供します。
SID range registry:
SIDレンジレジストリ：
An entity that supplies a SID assigner with SID ranges that it can use in assigning SIDs for a module. (In this specification, there is a structure with Mega-Ranges and individual SID ranges; this is not relevant here.)
SIDの割り当て者にSIDの範囲を提供するエンティティは、モジュールにSIDSの割り当てに使用できる範囲です。（この仕様には、巨大範囲と個々のSID範囲の構造があります。これはここでは関連していません。）
SID repository:
SIDリポジトリ：
An entity that supplies SID assignments to SID users, usually in the form of a ".sid" file.
通常は「.sid」ファイルの形でSIDユーザーにSIDの割り当てを提供するエンティティ。
SID user:
SIDユーザー：
The module user that uses the SIDs provided by a SID assigner for a YANG module. SID users need to find SID assigners (or at least their SID assignments).
YangモジュールにSID割り当て者が提供するSIDを使用するモジュールユーザー。SIDユーザーは、SID割り当て者（または少なくともSIDの割り当て）を見つける必要があります。
As the use of SIDs with YANG data models is introduced, the distribution of the SID roles to the existing parties for a YANG module will evolve.
Yangデータモデルを使用したSIDSの使用が導入されると、Yangモジュールの既存の当事者へのSIDの役割の分布が進化します。
The desirable end state of this evolution is shown in Table 1.
この進化の望ましい最終状態を表1に示します。
+====================+======================================+
| Role | Party |
+====================+======================================+
| SID assigner | module developer |
+--------------------+--------------------------------------+
| SID range registry | (as discussed in this specification) |
+--------------------+--------------------------------------+
| SID repository | module repository |
+--------------------+--------------------------------------+
| SID user | module user (naturally) |
+--------------------+--------------------------------------+
Table 1: Roles and Parties: Desired End State
表1：役割とパーティー：希望する終了状態
This grouping of roles and parties puts the module developer in a position where it can achieve the objectives laid out in this section (a "type-1", "SID-guiding" module controller). (While a third party might theoretically assign additional SIDs and conflict with Objective 2, there is very little reason to do so if ".sid" files are always provided by the module developer with the module.)
この役割とパーティーのグループ化により、モジュール開発者は、このセクションでレイアウトされた目標（「タイプ1」、「SIDガイド」モジュールコントローラー）を達成できる位置に置かれます。（サードパーティは、理論的には追加のSIDと対象2との競合を割り当てる可能性がありますが、「.SID」ファイルがモジュール開発者によって常にモジュールを提供される場合、そうする理由はほとんどありません。）
The rest of this section is concerned with the transition to this end state.
このセクションの残りの部分は、この最終状態への移行に関するものです。
For existing modules, there is no ".sid" file. The entity that stands in as the SID assigner is not specified. This situation has the highest potential for conflict with Objective 2.
既存のモジュールの場合、「.sid」ファイルはありません。SID割り当て者として立つエンティティは指定されていません。この状況は、目標2との対立の可能性が最も高い。
Similarly, for new module development, the module owner may not have heard about SIDs or may not be interested in assigning them (e.g., because of lack of software or procedures within their organization).
同様に、新しいモジュールの開発のために、モジュールの所有者はSIDについて聞いていないか、それらの割り当てに関心がないかもしれません（たとえば、組織内のソフトウェアや手順の不足のため）。
For these two cases (which we will collectively call "type-3", "SID-oblivious" module controller), module repositories can act as a mediator, giving SID users access to a SID assigner that is carefully chosen to be a likely choice by other module repositories as well, maximizing the likelihood of achieving Objective 2.
これらの2つのケース（「タイプ3」、「SID-Oblivious」モジュールコントローラーを集合的に呼びます）では、モジュールリポジトリはメディエーターとして機能し、SIDユーザーがSIDの割り当て者にアクセスできるようにします。他のモジュールリポジトリによっても、目標2を達成する可能性を最大化します。
If a module controller has heard about SIDs but is not assigning them yet, it can designate a SID assigner instead. This can lead to a stable, unique set of SID assignments being provided indirectly by a ("type-2", "SID-aware") module developer. Entities offering designated SID assigner services could make these available in an easy-to-use way, e.g., via a web interface.
モジュールコントローラーがSIDSについて聞いたが、まだ割り当てられていない場合、代わりにSID割り当て者を指定できます。これにより、（「タイプ2」、「SID-Aware」）モジュール開発者によって間接的に提供される安定した一意のSID割り当てのセットにつながる可能性があります。指定されたSID Assignerサービスを提供するエンティティは、Webインターフェイスを介して、これらを使いやすい方法で利用できるようにすることができます。
The entity acting as a SID assigner minimally needs to record the SID range it uses for the SID assignment. If the SID range registry employed can record the module name and revision and if the assignment processes (including the software used) are stable, the SID assigner can theoretically reconstruct its assignments, but this could invite implementation bugs.
SIDの割り当て者として行動するエンティティは、SIDの割り当てに使用するSID範囲を記録する必要があります。採用されているSID範囲レジストリがモジュール名と改訂を記録でき、割り当てプロセス（使用したソフトウェアを含む）が安定している場合、SIDアサイナーは理論的にその割り当てを再構築できますが、これにより実装のバグを招待できます。
SID assigners attending to a module in development (not yet stable) need to decide whether SIDs for a new revision are reassigned from scratch ("clean slate") or use existing assignments from a previous revision as a base, only assigning new SIDs for new names. Once a module is declared stable, its SID assignments SHOULD be declared stable as well (except that, for existing YANG modules, some review may be needed before this is done).
開発中のモジュールに参加するSIDアサイナー（まだ安定していない）新しい改訂のSIDがゼロから再割り当てされているか（「クリーンスレート」）か、以前の改訂から既存の割り当てをベースとして使用するかを決定する必要があります。名前。モジュールが安定していると宣言されると、SIDの割り当ても安定していると宣言する必要があります（既存のYangモジュールの場合、これが完了する前にいくつかのレビューが必要になる場合があります）。
This specification does not further discuss how mediating entities such as designated SID assigners or SID repositories could operate; instead, it supplies objectives for their operation.
この仕様では、指定されたSID割り当てやSIDリポジトリなどのメディーティングエンティティがどのように動作するかについてはさらに説明しません。代わりに、操作の目的を提供します。
YANG is a language designed to model data accessed using one of the compatible protocols (e.g., NETCONF [RFC6241], RESTCONF [RFC8040], and the CoAP Management Interface (CORECONF) [CORE-COMI]). A YANG module defines hierarchies of data, including configuration, state data, RPCs, actions, and notifications.
Yangは、互換性のあるプロトコルのいずれかを使用してアクセスしたデータをモデル化するように設計された言語です（例：NetConf [RFC6241]、RestConf [RFC8040]、およびCOAP管理インターフェイス（CoreConf）[Core-Comi]）。Yangモジュールは、構成、状態データ、RPC、アクション、通知など、データの階層を定義します。
Many YANG modules are not created in the context of constrained applications. YANG modules can be implemented using NETCONF [RFC6241] or RESTCONF [RFC8040] without the need to assign SIDs.
多くのヤンモジュールは、制約されたアプリケーションのコンテキストでは作成されていません。Yangモジュールは、SIDSを割り当てる必要なく、NetConf [RFC6241]またはRestConf [RFC8040]を使用して実装できます。
As needed, authors of YANG modules can assign SIDs to their YANG modules. In order to do that, they should first obtain a SID range from a registry and use that range to assign or generate SIDs to items in their YANG module. The assignments can then be stored in a ".sid" file. For an example of how this could be achieved, please refer to Appendix C.
必要に応じて、Yangモジュールの著者はYangモジュールにSIDを割り当てることができます。それを行うには、まずレジストリからSID範囲を取得し、その範囲を使用してYangモジュールのアイテムにSIDを割り当てたり生成したりする必要があります。割り当ては「.sid」ファイルに保存できます。これを達成する方法の例については、付録Cを参照してください。
Items introduced by a new revision of a YANG module are added to the list of SIDs already assigned. When this is done during the development of a new protocol document, it may be necessary to make provisional assignments. They may get changed, revised, or withdrawn during the development of a new standard. These provisional assignments are marked with a status of "unstable", so that they can be removed and the SID number possibly reassigned for a different YANG schema name/path later in the development process. When the specification is advanced to a final document, the assignment is marked with a status of "stable". During a period of development starting from a published specification, two variants of the ".sid" file should be made available by the tooling involved in that development: (1) a "published" ".sid" file with the existing stable SID assignments only (which the development effort should keep stable), as well as (2) an "unpublished" ".sid" file that also contains the unstable SID assignments.
Yangモジュールの新しい改訂によって導入されたアイテムは、すでに割り当てられているSIDのリストに追加されます。これが新しいプロトコルドキュメントの開発中に行われた場合、暫定的な割り当てを行う必要がある場合があります。それらは、新しい基準の開発中に変更、改訂、または撤回される場合があります。これらの暫定的な割り当てには、「不安定」のステータスがマークされているため、削除でき、SID番号は開発プロセスの後半で別のヤンスキーマ名/パスに対して再割り当てされる可能性があります。仕様が最終文書に進出されると、割り当てには「安定」のステータスがマークされます。公開された仕様から始まる開発期間中、その開発に関係するツールによって「.SID」ファイルの2つのバリアントを使用できるようにする必要があります。（2）不安定なSID割り当ても含まれる「未発表」の.SID "ファイルと同様に（開発の努力が安定しているはずです）。
Registration of the ".sid" file associated with a YANG module is optional but recommended; doing so will promote interoperability between devices and avoid duplicate allocation of SIDs to a single YANG module. Different registries might have different requirements for the registration and publication of the ".sid" files. For a diagram of one possible scenario, please refer to the activity diagram shown in Figure 4 in Appendix C.
Yangモジュールに関連付けられた「.SID」ファイルの登録はオプションですが、推奨されます。そうすることで、デバイス間の相互運用性を促進し、SIDの1つのYangモジュールへの重複割り当てを避けます。さまざまなレジストリには、「.SID」ファイルの登録と公開に関する要件が異なる場合があります。可能なシナリオの1つの図については、付録Cの図4に示すアクティビティ図を参照してください。
Each time a YANG module, one or more of its imported modules, or one or more of its included submodules are updated, a new ".sid" file MAY be created if the new or updated items will need SIDs. All the SIDs present in a previous version of the ".sid" file that was in active use MUST be present in the new version as well. The creation of this new version of the ".sid" file SHOULD be performed using an automated tool.
Yangモジュール、1つ以上のインポートされたモジュール、または1つ以上の含まれたサブモジュールが更新されるたびに、新しいアイテムまたは更新されたアイテムにSIDSが必要な場合、新しい「.SID」ファイルが作成される場合があります。アクティブに使用されていた「.SID」ファイルの以前のバージョンに存在するすべてのSIDは、新しいバージョンにも存在する必要があります。この新しいバージョンの「.SID」ファイルの作成は、自動化されたツールを使用して実行する必要があります。
If a new revision requires more SIDs than initially allocated, a new SID range MUST be added to the 'assignment-range' item as defined in Section 4. These extra SIDs are used for subsequent assignments.
新しい改訂で最初に割り当てられたよりも多くのSIDが必要な場合、セクション4で定義されているように、新しいSID範囲を「割り当て範囲」項目に追加する必要があります。これらの追加のSIDは、後続の割り当てに使用されます。
For an example of this update process, see the activity diagram shown in Figure 5 in Appendix C.
この更新プロセスの例については、付録Cの図5に示すアクティビティ図を参照してください。
".sid" files are used to persist and publish SIDs assigned to the different YANG items in a specific YANG module.
「.SID」ファイルは、特定のYangモジュール内の異なるYangアイテムに割り当てられたSIDを持続および公開するために使用されます。
The following tree diagram [BCP215] provides an overview of the data model:
次のツリー図[BCP215]は、データモデルの概要を示しています。
module: ietf-sid-file
structure sid-file:
+-- module-name yang:yang-identifier
+-- module-revision? revision-identifier
+-- sid-file-version? sid-file-version-identifier
+-- sid-file-status? enumeration
+-- description? string
+-- dependency-revision* [module-name]
| +-- module-name yang:yang-identifier
| +-- module-revision revision-identifier
+-- assignment-range* [entry-point]
| +-- entry-point sid
| +-- size uint64
+-- item* [namespace identifier]
+-- status? enumeration
+-- namespace enumeration
+-- identifier union
+-- sid sid
Figure 1: YANG Tree for 'ietf-sid-file'
図1：「IETF-SID-FILE」のYang Tree
The following YANG module defines the structure of ".sid" files. Encoding is performed in JSON [STD90] using the rules defined in [RFC7951]. This module imports 'ietf-yang-types' [RFC6991] and 'ietf-yang-structure-ext' [RFC8791]. It also references [STD68], [RFC7950], and [BCP216].
次のYangモジュールは、「.sid」ファイルの構造を定義します。エンコードは、[RFC7951]で定義されたルールを使用して、JSON [STD90]で実行されます。このモジュールは、「IETF-YANG-TYPES」[RFC6991]および「IETF-YANG-STRUCTURE-EXT」[RFC8791]をインポートします。また、[std68]、[rfc7950]、および[bcp216]を参照します。
<CODE BEGINS> file "ietf-sid-file@2024-07-31.yang"
module ietf-sid-file {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-sid-file";
prefix sid;
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-yang-structure-ext {
prefix sx;
reference
"RFC 8791: YANG Data Structure Extensions";
}
organization
"IETF CORE Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/core/>
WG List: <mailto:core@ietf.org>
Editor: Michel Veillette
<mailto:michel.veillette@trilliant.com>
Editor: Andy Bierman
<mailto:andy@yumaworks.com>
Editor: Alexander Pelov
<mailto:alexander.pelov@imt-atlantique.fr>
Editor: Ivaylo Petrov
<mailto:ivaylopetrov@google.com>";
description
"This module defines the structure of the '.sid' files.
Each '.sid' file contains the mapping between each
string identifier defined by a YANG module and a
corresponding numeric value called a YANG SID.
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 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
Copyright (c) 2024 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9595; see
the RFC itself for full legal notices.";
revision 2024-07-31 {
description
"Initial revision.";
reference
"RFC 9595: YANG Schema Item iDentifier (YANG SID)";
}
typedef revision-identifier {
type string {
pattern '[0-9]{4}-[0-9]{2}-[0-9]{2}';
}
description
"Represents a date in YYYY-MM-DD format.";
}
typedef sid-file-version-identifier {
type uint32;
description
"Represents the version of a '.sid' file.";
}
typedef sid {
type uint64 {
range "0..9223372036854775807";
}
description
"YANG Schema Item iDentifier.";
reference
"RFC 9595: YANG Schema Item iDentifier (YANG SID)";
}
typedef schema-node-path {
type string {
pattern
'/[a-zA-Z_][a-zA-Z0-9\-_.]*:[a-zA-Z_][a-zA-Z0-9\-_.]*' +
'(/[a-zA-Z_][a-zA-Z0-9\-_.]*(:[a-zA-Z_][a-zA-Z0-9\-_.]*)?)*';
}
description
"A schema-node path is an absolute YANG schema-node
identifier as defined by the YANG ABNF rule
'absolute-schema-nodeid', except that module names are used
instead of prefixes.
This string additionally follows the following rules:
- The leftmost (top-level) data node name is always in the
namespace-qualified form.
- Any subsequent schema-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. No predicates are allowed.";
reference
"RFC 5234 (STD 68): Augmented BNF for Syntax Specifications:
ABNF
RFC 7950: The YANG 1.1 Data Modeling Language,
Section 6.5: Schema Node Identifier";
}
sx:structure sid-file {
uses sid-file-contents;
}
grouping sid-file {
description
"A grouping that contains a YANG container
representing the file structure of a '.sid' file.";
container sid-file {
description
"A wrapper container that together with the 'sx:structure'
extension marks the YANG data structures inside as not
being intended to be implemented as part of a
configuration datastore or as an operational state within
the server.";
uses sid-file-contents;
}
}
grouping sid-file-contents {
description
"A grouping that defines the contents of a container that
represents the file structure of a '.sid' file.";
leaf module-name {
type yang:yang-identifier;
mandatory true;
description
"Name of the YANG module associated with this
'.sid' file.";
}
leaf module-revision {
type revision-identifier;
description
"Revision of the YANG module associated with this '.sid'
file.
This leaf is not present if no revision statement is
defined in the YANG module.";
}
leaf sid-file-version {
type sid-file-version-identifier;
default 0;
description
"Optional leaf that specifies the version number of the
'.sid' file. '.sid' files and the version sequence are
specific to a given YANG module revision. This number
starts at zero when there is a new YANG module revision
and increases monotonically. This number can distinguish
updates to the '.sid' file - for instance, as the result
of new processing or reported errata.";
}
leaf sid-file-status {
type enumeration {
enum unpublished {
description
"This '.sid' file is unpublished (BCP 216) and is
also called a work-in-progress or workfile.
This may be when it accompanies an unpublished YANG
module or when only the '.sid' file itself is
unpublished.
The 'item' list MAY contain entries with a status
value of 'unstable'.";
reference
"RFC 8407 (BCP 216): Guidelines for Authors and
Reviewers of Documents Containing
YANG Data Models";
}
enum published {
description
"This '.sid' file is published. This status
applies to '.sid' files for published YANG modules.
The 'item' list MUST NOT contain entries with a
status value of 'unstable'.";
}
}
default "published";
description
"Optional leaf that specifies the status of the
'.sid' file.";
}
leaf description {
type string;
description
"Free-form meta-information about the generated file. It
might include a '.sid' file generation tool and time,
among other things.";
}
list dependency-revision {
key "module-name";
description
"Information about the revision used during the
'.sid' file generation of each dependency, i.e., each
YANG module that the YANG module associated with this
'.sid' file imported.";
leaf module-name {
type yang:yang-identifier;
description
"YANG module name of this dependency.";
}
leaf module-revision {
type revision-identifier;
mandatory true;
description
"Revision of the YANG module of this dependency.";
}
}
list assignment-range {
key "entry-point";
description
"YANG-SID Range(s) allocated to the YANG module
identified by 'module-name' and 'module-revision'.
- The first available value in the YANG-SID Range is
'entry-point', and the last available value in the
range is ('entry-point' + size - 1).
- The YANG-SID Ranges specified by all
'assignment-range' entries MUST NOT overlap.";
leaf entry-point {
type sid;
description
"Lowest YANG SID available for assignment.";
}
leaf size {
type uint64;
mandatory true;
description
"Number of YANG SIDs available for assignment.";
}
}
list item {
key "namespace identifier";
unique "sid";
description
"Each entry within this list defines the mapping between
a YANG item string identifier and a YANG SID. This list
MUST include a mapping entry for each YANG item defined
by the YANG module identified by 'module-name' and
'module-revision'.";
leaf status {
type enumeration {
enum stable {
value 0;
description
"This SID allocation has been published as the
stable allocation for the given namespace and
identifier.";
}
enum unstable {
value 1;
description
"This SID allocation has been done during a
development process; it is not yet stable.";
}
enum obsolete {
value 2;
description
"This SID allocation is no longer in use. It is
recorded to avoid reallocation of its SID value.";
}
}
default "stable";
description
"The status field contains information about the
stability of the allocation. For each specific SID
value, over time it can only transition from
'unstable' to 'stable', and possibly from 'stable' to
'obsolete'.";
}
leaf namespace {
type enumeration {
enum module {
value 0;
description
"All module and submodule names share the same
global module identifier namespace.";
}
enum identity {
value 1;
description
"All identity names defined in a module and its
submodules share the same identity identifier
namespace.";
}
enum feature {
value 2;
description
"All feature names defined in a module and its
submodules share the same feature identifier
namespace.";
}
enum data {
value 3;
description
"The namespace for all data nodes, as defined in
YANG.";
}
}
description
"Namespace of the YANG item for this mapping entry.";
}
leaf identifier {
type union {
type yang:yang-identifier;
type schema-node-path;
}
description
"String identifier of the YANG item for this mapping
entry.
If the corresponding 'namespace' field is 'module',
'feature', or 'identity', then this field MUST
contain a valid YANG identifier string.
If the corresponding 'namespace' field is 'data',
then this field MUST contain a valid schema-node
path.";
}
leaf sid {
type sid;
mandatory true;
description
"YANG SID assigned to the YANG item for this mapping
entry.";
}
}
}
}
<CODE ENDS>
Figure 2: YANG Module 'ietf-sid-file'
図2：Yangモジュール「IETF-SID-FILE」
This document defines a new type of identifier used to encode data that are modeled in YANG [RFC7950]. This new identifier maps semantic concepts to integers, and if the source of this mapping is not trusted, then new security risks might occur if an attacker can control the mapping.
このドキュメントでは、Yang [RFC7950]でモデル化されたデータをエンコードするために使用される新しいタイプの識別子を定義します。この新しい識別子は、セマンティックの概念を整数にマップし、このマッピングのソースが信頼されていない場合、攻撃者がマッピングを制御できる場合、新しいセキュリティリスクが発生する可能性があります。
At the time of writing, it is expected that the ".sid" files will be processed by a software developer, within a software development environment. Developers are advised to only import ".sid" files from authoritative sources. IANA is the authoritative source for IETF-managed YANG modules.
執筆時点では、「.SID」ファイルは、ソフトウェア開発環境内のソフトウェア開発者によって処理されることが予想されます。開発者は、権威あるソースから「.SID」ファイルのみをインポートすることをお勧めします。IANAは、IETFが管理したYangモジュールの権威ある情報源です。
Conceptually, ".sid" files could be processed by less-constrained target systems such as network management systems. Such systems need to take extra care to make sure that they are only processing ".sid" files from authoritative sources that are as authoritative as the YANG modules that they are using.
概念的には、「.sid」ファイルは、ネットワーク管理システムなどの制約の少ないターゲットシステムによって処理される可能性があります。このようなシステムは、使用しているYangモジュールと同じくらい権威ある権威あるソースからの「.SID」ファイルのみを処理していることを確認するために、特別な注意を払う必要があります。
".sid" files are identified with and can employ _dereferenceable identifiers_, i.e., identifiers that could lead implementations in certain situations to automatically perform remote access, the target of which is indicated at least partially by those identifiers. This can give an attacker information from and/or control over such accesses, which can have security and privacy implications. Please also see Sections 6 and 7 of [DEREF-ID] for further considerations that may be applicable.
「.sid」ファイルは、_dereferencable Identifiers_、つまり特定の状況で実装を導く可能性のある識別子で識別され、リモートアクセスを自動的に実行できる識別子を使用できます。これにより、攻撃者がそのようなアクセスから情報を提供したり、制御したりすることができます。これにより、セキュリティとプライバシーへの影響があります。適用される可能性のあるさらなる考慮事項については、[Deref-ID]のセクション6および7を参照してください。
This document registers the following XML namespace URN in the "IETF XML Registry", following the format defined in [BCP81]:
このドキュメントは、[BCP81]で定義されている形式に従って、「IETF XMLレジストリ」に次のXML名空間URNを登録します。
URI:
URI:
urn:ietf:params:xml:ns:yang:ietf-sid-file
urn：ietf：params：xml：ns：yang：ietf-sid-file
Registrant Contact:
登録者の連絡先：
The IESG.
IESG。
XML:
XML:
N/A; the requested URI is an XML namespace.
n/a;要求されたURIはXMLネームスペースです。
Reference:
参照：
RFC 9595
RFC 9595
This document registers one YANG module in the "YANG Module Names" registry [RFC6020]:
このドキュメントは、「Yangモジュール名」レジストリ[RFC6020]に1つのYangモジュールを登録します。
Name:
名前：
ietf-sid-file
ietf-sid-file
Namespace:
名前空間：
urn:ietf:params:xml:ns:yang:ietf-sid-file
urn：ietf：params：xml：ns：yang：ietf-sid-file
Prefix:
プレフィックス：
sid
シド
Reference:
参照：
RFC 9595
RFC 9595
The name of this registry is "YANG-SID Mega-Ranges". This registry is used to record the delegation of the management of a block of SIDs to a third party (such as Standards Development Organizations (SDOs) or registrars).
このレジストリの名前は「Yang-Sid Mega-Ranges」です。このレジストリは、SIDSのブロックの管理の代表団を第三者（標準開発組織（SDO）やレジストラなど）に記録するために使用されます。
Each entry in this registry must include:
このレジストリの各エントリには、以下を含める必要があります。
* The entry point (first SID) of the registered SID block.
* 登録されたSIDブロックのエントリポイント（最初のSID）。
* The size of the registered SID block. The size SHOULD be one million (1,000,000) SIDs, but in exceptional cases, it MAY be a multiple of 1,000,000.
* 登録されたSIDブロックのサイズ。サイズは100万（1,000,000）のSIDでなければなりませんが、例外的な場合、それは1,000,000の倍数である可能性があります。
* The policy of SID range allocations: Public, Private, or both.
* SID範囲の配分のポリシー：パブリック、プライベート、またはその両方。
* The contact information of the requesting organization, including the following:
* 以下を含む要求組織の連絡先情報：
- Organization name.
- 組織名。
- URL.
- URL。
The IANA policy for future additions to this registry is "Expert Review" (Section 4.5 of RFC 8126 [BCP26]).
このレジストリへの将来の追加に関するIANAポリシーは、「エキスパートレビュー」です（RFC 8126 [BCP26]のセクション4.5）。
An organization requesting to manage a YANG-SID Range (and thus have an entry in the "YANG-SID Mega-Ranges" registry) must ensure the following capacities:
Yang-Sidの範囲の管理を要求する組織（したがって、「Yang-Sid Mega-Ranges」レジストリにエントリがある）は、次の能力を確保する必要があります。
* The capacity to manage and operate a registry of YANG-SID Ranges. A registry of YANG-SID Ranges MUST provide the following information for all YANG-SID Ranges allocated by the registry:
* Yang-SID範囲のレジストリを管理および運用する能力。Yang-SID範囲のレジストリは、レジストリによって割り当てられたすべてのYang-SID範囲に次の情報を提供する必要があります。
- The entry point of the allocated YANG-SID Range.
- 割り当てられたヤンシド範囲のエントリポイント。
- The size of the allocated YANG-SID Range.
- 割り当てられたヤンサイド範囲のサイズ。
- Type: Public or Private.
- タイプ：パブリックまたはプライベート。
o Public ranges MUST include at least a reference to the YANG module and ".sid" files for that YANG-SID Range (e.g., see Section 6.4.3 as an example for how this is handled for the "IETF YANG-SID Ranges" registry).
o パブリックレンジには、そのYang-SID範囲のYangモジュールと「.SID」ファイルへの参照を含める必要があります（たとえば、これが「IETF Yang-SID Range」レジストリの処理方法の例としてセクション6.4.3を参照してください。）。
o Private ranges MUST be marked as "Private".
o プライベート範囲は「プライベート」としてマークする必要があります。
* A policy of allocation, which clearly identifies whether the YANG-SID Range allocations would be Private, Public, or both.
* 配分の方針。これは、ヤンサイドの範囲の割り当てがプライベート、パブリック、またはその両方であるかどうかを明確に識別します。
* Technical capacity to provide or refer to ".sid" files in a way that meets the security objective of data integrity for these files (see also Section 5).
* これらのファイルのデータ整合性のセキュリティ目標を満たす方法で「.SID」ファイルを提供または参照する技術能力（セクション5も参照）。
* Technical capacity to ensure the sustained operation of the registry for a period of at least 5 years. If registrations in the Private category are allowed, the period must be at least 10 years.
* 少なくとも5年間、レジストリの持続的な運用を確保するための技術能力。プライベートカテゴリの登録が許可されている場合、期間は少なくとも10年でなければなりません。
If a size of the allocation beyond 1,000,000 is desired, the organization must demonstrate the sustainability of the technical approach for utilizing this size of allocation and how it does not negatively impact the overall usability of the SID allocation mechanisms; such allocations are preferably placed in the space above 4,295,000,000 (64-bit space).
1,000,000を超える配分のサイズが望ましい場合、組織は、このサイズの割り当てを利用するための技術的アプローチの持続可能性を実証する必要があり、SID割り当てメカニズムの全体的な使いやすさにどのように悪影響を与えないか。このような割り当ては、4,295,000,000（64ビットスペース）を超えるスペースに配置されることが好ましいです。
For a first allocation to be provided, the requesting organization must demonstrate a functional registry infrastructure.
最初の割り当てを提供するには、要求組織が機能的なレジストリインフラストラクチャを実証する必要があります。
On one or more subsequent allocation requests, the organization must demonstrate the exhaustion of the prior range. These conditions need to be asserted by the assigned expert(s).
1つ以上の後続の割り当て要求で、組織は以前の範囲の疲労を実証する必要があります。これらの条件は、割り当てられた専門家によって主張される必要があります。
If such a request for an additional allocation is made within 3 years of the last allocation, the experts need to discuss this request on the CORE Working Group mailing list and consensus needs to be obtained before allocating a new Mega-Range.
最後の割り当てから3年以内に追加の割り当ての要求が行われた場合、専門家は、新しいメガレンジを割り当てる前に、コアワーキンググループのメーリングリストとコンセンサスを取得する必要があります。
This registry contains the following initial entry:
このレジストリには、次の最初のエントリが含まれています。
+=====+=========+==========+============+=========================+
|Entry|Size |Allocation|Organization| URL |
|Point| | |Name | |
+=====+=========+==========+============+=========================+
|0 |1,000,000|Public |IANA | <https://www.iana.org/> |
+-----+---------+----------+------------+-------------------------+
Table 2: YANG-SID Mega-Ranges Registry: Initial Assignment
表2：Yang-Sid Mega-Rangesレジストリ：初期割り当て
The name of this registry is "IETF YANG-SID Ranges". This registry is used to record information related to the assignment of SID Ranges (e.g., entry point and size) to YANG modules identified by module name.
このレジストリの名前は「IETF Yang-Sid Ranges」です。このレジストリは、モジュール名で識別されたYangモジュールに対するSID範囲（エントリポイントとサイズなど）の割り当てに関連する情報を記録するために使用されます。
Each entry in this registry must include:
このレジストリの各エントリには、以下を含める必要があります。
* The SID range entry point.
* SIDレンジのエントリポイント。
* The SID range size.
* SID範囲サイズ。
* The YANG module name.
* Yangモジュール名。
* A document reference (the document making the registration).
* ドキュメントリファレンス（登録を作成するドキュメント）。
The first million SIDs assigned to IANA are subdivided as follows:
IANAに割り当てられた最初の100万個のSIDは次のように細分化されます。
1. The range of 0 to 999 (size 1,000) is subject to "IESG Approval" as defined in Section 4.10 of RFC 8126 [BCP26]; of these, SID value 0 has been reserved for implementations to internally signify the absence of a SID number and does not occur in interchange.
1. 0〜999（サイズ1,000）の範囲は、RFC 8126 [BCP26]のセクション4.10で定義されている「IESG承認」の対象となります。これらのうち、SID値0は、SID番号の欠如を内部的に意味する実装のために予約されており、インターチェンジでは発生しません。
2. The ranges of 1,000 to 59,999 (size 59,000) and 100,000 to 299,999 (size 200,000) are designated for YANG modules defined in RFCs.
2. RFCSで定義されたヤンモジュールに対して、1,000〜59,999（サイズ59,000）および100,000〜299,999（サイズ200,000）の範囲が指定されています。
a. The IANA policy for additions to this registry is:
a. このレジストリへの追加に関するIANAポリシーは次のとおりです。
i. "Expert Review" (Section 4.5 of RFC 8126 [BCP26]) if the ".sid" file comes from a YANG module from an existing RFC.
i. 「.SID」ファイルが既存のRFCからのYangモジュールから来ている場合、「Expert Review」（RFC 8126 [BCP26]のセクション4.5 [BCP26]）。
ii. "RFC Required" (Section 4.7 of RFC 8126 [BCP26]) otherwise.
ii。「RFC要求」（RFC 8126 [BCP26]のセクション4.7）。
b. The expert MUST verify that the YANG module for which this allocation is made has an RFC (existing RFC) OR is on track to become an RFC (Early Allocation with a request from the working group chairs as defined by [BCP100]).
b. 専門家は、この割り当てが行われるYangモジュールにはRFC（既存のRFC）があるか、RFC（[BCP100]で定義されているワーキンググループチェアからのリクエストによる早期割り当て）になることを軌道に乗せていることを確認する必要があります。
3. The range of 60,000 to 99,999 (size 40,000) is reserved for experimental YANG modules. This range MUST NOT be used in operational deployments, since these SIDs are not globally unique and their interoperability is therefore limited. The IANA policy for this range is "Experimental Use" (Section 4.2 of RFC 8126 [BCP26]).
3. 60,000〜99,999（サイズ40,000）の範囲は、実験的なヤンモジュール用に予約されています。これらのSIDはグローバルに一意ではなく、したがって相互運用性が限られているため、この範囲は運用展開に使用してはなりません。この範囲のIANAポリシーは「実験的使用」です（RFC 8126 [BCP26]のセクション4.2）。
4. The range of 300,000 to 999,999 (size 700,000) is "Reserved" as defined in Section 6 of RFC 8126 [BCP26].
4. 300,000〜999,999（サイズ700,000）の範囲は、RFC 8126 [BCP26]のセクション6で定義されているように「予約されています」。
+=============+=========+=============================+
| Entry Point | Size | IANA Policy |
+=============+=========+=============================+
| 0 | 1,000 | IESG Approval |
+-------------+---------+-----------------------------+
| 1,000 | 59,000 | RFC and Expert Review |
| | | Required (see item 2 above) |
+-------------+---------+-----------------------------+
| 60,000 | 40,000 | Reserved for Experimental |
| | | Use |
+-------------+---------+-----------------------------+
| 100,000 | 200,000 | RFC and Expert Review |
| | | Required (see item 2 above) |
+-------------+---------+-----------------------------+
| 300,000 | 700,000 | Reserved |
+-------------+---------+-----------------------------+
Table 3: IETF YANG-SID Ranges Registry: Policies for IETF Ranges
表3：IETF YANG-SID RANGESレジストリ：IETF範囲のポリシー
The size of the SID range allocated for a YANG module is recommended to be a multiple of 50 and to be at least 33% above the current number of YANG items. This headroom allows assignments within the same range of new YANG items introduced by subsequent revisions. The SID range size SHOULD NOT exceed 1,000; a larger size may be requested by the authors if this recommendation is considered insufficient. It is important to note that an additional SID range can be allocated to an existing YANG module if the initial range is exhausted; this then just leads to a slightly less efficient representation.
Yangモジュールに割り当てられたSID範囲のサイズは、50の倍数であり、現在のYangアイテムの数を少なくとも33％上回ることをお勧めします。このヘッドルームは、その後の改訂によって導入された同じ範囲の新しいヤンアイテム内の割り当てを可能にします。SID範囲のサイズは1,000を超えてはなりません。この推奨事項が不十分であると見なされた場合、著者はより大きなサイズを要求することができます。初期範囲が使い果たされている場合、追加のSID範囲を既存のYangモジュールに割り当てることができることに注意することが重要です。これにより、効率がわずかに低い表現につながります。
If a SID range is allocated for an existing RFC through the "Expert Review" policy (Section 4.5 of RFC 8126 [BCP26]), the Reference field for the given allocation should point to the RFC that the YANG module is defined in.
「Expert Review」ポリシー（RFC 8126のセクション4.5 [BCP26]）を通じて既存のRFCにSID範囲が割り当てられている場合、指定された割り当ての参照フィールドは、Yangモジュールが定義されているRFCを指す必要があります。
If a SID range is required before publishing the RFC due to implementations needing stable SID values, Early Allocation as defined in [BCP100] can be employed for the "RFC Required" range (Section 2 of RFC 7120 [BCP100]).
安定したSID値を必要とする実装のためにRFCを公開する前にSID範囲が必要な場合、[BCP100]で定義されている早期割り当てを「RFC要求」範囲に使用できます（RFC 7120 [BCP100]のセクション2）。
During an RFC's publication process, IANA contacts the designated expert team ("the team"), who are responsible for delivering a final ".sid" file for each module defined by the RFC. For a type-3 developer (SID-oblivious; see Section 2.4), the team creates a new ".sid" file from each YANG module; see below. For a type-2 (SID-aware) developer, the team first obtains the existing draft ".sid" file from a stable reference in the approved draft; for a type-1 (SID-guiding) developer, the team extracts the ".sid" file from the approved draft.
RFCの出版プロセス中、IANAは、RFCによって定義された各モジュールの最終的な「SID」ファイルを配信する責任がある指定された専門家チーム（「チーム」）に連絡します。タイプ3開発者（SID-Oblivious;セクション2.4を参照）の場合、チームは各Yangモジュールから新しい「.SID」ファイルを作成します。以下を参照してください。タイプ2（SID-AWARE）開発者の場合、チームは最初に既存のドラフト「.SID」ファイルを承認されたドラフトの安定した参照から取得します。Type-1（SID-Guiding）開発者の場合、チームは承認されたドラフトから「.SID」ファイルを抽出します。
The team uses a tool to generate a final ".sid" file from each YANG module; the final ".sid" file has all SID assignments set to "stable" and the ".sid" file status set to "published". A published ".sid" file MUST NOT contain SID assignments with a status of "unstable".
チームはツールを使用して、各Yangモジュールから最終的な「.SID」ファイルを生成します。最終的な「.sid」ファイルには、すべてのSID割り当てが「stable」に設定され、「sid」ファイルステータスが「公開」に設定されています。公開された「.SID」ファイルには、「不安定」のステータスを持つSID割り当てが含まれていないはずです。
For the cases other than type-3 (SID-oblivious), the team feeds the existing draft ".sid" file as an input ("reference ".sid" file") to the tool so that the changes resulting from regeneration are minimal. For YANG modules that are revisions of previously published modules, any existing published ".sid" file needs to serve as a reference ".sid" file for the tool, during generation of either the revised draft ".sid" file (type-1, type-2) or the final ".sid" file (type-3).
Type-3（SID-Blivious）以外のケースの場合、チームは既存のドラフト「.SID」ファイルに入力（「参照」.SID "ファイル"）としてフィードし、再生から生じる変更が最小限になるようにします。。以前に公開されたモジュールの改訂版であるYangモジュールの場合、既存の公開された「.sid」ファイルは、改訂されたドラフト「.sid」ファイルの生成中に、ツールのリファレンス「.sid」ファイルとして機能する必要があります（type-1（type-1）、タイプ-2）または最終「.sid」ファイル（タイプ3）。
In any case, the team checks the generated file, including checking for validity as a ".sid" file, for consistency with the SID range allocations, for full coverage of the YANG items in the YANG module, and for the best achievable consistency with the existing draft ".sid" file.
いずれにせよ、チームは生成されたファイルをチェックします。これには、「.SID」ファイルとしての有効性のチェック、SID範囲の割り当てとの一貫性、Yangモジュールのヤンアイテムの完全なカバレッジ、および最良の達成可能な一貫性のために既存のドラフト「.sid」ファイル。
The designated experts then give the ".sid" file to IANA to publish in the "IETF YANG-SID Modules" registry (Section 6.5) along with the YANG module.
指定された専門家は、「.SID」ファイルをIANAに提供して、Yangモジュールとともに「IETF Yang-SIDモジュール」レジストリ（セクション6.5）に公開します。
The ".sid" file MUST NOT be published as part of the RFC: the IANA registry is authoritative, and a link to it is to be inserted in the RFC. (Note that the present RFC is an exception to this rule, as the ".sid" file also serves as an example for exposition.) Internet-Drafts that need SIDs assigned to their new modules for use in the text of the document, e.g., for examples, need to alert the RFC Editor in the draft text that this is the case. Such RFCs cannot be produced by type-3 (SID-oblivious) developers: the SIDs used in the text need to be assigned in the existing draft ".sid" file, and the designated expert team needs to check that the assignments in the final ".sid" file are consistent with the usage in the RFC text or that the approved draft text is changed appropriately.
「.sid」ファイルはRFCの一部として公開されてはなりません。IANAレジストリは権威あるものであり、それへのリンクをRFCに挿入します。（現在のRFCは、「.SID」ファイルは博覧会の例としても機能するため、このルールの例外であることに注意してください。）ドキュメントのテキストで使用するために新しいモジュールに割り当てられたSIDを必要とするインターネットドラフト、例えば、たとえば、ドラフトテキストのRFCエディターに、これが当てはまることを警告する必要があります。このようなRFCは、Type-3（SID-Oblivious）開発者によって生成できません：テキストで使用されるSIDは、既存のドラフト「.SID」ファイルで割り当てる必要があり、指定された専門家チームは最終的な課題を確認する必要があります。「.sid」ファイルは、RFCテキストの使用法と一致しているか、承認されたドラフトテキストが適切に変更されていることと一致しています。
Initial entries in this registry are as follows:
このレジストリの初期エントリは次のとおりです。
+=============+======+=============================+=============+
| Entry Point | Size | Module Name | Reference |
+=============+======+=============================+=============+
| 0 | 1 | (Reserved: not a valid SID) | RFC 9595 |
+-------------+------+-----------------------------+-------------+
| 1,000 | 100 | ietf-coreconf | RFC 9595, |
| | | | [CORE-COMI] |
+-------------+------+-----------------------------+-------------+
| 1,100 | 50 | ietf-yang-types | [RFC6991] |
+-------------+------+-----------------------------+-------------+
| 1,150 | 50 | ietf-inet-types | [RFC6991] |
+-------------+------+-----------------------------+-------------+
| 1,200 | 50 | iana-crypt-hash | [RFC7317] |
+-------------+------+-----------------------------+-------------+
| 1,250 | 50 | ietf-netconf-acm | [STD91] |
+-------------+------+-----------------------------+-------------+
| 1,300 | 50 | ietf-sid-file | RFC 9595 |
+-------------+------+-----------------------------+-------------+
| 1,500 | 100 | ietf-interfaces | [RFC8343] |
+-------------+------+-----------------------------+-------------+
| 1,600 | 100 | ietf-ip | [RFC8344] |
+-------------+------+-----------------------------+-------------+
| 1,700 | 100 | ietf-system | [RFC7317] |
+-------------+------+-----------------------------+-------------+
| 1,800 | 400 | iana-if-type | [RFC7224] |
+-------------+------+-----------------------------+-------------+
Table 4: IETF YANG-SID Ranges Registry: Initial Range Assignments
表4：IETF Yang-SID Rangesレジストリ：初期範囲の割り当て
For allocation, RFC publication of the YANG module is required as per the "RFC Required" policy defined in Section 4.7 of RFC 8126 [BCP26]. The YANG module must be registered in the "YANG Module Names" registry according to the rules specified in Section 14 of [RFC6020].
割り当てのために、RFC 8126 [BCP26]のセクション4.7で定義されている「RFC要求」ポリシーに従って、YangモジュールのRFC出版が必要です。Yangモジュールは、[RFC6020]のセクション14で指定されたルールに従って、「Yangモジュール名」レジストリに登録する必要があります。
The name of this registry is "IETF YANG-SID Modules". This registry is used to record the allocation of SIDs for individual YANG module items.
このレジストリの名前は「IETF Yang-SIDモジュール」です。このレジストリは、個々のYangモジュールアイテムのSIDの割り当てを記録するために使用されます。
Each entry in this registry must include:
このレジストリの各エントリには、以下を含める必要があります。
* The YANG module name. This module name must be present in the "Name" column of the "YANG Module Names" registry.
* Yangモジュール名。このモジュール名は、「Yangモジュール名」レジストリの「名前」列に存在する必要があります。
* A URI for the associated ".yang" file. This file link must be present in the "File" column of the "YANG Module Names" registry.
* 関連する「.yang」ファイルのURI。このファイルリンクは、「Yangモジュール名」レジストリの「ファイル」列に存在する必要があります。
* The URI for the ".sid" file that defines the allocation. The ".sid" file is stored by IANA.
* 割り当てを定義する「.SID」ファイルのURI。「.sid」ファイルはianaによって保存されます。
* The number of actually allocated SIDs in the ".sid" file.
* 「.SID」ファイルに実際に割り当てられたSIDの数。
The allocation policy is "Expert Review" (Section 4.5 of RFC 8126 [BCP26]). The expert MUST ensure that the following conditions are met:
割り当てポリシーは「専門家のレビュー」です（RFC 8126 [BCP26]のセクション4.5）。専門家は、次の条件が満たされていることを確認する必要があります。
* The ".sid" file has a valid structure:
* 「.sid」ファイルには有効な構造があります。
- The ".sid" file MUST be a valid JSON file following the structure of the module defined in this document.
- 「.sid」ファイルは、このドキュメントで定義されているモジュールの構造に従って有効なJSONファイルでなければなりません。
* The ".sid" file allocates individual SIDs ONLY in the YANG-SID Ranges for this YANG module (as allocated in the "IETF YANG-SID Ranges" registry):
* 「.SID」ファイルは、このYangモジュールのYang-SID範囲に個々のSIDを割り当てます（「IETF Yang-SID範囲」レジストリに割り当てられています）：
- All SIDs in this ".sid" file MUST be within the ranges allocated to this YANG module in the "IETF YANG-SID Ranges" registry.
- この「.SID」ファイルのすべてのSIDは、「IETF Yang-SID範囲」レジストリのこのYangモジュールに割り当てられた範囲内にある必要があります。
* If another ".sid" file has already allocated SIDs for this YANG module (e.g., for older or newer versions of the YANG module), the YANG items are assigned the same SIDs as those in the other ".sid" file.
* 別の「.SID」ファイルがすでにこのYangモジュール（Yangモジュールの古いバージョンまたは新しいバージョン用）にSIDSを割り当てている場合、Yangアイテムには他の「.SID」ファイルのSIDと同じSIDが割り当てられます。
* If there is an older version of the ".sid" file, all allocated SIDs from that version are still present in the current version of the ".sid" file.
* 「.sid」ファイルの古いバージョンがある場合、そのバージョンのすべての割り当てられたSIDは、「.sid」ファイルの現在のバージョンにまだ存在します。
Due to the difficulty in changing SID values during IETF document processing, it is expected that most documents will ask for SID range allocations using Early Allocations [BCP100]. The details of the Early Allocation to be requested, including the timeline envisioned, should be included in any working group adoption call. Prior to working group adoption, an Internet-Draft author can use the experimental SID range (as per Section 6.4.2) for their SID allocations or other values that do not create ambiguity with other SID uses (for example, they can use ranges and SIDs registered in a non-IANA-managed registry that is based on a YANG-SID Mega-Range assignment).
IETFドキュメント処理中にSID値の変更が困難なため、ほとんどのドキュメントでは、早期割り当て[BCP100]を使用してSID範囲の割り当てを要求することが予想されます。想定されるタイムラインを含む、要求される早期配分の詳細は、ワーキンググループの養子縁組コールに含める必要があります。ワーキンググループの採用の前に、インターネットドラフトの著者は、他のSIDの使用と曖昧さを生み出さないSIDの割り当てまたはその他の値に対して、実験的なSID範囲（セクション6.4.2に従って）を使用できます（たとえば、範囲と使用できます。Yang-Sid Mega-Rangeの割り当てに基づいた非Aianaが管理するレジストリに登録されたSIDS。
After working group adoption, any modification of a ".sid" file is expected to be discussed on the mailing lists of the appropriate working groups. Specific attention should be paid to implementers' opinions after Working Group Last Call if a SID value is to change its meaning. In all cases, a ".sid" file and the SIDs associated with it are subject to change before the publication of an Internet-Draft as an RFC.
ワーキンググループの採用後、「.SID」ファイルの変更は、適切なワーキンググループのメーリングリストで議論される予定です。SID値がその意味を変えるために、ワーキンググループの最後のコールの後、実装者の意見に特定の注意を払う必要があります。すべての場合において、「.SID」ファイルとそれに関連するSIDSは、RFCとしてインターネットドラフトを公開する前に変更される場合があります。
As the concept of SIDs is first used, many existing, previously published YANG modules will not have SID allocations. For an allocation to be useful, the included YANG modules may also need to have SID allocations made, in a process that will generally be analogous to that in Section 6.4.3 for the type-3 (SID-oblivious) case.
SIDSの概念が最初に使用されるため、既存の以前に公開されていた多くのYangモジュールにはSIDの割り当てがありません。割り当てが役立つためには、含まれているYangモジュールには、一般的にType-3（SID-Oblivious）ケースのセクション6.4.3のプロセスに類似したプロセスで、SID割り当てが作成される必要がある場合があります。
The expert reviewer who performs the (Early) Allocation analysis will need to go through the list of included YANG modules and perform SID allocations for those modules as well.
（早期）割り当て分析を実行する専門家のレビュー担当者は、含まれているYangモジュールのリストを調べて、これらのモジュールにもSID割り当てを実行する必要があります。
* If the document is a published RFC, then the allocation of SIDs for its referenced YANG modules is permanent. The expert reviewer provides the generated ".sid" file to IANA for registration.
* ドキュメントが公開されているRFCである場合、参照されたYangモジュールのSIDSの割り当ては永続的です。エキスパートレビューアは、登録のために生成された「.sid」ファイルをianaに提供します。
* If the document is an unprocessed Internet-Draft adopted in a working group, then an Early Allocation is performed for this document as well. Early Allocations require approval by an IESG area director. An Early Allocation that requires additional allocations will list the other allocations in its description and will be cross-posted to the mailing lists of any other working groups concerned.
* ドキュメントがワーキンググループで採用されている未加工のインターネットドラフトである場合、このドキュメントにも早期割り当てが実行されます。早期の割り当てには、IESGエリアディレクターによる承認が必要です。追加の割り当てを必要とする早期配分は、その説明に他の割り当てをリストし、関係する他のワーキンググループのメーリングリストに相互に投稿されます。
* A YANG module that references a module in a document that has not yet been adopted by any working group will be unable to perform an Early Allocation for that other document until it is adopted by a working group. As described in Section 3 of RFC 7120 [BCP100], a shepherding AD will stand in for the working group chairs if the document is not the product of an IETF working group, effectively allowing the AD to exempt a document from this policy.
* ワーキンググループによってまだ採用されていないドキュメント内のモジュールを参照するYangモジュールは、ワーキンググループが採用するまでその他のドキュメントの早期配分を実行できません。RFC 7120 [BCP100]のセクション3で説明されているように、ドキュメントがIETFワーキンググループの製品ではない場合、羊飼い広告はワーキンググループチェアのために略で、このポリシーからドキュメントを免除できるようにします。
At the end of the IETF process, all the dependencies of a given module for which SIDs are assigned should also have SIDs assigned. Those dependencies' assignments should be permanent (not Early Allocation).
IETFプロセスの最後に、SIDが割り当てられている特定のモジュールのすべての依存関係もSIDを割り当てている必要があります。これらの依存関係の割り当ては永続的でなければなりません（早期割り当てではありません）。
A previously SID-allocated YANG module that changes its references to include a YANG module for which there is no SID allocation needs to repeat the Early Allocation process.
参照を変更する以前にSIDに割り当てられたYangモジュールには、早期割り当てプロセスを繰り返すためにSID割り当てが必要ないYangモジュールが含まれます。
[BCP100] defines a time limit for the validity of Early Allocations, after which they expire unless they are renewed. Section 3.3 of RFC 7120 [BCP100] also says:
[BCP100]は、早期配分の有効性の時間制限を定義し、その後、更新されない限り期限切れになります。RFC 7120 [BCP100]のセクション3.3は次のように述べています。
Note that if a document is submitted for review to the IESG, and at the time of submission some Early Allocations are valid (not expired), these allocations must not be considered to have expired while the document is under IESG consideration or is awaiting publication in the RFC Editor's queue after approval by the IESG.
IESGへのレビューのためにドキュメントが送信され、提出時にいくつかの早期割り当てが有効である場合（期限切れになっていない）、これらの割り当ては、文書がIESGの検討中であるか、またはの出版物を待っている間に期限切れになったと見なされないことに注意してください。IESGによる承認後のRFCエディターのキュー。
At the time of writing, this registry does not contain any entries.
執筆時点では、このレジストリにはエントリが含まれていません。
This document adds the following media type to the "Media Types" registry.
このドキュメントでは、次のメディアタイプを「メディアタイプ」レジストリに追加します。
+===============+===========================+===========+
| Name | Template | Reference |
+===============+===========================+===========+
| yang-sid+json | application/yang-sid+json | RFC 9595 |
+---------------+---------------------------+-----------+
Table 5: ".sid" File Media Type Registration
表5： ".sid"ファイルメディアタイプ登録
Type name:
タイプ名：
application
応用アプリケーション出願塗布申請アプリ使用利用申込申し込み応募運用願い願い出要請控訴勉励丹念請求応用力適用業務
Subtype name:
サブタイプ名：
yang-sid+json
Yang-Sid+Json
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
N/A
n/a
Encoding considerations:
考慮事項のエンコード：
binary (UTF-8)
バイナリ（UTF-8）
Security considerations:
セキュリティ上の考慮事項：
See Section 5 of RFC 9595.
RFC 9595のセクション5を参照してください。
Published specification:
公開された仕様：
RFC 9595
RFC 9595
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Applications that need to obtain YANG SIDs to interchange YANG-modeled data in a concise and efficient representation.
簡潔で効率的な表現でヤンモデルのデータを交換するためにヤンシドを取得する必要があるアプリケーション。
Fragment identifier considerations:
フラグメント識別子の考慮事項：
The syntax and semantics of fragment identifiers specified for "application/yang-sid+json" is as specified for "application/json". (At publication of this document, there is no fragment identification syntax defined for "application/json".)
「Application/Yang-SID+JSON」に指定されたフラグメント識別子の構文とセマンティクスは、「Application/JSON」に指定されています。（このドキュメントの公開時に、「アプリケーション/JSON」に対して定義されたフラグメント識別構文はありません。）
Additional information:
追加情報：
Magic number(s):
マジックナンバー：
N/A
n/a
File extension(s):
ファイル拡張子：
.sid
.sid
Macintosh file type code(s):
Macintoshファイルタイプコード：
N/A
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:
使用に関する制限：
none
なしのどれも
Author/Change controller:
著者/変更コントローラー：
IETF
IETF
This document adds the following Content-Format to the "CoAP Content-Formats" registry within the "Constrained RESTful Environments (CoRE) Parameters" group of registries, where 260 has been assigned from the "IETF Review" (256-9,999) range (see Section 4.8 of RFC 8126 [BCP26]).
このドキュメントでは、「COAPコンテンツフォーマット」レジストリに「COAPコンテンツフォーマット」レジストリに追加されます。RFC 8126 [BCP26]のセクション4.8を参照してください。
+===========================+================+=====+===========+
| Content Type | Content Coding | ID | Reference |
+===========================+================+=====+===========+
| application/yang-sid+json | - | 260 | RFC 9595 |
+---------------------------+----------------+-----+-----------+
Table 6: ".sid" File Content-Format Registration
表6： ".sid"ファイルコンテンツフォーマット登録
[BCP100] Best Current Practice 100,
<https://www.rfc-editor.org/info/bcp100>.
At the time of writing, this BCP comprises the following:
Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
2014, <https://www.rfc-editor.org/info/rfc7120>.
[BCP14] Best Current Practice 14,
<https://www.rfc-editor.org/info/bcp14>.
At the time of writing, this BCP comprises the following:
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>.
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>.
[BCP81] Best Current Practice 81,
<https://www.rfc-editor.org/info/bcp81>.
At the time of writing, this BCP comprises the following:
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[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>.
[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>.
[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>.
[STD68] Internet Standard 68,
<https://www.rfc-editor.org/info/std68>.
At the time of writing, this STD comprises the following:
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>.
[STD90] Internet Standard 90,
<https://www.rfc-editor.org/info/std90>.
At the time of writing, this STD comprises the following:
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>.
[BCP215] Best Current Practice 215,
<https://www.rfc-editor.org/info/bcp215>.
At the time of writing, this BCP comprises the following:
Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[BCP216] Best Current Practice 216,
<https://www.rfc-editor.org/info/bcp216>.
At the time of writing, this BCP comprises the following:
Bierman, A., "Guidelines for Authors and Reviewers of
Documents Containing YANG Data Models", BCP 216, RFC 8407,
DOI 10.17487/RFC8407, October 2018,
<https://www.rfc-editor.org/info/rfc8407>.
[BCP26] Best Current Practice 26,
<https://www.rfc-editor.org/info/bcp26>.
At the time of writing, this BCP comprises the following:
Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[CORE-COMI]
Veillette, M., Ed., van der Stok, P., Ed., Pelov, A., Ed.,
Bierman, A., and C. Bormann, Ed., "CoAP Management
Interface (CORECONF)", Work in Progress, Internet-Draft,
draft-ietf-core-comi-18, 23 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
comi-18>.
[DEREF-ID] Bormann, C. and C. Amsüss, "The 'dereferenceable
identifier' pattern", Work in Progress, Internet-Draft,
draft-bormann-t2trg-deref-id-03, 2 March 2024,
<https://datatracker.ietf.org/doc/html/draft-bormann-
t2trg-deref-id-03>.
[PYANG] Björklund, M., "An extensible YANG validator and converter
in python", commit fc9a965, May 2024,
<https://github.com/mbj4668/pyang>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[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>.
[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module",
RFC 7224, DOI 10.17487/RFC7224, May 2014,
<https://www.rfc-editor.org/info/rfc7224>.
[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>.
[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>.
[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>.
[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>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
[RFC9195] Lengyel, B. and B. Claise, "A File Format for YANG
Instance Data", RFC 9195, DOI 10.17487/RFC9195, February
2022, <https://www.rfc-editor.org/info/rfc9195>.
[RFC9254] Veillette, M., Ed., Petrov, I., Ed., Pelov, A., Bormann,
C., and M. Richardson, "Encoding of Data Modeled with YANG
in the Concise Binary Object Representation (CBOR)",
RFC 9254, DOI 10.17487/RFC9254, July 2022,
<https://www.rfc-editor.org/info/rfc9254>.
[STD91] Internet Standard 91,
<https://www.rfc-editor.org/info/std91>.
At the time of writing, this STD comprises the following:
Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[YANG-LIBRARY]
Veillette, M., Ed. and I. Petrov, Ed., "Constrained YANG
Module Library", Work in Progress, Internet-Draft, draft-
ietf-core-yang-library-03, 11 January 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
yang-library-03>.
[yangcatalog]
"YANG Catalog", <https://yangcatalog.org>.
The following ".sid" file ('ietf-system@2014-08-06.sid') has been generated using the following YANG modules:
次の「.sid」ファイル（ 'ietf-system@2014-08-06.sid'）が次のYangモジュールを使用して生成されました。
* 'ietf-system@2014-08-06.yang' (defined in [RFC7317])
* 'ietf-system@2014-08-06.yang'（[rfc7317]で定義）
* 'ietf-yang-types@2013-07-15.yang' (defined in [RFC6991])
* 'ietf-yang-types@2013-07-15.yang'（[rfc6991]で定義）
* 'ietf-inet-types@2013-07-15.yang' (defined in [RFC6991])
* 'ietf-inet-types@2013-07-15.yang'（[rfc6991]で定義）
* 'ietf-netconf-acm@2018-02-14.yang' (defined in [STD91])
* 'ietf-netconf-acm@2018-02-14.yang'（[std91]で定義）
* 'iana-crypt-hash@2014-08-06.yang' (defined in [RFC7317])
* 'iana-crypt-hash@2014-08-06.yang'（[rfc7317]で定義）
For purposes of exposition, per [RFC8792], line breaks have been introduced below in some JSON strings that represent overly long identifiers.
[RFC8792]によると、博覧会の目的のために、以下に、過度に長い識別子を表すいくつかのJSON文字列にラインブレークが導入されています。
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-sid-file:sid-file": {
"module-name": "ietf-system",
"module-revision": "2014-08-06",
"description": "Example '.sid' file",
"dependency-revision": [
{
"module-name": "ietf-yang-types",
"module-revision": "2013-07-15"
},
{
"module-name": "ietf-inet-types",
"module-revision": "2013-07-15"
},
{
"module-name": "ietf-netconf-acm",
"module-revision": "2018-02-14"
},
{
"module-name": "iana-crypt-hash",
"module-revision": "2014-08-06"
}
],
"assignment-range": [
{
"entry-point": "1700",
"size": "100"
}
],
"item": [
{
"namespace": "module",
"identifier": "ietf-system",
"sid": "1700"
},
{
"namespace": "identity",
"identifier": "authentication-method",
"sid": "1701"
},
{
"namespace": "identity",
"identifier": "local-users",
"sid": "1702"
},
{
"namespace": "identity",
"identifier": "radius",
"sid": "1703"
},
{
"namespace": "identity",
"identifier": "radius-authentication-type",
"sid": "1704"
},
{
"namespace": "identity",
"identifier": "radius-chap",
"sid": "1705"
},
{
"namespace": "identity",
"identifier": "radius-pap",
"sid": "1706"
},
{
"namespace": "feature",
"identifier": "authentication",
"sid": "1707"
},
{
"namespace": "feature",
"identifier": "dns-udp-tcp-port",
"sid": "1708"
},
{
"namespace": "feature",
"identifier": "local-users",
"sid": "1709"
},
{
"namespace": "feature",
"identifier": "ntp",
"sid": "1710"
},
{
"namespace": "feature",
"identifier": "ntp-udp-port",
"sid": "1711"
},
{
"namespace": "feature",
"identifier": "radius",
"sid": "1712"
},
{
"namespace": "feature",
"identifier": "radius-authentication",
"sid": "1713"
},
{
"namespace": "feature",
"identifier": "timezone-name",
"sid": "1714"
},
{
"namespace": "data",
"identifier": "/ietf-system:set-current-datetime",
"sid": "1715"
},
{
"namespace": "data",
"identifier": "/ietf-system:set-current-datetime/input",
"sid": "1775"
},
{
"namespace": "data",
"identifier": "/ietf-system:set-current-datetime/input/\
current-datetime",
"sid": "1776"
},
{
"namespace": "data",
"identifier": "/ietf-system:system",
"sid": "1717"
},
{
"namespace": "data",
"identifier": "/ietf-system:system-restart",
"sid": "1718"
},
{
"namespace": "data",
"identifier": "/ietf-system:system-shutdown",
"sid": "1719"
},
{
"namespace": "data",
"identifier": "/ietf-system:system-state",
"sid": "1720"
},
{
"namespace": "data",
"identifier": "/ietf-system:system-state/clock",
"sid": "1721"
},
{
"namespace": "data",
"identifier": "/ietf-system:system-state/clock/boot-datetime\
",
"sid": "1722"
},
{
"namespace": "data",
"identifier": "/ietf-system:system-state/clock/current-\
datetime",
"sid": "1723"
},
{
"namespace": "data",
"identifier": "/ietf-system:system-state/platform",
"sid": "1724"
},
{
"namespace": "data",
"identifier": "/ietf-system:system-state/platform/machine",
"sid": "1725"
},
{
"namespace": "data",
"identifier": "/ietf-system:system-state/platform/os-name",
"sid": "1726"
},
{
"namespace": "data",
"identifier": "/ietf-system:system-state/platform/os-release\
",
"sid": "1727"
},
{
"namespace": "data",
"identifier": "/ietf-system:system-state/platform/os-version\
",
"sid": "1728"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/authentication",
"sid": "1729"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/authentication/user",
"sid": "1730"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/authentication/user-\
authentication-order",
"sid": "1731"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/authentication/user/\
authorized-key",
"sid": "1732"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/authentication/user/\
authorized-key/algorithm",
"sid": "1733"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/authentication/user/\
authorized-key/key-data",
"sid": "1734"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/authentication/user/\
authorized-key/name",
"sid": "1735"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/authentication/user/name",
"sid": "1736"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/authentication/user/\
password",
"sid": "1737"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/clock",
"sid": "1738"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/clock/timezone-name",
"sid": "1739"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/clock/timezone-utc-offset\
",
"sid": "1740"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/contact",
"sid": "1741"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/dns-resolver",
"sid": "1742"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/dns-resolver/options",
"sid": "1743"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/dns-resolver/options/\
attempts",
"sid": "1744"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/dns-resolver/options/\
timeout",
"sid": "1745"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/dns-resolver/search",
"sid": "1746"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/dns-resolver/server",
"sid": "1747"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/dns-resolver/server/name",
"sid": "1748"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/dns-resolver/server/udp-\
and-tcp",
"sid": "1749"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/dns-resolver/server/udp-\
and-tcp/address",
"sid": "1750"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/dns-resolver/server/udp-\
and-tcp/port",
"sid": "1751"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/hostname",
"sid": "1752"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/location",
"sid": "1753"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/ntp",
"sid": "1754"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/ntp/enabled",
"sid": "1755"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/ntp/server",
"sid": "1756"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/ntp/server/association-\
type",
"sid": "1757"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/ntp/server/iburst",
"sid": "1758"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/ntp/server/name",
"sid": "1759"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/ntp/server/prefer",
"sid": "1760"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/ntp/server/udp",
"sid": "1761"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/ntp/server/udp/address",
"sid": "1762"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/ntp/server/udp/port",
"sid": "1763"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/radius",
"sid": "1764"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/radius/options",
"sid": "1765"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/radius/options/attempts",
"sid": "1766"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/radius/options/timeout",
"sid": "1767"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/radius/server",
"sid": "1768"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/radius/server/\
authentication-type",
"sid": "1769"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/radius/server/name",
"sid": "1770"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/radius/server/udp",
"sid": "1771"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/radius/server/udp/address\
",
"sid": "1772"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/radius/server/udp/\
authentication-port",
"sid": "1773"
},
{
"namespace": "data",
"identifier": "/ietf-system:system/radius/server/udp/shared-\
secret",
"sid": "1774"
}
]
}
}
Figure 3: Example ".sid" File ('ietf-system', with Extra Line Breaks)
図3：例 ".sid"ファイル（ 'ietf-system'、追加のラインブレーク付き）
The assignment of SIDs to YANG items SHOULD be automated. The recommended process to assign SIDs is as follows:
YangアイテムへのSIDSの割り当ては自動化する必要があります。SIDSを割り当てるための推奨プロセスは次のとおりです。
1. A tool extracts the different items defined for a specific YANG module.
1. ツールは、特定のYangモジュール用に定義されたさまざまなアイテムを抽出します。
2. The list of items is sorted in alphabetical order. 'namespace' entries are sorted in descending order, and 'identifier' entries are sorted in ascending order. The 'namespace' and 'identifier' formats are described in the YANG module 'ietf-sid-file' defined in Section 4.
2. アイテムのリストは、アルファベット順にソートされます。「名前空間」エントリは降順でソートされ、「識別子」エントリは昇順でソートされます。「名前空間」形式と「識別子」形式は、セクション4で定義されているYangモジュール「IETF-SID-FILE」で説明されています。
3. SIDs are assigned sequentially from the entry point up to the size of the registered SID range. This approach is recommended to minimize the serialization overhead, especially when the delta between a reference SID and the current SID is used by protocols aiming to reduce message size.
3. SIDは、登録されたSID範囲のサイズまでのエントリポイントから順次割り当てられます。このアプローチは、特に参照SIDと現在のSIDの間のデルタがメッセージサイズを削減することを目的としたプロトコルで使用される場合、シリアル化オーバーヘッドを最小限に抑えるために推奨されます。
4. If the number of items exceeds the SID range(s) allocated to a YANG module, an extra range is added for subsequent assignments.
4. アイテムの数がYangモジュールに割り当てられたSID範囲を超えると、その後の割り当てのために追加の範囲が追加されます。
5. The 'dependency-revision' list item should reflect the revision numbers of each YANG module that the YANG module imports at the moment of file generation.
5. 「依存関係」リスト項目は、ファイル生成の瞬間にYangモジュールがインポートする各Yangモジュールの改訂番号を反映する必要があります。
When updating a YANG module that is in active use, the existing SID assignments are maintained. (In contrast, when evolving an early version of an Internet-Draft that has not yet been adopted by a community of developers, SID assignments are often better done from scratch after a revision.) If the name of a schema node changes but the data remain structurally and semantically similar to what was previously available under an old name, the SID that was used for the old name MAY continue to be used for the new name. If the meaning of an item changes, a new SID MAY be assigned to it; this is particularly useful for allowing the new SID to identify the new structure or semantics of the item. If the YANG data type changes in a new revision of a published module such that the resulting CBOR encoding is changed, then implementations will be aided significantly if a new SID is assigned. Note that these decisions are generally at the discretion of the YANG module author, who should decide if the benefits of a manual intervention are worth the deviation from automatic assignment.
アクティブに使用されているYangモジュールを更新すると、既存のSID割り当てが維持されます。（対照的に、開発者コミュニティによってまだ採用されていないインターネットドラフトの初期バージョンを進化させる場合、SIDの割り当ては、改訂後にゼロからより良いことがよくあります。）スキーマノードの名前が変更された場合はデータが変更されます。以前に古い名前で利用可能だったものと構造的および意味的に類似したままであるため、古い名前に使用されたSIDは引き続き新しい名前に使用されます。アイテムの意味が変更された場合、新しいSIDが割り当てられる場合があります。これは、新しいSIDがアイテムの新しい構造またはセマンティクスを識別できるようにするために特に役立ちます。Yangデータ型が公開されたモジュールの新しい改訂で変更され、結果のCBORエンコードが変更されるように変更された場合、新しいSIDが割り当てられた場合、実装が大幅に支援されます。これらの決定は一般に、手動介入の利点が自動割り当てから逸脱する価値があるかどうかを判断する必要があるヤンモジュール著者の裁量にあることに注意してください。
In the case of an update to an existing ".sid" file, an additional step is needed that increments the ".sid" file version number. If there was no version number in the previous version of the ".sid" file, 0 is assumed to be the version number of the old version of the ".sid" file and the version number is 1 for the new ".sid" file. Apart from that, changes to ".sid" files can also be automated using the same method as that described above, except that in step #3, previous SID assignments are kept, only previously unassigned YANG items are processed, and these are assigned previously unassigned SIDs. Already-existing items in the ".sid" file should not be given new SIDs.
既存の「.sid」ファイルの更新の場合、「.sid」ファイルバージョン番号を増やす追加のステップが必要です。「.sid」ファイルの以前のバージョンにバージョン番号がなかった場合、0は「.sid」ファイルの古いバージョンのバージョン番号であると想定され、バージョン番号は新しい「.sid」の場合は1です。ファイル。それとは別に、ステップ＃3では以前のSID割り当てが保持され、以前に割り当てられていないヤンアイテムのみが処理され、これらは以前に割り当てられていることを除いて、上記と同じ方法を使用して「.SID」ファイルの変更を自動化することもできます。割り当てられていないSID。「.sid」ファイルに既存のアイテムに新しいSIDが与えられないでください。
Note that ".sid" file versions are specific to a YANG module revision. For each new YANG module or each new revision of an existing YANG module, the version number of the initial ".sid" file either (1) should be 0 or (2) should not be present.
「.SID」ファイルバージョンは、Yangモジュールの改訂に固有のものであることに注意してください。新しいYangモジュールごとに、または既存のYangモジュールの新しい改訂ごとに、（1）のバージョン番号（1）が0または（2）が存在しないでください。
Note also that RPC or action "input" and "output" YANG items MUST always be assigned SIDs even if they don't contain further YANG items. The reason for this requirement is that other modules can augment the given module and those SIDs might be necessary.
また、RPCまたはアクション「入力」および「出力」Yangアイテムには、Yangアイテムが含まれていなくても、常にSIDを割り当てる必要があることに注意してください。この要件の理由は、他のモジュールが指定されたモジュールを増強できるため、それらのSIDが必要になる可能性があるためです。
Before assigning SIDs to their YANG modules, YANG module authors must acquire a SID range from a registry of YANG-SID Ranges. If the YANG module is part of an IETF Internet-Draft or RFC, the SID range needs to be acquired from the "IETF YANG-SID Ranges" registry as defined in Section 6.4. For the other YANG modules, the authors can choose to acquire a SID range from any registry of YANG-SID Ranges.
Yangモジュールの著者は、YangモジュールにSIDを割り当てる前に、Yang-SID範囲のレジストリからSID範囲を取得する必要があります。YangモジュールがIETFインターネットドラフトまたはRFCの一部である場合、SID範囲は、セクション6.4で定義されている「IETF Yang-SID Ranges」レジストリから取得する必要があります。他のYangモジュールの場合、著者は、Yang-SID範囲の登録登録からSID範囲を取得することを選択できます。
Once the SID range is acquired, owners can use it to generate one or more ".sid" files for their YANG module or modules. It is recommended to leave some unallocated SIDs following the allocated range in each ".sid" file in order to allow better evolution of the owners' YANG modules in the future. Generation of ".sid" files should be performed using an automated tool. Note that ".sid" files can only be generated for YANG modules and not for submodules.
SID範囲が取得されると、所有者はそれを使用して、Yangモジュールまたはモジュールの1つ以上の「.SID」ファイルを生成できます。将来所有者のYangモジュールの進化を改善できるように、それぞれの「.SID」ファイルに割り当てられた範囲に従っていくつかの未割り当てのSIDを残すことをお勧めします。「.sid」ファイルの生成は、自動化されたツールを使用して実行する必要があります。「.sid」ファイルは、ヤンモジュールでのみ生成でき、サブモジュールでは生成できないことに注意してください。
The following activity diagram summarizes the creation of a YANG module and its associated ".sid" file.
次のアクティビティ図は、Yangモジュールと関連する「.SID」ファイルの作成をまとめたものです。
+---------------+
o | Creation of a |
-+- -->| YANG module |
/ \ +------+--------+
|
v
.-------------.
/ Standardized \ yes
\ YANG module? /------------+
'-----+-------' |
| no |
v v
.-------------. +---------------+
+--> / Constrained \ yes | SID range |
| \ application? /---->| registration |<--------+
| '-----+-------' +------+--------+ |
| | no | |
| v v |
| +---------------+ +---------------+ |
+----+ YANG module | | SID subrange | |
| update | | assignment |<---------+
+---------------+ +-------+-------+ |
| |
v |
+---------------+ +------+------+
| ".sid" file | | Rework YANG |
| generation | | module |
+-------+-------+ +-------------+
| ^
v |
.----------. yes |
/ Work-in- \ ------------+
\ progress? /
'----+-----'
| no
v
.-------------.
/ RFC \ no
\ publication? /--------------+
'------+------' |
yes | |
v v
+---------------+ +---------------+
| IANA | | Third-party |
| registration | | registration |
+-------+-------+ +-------+-------+
| |
+------------------------+
v
[DONE]
Figure 4: SID Lifecycle
図4：SIDライフサイクル
The following activity diagram summarizes the update of a YANG module and its associated ".sid" file.
次のアクティビティ図は、Yangモジュールと関連する「.SID」ファイルの更新を要約しています。
+--------------------+
o | Update of the |
-+- -->| YANG module, its |
/ \ | include(s), or its |
| import(s) |
+------+-------------+
|
v
.-------------.
/ New items \ yes
\ created? /------+
'------+------' |
| no v
| .-------------. +----------------+
| / SID range \ yes | Extra subrange |
| \ exhausted? /---->| assignment |
| '------+------' +-------+--------+
| | no |
| +---------------------+
| |
| v
| +---------------+
| | ".sid" file |
| | update based |
| | on previous |
| | ".sid" file |
| +-------+-------+
| |
| v
| .-------------. +---------------+
| / Publicly \ yes | YANG module |
| \ available? /---->| registration |
| '------+------' +-------+-------+
| | no |
+--------------+---------------------+
|
v
[DONE]
Figure 5: YANG and ".sid" File Update
図5：Yangと ".sid"ファイルの更新
[RFC9195] defines a format for "YANG instance data". This essentially leads to an encapsulation of the instance data within some metadata envelope.
[RFC9195]は、「Yang Instance Data」の形式を定義します。これは、基本的に、一部のメタデータエンベロープ内のインスタンスデータのカプセル化につながります。
If a ".sid" file needs to be stored in a YANG instance data file, this can be achieved by embedding the value of the ".sid" file as the value of the content-data member in the following template and copying over the second-level members as indicated with the angle brackets:
「.sid」ファイルをYangインスタンスデータファイルに保存する必要がある場合、これは次のテンプレートでコンテンツDATAメンバーの値として「.sid」ファイルの値を埋め込み、コピーすることで実現できます。角度ブラケットに示されている第2レベルのメンバー：
{
"ietf-yang-instance-data:instance-data-set": {
"name": "<module-name>@<module-revision>.sid",
"description": ["<description>"],
"content-schema": {
"module": "ietf-sid-file@2024-06-17"
},
"content-data": { <replace this object>
"ietf-sid-file:sid-file" : {
"module-name": ...
}
}
}
}
The authors would like to thank Andy Bierman, Abhinav Somaraju, Peter van der Stok, Laurent Toutain, and Randy Turner for their help during the development of this document and their useful comments during the review process. Special thanks go to the IESG members who supplied very useful comments during the IESG processing phase, in particular to Benjamin Kaduk and Rob Wilton, and to Francesca Palombini as responsible AD.
著者は、アンディ・ビアマン、アビナヴ・ソマラジュ、ピーター・ファン・デル・ストック、ローラン・トゥーテン、ランディ・ターナーに、この文書の開発中の助けとレビュープロセス中の有用なコメントに感謝したいと思います。IESG処理段階で非常に有用なコメントを提供したIESGメンバー、特にBenjamin KadukとRob Wilton、および責任ある広告としてFrancesca Palombiniに感謝します。
Andy Bierman
YumaWorks
685 Cochran St.
Suite #160
Simi Valley, CA 93065
United States of America
Email: andy@yumaworks.com
Michel Veillette (editor)
Trilliant Networks Inc.
610 Rue du Luxembourg
Granby Quebec J2J 2V2
Canada
Phone: +1-450-375-0556
Email: michel.veillette@trilliant.com
Alexander Pelov (editor)
IMT Atlantique
2 rue de la Châtaigneraie
35510 Cesson-Sévigné Cedex
France
Email: alexander.pelov@imt-atlantique.fr
Ivaylo Petrov (editor)
Google Switzerland GmbH
Brandschenkestrasse 110
CH-8002 Zurich
Switzerland
Email: ivaylopetrov@google.com
Carsten Bormann
Universität Bremen TZI
Postfach 330440
D-28359 Bremen
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
Michael Richardson
Sandelman Software Works
Canada
Email: mcr+ietf@sandelman.ca