[要約] RFC 8726は、独立ストリームでのIANAアクションの処理方法についてのガイドラインです。その目的は、独立ストリームのRFCに関連するIANAアクションの一貫性と効率性を確保することです。
Independent Submission A. Farrel
Request for Comments: 8726 Independent Submissions Editor
Category: Informational November 2020
ISSN: 2070-1721
How Requests for IANA Action Will Be Handled on the Independent Stream
IANAアクションのリクエストが独立したストリームでどのように処理されるか
Abstract
概要
The Internet Assigned Numbers Authority (IANA) maintains registries to track code points used by protocols such as those defined by the IETF and documented in RFCs developed on the IETF Stream.
Internet Assigned Numbers Authority（IANA）は、IETFによって定義され、IETFストリームで開発されたRFCに文書化されているプロトコルなどで使用されるコードポイントを追跡するためのレジストリを維持しています。
The Independent Submission Stream is another source of documents that can be published as RFCs. This stream is under the care of the Independent Submissions Editor (ISE).
Independent Submission Streamは、RFCとして公開できるドキュメントのもう1つのソースです。このストリームは、Independent Submissions Editor（ISE）の管理下にあります。
This document complements RFC 4846 by providing a description of how the ISE currently handles documents in the Independent Submission Stream that request actions from IANA. Nothing in this document changes existing IANA registries or their allocation policies, nor does it change any previously documented processes.
このドキュメントは、ISEがIANAからのアクションを要求するIndependent SubmissionStream内のドキュメントを現在どのように処理するかについての説明を提供することによってRFC4846を補完します。このドキュメントには、既存のIANAレジストリまたはその割り当てポリシーを変更するものはなく、以前に文書化されたプロセスも変更しません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準化過程の仕様ではありません。情報提供の目的で公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは関係なく、RFCシリーズへの貢献です。RFCエディターは、その裁量でこのドキュメントを公開することを選択し、実装または展開の価値については何も述べていません。RFCエディターによる公開が承認されたドキュメントは、どのレベルのインターネット標準の候補でもありません。RFC7841のセクション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/rfc8726.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8726で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2020 IETFTrustおよびドキュメントの作成者として特定された人物。全著作権所有。
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.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction
2. Allocations from Existing Registries
3. Changing Policies of Existing Registries
4. Creating New IANA Registries
5. Assigning Designated Experts
6. Transfer of Control
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Author's Address
The Internet Assigned Numbers Authority (IANA) maintains registries to track code points used by protocols such as those defined by the IETF and documented in RFCs developed on the IETF Stream. A full list of registries and code points can be found at https://www.iana.org/protocols.
Internet Assigned Numbers Authority（IANA）は、IETFによって定義され、IETFストリームで開発されたRFCに文書化されているプロトコルなどで使用されるコードポイントを追跡するためのレジストリを維持しています。レジストリとコードポイントの完全なリストは、https：//www.iana.org/protocolsにあります。
Requests may be made to IANA for actions to create registries or to allocate code points from existing registries. Procedures for these operations are described in [RFC8126].
レジストリを作成するアクション、または既存のレジストリからコードポイントを割り当てるアクションについて、IANAに要求を行うことができます。これらの操作の手順は、[RFC8126]で説明されています。
Many requests for IANA action are included in documents that are progressed for publication as RFCs. RFCs may be sourced from within the IETF (on the IETF Stream) but may also be sourced from other streams, including the Independent Submission Stream (the Independent Stream), as described in [RFC4846]. The Independent Stream is under the care of the Independent Submissions Editor (ISE).
IANAアクションの多くの要求は、RFCとして公開するために進行中のドキュメントに含まれています。RFCは、IETF内（IETFストリーム上）からソースされる場合がありますが、[RFC4846]で説明されているように、独立送信ストリーム（独立ストリーム）を含む他のストリームからソースされる場合もあります。Independent Streamは、Independent Submissions Editor（ISE）の管理下にあります。
This document complements [RFC4846] by providing a description of how the ISE currently handles documents in the Independent Stream that request actions from IANA. Nothing in this document changes existing IANA registries or their allocation policies, nor does it change any previously documented processes.
このドキュメントは、ISEがIANAからのアクションを要求する独立ストリーム内のドキュメントを現在どのように処理するかについての説明を提供することにより、[RFC4846]を補完します。このドキュメントには、既存のIANAレジストリまたはその割り当てポリシーを変更するものはなく、以前に文書化されたプロセスも変更しません。
If a case arises that is not precisely covered by this document, the ISE may discuss a solution with the interested parties, including IANA, the IESG, the stream managers for other streams, and the authors of an Independent Submission that requests IANA action.
このドキュメントで正確にカバーされていないケースが発生した場合、ISEは、IANA、IESG、他のストリームのストリームマネージャー、およびIANAアクションを要求する独立提出物の作成者を含む関係者と解決策について話し合う場合があります。
Each IANA registry is governed by an allocation policy -- the rules that IANA applies to determine which code points can be allocated and under what circumstances. These policies are described in [RFC8126].
各IANAレジストリは、割り当てポリシー（IANAが適用できるルール）によって管理され、どのコードポイントをどのような状況で割り当てることができるかを決定します。これらのポリシーは[RFC8126]で説明されています。
Documents proceeding from the Independent Stream will always follow the assignment policies defined for the registries from which they request allocations. Similarly, all code point assignments are subject to the oversight of any designated expert (DE) appointed for the registry.
インディペンデントストリームから処理されるドキュメントは、割り当てを要求するレジストリに対して定義された割り当てポリシーに従います。同様に、すべてのコードポイントの割り当ては、レジストリに任命された指定されたエキスパート（DE）の監視の対象となります。
It should be noted that documents on the Independent Stream can never result in Standards Track RFCs and Independent Stream documents are never subject to IETF review. Thus, a registry whose policy is "IETF Review" or "Standards Action" [RFC8126] is not available to Independent Stream documents.
独立ストリーム上のドキュメントが標準化過程RFCになることは決してなく、独立ストリーム文書がIETFレビューの対象になることは決してないことに注意する必要があります。したがって、ポリシーが「IETFレビュー」または「標準アクション」[RFC8126]であるレジストリは、IndependentStreamドキュメントでは使用できません。
From time to time, a decision is made to change the allocation policy for a registry. Such changes are normally only made using the allocation policy of the registry itself and usually require documentation from the same stream that created the registry.
レジストリの割り当てポリシーを変更することが時々決定されます。このような変更は通常、レジストリ自体の割り当てポリシーを使用してのみ行われ、通常、レジストリを作成したのと同じストリームからのドキュメントが必要です。
Independent Stream RFCs will not seek to change the allocation policies of any registries except those created by documents from the Independent Stream. The list of such registries is itself very limited (see Section 4).
独立ストリームRFCは、独立ストリームからのドキュメントによって作成されたものを除いて、レジストリの割り当てポリシーを変更しようとはしません。そのようなレジストリのリスト自体は非常に限られています（セクション4を参照）。
Sometimes registries are needed to track a new set of code points for a new protocol or an extension to an existing protocol.
新しいプロトコルまたは既存のプロトコルの拡張のために、新しいコードポイントのセットを追跡するためにレジストリが必要になる場合があります。
In general, documents on the Independent Stream cannot request the creation of a new IANA registry.
一般に、Independent Stream上のドキュメントは、新しいIANAレジストリの作成を要求できません。
The only exception to this rule is when a document to be published in the Independent Submission Stream requests the allocation of a code point from an existing registry with the allocation policy Specification Required, Expert Review, RFC Required, or First Come First Served. Then the document to be published may also need to create a registry that is tied to that specific code point and is used for interpreting a sub-code.
このルールの唯一の例外は、Independent Submission Streamで公開されるドキュメントが、割り当てポリシー仕様が必要、エキスパートレビュー、RFCが必要、または先着順で既存のレジストリからコードポイントの割り当てを要求する場合です。次に、公開するドキュメントで、その特定のコードポイントに関連付けられ、サブコードの解釈に使用されるレジストリを作成する必要がある場合もあります。
Consider, for example, the "Uniform Resource Identifier (URI) Schemes" registry [URL-URIschemes]. From time to time, a URI scheme may need a registry of associated parameters; for example, consider the tel URI scheme that has a register of parameters called the "tel URI Parameters" [URL-telURI].
たとえば、「Uniform Resource Identifier（URI）Schemes」レジストリ[URL-URIschemes]について考えてみます。URIスキームには、関連するパラメーターのレジストリが必要になる場合があります。たとえば、「telURIParameters」[URL-telURI]と呼ばれるパラメータのレジスタを持つtelURIスキームについて考えてみます。
Such examples are rare and only exist to support the allocation from the base registry. In such cases, where there is an appointed DE for the existing base registry, the assignment of the individual code point from the existing base registry and the creation of the new registry can only happen if the DE approves both actions.
このような例はまれであり、ベースレジストリからの割り当てをサポートするためにのみ存在します。このような場合、既存のベースレジストリに指定されたDEがある場合、既存のベースレジストリからの個々のコードポイントの割り当てと新しいレジストリの作成は、DEが両方のアクションを承認した場合にのみ発生します。
There are several further constraints on the new registry:
新しいレジストリには、さらにいくつかの制約があります。
* The allocation policy for the new registry may only be First Come First Served, RFC Required, Experimental, or Private Use. In particular, no registry may be created that would require IETF action to achieve a future code point allocation. See Section 5 for an explanation of why the application of Specification Required and Expert Review are not acceptable policies for any registry created from a document in the Independent Stream.
* 新しいレジストリの割り当てポリシーは、先着順、RFC必須、実験的、または私的使用のみです。特に、将来のコードポイント割り当てを実現するためにIETFアクションを必要とするレジストリを作成することはできません。インディペンデントストリーム内のドキュメントから作成されたレジストリに対して、仕様が必要でエキスパートレビューの適用が受け入れられないポリシーの説明については、セクション5を参照してください。
* If the allocation policy for the new registry is First Come First Served, the document must contain a brief statement and explanation of the expected arrival rate of new registrations over time.
* 新しいレジストリの割り当てポリシーが先入れ先出しである場合、ドキュメントには、時間の経過に伴う新規登録の予想到着率の簡単な説明と説明が含まれている必要があります。
* The new registry must contain a clear statement of the escalation process for any issues that arise with the registry. A model for this statement is as follows:
* 新しいレジストリには、レジストリで発生する問題のエスカレーションプロセスの明確なステートメントが含まれている必要があります。このステートメントのモデルは次のとおりです。
| This registry was created by [RFCXXXX], which was published on the
| Independent Submission Stream. Any issues that arise with the
| management of this registry will be resolved by IANA in
| consultation with the Independent Submissions Editor.
* The IESG will be invited to provide its opinions about the advisability of the creation of any new registries during its conflict review of the document [RFC5742], and the ISE will give full consideration to such opinions.
* IESGは、文書[RFC5742]の競合レビュー中に、新しいレジストリを作成することの妥当性について意見を述べるよう求められ、ISEはそのような意見を十分に考慮します。
Authors of Independent Submission Stream documents should consider the most appropriate venue to host such registries, taking into account where the expertise for managing and reviewing registry assignments may be found. In some cases, this may mean that registries are hosted by organizations other than IANA.
Independent Submission Streamドキュメントの作成者は、レジストリの割り当てを管理および確認するための専門知識がどこにあるかを考慮して、そのようなレジストリをホストするのに最も適切な場所を検討する必要があります。場合によっては、これは、レジストリがIANA以外の組織によってホストされていることを意味する場合があります。
Some IANA allocation policies (specifically, Specification Required and Expert Review) utilize the review of a DE. The procedures applicable to the appointment and actions of a DE are described in Section 5 of [RFC8126].
一部のIANA割り当てポリシー（具体的には、仕様が必要でエキスパートレビュー）は、DEのレビューを利用します。DEの任命と行動に適用される手順は、[RFC8126]のセクション5に記載されています。
When a DE is appointed, the position must be maintained and supported by whoever designated the DE in the first place. That is, someone must appoint replacement DEs if necessary, and someone must provide a backstop in case the appointed DEs are unresponsive.
DEが任命されるとき、その地位は、最初にDEを指定した人によって維持され、支持されなければなりません。つまり、誰かが必要に応じて交換用DEを指定する必要があり、指定されたDEが応答しない場合に備えて誰かがバックストップを提供する必要があります。
The ISE will not appoint a DE. That means that no subregistry created for Independent Stream documents will require the review of a DE. That means that no new subregistry can be created that uses the Specification Required or Expert Review policies.
ISEはDEを指定しません。つまり、Independent Streamドキュメント用に作成されたサブレジストリでは、DEのレビューは必要ありません。つまり、SpecificationRequiredまたはExpertReviewポリシーを使用する新しいサブレジストリを作成することはできません。
Very rarely, it may be desirable to transfer "ownership" of an IANA registry from the Independent Stream to the IETF Stream. This might happen, for example, if a protocol was originally documented in the Independent Stream but has been adopted for work and standardization in the IETF. Such a transfer may require an IETF Stream RFC to act as the base reference for the registry and will require discussion and agreement with the ISE.
ごくまれに、IANAレジストリの「所有権」をIndependentStreamからIETFStreamに転送することが望ましい場合があります。これは、たとえば、プロトコルが元々Independent Streamで文書化されていたが、IETFでの作業と標準化に採用された場合に発生する可能性があります。このような転送では、レジストリの基本参照として機能するIETFストリームRFCが必要になる場合があり、ISEとの話し合いと合意が必要になります。
Ownership of a registry will not be transferred from the IETF Stream to the Independent Stream.
レジストリの所有権は、IETFストリームから独立ストリームに転送されません。
This document is all about IANA actions but makes no request for IANA action.
このドキュメントはすべてIANAアクションに関するものですが、IANAアクションを要求するものではありません。
There are no direct security considerations arising from this document. It may be noted that some IANA registries relate to security protocols, and the stability and proper management of those registries contribute to the stability of the protocols themselves. That is a benefit for the security of the Internet and the users of the Internet.
このドキュメントから生じる直接的なセキュリティ上の考慮事項はありません。一部のIANAレジストリはセキュリティプロトコルに関連しており、それらのレジストリの安定性と適切な管理がプロトコル自体の安定性に貢献していることに注意してください。これは、インターネットとインターネットのユーザーのセキュリティにとってのメリットです。
[RFC4846] Klensin, J., Ed. and D. Thaler, Ed., "Independent Submissions to the RFC Editor", RFC 4846, DOI 10.17487/RFC4846, July 2007, <https://www.rfc-editor.org/info/rfc4846>.
[RFC4846] Klensin、J.、Ed。およびD.Thaler編、「RFCエディターへの独立した提出」、RFC 4846、DOI 10.17487 / RFC4846、2007年7月、<https://www.rfc-editor.org/info/rfc4846>。
[RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for Handling of Independent and IRTF Stream Submissions", BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009, <https://www.rfc-editor.org/info/rfc5742>.
[RFC5742] Alvestrand、H。and R. Housley、 "IESG Procedures for Handling of Independent and IRTF Stream Submissions"、BCP 92、RFC 5742、DOI 10.17487 / RFC5742、December 2009、<https：//www.rfc-editor。org / info / rfc5742>。
[RFC8126] 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>.
[RFC8126] Cotton、M.、Leiba、B。、およびT. Narten、「RFCでIANA考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www.rfc-editor.org / info / rfc8126>。
[URL-telURI] "tel URI Parameters", <https://www.iana.org/assignments/tel-uri-parameters>.
[URL-telURI]「telURIパラメーター」、<https://www.iana.org/assignments/tel-uri-parameters>。
[URL-URIschemes] "Uniform Resource Identifier (URI) Schemes", <https://www.iana.org/assignments/uri-schemes>.
[URL-URIschemes]「UniformResourceIdentifier（URI）Schemes」、<https://www.iana.org/assignments/uri-schemes>。
Acknowledgements
謝辞
Thanks to Brian Carpenter, Subramanian Moonesamy, Craig Partridge, Michelle Cotton, Andrew Malis, Warren Kumari, Ned Freed, Rich Salz, Michael Richardson, Colin Perkins, Stephen Farrell, Barry Leiba, and Benjamin Kaduk for suggestions and advice.
ブライアン・カーペンター、サブラマニア・ムーネサミー、クレイグ・パートリッジ、ミシェル・コットン、アンドリュー・マリス、ウォーレン・クマリ、ネッド・フリード、リッチ・サルツ、マイケル・リチャードソン、コリン・パーキンス、スティーブン・ファレル、バリー・レイバ、ベンジャミン・カドゥクに提案とアドバイスをありがとう。
Author's Address
著者の住所
Adrian Farrel Independent Submissions Editor
エイドリアンファレル独立提出編集者
Email: rfc-ise@rfc-editor.org