Network Working Group A. Mankin
Request for Comments: 4714
Category: Informational S. Hayes
Ericsson
October 2006
Requirements for IETF Technical Publication Service
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).
著作権（C）インターネット協会（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.
IETFの仕事は、議論の開発、およびインターネットの操作をサポートするための技術仕様を普及させることです。技術的な出版物は、その出力が大で社会に普及されるプロセスです。このように、公開プロセス上の要件を理解することが重要です。
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.
IETFの仕事は、議論の開発、およびインターネットの操作をサポートするための技術仕様を普及させることです。そのため、IETFの重要な出力は、技術仕様を公開しています。 IETFの技術的な出版社が出版され、技術仕様の生産の最終段階に責任があります。この文書は、IETFの技術的な出版社とそれがどのようにこれらの出版物の生産にIETFと相互作用の職務上の要求事項を規定して。
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の技術的な出力を参照するために意図的にここで使用されます。このドキュメントは、「ある」RFCは、それらを分類する方法、などが挙げられる。これらの問題は適用範囲外と見なされているもの、それは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.
このドキュメントの意図は、その技術的な出版サービスのためにその要件にIETFのコンセンサスを明らかにすることです。将来の契約の調製に使用されることが予想されます。この文書では、現在の技術的な出版社（RFC Editorは）これらの要件を満たしてどれだけの議論ではありません。
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].
この文書の範囲は、IETFのための技術的な公開プロセスのための要件です。技術的な出版社の要件は、IETFの技術的な出版社が担当するとパフォーマンスがIETFの技術的な出版社が満たさなければならない対象何タスクの両方で表すことができます。技術出版社によって提供される機能は、時には編集管理[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.
この文書では、特にIETFの技術的な標準化プロセスによって公開され、それらのドキュメントを扱います。彼らは他の場所で、他の出版物の流れの要件を表現するために使用することができるように、すべての場合において、要件は、一般的な用語で書かれています。
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によって指定された個人や出版プロセスであり、多くの場合、ADはありません。寿命は、IETFワーキンググループがもはや存在しているためのプロトコル、または学際的なトピックに関する文書を更新した文書としてAD-後援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
|著者、| WGLC | IESG、| | IANA、|エディタ、| AD |シェパード、| |テック| IETF SEC-| IETF LC |エディタ、| P |出版社、| retariat | IANA | WG、| P |以下からの入力| | IESG | AD | R |著者ら。 | | | | O |アクション|創造、| |解像度| V |非作者|編集、| |すべての| |編集、|ドラフトパブ、| |レビュー| L |その他|トラッキング| | | |出版
|---------------| |---------------------| |----------------|
In WG Out of WG Post-approval
WG承認後のWGアウトで
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やその他の標準開発組織の技術刊行物政策を分析した後に得られました。
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-前編集-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 Editorは承認後のクリーンアップのレビューと編集を行います。クリーンアップのための野心レベルが異なることができます。
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
あまり巧みなWGの編集者との文書の重要な編集、およびWGの編集者は、熟練した最小限の編集O、へ
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.
昨年の倍で、文体の編集は、多くの文書の変更のかなりの数になりました。これらの変更は、著者の受け入れ、再審査のその後のラウンドに続いて、すべての著者によって吟味されなければなりません。これは、クリーンアップすることによって達成通信改善における増分利得比較検討されなければならないパブリケーションプロセスにかなりの遅延を追加できます。
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)).
- 「ボイラープレートは、」派生物（例えば、IANA登録文書や管理情報ベース（MIB））のすべてのインスタンスに適用するIETFワーキンググループで合意しました。
- 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標準化プロセスストリームの場合、これは作者、文書の羊飼いが含まれています。エリアディレクターは、すべての変更の承認の権限です。
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.
REQ-POSTEDIT-4 O - 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.
ディスカッション：他のIETF文書の可用性を待っている間、RFC Editorは保留に文書を置いてもよいです。不正な参照は、社説レビューで検出され、他の障害と同様に扱われます。
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.
REQ-REFVAL-2 O - すべての必要な（規定）の参照が公開のための準備が整うまで、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 Editorは構文上のMIB、増補バッカスナウア記法（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.
REQ-FORMALVAL-1 O - 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.
REQ-POSTCORR-1 O - 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.
REQ-POSTCORR-2 O - 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.
REQ-POSTCORR-3 O - それは要求された変更は、（例えば、未承認の技術的変更）、または不当な（例えば、大規模な編集上の変更）容疑者であることを感じているとき、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 EditorはRFC番号やその他の識別子（現在IETF安定した識別子）を割り当てます。早期割り当てられた識別子を持つことは考えられていたが、明確な必要性を確立できませんでした。
Derived Requirements:
派生要件：
o Req-PERMID-1 - The IETF technical publisher should allocate stable identifiers as part of the publication process.
REQ-PERMID-1 O - 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.
REQ-PERMID-2 O - 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.
タスクの説明：技術的な出版社は、1つまたは複数の出力フォーマット（例えば、テキスト、PDF（Portable Document Format）形式）に文書を変換するための責任があります。いくつかの標準化団体では、技術的な出版社は、さまざまな形式の入力文書を受け入れ、出力文書の均質なセットを生成するために必要とすることができます。
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 EditorはASCIIテキストファイルとして入力を受け付けます。 RFC Editorはまた、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.
REQ-DOCCONVERT-2 O - 技術的な出版社は、正式な記述（例えば、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 Editorは現在、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.
REQ-STATUSTRK-1 O - 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.
REQ-STATUSTRK-2 O - 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.
REQ-STATUSTRK-3 O - 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.
REQ-EXPEDITE-1 O - IETFの技術的な出版社は、適切な権限の要求に応じて特定の文書の処理を促進すべきです。 IETF標準化プロセスの流れについては、その権威はIESGかIABです。
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.
REQ-例外-1 O - 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.
REQ-例外-2 O - 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 EditorはRFC-distの上の文書出版のコミュニティを通知し、メーリングリストをIETF-発表。
Derived Requirements:
派生要件：
o Req-PUBNOTIFY-1 - The IETF technical publisher should announce the availability of published documents.
REQ-PUBNOTIFY-1 O - 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.
タスクの説明：修正が公開後に特定された場合、技術的な出版社は、元の文書とリンクすることができ正誤表を公開することができるはずです。
Discussion: The RFC Editor maintains a list of errata. Pointers to relevant errata are presented as output from the RFC Editor search engine.
ディスカッション：RFC Editorは正誤表のリストを管理します。関連する正誤表へのポインタは、RFC Editorの検索エンジンからの出力として提示されています。
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.
REQ-ERRATA-1 O - IETFの技術的な出版社が出版された文書の正誤表を維持する必要があります。レビュー、更新、およびIETF文書の正誤表を承認するためのプロセスは、IETFによって定義されます。
o Req-ERRATA-2 - The IETF technical publisher should provide information on relevant errata as part of the information associated with an RFC.
REQ-ERRATA-2 O - IETFの技術的な出版社は、RFCに関連付けられた情報の一部として関連エラッタに関する情報を提供すべきです。
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 Editorはカタログを維持します。 RFC Editorはまた、仕様の永久的なアーカイブを担当しています。 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.
REQ-INDEX-2 O - 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.
REQ-INDEX-4 O - アーカイブは、外部関係者によって公開された文書の変更を防ぐために十分に安全でなければなりません。
o Req-INDEX-5 - The IETF technical publisher should provide the permanent archive of any source documents associated with a published specification.
REQ-INDEX-5 O - 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.
REQ-INDEX-6 O - 適切な権限は、それが（例えば、歴史的に）文書のステータスを変更する必要があることをサイト運営者に示すことができ、これはインデックスに反映されるべきです。 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.
REQ-PUBACCESS-1 O - 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.
REQ-PUBACCESS-3 O - 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 Editorは用語や頭字語の公開文書やデータベースを保持しません。
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.
REQ-STATS-1 O - IETFの技術的な出版社は、処理の平均キュー時間と文書で公開月次統計情報を提供する必要があります。プレゼンテーションは、（目標スループット-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.
REQ-STATS-2 O - 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.
REQ-STATS-3 O - 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.
REQ-STATS-4 O - IETFの技術的な出版社は出版物の下の文書への著者、要求された変更で公開月次統計情報を提供する必要があります。この統計はまた、技術的な出版社は変更を加えるために権限外の他の当局によって必要な変更を含める必要があります。 IETF標準化プロセスでは、指定された権限は、IESGまたはその指名だろう。
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 Editorは、公表された文書の現在の期待を文書化するなど、そのような議論や提供のガイド、政策、よくある質問、に携わってきました。
Derived Requirements:
派生要件：
o Req-PROCESSCHG-1 - The IETF technical publisher should participate in the discussions of changes to author guidelines and publication process changes.
REQ-PROCESSCHG-1 O - IETFの技術的な出版社、著者のガイドラインおよび公開プロセスの変更への変更の議論に参加すべきです。
o Req-PROCESSCHG-2 - The IETF technical publisher should participate in and support process experiments involving the technical publication process.
REQ-PROCESSCHG-2 O - 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 Editorは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.
REQ-PUBHELP-2 O - 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.
REQ-PUBHELP-4 O - 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 Editorは現在、IESGとの連絡位置を維持しています。特に、これらの要件に対処していないが、RFC Editorはまた、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.
REQ-LIAISON-1 O - 仕事の流れに関連する継続的な活動を意識するために、必要に応じて連絡参加を通じて、技術的な出版社は、会議や活動に参加する必要があります。 IETF標準化のための技術的な出版社は、このようなリトリートとしてIESG正式な会議、IESG対面活動IETFで、その他の活動に参加すべきストリーム。
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:
目標は、以下の分野に記載されています。
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 Editorの待ち行列へのエントリーからの時間の尺度です。メトリックは、（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ゴール時間枠-1 - IETFコミュニティのコンセンサスは、月の下での平均出版時間が望ましいということです。いくつかのケースでは、出版社のコントロールの外に遅れがあることが理解されています。実際の業績目標と評価指標は、契約交渉プロセスの一部として決定されることが期待されます。
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ゴール時間枠-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).
目標の説明：指定された期間中に公表された文書の数は、パブリッシャのスループットの測定値です。いくつかの出版社はまた、生成ページ単位でデータを提供します。カウントは、文書のカテゴリで区切る必要があります。メトリックは、（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 Editorは現在、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目標スループット-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.
技術的な公開プロセス上の要件は、これまでの技術的な出版社に関する要件の用語で記述されています。しかし、これらの要件の多くはIETF自体の内部プロセスとツールのための意味を持っていることを認識しなければなりません。これらのプロセスは、コンパニオンの文書に記載されることが予想されます。
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承認後論説クリーンアップ：IETFは、出版社が承認後の編集を回避または最小化するように指示する必要がありますどのような条件の下で定義する必要があります。
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によって文書の作業の流れが影響を受けているために理解するために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.
バートWijnenは早期copyedit実験に入力を提供し、文書全体有益なコメントが寄せられていました。レスリーDaigle氏は、このテキストに強く貢献してきました。 ATIS、ETSI、IEEE、およびITUの出版慣行の議論のためのスティーブ・バークレー、ジョン・メレディス、イヴェット・ホーサンウ、およびサミTrabulsiに感謝します。これまでの他の謝辞：リスト、ヘニングSchulzrinneと、とヘンリクLevkowetzを郵送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
アリソンマンキンベセスダ、MD USA
Phone: +1 301 728 7199 EMail: mankin@psg.com URI: http://www.psg.com/~mankin/
電話：+1 301 728 7199 Eメール：mankin@psg.com URI：http://www.psg.com/~mankin/
Stephen Hayes Ericsson 3634 Long Prairie Rd. Ste 108-125 Flower Mound, TX 75022 USA
スティーブン・ヘイズエリクソン3634ロングプレーリーRdを。サント108から125フラワーマウンド、TX 75022 USA
Phone: +1 469 360 8500 EMail: stephen.hayes@ericsson.com
電話：+1 469 360 8500 Eメール：stephen.hayes@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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）によって提供されます。