[要約] RFC 4714は、IETFの技術出版サービスに関する要件を定義しています。その目的は、IETFの技術文書の品質と一貫性を確保し、効果的な情報の提供を支援することです。
Network Working Group A. Mankin
Request for Comments: 4714
Category: Informational S. Hayes
Ericsson
October 2006
Requirements for IETF Technical Publication Service
IETF技術出版サービスの要件
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Abstract
概要
The work of the IETF is to discuss, develop, and disseminate technical specifications to support the Internet's operation. Technical publication is the process by which that output is disseminated to the community at large. As such, it is important to understand the requirements on the publication process.
Table of Contents
目次
1. Introduction ....................................................2
2. Scope ...........................................................3
2.1. Stages in the Technical Specification Publication
Lifetime ...................................................4
3. Technical Publication Tasks and Requirements ....................5
3.1. Pre-approval Review or Editing .............................6
3.2. Preliminary Specification Availability .....................6
3.3. Post-approval Editorial Cleanup (Non-author Editing) .......7
3.4. Validation of References ...................................9
3.5. Validation of Formal Languages .............................9
3.6. Insertion of Parameter Values .............................10
3.7. Post-approval, Pre-publication Technical Corrections ......10
3.8. Allocation of Permanent Stable Identifiers ................11
3.9. Document Format Conversions ...............................12
3.10. Language Translation .....................................12
3.11. Publication Status Tracking ..............................12
3.12. Expedited Handling .......................................13
3.13. Exception Handling .......................................14
3.14. Notification of Publication ..............................14
3.15. Post-publication Corrections (errata) ....................15
3.16. Indexing: Maintenance of the Catalog .....................15
3.17. Access to Published Documents ............................16
3.18. Maintenance of a Vocabulary Document .....................17
3.19. Providing Publication Statistics and Status Reports ......17
3.20. Process and Document Evolution ...........................18
3.21. Tutorial and Help Services ...............................18
3.22. Liaison and Communication Support ........................19
4. Technical Publisher Performance Goals ..........................20
4.1. Publication Timeframes ....................................20
4.2. Publication Throughput ....................................21
5. IETF Implications of Technical Publication Requirements ........21
6. IANA Considerations ............................................22
7. Security Considerations ........................................22
8. Acknowledgements ...............................................23
9. Informative References .........................................23
The work of the IETF is to discuss, develop, and disseminate technical specifications to support the Internet's operation. Therefore, an important output of the IETF is published technical specifications. The IETF technical publisher is responsible for the final steps in the production of the published technical specifications. This document sets forth requirements on the duties of the IETF technical publisher and how it interacts with the IETF in the production of those publications.
The term "technical specification" is used here purposefully to refer to the technical output of the IETF. This document does not engage in the debate about whether it is expressed as RFCs or otherwise, what "is" an RFC, how to classify them, etc. These issues are considered out of scope.
「技術仕様」という用語は、IETFの技術出力を指すために意図的にここで使用されます。このドキュメントでは、RFCSまたはその他として表現されているかどうか、「RFC」、それらを分類する方法などについての議論に関与していません。これらの問題は範囲外であると見なされます。
The intention of this document is to clarify the IETF's consensus on its requirements for its technical publication service. It is expected to be used in the preparation of future contracts. This document is not a discussion of how well the current technical publisher (the RFC Editor) fulfills those requirements.
The scope of this document is the requirements for the technical publication process for the IETF. Requirements on a technical publisher can be expressed in terms of both what tasks the IETF technical publisher is responsible for and performance targets the IETF technical publisher should meet. The functions provided by the technical publisher are sometimes referred to as editorial management [RFC2850].
This document specifically addresses those documents published by the IETF technical standards process. In all cases, the requirements have been written in generic terms, so that they may be used to express the requirements of other publication streams, elsewhere.
The list of potential technical publication tasks was derived by considering the tasks currently performed by the RFC Editor as well as the responsibilities of the technical publishers in other standards organizations including 3GPP, ATIS, ETSI, IEEE, and ITU.
潜在的な技術出版タスクのリストは、RFCエディターが現在実行しているタスクと、3GPP、ATIS、ETSI、IEEE、ITUを含む他の標準組織における技術出版社の責任を考慮することにより導き出されました。
This requirements document focuses on process issues in how the IETF technical publisher serves the IETF. There are related issues regarding non-technical aspects of document content that are not addressed in this requirements document. Issues not addressed in this document are:
この要件ドキュメントは、IETFテクニカルパブリッシャーがIETFにどのようにサービスを提供するかについてのプロセスの問題に焦点を当てています。この要件ドキュメントでは対処されていないドキュメントコンテンツの非技術的側面に関する関連する問題があります。このドキュメントで対処されていない問題は次のとおりです。
o Policies governing the acceptable input and output document formats (including figures, etc.)
o 許容可能な入力および出力ドキュメント形式を管理するポリシー（図などを含む）
o Policies governing the acceptable character sets (internationalization)
o 許容可能なキャラクターセットを管理するポリシー（国際化）
o Policies governing the layout and style of published documents
o 公開されたドキュメントのレイアウトとスタイルを管理するポリシー
o Policies governing the contents of non-technical sections (acknowledgement sections, reference classifications, etc.)
o 非技術セクションの内容を管理するポリシー（謝辞セクション、参照分類など）
It is realized that the above policies are also important aspects in determining that the final published document is a product of the IETF. These policies are likely to evolve as part of the ongoing IETF dialog. The IETF technical publisher should be part of the discussions of these policies and be prepared to implement and facilitate policy changes as they are determined by IETF consensus. This requirement is captured under the discussion of process and document evolution.
上記のポリシーは、最終公開されたドキュメントがIETFの製品であると判断する上で重要な側面でもあることが認識されています。これらのポリシーは、進行中のIETFダイアログの一部として進化する可能性があります。IETFの技術出版社は、これらのポリシーの議論の一部であり、IETFコンセンサスによって決定されるため、ポリシーの変更を実装および促進する準備をする必要があります。この要件は、プロセスとドキュメントの進化の議論の下でキャプチャされます。
Figure 1 below provides a useful summary of where technical publication falls in the current lifetime of a document in the IETF standards process. This figure shows a Working Group (WG) document and the reviews including Working Group Last Call (WGLC), Area Director (AD) review, IETF Last Call (IETF LC), IANA review, and IESG review. The document shepherd (shown in the diagram as "Shepherd") is an individual designated by the IESG to shepherd a document through the reviews and the publication process and is often not an AD. The lifetime is very similar for AD-sponsored IETF documents, such as documents that update IETF protocols for which there is no longer a working group, or documents on interdisciplinary topics.
以下の図1に、IETF標準プロセスのドキュメントの現在の寿命における技術的な出版物がどこにあるかについての有用な要約を示しています。この図は、ワーキンググループ（WG）ドキュメントと、ワーキンググループラストコール（WGLC）、エリアディレクター（AD）レビュー、IETFラストコール（IETF LC）、IANAレビュー、IESGレビューなどのレビューを示しています。ドキュメントシェパード（「シェパード」として図に示されている）は、IESGによってレビューと出版プロセスを通じて文書を羊飼いするために指定された個人であり、しばしば広告ではありません。Lifetimeは、ワーキンググループがなくなったIETFプロトコルを更新するドキュメントや、学際的なトピックに関するドキュメントなど、広告支援IETFドキュメントに非常に似ています。
Actors Formal Actors Actors Reviews
俳優の正式な俳優俳優のレビュー
| Author, | WGLC | IESG, | | IANA,
| Editor, | AD | Shepherd, | A | Tech
| IETF Sec- | IETF LC | Editor, | P | Publisher,
| retariat | IANA | WG, | P | input from
| | IESG | AD | R | authors, et al.
| | | | O |
Actions | Creation, | | Resolution | V | Non-author
| Editing, | | of all | A | editing,
| Draft Pub,| | reviews | L | other
| Tracking | | | | publication
|---------------| |---------------------| |----------------|
In WG Out of WG Post-approval
Figure 1: Stages of a Working Group Document
図1：ワーキンググループドキュメントの段階
Note that in some cases a single submission may actually consist of multiple source documents (supporting files, code, etc.).
場合によっては、単一の提出物が実際に複数のソースドキュメント（サポートファイル、コードなど）で構成される場合があることに注意してください。
Under the IETF standards process stream, the post-approval processing is initiated by the IESG after technical approval.
IETF標準プロセスストリームでは、承認後処理は、技術的な承認後にIESGによって開始されます。
Standards development organizations all have technical publication as part of their process. However, the boundaries between what is done by the technical committees and the technical publisher vary.
標準開発組織はすべて、プロセスの一環として技術的な出版物を持っています。ただし、技術委員会と技術出版社によって行われることの境界はさまざまです。
The following are potential tasks of a technical publisher. The following list was derived after analyzing the technical publication policies of the IETF and other standards development organizations.
以下は、技術出版社の潜在的なタスクです。次のリストは、IETFおよびその他の標準開発組織の技術出版ポリシーを分析した後に導き出されました。
1. Pre-approval review or editing
1. 承認前のレビューまたは編集
2. Preliminary specification availability
2.
3. Post-approval editorial cleanup (non-author editing)
3. 承認後の編集クリーンアップ（非著者の編集）
4. Validation of references
4.
5. Validation of formal languages
5. 正式な言語の検証
6. Insertion of parameter values
6. パラメーター値の挿入
7. Post-approval, pre-publication technical corrections
7. 承認後、出版前の技術的修正
8. Allocation of permanent stable identifiers
8. 永久安定した識別子の割り当て
9. Document format conversions
9. ドキュメントフォーマット変換
10. Language translation
10. 言語翻訳
11. Publication status tracking
11. 出版ステータス追跡
12. Expedited handling
12. 迅速な取り扱い
13. Exception handling
13.
14. Notification of publication
14. 公開の通知
15. Post-publication corrections (errata)
15.
16. Indexing: maintenance of the catalog
16. インデックス作成：カタログのメンテナンス
17. Access to published documents
17.
18. Maintenance of a vocabulary document
18.
19. Providing publication statistics and status reports 20. Process and document evolution
19. 出版物の統計とステータスレポートの提供20.プロセスとドキュメントの進化
21. Tutorial and help services
21.
22. Liaison and communication support
22.
For each of these tasks, we discuss its relevance to the IETF and how it is realized within the IETF processes. Based upon this information, we derive requirements on the IETF technical publisher.
これらのタスクのそれぞれについて、IETFとの関連性と、IETFプロセス内でそれがどのように実現されるかについて説明します。この情報に基づいて、IETF技術出版社の要件を導き出します。
Task Description: This provides a review or editing service to improve document quality prior to the approval of a document. This review process would normally address issues such as grammar, spelling, formatting, adherence to pre-approval boilerplate, document structure, etc.
タスクの説明：これは、ドキュメントの承認前にドキュメントの品質を改善するためのレビューまたは編集サービスを提供します。このレビュープロセスは、通常、文法、スペル、フォーマット、承認前のボイラープレートへの順守、ドキュメント構造などの問題に対処します。
Discussion: Pre-approval review is not part of the current IETF standards process, but this concept has been explored in the early copyediting experiment. Early feedback from the experiment has been promising; however, the effectiveness of early editing is still being evaluated.
議論：承認前のレビューは、現在のIETF標準プロセスの一部ではありませんが、この概念は早期のコピー編集実験で調査されています。実験からの早期フィードバックは有望です。ただし、早期編集の有効性はまだ評価されています。
Derived Requirements:
派生要件：
Req-PREEDIT-1: The IETF technical publisher should be capable of performing an editorial review of documents early enough to allow changes to be reviewed within the technical review process, should the IETF choose to implement pre-approval editing. For the IETF standards process stream, this review should be performed before WG Last Call and provide feedback to the authors to improve the quality of the documents. For the IETF standards process stream, the publisher should not perform a technical review of the document.
Req-Preedit-1：IETFの技術出版社は、IETFが承認前編集を選択した場合、技術レビュープロセス内で変更をレビューできるように、ドキュメントの編集レビューを十分に早く実行できる必要があります。IETF標準プロセスストリームの場合、このレビューはWGの最後の呼び出しの前に実行され、ドキュメントの品質を向上させるために著者にフィードバックを提供する必要があります。IETF標準プロセスストリームの場合、パブリッシャーはドキュメントの技術レビューを実行してはなりません。
Task Description: Some standards organizations require their publisher to make available a preliminary version of a document (with appropriate caveats) to make the information available to the industry as early as possible. This document is provided "as is" after the approval. This document is withdrawn once the final document is published.
タスクの説明：一部の標準組織は、出版社に、できるだけ早く業界で情報を利用できるようにするために、ドキュメントの予備バージョン（適切な警告を使用して）を利用できるように要求しています。このドキュメントは、承認後に「現状のまま」提供されます。このドキュメントは、最終文書が公開されると撤回されます。
Discussion: This is not required. A final approved version is available as an internet draft. If publication can take more than 6 months, it may be necessary to request that the draft version remains available.
ディスカッション：これは必要ありません。最終的な承認版は、インターネットドラフトとして利用できます。出版物に6か月以上かかる場合は、ドラフトバージョンが利用可能なままであることを要求する必要がある場合があります。
Derived Requirements: none
派生要件：なし
Task Description: Most technical publishers do an editorial review to ensure the quality of published documents. Typically, this may address issues such as grammar, spelling, readability, formatting, adherence to boilerplate, document structure, etc. Since any proposed changes occur after approval, a review and signoff mechanism should usually be established to ensure that the required changes are truly editorial. Since such changes occur outside of the normal approval process, it is desirable that such changes are minimized. Most standards organizations target "light" editing due to the dangers of changing agreed-on text.
タスクの説明：ほとんどの技術出版社は、公開されたドキュメントの品質を確保するために編集レビューを行います。通常、これは、文法、スペル、読みやすさ、フォーマット、ボイラープレートへの順守、ドキュメント構造などの問題に対処する場合があります。社説。このような変更は通常の承認プロセスの外で発生するため、そのような変更が最小化されることが望ましいです。ほとんどの標準組織は、合意されたテキストの変化の危険により、「ライト」編集をターゲットにしています。
Discussion: Within the IETF, the RFC Editor does post-approval cleanup review and editing. The ambition level for cleanup can vary from:
ディスカッション：IETF内で、RFCエディターは承認後のクリーンアップレビューと編集を行います。クリーンアップの野心レベルは次のものから異なります。
o corrections to errors only,
o エラーのみの修正、
o light rewriting,
o 軽い書き換え、
o significant editing of documents with less skillful WG editors, and minimal editing when the WG editors were skilled, to
o 熟練したWGエディターを備えたドキュメントの重要な編集、およびWGエディターが熟練したときの最小限の編集
o rewriting of all documents to the dictates of a style manual.
o すべてのドキュメントをスタイルマニュアルの指示に書き換えます。
At times in the past year, stylistic editing has resulted in a substantial number of changes in many documents. These changes must then be vetted by all the authors followed by subsequent rounds of author acceptance and re-vetting. This can add up to a substantial delay in the publication process, which must be weighed against the incremental gain in communication improvement accomplished by the cleanup.
過去1年間で、文体的な編集により、多くのドキュメントがかなりの数の変更が生じました。これらの変更は、すべての著者によって吟味され、その後の著者の受け入れと再vetのラウンドが続く必要があります。これにより、公開プロセスの大幅な遅延が増える可能性があります。これは、クリーンアップによって達成されたコミュニケーション改善の増分ゲインと比較検討する必要があります。
Changes to improve readability (or possibly even grammar) can end up inadvertently affecting consensus wording or technical meaning. Note that pre-approval editing to some extent avoids this problem.
読みやすさを改善するための変更（または文法）は、コンセンサスの言葉遣いや技術的な意味に不注意に影響を与える可能性があります。承認前の編集により、ある程度の問題が回避されることに注意してください。
In specific instances, it may be necessary to require that text be published "verbatim" even if doing so introduces what is perceived as poor readability or stylistic inconsistency. Examples of this include:
特定の例では、テキストを「逐語的」に公開することを要求する必要がある場合があります。これの例は次のとおりです。
- "Boilerplate" agreed on in an IETF working group to apply to all instances of derivative works (e.g., IANA registration documents and Management Information Bases (MIBs)).
- 「ボイラープレート」は、IETFワーキンググループで、デリバティブ作業のすべてのインスタンス（IANA登録文書および管理情報ベース（MIBS））に適用するために同意しました。
- Text referring to other organizations' work that has been carefully phrased and arranged with representatives of that other organization to deal with some politically sensitive issue.
- 政治的に敏感な問題に対処するために、その他の組織の代表者と慎重に表現され、整理されている他の組織の仕事を参照するテキスト。
If pre-approval editing or review is done, it may be possible to reduce or even eliminate entirely the post-approval editing task in some cases. Pre-approval editing may be more efficient since a separate change control process is not required.
承認前の編集またはレビューが行われた場合、場合によっては承認後の編集タスクを完全に削減または排除することさえ可能かもしれません。個別の変更制御プロセスは必要ないため、承認前の編集はより効率的になる場合があります。
Derived Requirements:
派生要件：
o Req-POSTEDIT-1 - The IETF technical publisher should review the document for grammar, spelling, formatting, alignment with boilerplate, document structure, etc. The review should strive to maintain consistency in appearance with previously published documents. In the IETF standards process stream, the publisher should not perform a technical review of the document.
o req-postedit-1-IETF技術パブリッシャーは、文法、スペル、フォーマット、ボイラープレート、ドキュメント構造などとのアライメントについてドキュメントを確認する必要があります。レビューは、以前に公開されたドキュメントとの外観の一貫性を維持するよう努力する必要があります。IETF標準プロセスストリームでは、パブリッシャーはドキュメントの技術的なレビューを実行すべきではありません。
o Req-POSTEDIT-2 - All changes made to post-approval documents should be tracked and the changes must be signed off on by the appropriate technical representatives. For the IETF standards process stream, this includes the authors, the document shepherd (if there is one), and the Area Director. The Area Director is the authority for approval of all changes.
o req-postedit-2-承認後の文書に行われたすべての変更を追跡し、適切な技術的代表者が変更を承認する必要があります。IETF標準プロセスストリームの場合、これには著者、ドキュメントシェパード（1つがある場合）、およびエリアディレクターが含まれます。エリアディレクターは、すべての変更を承認する権限です。
o Req-POSTEDIT-3 - The IETF technical publisher should exercise restraint in making stylistic changes that introduce a substantial review load but only provide an incremental increase in the clarity of the specification. Specific guidelines on the types of changes allowed may be further specified, but ultimately restraint in editing must be imposed by the IETF technical publisher. Changes for stylistic consistency should be done only when there are major problems with the quality of the document.
o REQ-POSTEDIT-3-IETF技術パブリッシャーは、実質的なレビュー負荷を導入するが、仕様の明確性の増加の増加のみを提供する文体的な変更を行う際に抑制を行使する必要があります。許可されている変更の種類に関する特定のガイドラインがさらに指定される場合がありますが、最終的に編集の抑制はIETF技術パブリッシャーによって課さなければなりません。文体の品質に大きな問題がある場合にのみ、文体的な一貫性の変更を行う必要があります。
o Req-POSTEDIT-4 - The IETF technical publisher should exercise restraint in making changes to improve readability that may change technical and consensus wording. Specific guidelines on the types of changes allowed may be further specified, but ultimately restraint in editing must be imposed by the IETF technical publisher.
o req-postedit-4-IETF技術出版社は、技術的およびコンセンサスの言葉遣いを変更する可能性のある読みやすさを改善するために変更を加えるために抑制を行使する必要があります。許可されている変更の種類に関する特定のガイドラインがさらに指定される場合がありますが、最終的に編集の抑制はIETF技術パブリッシャーによって課さなければなりません。
o Req-POSTEDIT-5 - In specific instances, where some or all of document text is the result of a careful negotiation of contributions (within or between working groups, reviewers, etc.), the technical publisher may be required to publish that text verbatim. In the IETF standards process, verbatim publication may be requested by the IESG. It is the expectation of the IETF community that this will not be done often.
o req-postedit-5-特定の例では、ドキュメントテキストの一部またはすべてが、貢献の慎重な交渉の結果である場合（ワーキンググループ、レビュー担当者など）、技術出版社はそのテキストの逐語的な公開を必要とする場合があります。IETF標準プロセスでは、IESGから逐語的な公開が要求される場合があります。これが頻繁に行われないのは、IETFコミュニティの期待です。
Task Description: Most standards organizations require that normative references be publicly available. Some technical publishers verify the validity and availability of references (including referenced clauses and figures). Although some editorial cleanup of references may be obvious, the issue becomes more severe when reference links are broken, are not publicly available, or refer to obsoleted documents. Such faults may be viewed as a post-approval fault found in the document. Most publishers have the ability to put a document on hold awaiting the publication of a reference expected to be available soon.
タスクの説明：ほとんどの標準組織は、規範的な参照を公開する必要があります。一部の技術出版社は、参照の妥当性と可用性を検証します（参照された条項と図を含む）。一部の編集上の参照のクリーンアップは明らかな場合がありますが、参照リンクが壊れたり、公開されていない場合、または廃止されたドキュメントを参照すると、問題はより深刻になります。このような障害は、文書にある承認後の障害と見なされる場合があります。ほとんどの出版社は、すぐに利用可能になると予想されるリファレンスの公開を待っているドキュメントを保留にする能力を持っています。
Discussion: The RFC Editor may put a document on hold while waiting for the availability of other IETF documents. Incorrect references are handled like any other fault detected in the editorial review.
ディスカッション：RFCエディターは、他のIETFドキュメントの可用性を待っている間にドキュメントを保留する場合があります。誤った参照は、編集レビューで検出された他の障害と同様に処理されます。
Derived Requirements:
派生要件：
o Req-REFVAL-1 - The IETF technical publisher should ensure that all references within specifications are currently available and are expected to remain available.
o REQ-REFVAL-1-IETFテクニカルパブリッシャーは、仕様内のすべての参照が現在利用可能であり、利用可能なままであることが期待されることを確認する必要があります。
o Req-REFVAL-2 - The IETF technical publisher should delay publication until all required (normative) references are ready for publication.
o Req-Refval-2-IETF技術パブリッシャーは、必要な（規範的）参照がすべて公開されるまで公開を遅らせる必要があります。
Task Description: If the specification contains a formal language section (such as a MIB), the technical publisher may be required to validate this using a tool.
タスクの説明：仕様に正式な言語セクション（MIBなど）が含まれている場合、技術出版社はツールを使用してこれを検証する必要がある場合があります。
Discussion: The RFC Editor syntactically validates sections of a document containing MIBs, Augmented Backus Naur Form (ABNF), eXtensible Markup Language (XML), Abstract Syntax Notation One (ASN.1), and possibly other formal languages.
ディスカッション：RFCエディターは、MIBS、拡張されたBackus Naurフォーム（ABNF）、拡張可能なマークアップ言語（XML）、抽象的構文表記1（ASN.1）、および場合によっては他の正式な言語を含むドキュメントのセクションを構文的に検証します。
Derived Requirements:
派生要件：
o Req-FORMALVAL-1 - The IETF technical publisher should validate the syntax of sections of documents containing formal languages. In particular, ASN.1, ABNF, and XML should be verified using appropriate tools.
o Req-FormalVal-1-IETF技術パブリッシャーは、正式な言語を含むドキュメントのセクションの構文を検証する必要があります。特に、ASN.1、ABNF、およびXMLは、適切なツールを使用して検証する必要があります。
Task Description: The technical publisher is expected to work with IANA (or possibly other organizations maintaining registries) to populate assigned protocol parameter values when required, prior to publication. The population of these parameters values should not require technical expertise by the technical publisher.
タスクの説明：技術出版社は、IANA（またはレジストリを維持している他の組織）と協力して、公開前に、必要に応じて割り当てられたプロトコルパラメーター値を設定することが期待されています。これらのパラメーター値の人口は、技術出版社による技術的な専門知識を必要としないはずです。
Discussion: Within the IETF, IANA normally does its allocations as an early step in the technical publication process.
議論：IETF内で、IANAは通常、技術出版プロセスの初期のステップとして割り当てを行います。
Derived Requirements:
派生要件：
o Req-PARAMEDIT-1 - The IETF technical publisher should work with IANA in the population of required parameter values into documents.
o Req-Paramedit-1-IETF技術パブリッシャーは、必要なパラメーター値の母集団でIANAと協力してドキュメントに協力する必要があります。
Task Description: Regardless of efforts to minimize their occurrence, it is always possible that technical flaws will be discovered in the window between document approval and publication. The technical publisher may be requested to incorporate technical changes into the document prior to publication. Such changes necessitate a review and sign-off procedure. Another option is to disallow such corrections and treat them as post-publication errata would be treated. Note that this task is distinct from post-approval changes that might originate due to editorial review because they originate from outside the technical publisher. For severe flaws, it should always be possible to withdraw the document from the publication queue (see Section 3.13).
タスクの説明：それらの発生を最小限に抑える努力に関係なく、ドキュメントの承認と公開の間のウィンドウで技術的な欠陥が発見される可能性が常にあります。技術出版社は、公開前に技術的な変更を文書に組み込むように要求される場合があります。このような変更には、レビューとサインオフ手順が必要です。別のオプションは、そのような補正を禁止し、出版後の誤差が治療されるように扱うことです。このタスクは、技術出版社の外部から発生するため、編集レビューが原因で発生する可能性のある承認後の変更とは異なることに注意してください。深刻な欠陥については、出版キューから文書を引き出すことができるはずです（セクション3.13を参照）。
Discussion: The IETF allows minor technical corrections during the publication process. This should ideally be a rare occurrence. Since any changes introduced during the post-approval phase can lead to publication delays, it is important that only changes with technical merit be permitted. In particular, stylistic changes should be discouraged. IETF processes must be in place to vet changes proposed by the author, but this is not specifically a requirement on the technical publisher.
ディスカッション：IETFは、出版プロセス中に軽微な技術的修正を可能にします。これは理想的にはまれな出来事であるはずです。承認後の段階で導入された変更は、公開の遅延につながる可能性があるため、技術的なメリットを伴う変更のみが許可されることが重要です。特に、文体的な変化は落胆する必要があります。IETFプロセスは、著者によって提案された変更を審査するために整備されている必要がありますが、これは特に技術出版社の要件ではありません。
The interaction between the authors and the technical publisher must be sufficiently well policed that untracked and unapproved changes cannot be introduced by the author or other parties.
著者と技術出版社との間の相互作用は、著者や他の当事者が追跡せず承認されていない変更を導入できないほど十分に警察されなければなりません。
Derived Requirements:
派生要件：
o Req-POSTCORR-1 - The IETF technical publisher should permit the incorporation of technical changes detected after approval but pre-publication.
o Req-Postcorr-1-IETF技術出版社は、承認後に検出されたが事前に公開された技術的な変更を組み込むことを許可する必要があります。
o Req-POSTCORR-2 - The IETF technical publisher should only allow post-approval technical changes that have been approved by the appropriate party. In the IETF standards process stream, this includes the authors and the Area Director. The document shepherd (if there is one) should be kept informed of these changes.
o Req-Postcorr-2-IETF技術出版社は、適切な当事者によって承認された承認後の技術的変更のみを許可する必要があります。IETF標準プロセスストリームには、著者とエリアディレクターが含まれます。ドキュメントシェパード（ある場合）には、これらの変更を知らせておく必要があります。
o Req-POSTCORR-3 - The IETF technical publisher should alert the appropriate authority when it feels that a requested change is suspect (e.g., an unapproved technical alteration) or unreasonable (e.g., massive editorial changes). Further processing of the draft should be suspended pending a response by that authority. For the IETF standards process stream, that authority is the Area Director. If there is a document shepherd working with the Area Director, the shepherd should be notified and kept informed as well.
o req-postcorr-3- IETFの技術出版社は、要求された変更が疑わしい（承認されていない技術的変更）または不合理（例えば、大規模な編集上の変更）であると感じた場合、適切な権限を警告する必要があります。ドラフトのさらなる処理は、その当局による応答が保留されているまで停止する必要があります。IETF標準プロセスストリームの場合、その権限はエリアディレクターです。エリアディレクターと協力している文書羊飼いがある場合、羊飼いに通知され、同様に情報を提供する必要があります。
o Req-POSTCORR-4 - The IETF technical publisher should ensure that any source documents associated with a publication are updated in conjunction with their associated specifications.
o Req-PostCorr-4-IETF技術出版社は、出版物に関連するソースドキュメントが、関連する仕様と併せて更新されるようにする必要があります。
Task Description: For a document to be referenced, it must have a unique permanent identifier. In some standards organizations, it is the technical publisher that generates this identifier. In other cases, the identifier may be allocated earlier in the process.
タスクの説明：文書を参照するには、一意の永久識別子が必要です。一部の標準組織では、この識別子を生成するのは技術出版社です。それ以外の場合、識別子はプロセスの早期に割り当てられる場合があります。
Discussion: Currently, the RFC Editor allocates RFC numbers and other identifiers (the current IETF stable identifiers) when the document is near the end of the publication process. Having identifiers allocated early was considered, but a definite need could not be established.
ディスカッション：現在、RFCエディターは、ドキュメントが公開プロセスの終わり近くにある場合、RFC番号とその他の識別子（現在のIETF安定性識別子）を割り当てています。識別子を早期に割り当てることを考慮しましたが、明確なニーズを確立することはできませんでした。
Derived Requirements:
派生要件：
o Req-PERMID-1 - The IETF technical publisher should allocate stable identifiers as part of the publication process.
o Req-Permid-1-IETFテクニカルパブリッシャーは、公開プロセスの一部として安定した識別子を割り当てる必要があります。
o Req-PERMID-2 - The IETF technical publisher should assign additional permanent identifiers associated with various classes of documents as directed by the appropriate authority. For the IETF standards process stream, that authority is the IESG.
o Req-Permid-2-IETF技術パブリッシャーは、適切な当局が指示するように、さまざまなクラスのドキュメントに関連付けられた追加の永続的な識別子を割り当てる必要があります。IETF標準プロセスストリームの場合、その権限はIESGです。
Task Description: The technical publisher is responsible for converting the documents into one or more output formats (e.g., text, Portable Document Format (PDF)). In some standards organizations, the technical publisher may be required to accept input documents in various formats and produce a homogeneous set of output documents.
Discussion: Currently, the RFC Editor accepts input as an ASCII text file. The RFC Editor has also accepted supplementary formats that were used to generate the ASCII text (XML and NROFF). The documents are published as ASCII text and PDF files.
ディスカッション：現在、RFCエディターはASCIIテキストファイルとして入力を受け入れています。RFCエディターは、ASCIIテキスト（XMLおよびNROFF）を生成するために使用された補足形式も受け入れています。ドキュメントは、ASCIIテキストおよびPDFファイルとして公開されています。
Derived Requirements:
派生要件：
o Req-DOCCONVERT-1 - The IETF technical publisher should accept as input ASCII text files and publish documents as ASCII text files and PDF files.
o req-docconvert-1-IETFテクニカルパブリッシャーは、入力ASCIIテキストファイルとして受け入れ、ASCIIテキストファイルおよびPDFファイルとしてドキュメントを公開する必要があります。
o Req-DOCCONVERT-2 - The technical publisher should accept supplemental files that may contain information such as code, formal descriptions (e.g., XML, ASN.1) graphics, data files, etc. Supplemental files may also include enhanced versions of the document containing graphics or sections not presentable in text format. Any supplemental files, barring any changes to the IETF process rules, will be associated with the published IETF documents, but may not be editable by the publisher.
o Req-DocConvert-2-技術出版社は、コード、正式な説明（XML、ASN.1など）グラフィックス、データファイルなどの情報などの情報を含む補足ファイルを受け入れる必要があります。テキスト形式では表示できないグラフィックまたはセクション。IETFプロセスルールの変更を禁止する補足ファイルは、公開されているIETFドキュメントに関連付けられますが、出版社は編集できない場合があります。
Task Description: Some standards organizations require publication of documents in multiple languages. This translation is the responsibility of the technical publisher.
タスクの説明：一部の標準組織は、複数の言語でドキュメントを公開する必要があります。この翻訳は、技術出版社の責任です。
Discussion: IETF specifications are published only in English.
ディスカッション：IETF仕様は英語でのみ公開されています。
Derived Requirements: none
Task Description: The technical publisher should have the ability to provide status information on the status of a document. This may involve developing a process model or a checklist and providing information on a document's state, outstanding issues, and responsibility tokens. Depending on the need for transparency, this information may need to be available online and continuously updated.
タスクの説明：技術出版社には、ドキュメントのステータスに関するステータス情報を提供する機能が必要です。これには、プロセスモデルまたはチェックリストを開発し、ドキュメントの状態、未解決の問題、および責任に関する情報を提供する場合があります。透明性の必要性に応じて、この情報はオンラインで利用可能になり、継続的に更新する必要がある場合があります。
Discussion: The RFC Editor currently provides status information via the RFC Editor queue. Each document is attributed a status (e.g., AUTH48, RFC-EDITOR, IANA, ISR). Items may stay in the queue for a long time without changing status. This status tracking information is not integrated with the IESG tracking tools. Within the IETF, the Process and Tools (PROTO) team is considering requirements for marking the token-holder accurately during long waiting periods, and others are looking into improved notification tools. Requirements on the IETF technical publisher for improved status integration and visibility could be met by collaborations with these efforts, by providing public access to email logs regarding publications, or by some other proposal.
ディスカッション：RFCエディターは現在、RFCエディターキューを介してステータス情報を提供しています。各ドキュメントは、ステータス（Auth48、RFC-Editor、IANA、ISRなど）に起因しています。アイテムは、ステータスを変更せずに長い間キューに留まることがあります。このステータス追跡情報は、IESG追跡ツールと統合されていません。IETF内では、プロセスおよびツール（ProTO）チームは、長い待機期間中にトークンホルダーを正確にマークするための要件を検討しており、他のチームは改善された通知ツールを検討しています。IETFの技術出版社の要件は、ステータスの統合と可視性を改善するための要件を、これらの取り組みとのコラボレーション、出版物に関する電子メールログへのパブリックアクセスを提供すること、またはその他の提案によって満たすことができます。
Derived Requirements:
派生要件：
o Req-STATUSTRK-1 - The IETF technical publisher should make state information publicly available for each document in the publication process. It is desirable that this information be available through a documented interface to facilitate tools development.
o REQ-STATURTK-1-IETF技術パブリッシャーは、公開プロセスで各ドキュメントで州情報を公開する必要があります。この情報は、ツール開発を促進するために、文書化されたインターフェイスを通じて利用できることが望ましいです。
o Req-STATUSTRK-2 - The IETF technical publisher should integrate its state information with the IETF tools to provide end-to-end status tracking of documents. For the documents in the IETF standards process stream, it is expected that documents should be able to move seamlessly from the IETF standards tracking system into the technical publication tracking system.
o REQ-STATURTK-2-IETF技術パブリッシャーは、その状態情報をIETFツールと統合して、ドキュメントのエンドツーエンドステータス追跡を提供する必要があります。IETF標準プロセスストリームのドキュメントの場合、ドキュメントはIETF標準追跡システムから技術出版追跡システムにシームレスに移動できる必要があると予想されます。
o Req-STATUSTRK-3 - The IETF technical publisher should provide external visibility of not only the fact that a document is in an extended waiting period but also the token-holder and circumstances of the wait.
o req-staturtk-3-IETF技術パブリッシャーは、ドキュメントが延長待機期間だけでなく、トークンホルダーと待機の状況であるという事実の外部可視性を提供する必要があります。
Task Description: In some cases (such as when the documents are needed by another standards body), it should be possible for the approving organization to request expedited publication of a document. Ideally, this should not skip any of the publication steps, but allocates it higher priority in the work queue to ensure earlier publication than normal. Expedited publication should be used sparingly since as with any priority scheme, overuse will negate its benefits.
タスクの説明：場合によっては（別の標準機関がドキュメントが必要な場合など）、承認組織が文書の迅速な公開を要求することが可能であるはずです。理想的には、これは出版手順をスキップする必要はありませんが、作業キューでより高い優先度を割り当てて、通常よりも早期の出版物を確保します。優先順位のスキームと同様に、過剰使用がその利点を無効にするため、迅速な出版物は控えめに使用する必要があります。
Discussion: The fast-tracking procedure is used to expedite publication of a document at the request of the IESG. Fast-tracking is generally employed when an external organization has a looming publication deadline and a need to reference a document currently in the RFC Editor's queue. Having short publication times would likely reduce the need for fast-tracking.
ディスカッション：高速追跡手順は、IESGの要求に応じて文書の公開を促進するために使用されます。一般に、外部組織が迫り来る出版物の締め切りがあり、現在RFCエディターのキューにあるドキュメントを参照する必要がある場合、一般に採用されます。公開時間が短いと、迅速な追跡の必要性が減る可能性があります。
Since fast-tracking is disruptive to the work flow, it is recommended that expedited handling be phased out as soon as alternative ways of achieving timely publication are in place.
高速追跡はワークフローを破壊するため、タイムリーな出版物を達成する別の方法が導入されるとすぐに、迅速な取り扱いを段階的に廃止することをお勧めします。
Derived Requirements:
派生要件：
o Req-EXPEDITE-1 - The IETF technical publisher should expedite the processing of specific documents at the request of an appropriate authority. For the IETF standards process stream, that authority is the IESG or the IAB.
o
Task Description: It should be possible for various reasons for a document to be withdrawn from publication or the publication to be put on hold. Reasons for this could be due to an appeals process, detection of a serious technical flaw, or determination that the document is unsuitable for publication.
Discussion: For various reasons, a document can be withdrawn before publication.
ディスカッション：さまざまな理由で、公開前に文書を撤回することができます。
Derived Requirements:
派生要件：
o Req-EXCEPTIONS-1 - The IETF technical publisher should permit documents to be withdrawn from publication at the direction of an appropriate authority. For the IETF standards process stream, that authority is the IESG.
o req-exceptions-1-IETF技術出版社は、適切な当局の指示での出版から文書を撤回することを許可する必要があります。IETF標準プロセスストリームの場合、その権限はIESGです。
o Req-EXCEPTIONS-2 - The IETF technical publisher should permit documents to be put on hold awaiting the outcome of an appeal at the direction of an appropriate authority. For the IETF standards process stream, that authority is the IESG.
o req-exceptions-2-IETF技術出版社は、適切な当局の指示での控訴の結果を待っている文書を保留にすることを許可する必要があります。IETF標準プロセスストリームの場合、その権限はIESGです。
Task Description: The technical publisher should provide a mechanism for alerting the community at large of the availability of published documents.
タスクの説明：技術出版社は、公開されたドキュメントの利用可能性について、コミュニティに警告するためのメカニズムを提供する必要があります。
Discussion: The RFC Editor notifies the community of document publication on the rfc-dist and ietf-announce mailing lists.
ディスカッション：RFCエディターは、RFC-DistおよびIETF-Announceメーリングリストに関するドキュメント公開のコミュニティに通知します。
Derived Requirements:
派生要件：
o Req-PUBNOTIFY-1 - The IETF technical publisher should announce the availability of published documents.
o req-pubnotify-1-IETF技術出版社は、公開されたドキュメントの可用性を発表する必要があります。
Task Description: If corrections are identified after publication, the technical publisher should be able to publish errata that can be linked with the original document.
タスクの説明：公開後に修正が特定された場合、技術出版社は元のドキュメントにリンクできるErrataを公開できるはずです。
Discussion: The RFC Editor maintains a list of errata. Pointers to relevant errata are presented as output from the RFC Editor search engine.
ディスカッション：RFCエディターは、Errataのリストを維持しています。関連するERRATAへのポインターは、RFCエディター検索エンジンからの出力として表示されます。
Derived Requirements:
派生要件：
o Req-ERRATA-1 - The IETF technical publisher should maintain errata for published documents. The process for review, updating, and approval of errata for IETF documents will be defined by the IETF.
o req-errata-1-IETF技術パブリッシャーは、公開されたドキュメントのserrataを維持する必要があります。IETFドキュメントのERRATAのレビュー、更新、承認のプロセスは、IETFによって定義されます。
o Req-ERRATA-2 - The IETF technical publisher should provide information on relevant errata as part of the information associated with an RFC.
o REQ-ERRATA-2-IETF技術出版社は、RFCに関連する情報の一部として、関連するErrataに関する情報を提供する必要があります。
Task Description: The technical publisher normally provides and maintains the master catalog of publications of that organization. As the publishers of the organization's output, the technical publisher is expected to be the definitive source of publications and the maintainer of the database of published documents. This also includes the cataloging and storage of meta-information associated with documents such as their history, status (e.g., updated, obsoleted), document categories (e.g., standard, draft standard, BCP).
タスクの説明：技術出版社は通常、その組織の出版物のマスターカタログを提供および維持します。組織の出力の出版社として、技術出版社は出版物の決定的なソースであり、公開されたドキュメントのデータベースのメンテナーになることが期待されています。これには、履歴、ステータス（更新、廃止）、ドキュメントカテゴリ（標準、ドラフト標準、BCPなど）などのドキュメントに関連するメタ情報のカタログとストレージも含まれます。
Discussion: The RFC Editor maintains the catalog. The RFC Editor is also responsible for the permanent archival of specifications. Meta-information associated with an RFC should also be maintained. Since this is the definitive archive, sufficient security should be in place to prevent tampering with approved documents.
ディスカッション：RFCエディターはカタログを維持しています。RFCエディターは、仕様の永続的なアーカイブについても責任を負います。RFCに関連するメタ情報も維持する必要があります。これは決定的なアーカイブであるため、承認されたドキュメントの改ざんを防ぐのに十分なセキュリティが整っている必要があります。
Derived Requirements:
派生要件：
o Req-INDEX-1 - The IETF technical publisher should maintain the index of all IETF published documents. It is desirable that the interface to the index be documented to facilitate tools development.
o Req-Index-1-IETF技術パブリッシャーは、すべてのIETF公開ドキュメントのインデックスを維持する必要があります。ツールの開発を促進するために、インデックスへのインターフェイスを文書化することが望ましいです。
o Req-INDEX-2 - The IETF technical publisher should provide the permanent archive for published documents.
o REQ-Index-2-IETF技術パブリッシャーは、公開されたドキュメントの常設アーカイブを提供する必要があります。
o Req-INDEX-3 - Meta-information associated with a published document must be stored and updated as its status changes.
o REQ-Index-3-公開されたドキュメントに関連付けられたメタ情報は、ステータスが変更されるにつれて保存および更新する必要があります。
o Req-INDEX-4 - The archive must be sufficiently secure to prevent the modification of published documents by external parties.
o Req-Index-4-外部関係者による公開された文書の変更を防ぐために、アーカイブは十分に安全でなければなりません。
o Req-INDEX-5 - The IETF technical publisher should provide the permanent archive of any source documents associated with a published specification.
o Req-Index-5-IETF技術パブリッシャーは、公開された仕様に関連付けられたソースドキュメントの永続的なアーカイブを提供する必要があります。
o Req-INDEX-6 - An appropriate authority can indicate to the publisher that it should change the status of a document (e.g., to Historical) and this should be reflected in the index. For the IETF standards process stream, the indicating authority is the IESG.
o Req-Index-6-適切な当局は、ドキュメントのステータス（たとえば、歴史）を変更する必要があることをパブリッシャーに示すことができ、これはインデックスに反映される必要があります。IETF標準プロセスストリームの場合、指定当局はIESGです。
Task Description: The technical publisher should facilitate access to the documents published. It is assumed that the technical publisher will provide online tools to search for and find information within the archive of published documents. These access tools should facilitate understanding the state of the document (e.g., identification of replacement or updated documents, linkage to pertinent errata).
タスクの説明：技術出版社は、公開されたドキュメントへのアクセスを容易にする必要があります。テクニカルパブリッシャーは、公開されたドキュメントのアーカイブ内で情報を検索して検索するためのオンラインツールを提供すると想定されています。これらのアクセスツールは、ドキュメントの状態を理解することを容易にする必要があります（たとえば、交換または更新されたドキュメントの識別、適切な正誤表へのリンク）。
Discussion: Documents and status may be accessed via the RFC Editor's web page.
ディスカッション：ドキュメントとステータスには、RFCエディターのWebページからアクセスできます。
Derived Requirements:
o Req-PUBACCESS-1 - The IETF technical publisher should provide search tools for finding and retrieving published documents.
o REQ-PUBACCESS-1-IETFテクニカルパブリッシャーは、公開されたドキュメントを見つけて取得するための検索ツールを提供する必要があります。
o Req-PUBACCESS-2 - The IETF technical publisher tool should return relevant meta-information associated with a published document (e.g., category of document, type of standard (if standards track), obsoleted by or updated by information, associated errata).
o REQ-PUBACCESS-2-IETFテクニカルパブリッシャーツールは、公開されたドキュメント（例：ドキュメントのカテゴリ、標準トラックのタイプ（標準トラックの場合）の種類）に関連付けられた関連するメタ情報を返します。
o Req-PUBACCESS-3 - The IETF technical publication search tools should be integrated with the IETF search tools. For the IETF standards process stream, this refers to integration with the search tools used by the IETF standards process.
o REQ-PUBACCESS-3-IETF技術出版物検索ツールは、IETF検索ツールと統合する必要があります。IETF標準プロセスストリームの場合、これはIETF標準プロセスで使用される検索ツールとの統合を指します。
Task Description: Some standards organizations require the technical publisher to maintain a publicly available vocabulary document or database containing common terms and acronyms. The goal is to provide consistency of terminology between documents.
タスクの説明：一部の標準組織は、一般的に利用可能な語彙文書または一般的な用語と頭字語を含むデータベースを維持するために技術出版社を要求しています。目標は、ドキュメント間で用語の一貫性を提供することです。
Discussion: The RFC Editor does not maintain a public document or database of terms or acronyms.
ディスカッション：RFCエディターは、用語や頭字語の公開文書やデータベースを維持していません。
Derived Requirements: none
派生要件：なし
Task Description: The technical publisher may be required to periodically or continuously measure its performance. In many standards organizations, performance targets are set in terms of timeliness, throughput, etc.
タスクの説明：技術出版社は、定期的または継続的にそのパフォーマンスを測定する必要がある場合があります。多くの標準組織では、パフォーマンス目標が適時、スループットなどの観点から設定されています。
Discussion: The IETF technical publisher currently provides monthly statistics on arrivals and completions of documents by category. In addition, a status report is provided at each IETF meeting. Other statistics can be used to judge the health of the editing process. Many of these statistics could be gathered using sampling techniques to avoid excessive load on the technical publisher.
ディスカッション：IETF技術出版社は現在、カテゴリごとの到着とドキュメントの完成に関する毎月の統計を提供しています。さらに、各IETF会議でステータスレポートが提供されます。他の統計を使用して、編集プロセスの健康を判断できます。これらの統計の多くは、技術出版社の過度の負荷を避けるために、サンプリング手法を使用して収集できます。
Derived Requirements:
派生要件：
o Req-STATS-1 - The IETF technical publisher should provide publicly available monthly statistics on average queue times and documents processed. The presentation should provide a historical context to identify trends (see Goal-THROUGHPUT-1). For the IETF standards process, this should include queue arrivals, completions, documents in the queue, and the number of documents in each state at the end of the month.
o REQ-STATS-1-IETFテクニカルパブリッシャーは、平均的なキュー時間と処理されたドキュメントについて、一般に利用可能な毎月の統計を提供する必要があります。プレゼンテーションは、トレンドを特定するための歴史的コンテキストを提供する必要があります（Goal-Throughput-1を参照）。IETF標準プロセスの場合、これには、キューの到着、完了、キュー内のドキュメント、および月末の各州のドキュメントの数を含める必要があります。
o Req-STATS-2 - The IETF technical publisher should provide periodic status reports at the IETF meetings to apprise the community of its work and performance.
o REQ-STATS-2-IETF技術パブリッシャーは、IETF会議で定期的なステータスレポートを提供して、コミュニティにその仕事とパフォーマンスを把握する必要があります。
o Req-STATS-3 - The IETF technical publisher should provide publicly available monthly statistics on the types of editorial corrections being found during reviews as well as the percentage of corrections that are rejected by the authors.
o REQ-STATS-3-IETF技術出版社は、著者によって拒否された修正の割合と同様に、レビュー中に見つかった編集修正の種類について、一般に利用可能な月次統計を提供する必要があります。
o Req-STATS-4 - The IETF technical publisher should provide publicly available monthly statistics on author-requested changes to documents under publication. This statistic should also include changes required by other authorities outside of the technical publisher empowered to make changes. For the IETF standards process, the designated authority would be the IESG or its designees.
o
Task Description: The guidelines and rules for an organization's publication output will change over time. New sections will be added to documents, styles and conventions will change, boilerplate will be changed, etc. Similarly, the specific processes for publication of a specification will change. The technical publisher is expected to be involved in these discussions and accommodate these changes as required.
タスクの説明：組織の公開出力のガイドラインとルールは、時間とともに変化します。ドキュメント、スタイル、および規則に新しいセクションが追加され、変更が変更され、ボイラープレートが変更されます。同様に、仕様の公開のための特定のプロセスが変更されます。技術出版社は、これらの議論に関与し、必要に応じてこれらの変更に対応することが期待されています。
Discussion: Over time, the IETF consensus on what should be in a published document has changed. Processes interfacing with the publisher have also changed. Such changes are likely to continue in the future. The RFC Editor has been involved in such discussions and provided guides, policies, faqs, etc. to document the current expectations on published documents.
ディスカッション：時間が経つにつれて、公開されたドキュメントにあるべきものに関するIETFコンセンサスが変更されました。出版社とのインターフェースのプロセスも変更されました。このような変更は将来続く可能性があります。RFCエディターは、このような議論に関与し、公開されたドキュメントに現在の期待を文書化するために、ガイド、ポリシー、FAQなどを提供しています。
Derived Requirements:
o Req-PROCESSCHG-1 - The IETF technical publisher should participate in the discussions of changes to author guidelines and publication process changes.
o Req-ProcessChg-1-IETF技術出版社は、著者のガイドラインと出版プロセスの変更の変更の議論に参加する必要があります。
o Req-PROCESSCHG-2 - The IETF technical publisher should participate in and support process experiments involving the technical publication process.
o Req-ProcessChg-2-IETF技術出版社は、技術的な出版プロセスを含むプロセス実験に参加し、サポートする必要があります。
Task Description: The technical publisher may be required to provide tutorials, mentoring, help desks, online tools, etc. to facilitate smooth interaction with the technical publisher and to increase the IETF community's awareness of document guidelines, procedures, etc. In many organizations, the publisher maintains a style manual giving explicit guidance to authors on how to write a specification.
タスクの説明：技術出版社は、テクニカルパブリッシャーとのスムーズな相互作用を促進し、多くの組織で文書ガイドライン、手順などのIETFコミュニティの認識を高めるために、チュートリアル、メンタリング、ヘルプデスク、オンラインツールなどを提供する必要がある場合があります。出版社は、仕様の作成方法について著者に明示的なガイダンスを与えるスタイルマニュアルを維持しています。
Discussion: Guidelines are provided to the authors on how to write an RFC as well as occasional tutorial presentations. The RFC Editor provides a help desk at IETF meetings.
ディスカッション：著者には、RFCの作成方法と時折のチュートリアルプレゼンテーションについてガイドラインが提供されます。RFCエディターは、IETFミーティングでヘルプデスクを提供しています。
Derived Requirements:
派生要件：
o Req-PUBHELP-1 - The IETF technical publisher should provide and maintain documentation giving guidance to authors on the layout, structure, expectations, etc. required to develop documents suitable for publication. For the IETF standards process stream, the technical publisher should follow IESG guidance in specifying documentation guidelines.
o REQ-PUBHELP-1-IETF技術出版社は、出版に適したドキュメントを開発するために必要なレイアウト、構造、期待などに関する著者にガイダンスを与えるドキュメントを提供および維持する必要があります。IETF標準プロセスストリームの場合、技術出版社は、ドキュメントガイドラインを指定する際にIESGガイダンスに従う必要があります。
o Req-PUBHELP-2 - The IETF technical publisher should provide tutorials to the IETF community to educate authors on the processes and expectations of the IETF technical publisher.
o REQ-PUBHELP-2-IETF技術パブリッシャーは、IETFコミュニティにチュートリアルを提供して、IETF技術出版社のプロセスと期待について著者を教育する必要があります。
o Req-PUBHELP-3 - The IETF technical publisher should provide a contact email address and correspond as required to progress the publication work. The publisher should address queries from both inside and outside of the IETF community.
o REQ-PUBHELP-3-IETFテクニカルパブリッシャーは、連絡先の電子メールアドレスを提供し、出版作業の進行に必要な場合に対応する必要があります。パブリッシャーは、IETFコミュニティの内側と外側の両方からのクエリに対処する必要があります。
o Req-PUBHELP-4 - The IETF technical publisher should provide a help desk at IETF meetings.
o REQ-PUBHELP-4-IETF技術出版社は、IETFミーティングでヘルプデスクを提供する必要があります。
Task Description: It is very valuable for the technical publisher of an organization to have good information and communication about the work streams that will result in publication streams. In order to ensure a wide communication channel for the work, the technical publisher holds a liaison position on the IESG, where there can be valuable give-and-take about matters concerning the IETF standards stream.
タスクの説明：組織の技術出版社が、出版物のストリームをもたらす作業ストリームに関する良い情報とコミュニケーションを持つことは非常に価値があります。作業の幅広いコミュニケーションチャネルを確保するために、技術出版社はIESGでリエゾンポジションを保持します。そこでは、IETF標準のストリームに関する問題について貴重なギブアンドテイクがあります。
Discussion: The RFC Editor currently maintains a liaison position with the IESG. Although not specifically addressed in these requirements, the RFC Editor also maintains a liaison position toward the IAB.
ディスカッション：RFCエディターは現在、IESGとのリエゾンポジションを維持しています。これらの要件では特に扱われていませんが、RFCエディターはIABに向けてリエゾン位置も維持しています。
Derived Requirements:
o Req-LIAISON-1 - Through a liaison participant, the technical publisher should take part in meetings and activities as required in order to be aware of ongoing activities related to the work streams. For the IETF standards stream the technical publisher should participate in IESG formal meetings, IESG face-to-face activities at IETF, and other activities such as retreats.
o
Technical publishers are typically measured not only on what they do but how well they perform the tasks. The expectations in this section are treated as goals instead of requirements because:
- Achieving a given level of performance is not totally under the control of the technical publisher. Publication is a process and the goals are of the process, not just the publisher.
- 特定のレベルのパフォーマンスを達成することは、技術出版社の完全に管理されているわけではありません。出版物はプロセスであり、出版社だけでなく、目標はプロセスのものです。
- The actual performance objectives will be set contractually. The values herein represent values that the IETF community feels are desirable and reasonable for work progress without consideration of financial or other factors.
- 実際のパフォーマンス目標は契約上に設定されます。ここでの値は、IETFコミュニティが財務やその他の要因を考慮せずに、仕事の進歩に望ましいと感じる価値を表します。
Goals are set forth in the following areas:
目標は次の領域に記載されています。
1. Publication timeframes
1.
2. Publication throughput
2. 出版スループット
Goal Description: This is a measure of the time from entry into the RFC Editor queue until the documents are published. The metrics are defined in (req-STATS-1).
目標の説明：これは、RFCエディターキューへの入場からドキュメントが公開されるまでの時間の尺度です。メトリックは（req-stats-1）で定義されています。
Discussion: Long publication times create both internal and external difficulties. Internal difficulties include the migration of authors to other activities and the accumulation of tempting post-approval fixes to be added to the document. External difficulties include the inability of other standards organizations to reference IETF publications for lack of an RFC number.
議論：長い出版時間は、内部と外部の両方の困難を生み出します。内部の難しさには、著者の他の活動への移行や、文書に追加される魅力的な承認後の修正の蓄積が含まれます。外部の難しさには、他の標準組織がRFC番号がないためにIETF出版物を参照できないことが含まれます。
Derived Goals:
派生目標：
o Goal-TIMEFRAMES-1 - The consensus of the IETF community is that an average publication time of under a month is desirable. It is understood that in some cases there will be delays outside of the publisher's control. The actual performance targets and metrics are expected to be determined as part of the contract negotiation process.
o Goal-TimeFrames-1-IETFコミュニティのコンセンサスは、1か月未満の平均出版時間が望ましいということです。場合によっては、出版社のコントロールの外に遅延があることが理解されています。実際のパフォーマンス目標とメトリックは、契約交渉プロセスの一部として決定されると予想されます。
o Goal-TIMEFRAMES-2 - The consensus of the IETF community is that the time required for a pre-approval review should be under 10 days. The actual performance targets and metrics are expected to be determined as part of the contract negotiation process.
o Goal-TimeFrames-2-IETFコミュニティのコンセンサスは、承認前のレビューに必要な時間は10日未満であるということです。実際のパフォーマンス目標とメトリックは、契約交渉プロセスの一部として決定されると予想されます。
Goal Description: The number of documents published during a given time period is a measure of publisher throughput. Some publishers also provide the data in terms of pages produced. The counts should be separated by categories of documents. The metrics are defined in (req-STATS-1).
Discussion: The RFC Editor currently provides monthly statistics on the arrival and completion of documents into the RFC queue. This is sorted by category of document. This provides a measure of the delays in the publication process.
ディスカッション：RFCエディターは現在、RFCキューへのドキュメントの到着と完成に関する毎月の統計を提供しています。これは、ドキュメントのカテゴリでソートされます。これにより、出版プロセスの遅延の尺度が提供されます。
Derived Goals:
o Goal-THROUGHPUT-1 - Although minor variations are expected, there should be no long-term growth trend in the length of the publication queue. The actual performance targets and metrics are expected to be determined as part of the contract negotiation process.
o Goal-Throughput-1-マイナーなバリエーションが予想されますが、出版キューの長さに長期的な成長傾向はないはずです。実際のパフォーマンス目標とメトリックは、契約交渉プロセスの一部として決定されると予想されます。
Requirements on the technical publication process have so far been stated in terms of requirements on the technical publisher. However, it must be recognized that many of these requirements have implications for the processes and tools within the IETF itself. It is anticipated that these processes will be documented in companion documents.
The following is a list of potential issues that should be addressed within the IETF based on the requirements applied to the technical publisher:
以下は、技術出版社に適用される要件に基づいてIETF内で対処すべき潜在的な問題のリストです。
o Pre- vs. Post-approval Editing: If emphasis switches from post-approval editing to pre-approval editing, then IETF processes must be adapted to make use of this service. The processes for post-approval editing can also be streamlined.
o 前承認後編集：承認後の編集：承認後の編集から承認前編集に強調された場合、IETFプロセスをこのサービスを利用するために適応する必要があります。承認後の編集のプロセスも合理化できます。
o Post-approval Editorial Cleanup: The IETF must define under what conditions the publisher should be instructed to bypass or minimize post-approval editing.
o
o Approval of Post-approval, Pre-publication Technical Corrections: Since the technical publisher can only accept approved changes, it must be clear who is allowed to approve technical changes. This process within the IETF needs to be decided and documented.
o 承認後、出版前の技術的修正の承認：技術出版社は承認された変更のみを受け入れることができるため、誰が技術的な変更を承認することを許可されているかは明確でなければなりません。IETF内のこのプロセスは、決定および文書化する必要があります。
o Allocation of Permanent Stable Identifiers: The IETF needs to clearly identify the naming/numbering schemes and classes of documents to which those names and numbers apply. Furthermore, the responsibility for allocation of those names/numbers needs to be identified.
o 永続的な安定した識別子の割り当て：IETFは、それらの名前と番号が適用されるドキュメントの命名/番号付けスキームとクラスを明確に識別する必要があります。さらに、これらの名前/番号の割り当ての責任を特定する必要があります。
o Expedited Handling: If publication timelines can be reduced sufficiently, then expedited handling may no longer be needed.
o 迅速な取り扱い：出版物のタイムラインを十分に削減できる場合、迅速なハンドリングは不要になる場合があります。
o Post-publication Corrections: Appropriate processes must be defined with the IETF to ensure that errata are appropriately vetted and authorized.
o 出版後の修正：適切なプロセスをIETFで定義する必要があります。
o Indexing: Appropriate processes must be defined within the IETF to decide and inform the technical publisher of status changes to published documents as the result of an appeal, legal action, or some other procedural action.
o インデックス作成：適切なプロセスをIETF内で定義して、アピール、法的措置、またはその他の手続き訴訟の結果として、公開されたドキュメントのステータスの変更を技術出版社に決定および通知する必要があります。
Any new requirements that result from this discussion need to be reviewed by IANA and the IETF to understand to what extent, if any, the work flow of the documents through IANA is affected.
この議論から生じる新しい要件は、IANAおよびIETFによってレビューされる必要があります。
Interactions with IANA on population of parameter values is discussed in Section 3.6.
パラメーター値の母集団でのIANAとの相互作用については、セクション3.6で説明します。
There is a tussle between the sought-for improvements in readability and the specific language that has often been negotiated carefully for the security content of IETF documents. As with other text, extreme caution is needed in modifying any text in the security considerations. This issue is assumed to have been dealt with under Section 3.3.
読みやすさの求められている改善と、IETFドキュメントのセキュリティコンテンツのために慎重に交渉されることが多い特定の言語の間には、争いがあります。他のテキストと同様に、セキュリティ上の考慮事項のテキストを変更する際には極端な注意が必要です。この問題は、セクション3.3に基づいて扱われていると想定されています。
The processes for the publication of documents should prevent the introduction of unapproved changes (see Section 3.7). Since the IETF publisher maintains the index of publications, sufficient security should be in place to prevent these published documents from being changed by external parties (see Section 3.16)
ドキュメントを公開するプロセスは、承認されていない変更の導入を妨げるはずです（セクション3.7を参照）。IETFパブリッシャーは出版物のインデックスを維持しているため、これらの公開されたドキュメントが外部関係者によって変更されるのを防ぐのに十分なセキュリティを整える必要があります（セクション3.16を参照）
Bert Wijnen has provided input on the early copyedit experiment and made useful comments throughout the document. Leslie Daigle has contributed strongly to this text. Thanks to Steve Barclay, John Meredith, Yvette Ho Sang, and Sami Trabulsi for discussions of the publication practices of ATIS, ETSI, IEEE, and ITU. Other acknowledgements to date: a discussion on the wg chairs mailing list, Henning Schulzrinne, and Henrik Levkowetz.
Bert Wijnenは、初期のCopyEdit実験に関する情報を提供し、文書全体で有用なコメントをしました。レスリー・デイグルはこのテキストに強く貢献しています。Steve Barclay、John Meredith、Yvette Ho Sang、およびSami Trabulsiに感謝します。ATIS、ETSI、IEEE、およびITUの出版慣行の議論をしてくれました。これまでのその他の謝辞：WGチェアメーリングリスト、ヘニングシュルツリンヌ、およびヘンリックレヴコウェッツに関する議論。
[RFC2850] Internet Architecture Board and B. Carpenter, "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000.
[RFC2850]インターネットアーキテクチャボードとB.カーペンター、「インターネットアーキテクチャボードのチャーター（IAB）」、BCP 39、RFC 2850、2000年5月。
Authors' Addresses
著者のアドレス
Allison Mankin Bethesda, MD USA
Allison Mankin Bethesda、MD USA
Phone: +1 301 728 7199
EMail: mankin@psg.com
URI: http://www.psg.com/~mankin/
Stephen Hayes Ericsson 3634 Long Prairie Rd. Ste 108-125 Flower Mound, TX 75022 USA
Stephen Hayes Ericsson 3634 Long Prairie Rd。STE 108-125フラワーマウンド、テキサス75022 USA
Phone: +1 469 360 8500
EMail: stephen.hayes@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。