RFC4714 日本語訳
4714 Requirements for IETF Technical Publication Service. A. Mankin,S. Hayes. October 2006. (Format: TXT=53988 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Mankin
Request for Comments: 4714
Category: Informational S. Hayes
Ericsson
October 2006
コメントを求めるワーキンググループA.マンキンの要求をネットワークでつないでください: 4714年のカテゴリ: 情報のS.ヘイズエリクソン2006年10月
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).
Copyright(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の仕事は、インターネットの操作を支持する技術仕様書を議論して、開発して、広めることです。 技術刊行物はその出力が一般社会に広められる過程です。 そういうものとして、公表の過程に関する要件を理解しているのは重要です。
Mankin & Hayes Informational [Page 1] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[1ページ]のRFC4714IETF
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
1. 序論…2 2. 範囲…3 2.1. 仕様書公表生涯のステージ…4 3. 技術刊行物タスクと要件…5 3.1. 事前承認レビューか編集…6 3.2. 予備の仕様の有用性…6 3.3. ポスト承認の編集クリーンアップ(非作者編集)…7 3.4. 参照の合法化…9 3.5. 形式言語の合法化…9 3.6. パラメタ値の挿入…10 3.7. ポスト承認、プレ公表技術的調整…10 3.8. 永久的な安定した識別子の配分…11 3.9. フォーマット変換を記録してください…12 3.10. 言語翻訳…12 3.11. 公表状態追跡…12 3.12. 取り扱いを速めます…13 3.13. 例外処理…14 3.14. 公表の通知…14 3.15. ポスト公表修正(誤字)…15 3.16. 索引をつけます: カタログの維持…15 3.17. 公表された文書へのアクセス…16 3.18. ボキャブラリードキュメントの維持…17 3.19. 公表統計と現状報告を提供します…17 3.20. 発展を処理して、記録してください…18 3.21. チュートリアルとヘルプサービス…18 3.22. 連絡とコミュニケーションサポート…19 4. 技術的な出版社パフォーマンス目標…20 4.1. 公表時間枠…20 4.2. 公表スループット…21 5. 技術刊行物要件のIETF含意…21 6. IANA問題…22 7. セキュリティ問題…22 8. 承認…23 9. 有益な参照…23
1. Introduction
1. 序論
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と対話するかに関する義務に先へそれらの刊行物の生産で必要条件を定めます。
Mankin & Hayes Informational [Page 2] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[2ページ]のRFC4714IETF
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.
このドキュメントの意志は技術刊行物サービスのための要件に関するIETFのコンセンサスをはっきりさせることです。 将来の契約の準備にそれが使用されると予想されます。 このドキュメントは現在の技術的な出版社(RFC Editor)がそれらの要件をどれくらいよく実現させるかに関する議論ではありません。
2. Scope
2. 範囲
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.
タスクが現在他の規格組織における技術的な出版社が3GPP、ATIS、ETSI、IEEE、およびITUを含める責任と同様にRFC Editorによって実行されていると考えることによって、潜在的技術刊行物タスクのリストは引き出されました。
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 非技術系のセクションのコンテンツを治める方針(承認部、参照分類など)
Mankin & Hayes Informational [Page 3] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[3ページ]のRFC4714IETF
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コンセンサスで決定するとき、政策変更を実行して、容易にするように準備されるべきです。 過程とドキュメント発展の議論でこの要件を得ます。
2.1. Stages in the Technical Specification Publication Lifetime
2.1. 仕様書公表生涯のステージ
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)ドキュメントと作業部会Last Call(WGLC)(Areaディレクター(AD)のレビュー、IETF Last Call(IETF LC)、IANAレビュー、およびIESGレビュー)を含むレビューを示しています。 ドキュメント羊飼い(ダイヤグラムで、「羊飼い」として目立つ)は、レビューでドキュメントを守るためにIESGによって任命された個人と公表の過程であり、しばしば西暦であるというわけではありません。 ADで後援された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
| 作者| WGLC| IESG| | IANA| エディタ| 西暦| 羊飼い| A| 技術者| IETF秒| IETF LC| エディタ| P| 出版社| retariat| IANA| WG| P| 入力されます。| | IESG| 西暦| R| 作者、他 | | | | O| 動作| 創造| | 解決| V| 非作者| 編集であること| | すべてについて| A| 編集であること| パブを作成してください。| | レビュー| 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によって開始されます。
Mankin & Hayes Informational [Page 4] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[4ページ]のRFC4714IETF
3. Technical Publication Tasks and Requirements
3. 技術刊行物タスクと要件
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
19. 公表統計と現状報告を提供します。
Mankin & Hayes Informational [Page 5] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[5ページ]のRFC4714IETF
20. Process and document evolution
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の技術的な出版社に関する要件を引き出します。
3.1. Pre-approval Review or Editing
3.1. 事前承認レビューか編集
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 Last Callの前で実行されて、フィードバックを作者に提供するべきです。 IETF標準化過程の流れのために、出版社はドキュメントの技術審査を実行するべきではありません。
3.2. Preliminary Specification Availability
3.2. 予備の仕様の有用性
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.
記述に仕事を課してください: 規格組織の中にはそれらの出版社ができるだけ早く情報を産業に利用可能にするようにドキュメント(適切な警告がある)の準備段階を利用可能にするのを必要とするものもあります。 承認の後に「そのままで」このドキュメントを提供します。 最終合意文書がいったん発行されると、このドキュメントはよそよそしいです。
Mankin & Hayes Informational [Page 6] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[6ページ]のRFC4714IETF
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
要件を引き出します: なし
3.3. Post-approval Editorial Cleanup (Non-author Editing)
3.3. ポスト承認の編集クリーンアップ(非作者編集)
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.
記述に仕事を課してください: ほとんどの技術的な出版社が、公表された文書の品質を確実にするために社説のレビューをします。 通常、これは文法、スペル、読み易さ、形式、決まり文句への固守、ドキュメント構造などの問題を記述するかもしれません。 以来、通常、承認、レビュー、およびsignoffメカニズムが必要な変化が確実に本当に、編集になるようにするために確立されたべきであった後にどんな変更案も起こります。 そのような変化が正常な承認審査方式の外に起こるので、そのような変化が最小にされるのは、望ましいです。 ほとんどの規格組織が、変化するという危険のため同意しているテキストを編集しながら、「光」を狙います。
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
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.
昨年時には、文体上の編集は多くのドキュメントにおけるかなりの数の変化をもたらしました。 そして、作者承認とリベット打ちのその後のラウンドがあとに続いたすべての作者がこれらの変化を診察しなければなりません。 これは公表の過程のかなりの遅れを意味できます。(クリーンアップによって実行されたコミュニケーション改善における増加の利得に過程について比較考量しなければなりません)。
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
特定の例では、そうしてもテキストが「逐語的に」発行されるのが必要であるのが知覚されるものを導入するのが必要であるかもしれません。
Mankin & Hayes Informational [Page 7] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[7ページ]のRFC4714IETF
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登録用書類とManagement Information基地(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つがあれば)、およびAreaディレクターを含んでいます。 Areaディレクターはすべての変化の承認のための権威です。
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の技術的な出版社は編集における抑制を課さなければなりません。
Mankin & Hayes Informational [Page 8] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[8ページ]のRFC4714IETF
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共同体への期待です。
3.4. Validation of References
3.4. 参照の合法化
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 Editorは他の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の技術的な出版社は出版を遅らせるべきです。
3.5. Validation of Formal Languages
3.5. 形式言語の合法化
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はシンタクス上MIBs、AugmentedバッカスナウアForm(ABNF)、eXtensible Markup Language(XML)、抽象的なSyntax Notation One(ASN.1)、およびことによると他の形式言語を含むドキュメントのセクションを有効にします。
Mankin & Hayes Informational [Page 9] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[9ページ]のRFC4714IETF
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は、適切なツールを使用することで確かめられるべきです。
3.6. Insertion of Parameter Values
3.6. パラメタ値の挿入
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と共に必要なパラメタ値の人口にドキュメントに取り組むべきです。
3.7. Post-approval, Pre-publication Technical Corrections
3.7. ポスト承認、プレ公表技術的調整
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の過程は適所にあるに違いありませんが、これは明確に技術的な出版社に関する要件ではありません。
Mankin & Hayes Informational [Page 10] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[10ページ]のRFC4714IETF
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標準化過程の流れでは、これは作者とAreaディレクターを含んでいます。 ドキュメント羊飼い(1つがあれば)はこれらの変化において知識があるように保たれるべきです。
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標準化過程の流れのために、その権威はAreaディレクターです。 Areaディレクターと共に働いているドキュメント羊飼いがいれば、また、羊飼いは、通知されて、知識があるように保たれるべきです。
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の技術的な出版社は、それらの関連仕様に関連して刊行物に関連しているどんなソースドキュメントもアップデートするのを確実にするべきです。
3.8. Allocation of Permanent Stable Identifiers
3.8. 永久的な安定した識別子の配分
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.
o Req-PERMID-1--IETFの技術的な出版社は公表の過程の一部として安定した識別子を割り当てるべきです。
Mankin & Hayes Informational [Page 11] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[11ページ]のRFC4714IETF
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です。
3.9. Document Format Conversions
3.9. ドキュメント・フォーマット変換
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つ以上の出力形式(例えば、テキスト、Portable Document Format(PDF))にドキュメントを変換するのに責任があります。 いくつかの規格組織では、技術的な出版社は、様々な形式で入力ドキュメントを受け入れて、均質のセットの出力ドキュメントを製作しなければならないかもしれません。
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--ASCIIテキストがファイルされて、PDFがファイルするとき、IETFの技術的な出版社は、入力ASCIIテキストがファイルされるとき受け入れて、ドキュメントを発表するべきです。
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ドキュメントに関連しますが、出版社は編集可能でないかもしれません。
3.10. Language Translation
3.10. 言語翻訳
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
要件を引き出します: なし
3.11. Publication Status Tracking
3.11. 公表状態追跡
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
記述に仕事を課してください: 技術的な出版社には、ドキュメントの状態の状態情報を提供する能力があるべきです。 これは、プロセス・モデルかチェックリストを開発して、提供することを伴うかもしれません。
Mankin & Hayes Informational [Page 12] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[12ページ]のRFC4714IETF
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 Editor待ち行列で状態情報を提供します。 各ドキュメントは結果と考えられたa状態(例えば、AUTH48、RFC-EDITOR、IANA、ISR)です。 長い間、状態を変えないで、項目は待ち行列に残るかもしれません。 この状態の追跡情報はツールを追跡するIESGと統合されません。 IETFの中では、ProcessとTools(プロト)チームは長い待ちの期間、正確に象徴所有者をマークするための要件を考えています、そして、他のものは改良された通知ツールを調べています。 これらの努力による共同研究、刊行物に関するログをメールするためにパブリックアクセスを提供するか、またはある他の提案で改良された状態統合と目に見えることへの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-STATUSTRK-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-STATUSTRK-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-STATUSTRK-3--IETFの技術的な出版社はドキュメントが延ばされた待ち時代にあるという事実だけではなく、象徴所有者について外部の目に見えることと待ちの事情を提供するべきです。
3.12. Expedited Handling
3.12. 速められた取り扱い
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.
記述に仕事を課してください: いくつかの場合(ドキュメントが別の標準化団体によって必要とされる時などの)では、承認している組織がドキュメントの速められた公表を要求するのは、可能であるべきです。 理想的に、これは、公表ステップのどれかをサボるべきではありませんが、標準より初期の公表を確実にするために仕事待ち行列におけるさらに高い優先度をそれに割り当てます。 酷使がどんな優先権計画の場合も、利益を否定するので、速められた公表は控えめに使用されるべきです。
Mankin & Hayes Informational [Page 13] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[13ページ]のRFC4714IETF
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 Editorの待ち行列におけるドキュメントは参照への必要性が使われます。 短い公表時を過すと、ファーストトラッキングの必要性はおそらく減少するでしょう。
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 Req-EXPEDITE-1--IETFの技術的な出版社は適切な権威の依頼で特定のドキュメントの処理を速めるべきです。 IETF標準化過程の流れのために、その権威は、IESGかIABです。
3.13. Exception Handling
3.13. 例外処理
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です。
3.14. Notification of Publication
3.14. 公表の通知
Task Description: The technical publisher should provide a mechanism for alerting the community at large of the availability of published documents.
記述に仕事を課してください: 技術的な出版社は公表された文書の有用性の一般社会を警告するのにメカニズムを提供するべきです。
Mankin & Hayes Informational [Page 14] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[14ページ]のRFC4714IETF
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.
o Req-PUBNOTIFY-1--IETFの技術的な出版社は公表された文書の有用性を発表するべきです。
3.15. Post-publication Corrections (errata)
3.15. ポスト公表修正(誤字)
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.
o Req-ERRATA-1--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.
o Req-ERRATA-2--情報の一部がRFCと交際したので、IETFの技術的な出版社は関連誤字の情報を提供するべきです。
3.16. Indexing: Maintenance of the Catalog
3.16. 索引をつけます: カタログの維持
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に関連しているメタ情報は保守されるべきです。 これが決定的なアーカイブであるので、承認されたドキュメントをいじるのを防ぐために、十分なセキュリティは適所にあるべきです。
Mankin & Hayes Informational [Page 15] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[15ページ]のRFC4714IETF
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--適切な権威はドキュメント(例えば、Historicalへの)の状態を変えるべきであり、これがインデックスに反映されるべきであるのを出版社に示すことができます。 IETF標準化過程の流れのために、表示権威はIESGです。
3.17. Access to Published Documents
3.17. 公表された文書へのアクセス
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 Editorのウェブページでドキュメントと状態はアクセスされるかもしれません。
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
o Req-PUBACCESS-2、--、IETFの技術的な出版社ツールが発行されたドキュメントに関連している関連メタ情報を返すはずである(例えば、ドキュメントのカテゴリ、規格のタイプ、(規格です。
Mankin & Hayes Informational [Page 16] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[16ページ]のRFC4714IETF
track), obsoleted by or updated by information, associated
errata).
道) 関連誤字、時代遅れにするか、または情報でアップデートして、)
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標準化過程で使用されている状態で、これは統合を示します。
3.18. Maintenance of a Vocabulary Document
3.18. ボキャブラリードキュメントの維持
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
要件を引き出します: なし
3.19. Providing Publication Statistics and Status Reports
3.19. 公表統計と現状報告を提供します。
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ミーティングで周期的な現状報告を提供するべきです。
Mankin & Hayes Informational [Page 17] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[17ページ]のRFC4714IETF
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 Req-STATS-4--IETFの技術的な出版社は公表の下におけるドキュメントへの作者によって要求された変化における公的に利用可能な毎月の統計を提供するべきです。 また、この統計値は技術的な出版社の外部が変更を行うのに権限を与えた他の当局によって求められた変化を含むべきです。 IETF標準化過程のために、指定された権威は、IESGかその指名された人でしょう。
3.20. Process and Document Evolution
3.20. 過程とドキュメント発展
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は、現在の期待を公表された文書に記録するためにそのような議論にかかわって、ガイド、方針、faqsなどを提供しました。
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の技術的な出版社は、技術刊行物の過程にかかわる過程実験を、参加して、支持するべきです。
3.21. Tutorial and Help Services
3.21. チュートリアルとヘルプサービス
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共同体のドキュメントガイドライン、手順などの認識を増加させるようにチュートリアル、メンタリング、ヘルプデスク、オンラインツールなどを提供しなければならないかもしれません。 多くの組織では、出版社は、どう仕様を書くかに関して明白な指導を作者に与えながら、スタイルマニュアルを維持します。
Mankin & Hayes Informational [Page 18] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[18ページ]のRFC4714IETF
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.
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の技術的な出版社は、連絡Eメールアドレスを提供して、公表仕事を進行するように必要に応じて対応するべきです。 出版社はIETF共同体の中と外に両方からの質問を記述するべきです。
o Req-PUBHELP-4 - The IETF technical publisher should provide a help
desk at IETF meetings.
o Req-PUBHELP-4--IETFの技術的な出版社はIETFミーティングでヘルプデスクを提供するべきです。
3.22. Liaison and Communication Support
3.22. 連絡とコミュニケーションサポート
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.
o 連絡の関係者を通して、技術的な出版社は、仕事の流れに関連する進行中の活動を意識しているために必要に応じてミーティングと活動に参加するべきです。Req-LIAISON-1--IETF規格の流れのために、技術的な出版社は後退などのIESGの正式なミーティング、IETFのIESGの面と向かっている活動、および他の活動に参加するべきです。
Mankin & Hayes Informational [Page 19] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[19ページ]のRFC4714IETF
4. Technical Publisher Performance Goals
4. 技術的な出版社パフォーマンス目標
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. 公表スループット
4.1. Publication Timeframes
4.1. 公表時間枠
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 目標-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 目標-TIMEFRAMES-2--IETF共同体のコンセンサスは事前承認レビューに必要である時間が10日間未満であるべきであるということです。 実績目標と測定基準が契約交渉の過程の一部として断固としていると予想されます。
Mankin & Hayes Informational [Page 20] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[20ページ]のRFC4714IETF
4.2. Publication Throughput
4.2. 公表スループット
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 目標-THROUGHPUT-1--小さい方の変化は予想されますが、公表待ち行列の長さにおける長期的成長傾向が全くあるべきではありません。 実績目標と測定基準が契約交渉の過程の一部として断固としていると予想されます。
5. IETF Implications of Technical Publication Requirements
5. 技術刊行物要件のIETF含意
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の中のこの過程は、決められて、記録される必要があります。
Mankin & Hayes Informational [Page 21] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[21ページ]のRFC4714IETF
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の中で適切な過程を定義しなければなりません。
6. IANA Considerations
6. IANA問題
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.
セクション3.6でパラメタ値の人口のIANAとの相互作用について議論します。
7. Security Considerations
7. セキュリティ問題
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を見ます)
Mankin & Hayes Informational [Page 22] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[22ページ]のRFC4714IETF
8. Acknowledgements
8. 承認
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は早さに関する提供された入力に実験の原稿整理をさせて、ドキュメント中で役に立つコメントをしました。 レスリーDaigleは強く本稿に貢献しました。 ATIS、ETSI、IEEE、およびITUの公表習慣の議論をスティーブ・バークレー、ジョン・メレディス、イヴェットHo Sang、およびサミTrabulsiをありがとうございます。 これまでの他の承認: wgについての議論はメーリングリスト、ヘニングSchulzrinne、およびHenrik Levkowetzをまとめます。
9. Informative References
9. 有益な参照
[RFC2850] Internet Architecture Board and B. Carpenter, "Charter of
the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
May 2000.
[RFC2850]インターネット・アーキテクチャ委員会とB.は大工仕事をして、「インターネット・アーキテクチャ委員会(IAB)の憲章」(BCP39、RFC2850)は2000がそうするかもしれません。
Authors' Addresses
作者のアドレス
Allison Mankin Bethesda, MD USA
アリソン・マンキン・MDベセスダ(米国)
Phone: +1 301 728 7199 EMail: mankin@psg.com URI: http://www.psg.com/~mankin/
以下に電話をしてください。 +1 7199年の301 728メール: mankin@psg.com ユリ: http://www.psg.com/~mankin/
Stephen Hayes Ericsson 3634 Long Prairie Rd. Ste 108-125 Flower Mound, TX 75022 USA
スティーブンヘイズエリクソン3634の長いPrairie通り Ste108-125花の土手、テキサス75022米国
Phone: +1 469 360 8500 EMail: stephen.hayes@ericsson.com
以下に電話をしてください。 +1 8500年の469 360メール: stephen.hayes@ericsson.com
Mankin & Hayes Informational [Page 23] RFC 4714 IETF Technical Publisher Requirements October 2006
出版社要件2006年10月に技術的なマンキンとヘイズの情報[23ページ]のRFC4714IETF
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Mankin & Hayes Informational [Page 24]
マンキンとヘイズInformationalです。[24ページ]
一覧
スポンサーリンク
