RFC4846 日本語訳
4846 Independent Submissions to the RFC Editor. J. Klensin, Ed., D.Thaler, Ed.. July 2007. (Format: TXT=36562 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Klensin, Ed. Request for Comments: 4846 D. Thaler, Ed. Category: Informational July 2007
ワーキンググループJ.Klensin、エドをネットワークでつないでください。コメントのために以下を要求してください。 エド4846のD.ターレル、カテゴリ: 情報の2007年7月
Independent Submissions to the RFC Editor
RFCエディタへの独立している差出
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 IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
There is a long-standing tradition in the Internet community, predating the Internet Engineering Task Force (IETF) by many years, of use of the RFC Series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms. These documents, known as "Independent Submissions", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants. This document discusses the Independent Submission model and some reasons why it is important. It then describes editorial and processing norms that can be used for Independent Submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher.
長年の伝統がインターネットコミュニティにあります、IETF標準化過程、レビュー、および承認のメカニズムに根づかない材料を発行するために、RFC Seriesの使用の何年もインターネット・エンジニアリング・タスク・フォース(IETF)より前に起こって。「独立している差出」として知られているこれらのドキュメントはインターネットコミュニティのための多くの重要な機能、内部と活発なIETF関係者の共同体の外部の両方に役立ちます。 このドキュメントは無党派Submissionモデルとそれが重要であるいくつかの理由について議論します。 そして、それは共同体がIETF共同体とその第一の技術的な出版社とのはじまったばかりの男女関係に進んでいるので無党派Submissionsに使用できる社説と処理標準について説明します。
Klensin & Thaler Informational [Page 1] RFC 4846 Independent Submissions July 2007
独立している[1ページ]RFC4846差出2007年7月の情報のKlensinとターレル
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology Note . . . . . . . . . . . . . . . . . . . . . 3
1.2. Context and Philosophical Assumptions . . . . . . . . . . 4
2. The Role of Independent Submissions . . . . . . . . . . . . . 4
3. Document Submission . . . . . . . . . . . . . . . . . . . . . 5
4. The Review Process . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Posting of Draft . . . . . . . . . . . . . . . . . . . . . 6
4.2. Request for Publication . . . . . . . . . . . . . . . . . 6
4.3. Initial RFC Editor Review . . . . . . . . . . . . . . . . 6
4.4. Review and Evaluation . . . . . . . . . . . . . . . . . . 7
4.5. Additional Reviews . . . . . . . . . . . . . . . . . . . . 7
4.6. Document Rejection . . . . . . . . . . . . . . . . . . . . 7
4.7. Final Decision and Notification . . . . . . . . . . . . . 8
4.8. Final Editing and Publication . . . . . . . . . . . . . . 8
5. Formal IESG Review . . . . . . . . . . . . . . . . . . . . . . 8
6. The Editorial Review Board . . . . . . . . . . . . . . . . . . 9
7. Status and Availability of Reviews . . . . . . . . . . . . . . 10
7.1. Posted Reviews . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Rejected Documents . . . . . . . . . . . . . . . . . . . . 11
7.3. Documents Approved for Publication . . . . . . . . . . . . 11
8. Intellectual Property Rights . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. IAB Members at the Time of Approval . . . . . . . . . 15
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 用語注意. . . . . . . . . . . . . . . . . . . . . 3 1.2。 文脈と哲学的な仮定. . . . . . . . . . 4 2。 独立している差出. . . . . . . . . . . . . 4 3の役割。 服従. . . . . . . . . . . . . . . . . . . . . 5 4を記録してください。 吟味の過程. . . . . . . . . . . . . . . . . . . . . . 6 4.1。 草稿. . . . . . . . . . . . . . . . . . . . . 6 4.2の任命。 公表. . . . . . . . . . . . . . . . . 6 4.3のために、要求します。 RFCエディタレビュー. . . . . . . . . . . . . . . . 6 4.4に頭文字をつけてください。 レビューと評価. . . . . . . . . . . . . . . . . . 7 4.5。 追加レビュー. . . . . . . . . . . . . . . . . . . . 7 4.6。 拒絶. . . . . . . . . . . . . . . . . . . . 7 4.7を記録してください。 最終決定と通知. . . . . . . . . . . . . 8 4.8。 最終的な編集と公表. . . . . . . . . . . . . . 8 5。 正式なIESGは.8 6を見直します。 編集の再調査板. . . . . . . . . . . . . . . . . . 9 7。 レビュー. . . . . . . . . . . . . . 10 7.1の状態と有用性。 掲示されたレビュー. . . . . . . . . . . . . . . . . . . . . . 10 7.2。 ドキュメント. . . . . . . . . . . . . . . . . . . . 11 7.3を拒絶しました。 公表. . . . . . . . . . . . 11 8のために承認されたドキュメント。 知的所有権. . . . . . . . . . . . . . . . . 11 9。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 13 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 13 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1。 引用規格. . . . . . . . . . . . . . . . . . . 13 11.2。 承認. . . . . . . . . 15時点の有益な参照. . . . . . . . . . . . . . . . . . 14付録A.IABメンバー
Klensin & Thaler Informational [Page 2] RFC 4846 Independent Submissions July 2007
独立している[2ページ]RFC4846差出2007年7月の情報のKlensinとターレル
1. Introduction
1. 序論
There is a long-standing tradition in the Internet community, predating the IETF by many years, of use of the RFC Series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms. These documents, known as "Independent Submissions", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants. This document discusses the Independent Submission model and some reasons why it is important. It then describes editorial and processing norms that can be used for Independent Submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher.
長年の伝統がインターネットコミュニティにあります、IETF標準化過程、レビュー、および承認のメカニズムに根づかない材料を発行するためにRFC Seriesの使用の何年もIETFより前に起こって。「独立している差出」として知られているこれらのドキュメントはインターネットコミュニティのための多くの重要な機能、内部と活発なIETF関係者の共同体の外部の両方に役立ちます。 このドキュメントは無党派Submissionモデルとそれが重要であるいくつかの理由について議論します。 そして、それは共同体がIETF共同体とその第一の技術的な出版社とのはじまったばかりの男女関係に進んでいるので無党派Submissionsに使用できる社説と処理標準について説明します。
To understand the perspective of this document, it is important to remember that the RFC Editor function predates the creation of the IETF. As of the time of this writing, the RFC Series goes back 38 years [RFC2555], while the IETF is celebrating its 21st anniversary. All of the documents that were published before the IETF was created, and for some years thereafter, would be considered Independent Submissions today. As the IETF evolved, the Internet Architecture Board (IAB) and then the IETF itself chose to publish IETF documents as RFCs while fully understanding that the RFC Editor function was an independent publication mechanism. Other decisions were possible: e.g., the IETF could have decided to create its own publication series. It was felt that there was considerable value in continuing to publish the IETF work in the same series as the one used to publish the basic protocols for the Internet.
このドキュメントの見解を理解するために、RFC Editor機能がIETFの創造より前に起こるのを覚えているのは重要です。 この書くことの時現在、RFC Seriesは38年間[RFC2555]戻ります、IETFが21周年を祝っている間。 その後IETFが作成される前と数年間間に発表されたドキュメントのすべてが今日の無党派Submissionsであると考えられるでしょう。 IETFが発展したとき、インターネット・アーキテクチャ委員会(IAB)と次に、IETF自身は、RFC Editorが機能するのを完全に理解している間、RFCsが独立している公表メカニズムであったのでIETFドキュメントを発表するのを選びました。 他の決定は可能でした: 例えば、IETFは、それ自身の公表シリーズを作成すると決めたかもしれません。 基本プロトコルをインターネットに発表するのに使用されるものと同じシリーズにはかなりの値がIETF仕事を発行し続けるのにおいてあったと感じられました。
1.1. Terminology Note
1.1. 用語注意
This document describes what have historically been referred to as "Independent Submissions". That term is distinguished from those IETF and IAB community documents that originate from formal groups -- the IAB, IRTF, and IETF Working Groups -- and from submissions submitted to the Internet Engineering Steering Group (IESG) for Standards-Track, Informational, or Experimental processing. Documents produced by individuals, rather than IETF WGs or others IETF-affiliated groups, but submitted for publication via the IESG under Area Director sponsorship, are known as "individual submissions".
このドキュメントは、何が「独立している差出」と歴史的に呼ばれたかを説明します。 その用語を正式なグループ(IAB、IRTF、およびIETF Working Groups)から発するそれらのIETFとIAB共同体ドキュメントと区別して、Standards-道、Informational、またはExperimental処理のために差出からインターネットEngineering Steering Group(IESG)に提出します。 IETF WGsよりむしろ個人か他のものIETF-系列グループによって生産されますが、公表のためにAreaディレクターのスポンサーシップの下のIESGを通して提出されたドキュメントは「個々の差出」として知られています。
For convenience and obvious historical reasons, the editor and publisher of documents that are not processed through the IETF is known below as the "RFC Editor". The RFC Editor will typically be an organization of one or more senior people and associated editorial staff, and the term is used collectively below. That term is not
処理されない文書の便利、明白な歴史的な理由、エディタ、および出版社に関しては、IETFは「RFCエディタ」として以下で知られています。 RFC Editorは1人以上の年上の人々と関連編集部員の通常組織になるでしょう、そして、用語は以下でまとめて使用されます。 その用語はそうではありません。
Klensin & Thaler Informational [Page 3] RFC 4846 Independent Submissions July 2007
独立している[3ページ]RFC4846差出2007年7月の情報のKlensinとターレル
intended to predict the future, either in terms of who does the job or what they, or the document series, are called.
だれが仕事するか、そして、またはそれら、またはドキュメントシリーズが何に呼ばれるかに関して未来について予言するつもりでした。
1.2. Context and Philosophical Assumptions
1.2. 文脈と哲学的な仮定
This document complements the discussion and guidelines in [RFC4714], which focuses on Standards-Track documents. It takes a somewhat stronger view than the discussions that led to that document, starting from the belief that Independent Submissions are most valuable if they are, in fact, independent of the IETF process. From the perspective of the IETF, Independent Submissions are especially important as checks on the IETF processes even though such checks are not the only, or even a common, reason for them. That role is compromised if IETF-related entities are able to block or deprecate such documents to a degree beyond that needed to avoid difficulties with the standards process.
このドキュメントは[RFC4714]の議論とガイドラインの補足となります。(]はStandards-道のドキュメントに焦点を合わせます)。 それはそのドキュメントにつながった議論よりいくらか強い意見を取ります、彼らがIETFの過程から事実上独立しているなら無党派Submissionsが最も貴重であるという信念から始めて。 IETFの見解から、無党派Submissionsは、そのようなものがチェックしますが、IETFの過程のチェックが唯一の、または、同等のaコモン(それらの理由)でないので、特に重要です。 IETF関連の実体が標準化過程における困難を避けるのに必要であるそれを超えてそのようなドキュメントを非常に妨げるか、または非難できるなら、その役割は妥協します。
2. The Role of Independent Submissions
2. 独立している差出の役割
When the RFC Series was fairly new, RFCs were used to publish general papers on networking as well as the types of documents we would describe as standards today. Those roles also developed as part of the early design and development of the ARPANET, long before anyone dreamt of the IETF and when the distinction between, e.g., Standards and Informational documents was less precisely drawn. In more recent years, Independent Submissions have become important for multiple reasons, some of them relatively new. They include:
RFC Seriesがかなり新しかったときに、RFCsは、今日私たちが規格と説明するドキュメントのタイプと同様にネットワークでの一般的な論文を発行するのに使用されました。 また、それらの役割は早めのデザインの一部とアルパネットの開発として展開しました、だれでもIETFを夢にみる前、区別であるなら長く、例えば、StandardsとInformationalドキュメントはそれほど正確でなく作成されませんでした。 より最近の数年の間、無党派Submissionsは複数の理由で重要になっています。(それらのいくつかが理由のために比較的新しいです)。 それらは:
o Discussion of Internet-related technologies that are not part of
the IETF agenda.
o IETF議題の一部でないインターネット関連の技術の議論。
o Introduction of important new ideas as a bridge publication venue
between academia and IETF engineering.
o アカデミーとIETF工学の間の橋の公表開催地としての重要な新しいアイデアの導入。
o Informational discussions of technologies, options, or experience
with protocols.
o プロトコルの技術、オプション、または経験の情報の議論。
o Informational publication of vendor-specific protocols.
o ベンダー独自のプロトコルの情報の公表。
o Critiques and discussions of alternatives to IETF Standards-Track
protocols. The potential for such critiques provides an important
check on the IETF's standards processes and should be seen in that
light.
o 批評とIETF Standards-道のプロトコルへの代替手段の議論。 そのような批評の可能性は、IETFの標準化過程で重要なチェックを提供して、その光の中で見られるべきです。
o Documents considered by IETF Working Groups but not standardized.
While many documents of this type are still published in the IETF
document stream (see [RFC4844], Section 5.1.1) as Informational or
o IETF Working Groupsによって考えられますが、標準化されなかったドキュメント。 またはこのタイプの多くのドキュメントがInformationalとしてIETFドキュメントストリーム([RFC4844]、セクション5.1.1を見る)でまだ発表されている。
Klensin & Thaler Informational [Page 4] RFC 4846 Independent Submissions July 2007
独立している[4ページ]RFC4846差出2007年7月の情報のKlensinとターレル
Experimental RFCs, the Independent Submission path has
traditionally been open to them as well. However, because of
their intimate connection to the IETF Standards Process and WG
activities and the consequent sensitivity to exact statements of
relationships and to timing, there is reason to believe that such
documents should normally be published via the IETF document
stream. In any event, these documents are published for the
historical record.
実験的なRFCs、また、彼らにとって、無党派Submission道は伝統的に開いています。 しかしながら、IETF Standards ProcessとWG活動との彼らの親密な接続と関係の正確な声明と、そして、タイミングへの結果の感度のために、通常、そのようなドキュメントがIETFドキュメントストリームで発表されるはずであると信じる理由があります。 とにかく、これらのドキュメントは歴史的な記録のために発表されます。
o Satirical materials.
o 皮肉な材料。
o Meeting notes and reports (RFC 21 [RFC0021] is the earliest; RFC
1109 [RFC1109] is probably the most important).
o メモとレポート(RFC21[RFC0021]は最も前です; RFC1109[RFC1109]はたぶん最も重要である)を満たします。
o Editorials (the best example is IEN 137 [IEN137], not an RFC).
o 社説(最も良い例はRFCではなく、IEN137[IEN137]です)。
o Eulogies (RFC 2441 [RFC2441]).
o 賞賛(RFC2441[RFC2441])。
o Technical contributions (e.g., RFC 1810 [RFC1810]).
o 技術的な貢献(例えば、RFC1810[RFC1810])。
o Historically, RFC Editor and, at least prior to the handoff
between the Informational Sciences Institute (ISI) and the
Internet Corporation for Assigned Names and Numbers (ICANN) and
the June 2000 MOU [RFC2860], Internet Assigned Numbers Authority
(IANA) Policy Statements (e.g., RFC 2223 [RFC2223] and RFC 1591
[RFC1591]).
o 歴史的である、RFC Editorと少なくともInformational Sciences Institute(ISI)と、アイキャン(ICANN)と2000年6月のMOU[RFC2860]の間の移管の前にインターネットAssigned民数記Authority(IANA)方針Statements(例えば、RFC2223[RFC2223]とRFC1591[RFC1591])。
It should be clear from the list above that, to be effective, the review and approval process for Independent Submissions should be largely independent of the IETF. As an important principle that has been applied historically, the RFC Editor seeks advice from the IESG about possible relationships and conflicts with IETF work. Any submission that constitutes an alternative to, or is in conflict with, an IETF Standard or proposal for Standards-Track adoption must clearly indicate that relationship. The IESG may identify such conflicts as part of its review.
無党派Submissionsのためのレビューと承認審査方式が有効に、なるようにIETFから主に独立しているのは、上記のリストから明確であるはずです。 歴史的に適用された重要な原則として、RFC EditorはIETF仕事との可能な関係と闘争に関してIESGから助言を求めます。 Standards-道の採用のためのどんなそれと代替手段を構成しているか、または闘争中であることの服従、IETF Standardまたは提案も明確にその関係を示さなければなりません。 IESGは、そのような闘争がレビューの一部であると認識するかもしれません。
The specific procedures to be followed in review are described in Section 4 and Section 5.
レビューで続くべき特定の手順はセクション4とセクション5で説明されます。
3. Document Submission
3. 書類提出
Independent Submissions are submitted directly to the RFC Editor. They must first be posted as Internet-Drafts (I-Ds), so the submission is typically simply a note requesting that the RFC Editor consider a particular Internet-Draft for publication. The process is described in [RFC2223]. Further information can be found in the working draft of an update of that document [RFC2223BIS].
直接RFC Editorに独立しているSubmissionsを提出します。 最初にインターネット草稿(I-Ds)としてそれらを掲示しなければならないので、通常、服従は単にRFC Editorが公表のための特定のインターネット草稿を考えるよう要求する注意です。 過程は[RFC2223]で説明されます。 そのドキュメント[RFC2223BIS]のアップデートの概要版で詳細を見つけることができます。
Klensin & Thaler Informational [Page 5] RFC 4846 Independent Submissions July 2007
独立している[5ページ]RFC4846差出2007年7月の情報のKlensinとターレル
Any document that meets the requirements of this specification, of [RFC2223] and its successors, and of any intellectual property or other conditions that may be established from time to time, may be submitted to the RFC Editor for consideration as an Independent Submission. However, the RFC Editor prefers that documents created through IETF processes (e.g., working group output) be considered by the IESG and submitted using this path only if a working group or the IESG declines to publish it. In the latter cases, the review process will be more efficient if the authors provide a history of consideration and reviews of the document at the time of submission.
考慮のために無党派Submissionとして時々確立されるどんなこの仕様や、[RFC2223]とその後継者と、知的所有権や他の状態に関する必要条件も満たすどんなドキュメントもRFC Editorに提出するかもしれません。 しかしながら、RFC EditorはワーキンググループかIESGが、それを発行するのを断る場合にだけこの経路を使用することでIETFの過程(例えば、ワーキンググループ出力)で作成されたドキュメントをIESGが考えて、提出するのを好みます。 後者の場合では、作者が服従時点で考慮の歴史とドキュメントのレビューを供給するなら、吟味の過程は、より効率的になるでしょう。
4. The Review Process
4. 吟味の過程
In general, the steps in the review process are identified in the subsections below. Any of them may be iterated and, at the discretion of the RFC Editor, steps after the first may be taken out of order. In addition, the IESG review, as discussed in Section 5, must take place before a final decision is made on whether to publish the document.
一般に、吟味の過程におけるステップは以下の小区分で特定されます。 故障していた状態で1番目を取ったかもしれない後に、RFC Editorの裁量では、彼らのいずれも、繰り返されるかもしれなくて、踏みます。 さらに、ドキュメントを発表するかどうかに関して最終決定をする前にセクション5で議論するIESGレビューは行われなければなりません。
4.1. Posting of Draft
4.1. 草稿の任命
The author(s) or editor(s) of a document post it as an Internet- Draft.
ドキュメントの作者かエディタがインターネット草稿としてそれを掲示します。
4.2. Request for Publication
4.2. 公表に関する要求
After the normal opportunity for community review and feedback provided by the submission of the I-D and the I-D repository announcement thereof, the author or editor sends a request for consideration for publication to the RFC Editor at rfc-editor@rfc-editor.org. That request should note any community discussion or reviews of the document that have occurred before submission, as well as the desired document category (Informational or Experimental, as discussed in RFC 2026 [RFC2026], Section 4.2).
I-Dの服従とそれのI-D倉庫発表で提供された共同体レビューとフィードバックの正常な機会の後に、作者かエディタが公表のための考慮を求める要求を rfc-editor@rfc-editor.org のRFC Editorに送ります。 または、その要求がどんな共同体議論か服従の前に起こったドキュメントのレビューと、必要なドキュメントカテゴリにも注意するべきである、(情報、RFC2026[RFC2026]、セクション4.2で議論するようなExperimental
If the document requires any IANA allocations, authors should take care to check the assignment policy for the relevant namespace, since some assignment policies (e.g., "IETF Consensus") cannot be used by Independent Submissions. See RFC 2434 [RFC2434] for more information.
ドキュメントがIANA配分を必要とするなら、作者は関連名前空間がないかどうか課題方針をチェックするために注意するべきです、無党派Submissionsがいくつかの課題方針(例えば、「IETFコンセンサス」)を使用できないので。 詳しい情報に関してRFC2434[RFC2434]を見てください。
4.3. Initial RFC Editor Review
4.3. 初期のRFCエディタレビュー
RFC Editor staff performs an initial check on the document to determine whether there are obvious issues or problems and to decide on the sequencing of other steps.
RFC Editorスタッフは、明白な問題か問題があるかどうか決定して、他のステップの配列を決めるために初期のチェックをドキュメントに実行します。
Klensin & Thaler Informational [Page 6] RFC 4846 Independent Submissions July 2007
独立している[6ページ]RFC4846差出2007年7月の情報のKlensinとターレル
At any time during the process, the RFC Editor may make general and/or specific suggestions to the author on how to improve the editorial quality of the document and note any specific violations of the rules. The author will be expected to make the suggested updates, submit a new version, and inform the RFC Editor. This may be repeated as often as necessary to obtain an acceptable editorial quality.
いつでも、過程の間、RFC Editorは作者へのドキュメントの編集の品質を改良して、どう規則のどんな特定の違反にも注意するかに関する一般的な、そして/または、特定の提案をするかもしれません。 作者は、提案されたアップデートをして、新しいバージョンを提出して、RFC Editorに知らせると予想されるでしょう。 これは許容できる編集の品質を得るのにしばしば同じくらい必要な状態で繰り返されるかもしれません。
4.4. Review and Evaluation
4.4. レビューと評価
The RFC Editor arranges for one or more reviews of the document. This may include Editorial Board (see Section 6) reviews or reviews by others. Unsolicited reviews from parties independent of the author are welcome at any time.
RFC Editorはドキュメントの1つ以上のレビューを準備します。 これは他のものによるEditorial Board(セクション6を見る)レビューかレビューを含むかもしれません。 いつでも、作者の如何にかかわらずパーティーからの求められていないレビューを歓迎します。
At minimum, the author of every document shall receive a written summary of the review(s). Reviewer anonymity is discussed in Section 7. The RFC Editor may also share reviews with the Editorial Board.
最小限では、あらゆるドキュメントの作者はレビューの書かれた概要を受け取るものとします。 セクション7で評論家匿名について議論します。 また、RFC EditorはEditorial Boardとレビューを共有するかもしれません。
An author rebuttal to some aspect of a review, followed by a healthy technical dialog among the author and the reviewer(s), is fully appropriate. Consensus followed by document revision is the desired outcome.
作者と評論家の中の健康な技術的な対話があとに続いたレビューの何らかの局面への作者反論は完全に適切です。 ドキュメント改正があとに続いたコンセンサスは望ましい結果です。
The RFC Editor is expected to consider all competent reviews carefully, and in the absence of some unusual circumstance, a preponderance of favorable reviews should lead to publication.
RFC Editorが慎重にすべての十分なレビューを考えると予想されて、何らかの珍しい状況がないとき好評の優勢は公表につながるべきです。
4.5. Additional Reviews
4.5. 追加レビュー
If the author is dissatisfied with one or more review(s), the author may request that the RFC Editor solicit additional reviews. In exceptional circumstances, the author may request that the IAB review the document. Such requests to the IAB, and any reviews the IAB chooses to perform, will occur according to procedures of the IAB's choosing. The IAB is not required to initiate a review or comply with a request for one: a request to the IAB for a review is not an appeal process.
作者が1つ以上のレビューに不満であるなら、作者は、RFC Editorが追加レビューに請求するよう要求するかもしれません。 例外的な事情では、作者は、IABがドキュメントを再検討するよう要求するかもしれません。 IABの選ぶことの手順によると、IABへのそのような要求、およびIABが実行するのを選ぶどんなレビューも現れるでしょう。 IABはレビューを開始するか、または1のために要求に応じる必要はありません: レビューのためのIABへの要求は上告の過程ではありません。
4.6. Document Rejection
4.6. ドキュメント拒絶
If any stage of the review process just described leads to the conclusion that the document is not publishable, the RFC Editor may reject the document. Such rejection would normally be based on the conclusion that the submission does not meet the technical or editorial standards of the RFC Series or is not relevant to the areas that the series covers.
ただ説明された吟味の過程のどれかステージがドキュメントが発行可能でないという結論につながるなら、RFC Editorはドキュメントを拒絶するかもしれません。 通常、そのような拒絶は服従がRFC Seriesの技術的であるか編集の規格を満たさないか、またはシリーズがカバーする領域に関連していないという結論に基づくでしょう。
Klensin & Thaler Informational [Page 7] RFC 4846 Independent Submissions July 2007
独立している[7ページ]RFC4846差出2007年7月の情報のKlensinとターレル
If a document is rejected by the RFC Editor, the author may request an additional review from the IAB, as described below, but the IAB is not obligated to perform that review, nor is the RFC Editor obligated to publish it, even with a favorable IAB review.
ドキュメントがRFC Editorによって拒絶されるなら、作者が以下で説明されるようにIABから追加レビューを要求するかもしれませんが、IABはそのレビューを実行するのは義務付けられないで、それを発行するのが義務付けられたRFC Editorです、好ましいIABレビューがあっても。
4.7. Final Decision and Notification
4.7. 最終決定と通知
In all cases, the ultimate decision to publish or not publish, and with what text, rests with the RFC Editor.
全部で、ケース、発行するか、または発行しないで、どんなテキストで最終決定はRFC Editorに責任があります。
The RFC Editor will communicate the final decision to the author and the Editorial Board. For a rejection, there will be a summary of the reason(s) for the action.
RFC Editorは作者とEditorial Boardに最終決定を伝えるでしょう。 拒絶のために、動作の理由の概要があるでしょう。
Information about any IESG-requested publication delay or request to not publish a document will be posted to the RFC Editor Web site to supplement document status information.
どんなIESGによって要求された公表遅れかドキュメントを発表しないという要求に関する情報も、ドキュメント状態情報を補うためにRFC Editorウェブサイトに掲示されるでしょう。
4.8. Final Editing and Publication
4.8. 最終的な編集と公表
Once a document is approved for publication, it is handled in a fashion similar to other RFCs, with principles about priorities worked out with the IAB as appropriate.
ドキュメントが公表のためにいったん承認されると、それは他のRFCsと同様のファッションで扱われます、IABが適切な状態で解決されたプライオリティに関する原則で。
5. Formal IESG Review
5. 正式なIESGレビュー
At an appropriate time in the review process, normally after the RFC Editor has made a tentative decision to publish, the document is forwarded to the IESG for evaluation with a relatively short timeout. If the nature of the document persuades the RFC Editor or the IESG that the interests of the community or efficiency in the publication process would be better served by a different schedule, then that schedule should be followed. For example, if it appears to the RFC Editor that it is likely that the IESG will wish to take the document over and assign it to a working group, it may be better to ask for the IESG review prior to incurring the delays associated with other reviews or significant editorial work.
適当な機会に、吟味の過程で、RFC Editorが通常、発行するという仮の決定をした後に比較的短いタイムアウトに伴う評価のためにドキュメントをIESGに転送します。 ドキュメントの本質が、公表の過程への共同体か効率の関心が異なったスケジュールによって役立たれるほうがよいとRFC EditorかIESGを説得するなら、そのスケジュールは従われるべきです。 例えば、IESGがドキュメントを持って行って、ワーキンググループにそれを配属したくなりそうなようにRFC Editorにおいて見えるなら、他のレビューか重要な編集の仕事に関連している遅れを被る前に、IESGレビューを求めるほうがよいかもしれません。
The IESG evaluation is not a technical one. Instead, it covers the
issues listed in RFC 3932 [RFC3932] or its successors, presumably
from the perspective outlined above in Section 1.2. That is, the
evaluation should focus exclusively on conflicts or confusion with
IETF process and attempts to subvert ("end run") working group
activities.
IESG評価は技術的なものではありません。 代わりに、RFC3932[RFC3932]に記載された問題かその後継者を覆います、おそらくセクション1.2に上に概説された見解から。 すなわち、評価は、排他的にIETFの過程への闘争か混乱に焦点を合わせるべきであり、(「回避的な戦術」)ワーキンググループ活動を打倒するのを試みます。
At the time the document is forwarded to the IESG, the RFC Editor posts an indication on its Web site that the document is under IESG review and that comments on conflicts can be sent to the IESG with
ドキュメントがIESGレビューであって、闘争のコメントをIESGに送ることができるというIESG、RFC Editorポストへのウェブサイトにおける指示がドキュメントに送られる時に
Klensin & Thaler Informational [Page 8] RFC 4846 Independent Submissions July 2007
独立している[8ページ]RFC4846差出2007年7月の情報のKlensinとターレル
copies to the RFC Editor. Additional mechanisms may be developed from time to time to inform a community that a document is entering formal prepublication review. Comments not directly related to IETF procedures or conflicts may be sent directly to the author(s) and RFC Editor.
RFC Editorへのコピー。 追加メカニズムは、ドキュメントが正式な前公表レビューに入っていることを共同体に知らせるために時々開発されるかもしれません。 直接IETF手順に関連しないコメントか闘争を直接作者とRFC Editorに送るかもしれません。
In addition to the IESG review for conflict with IETF work, individuals in the IESG or in the broader IETF community are free to review a draft and, if they have comments of any kind --including the extreme case of believing that the proposal is damaging to the Internet as a whole-- these comments should be directed to the author(s) and the RFC Editor.
IETF仕事との闘争のためのIESGレビューに加えて、IESGか、より広いIETF共同体の個人は自由に草稿を見直すことができます、そして、彼らにどんな種類(提案が全体でインターネットにダメージが大きいと信じる極端なケースを含んでいる)のコメントもあるなら、これらのコメントは作者とRFC Editorに向けられるべきです。
If the IESG, after completing its review, identifies issues, it may recommend explanatory or qualifying text for the RFC Editor to include in the document if it is published.
レビューを終了した後にIESGが問題を特定するなら、RFC Editorが、ドキュメントにそれが発行されるかどうかを含むように、それは説明しているか資格を得ているテキストを推薦するかもしれません。
If the IESG concludes that publication of the document should be delayed for a reasonable period of time because its untimely publication could cause confusion or other harm with proposals under consideration for standardization, the RFC Editor will grant that request. The current agreement between the RFC Editor and the IESG on requested delays is expected to continue. That agreement permits the IESG to ask for a delay of up to six months and, if necessary, to renew that request twice, for a total possible delay of 18 months.
IESGが、タイミングの悪い公表が標準化のために考慮での提案で混乱か他の害を引き起こす場合があったのでドキュメントの公表が適正な期間の間遅れるべきであると結論を下すと、RFC Editorはその要求を承諾するでしょう。 要求された遅れのRFC EditorとIESGとの現在の協定が続くと予想されます。 その協定は、IESGが最大6カ月の遅れを求めることを許可します、そして、必要なら、それを更新するには、可能な合計のために、二度、延着するよう18カ月を要求してください。
If the IESG concludes that the document should not be published as an RFC, it will request that the RFC Editor not publish and provide appropriate justification for that request. The RFC Editor will consider the request to not publish the document.
IESGが、ドキュメントがRFCとして発表されるべきでないと結論を下すと、それは、RFC Editorがその要求のための適切な正当化を発行して、提供しないよう要求するでしょう。 RFC Editorはドキュメントを発表しないという要求を考えるでしょう。
The RFC Editor or the author may request that the IAB review the IESG's request to delay or not publish the document and request that the IAB provide an additional opinion. Such a request will be made public via the RFC Editor Web site. As with the IESG review itself, the IAB's opinion, if any, will be advisory. And, as with author requests for an IAB technical review (see Section 4.5), the IAB is not obligated to perform this type of review and may decline the request.
RFC Editorか作者が、IABが延着するというIESGの要求を再検討するよう要求しないか、ドキュメントを発表して、IABが追加意見を提供するよう要求しないかもしれません。 そのような要求はRFC Editorウェブサイトを通して公表されるでしょう。 IESGレビュー自体の場合、もしあればIABの意見は顧問になるでしょう。 そして、IAB技術審査(セクション4.5を見る)を求める作者要求なら、IABはこのタイプのレビューを実行するのは義務付けられないで、要求を断つかもしれません。
6. The Editorial Review Board
6. 編集の再調査板
The RFC Editor appoints and maintains the Editorial Review Board, which, much like the editorial boards of professional journals and publishers, provides the RFC Editor with both advice and reviews of particular proposed publications and general and strategic policy advice. The membership list of the Editorial Review Board is public and can be found at http://www.rfc-editor.org/edboard.html.
RFC EditorはEditorial Review Boardを任命して、維持します。(専門雑誌と出版社の編集局のように、Editorial Review Boardは特定の提案された刊行物のアドバイスとレビューと一般的で戦略の政策的助言の両方をRFC Editorに提供します)。 Editorial Review Boardに関する会員名簿は、公共であり、 http://www.rfc-editor.org/edboard.html で見つけることができます。
Klensin & Thaler Informational [Page 9] RFC 4846 Independent Submissions July 2007
独立している[9ページ]RFC4846差出2007年7月の情報のKlensinとターレル
Editorial Board members serve at the pleasure of the RFC Editor. From time to time, the RFC Editor will solicit suggestions for new appointees from the IAB and other sources and will seek IAB comments on those to be appointed. The RFC Editor will also solicit IAB comments on the effectiveness of the review process and the quality of documents being published and criteria applied. However, to ensure the independence of the Independent Submission process, the final decision to appoint (or not appoint) Editorial Board members rests with the RFC Editor.
編集BoardメンバーはRFC Editorの喜びで勤めます。 RFC Editorは、時々、新しい被任命者のためにIABと他のソースから提案に請求して、任命されるためにそれらでIABコメントを求めるでしょう。 また、RFC Editorは吟味の過程の有効性と発表されるドキュメントと評価基準の品質のコメントが適用したIABに請求するでしょう。 または、しかしながら、無党派からの独立を確実にするために、Submissionは処理します、任命する最終決定、(任命しない、)、RFC Editorとの編集のBoardメンバー休息。
7. Status and Availability of Reviews
7. レビューの状態と有用性
The RFC Editor will conduct the reviews discussed above with the intent of balancing fairness to authors, transparency of the review process to the general community, protection of reviewers from possible retaliation or undue pressure, and the interest of the community in having any significant dissents from published documents available to the community with the same degree of scrutiny that the original documents received. To this end, reviews and information about reviewers will be made public under the following circumstances. In special cases in which other considerations apply, the RFC Editor may adopt special provisions after reviewing the circumstances and proposed action with the IAB.
RFC Editorは上で正本が受けた同じ度の精査で共同体に利用可能な公表された文書から作者へのバランスをとることの公正の意図、一般的な共同体への吟味の過程の透明、可能な報復か不当な圧力からの評論家の保護、およびどんな重要な異議も持っていることへの共同体の関心と議論したレビューを行うでしょう。 このために、評論家のレビューと情報は以下の状況で公表されるでしょう。 他の問題が適用される特別な場合では、IABとの事情と提案された動作を再検討した後に、RFC Editorは特別条項を採用するかもしれません。
Any reviewer participating in the process outlined in this document does so on the condition of giving consent to handling of the reviews as outlined in this section. In special cases, individual arrangements may be worked out in advance with the RFC Editor.
本書では概説された過程に参加するどんな評論家もなどに、このセクションで概説されているようにレビューの取り扱いに承諾を与えるという条件をします。 特別な場合では、個々のアレンジメントはあらかじめ、RFC Editorと共に解決されるかもしれません。
As described in Section 4.4, all reviews will be shared with the document authors (with possible editing to remove any extreme language). The names of the reviewers will normally accompany these reviews, but reviewers will be granted anonymity upon request to the RFC Editor. The RFC Editor will in any case forward any author rebuttal messages to the reviewer.
セクション4.4で説明されるように、すべてのレビューがドキュメント作者(どんな極端な言語も取り除く可能な編集がある)と共有されるでしょう。 評論家の名前は通常これらのレビューに伴うでしょうが、匿名は評論家がRFC Editorへの要求への承諾になるでしょう。 どのような場合でも、RFC Editorはどんな作者反論メッセージも評論家に転送するでしょう。
Nothing in this section or the subsections below precludes private communications between reviewers, the Editorial Board, and the RFC Editor; such communications will remain confidential.
下のこのセクションか小区分における何も評論家(Editorial Board)とRFC Editorとの私信を排除しません。 そのようなコミュニケーションは秘密のままで残るでしょう。
7.1. Posted Reviews
7.1. 掲示されたレビュー
Once a final accept or reject decision has been made on a document, the RFC Editor may choose to post the full set of reviews (and author rebuttals, if any) associated with a document, if doing so would be in the best interest of the community. The author may request earlier posting of reviews and rebuttals, to inspire additional unsolicited reviews, for example. The names of the reviewers will
一度、決勝が受け入れるか、またはドキュメントの上に廃棄物決定をしました、とRFC Editorはレビュー(もしあれば反論を書く)のフルセットがドキュメントに関連づけたポストに選ぶかもしれません、そうするのが、共同体の最も良い利益のためでそうなら。 作者は、例えば、追加求められていないレビューを奮い立たせるためにレビューと反論の以前の任命を要求するかもしれません。 評論家の名前はそうするでしょう。
Klensin & Thaler Informational [Page 10] RFC 4846 Independent Submissions July 2007
独立している[10ページ]RFC4846差出2007年7月の情報のKlensinとターレル
accompany their reviews, except for a reviewer who requested anonymity.
匿名を希望した評論家以外の彼らのレビューに伴ってください。
The author will be notified in advance of the intent to post the final reviews. The author may then request that the document be withdrawn and the reviews kept private. However, such an author request must be timely, generally within 14 days of the notification of intent to post.
作者は最終審査を掲示する意図の前に通知されるでしょう。 次に、作者は、ドキュメントが引っ込められるよう要求するかもしれません、そして、レビューは個人的にままでした。 しかしながら、そのような作者要求は一般に掲示する意向の通知の14日以内にタイムリーであるに違いありません。
7.2. Rejected Documents
7.2. 拒絶されたドキュメント
If the RFC Editor rejects a document, the author has the following options for recourse.
RFC Editorがドキュメントを拒絶するなら、作者には、償還請求のための以下のオプションがあります。
o Request one or more additional reviews (Section 4.5) followed by a
reconsideration.
o 再考で要求1か、より多くの追加レビュー(セクション4.5)が続きました。
o Request an IAB review (Section 4.5, Section 4.6) followed by a
reconsideration.
o 再考でIABレビュー(セクション4.5、セクション4.6)が続いたよう要求してください。
o Request that the reviews be published on the RFC Editor Web site.
o レビューがRFC Editorウェブサイトで発行されるよう要求してください。
7.3. Documents Approved for Publication
7.3. 公表のために承認されたドキュメント
In considering whether to make review materials public for documents accepted for publication, the RFC Editor is expected to note that the best way to comment on or dissent from an RFC is generally another RFC; that reviews critical of a document are not themselves reviewed; that the review and refutation process is necessarily fragmentary; and that a reviewer who feels strongly about a subject about which a review has already been written often would not need to do significant additional work to produce an RFC-format document from that review.
レビューの材料を公表のために受け入れられたドキュメントに公共にするかどうか考える際に、RFC Editorが、一般に、RFCから批評するか、または反対する最も良い方法が別のRFCであることに注意すると予想されます。 ドキュメントについて批判的なレビューが自分たちでないことは論評しました。 レビューと論破が処理されるのは、必ず断片的です。 そして、レビューが既に書かれているこの件に関して確信する評論家は、しばしばそのレビューからRFC-形式ドキュメントを製作するために重要な追加仕事をする必要があるというわけではないでしょう。
8. Intellectual Property Rights
8. 知的所有権
The following material was extracted from the relevant sections of BCP 78 [RFC3978] [RFC4748] in order to get all Independent Submission information for technical publications produced under the auspices of the IETF, the IETF Administrative Support Activity (IASA) or the IETF Trust, or the Internet Society (ISOC) into a single place and to initialize the process of separating discussions of Independent Submissions from those about Standards-Track or other IETF documents. Note that the text that follows uses the term "RFC Editor Contribution" to describe the same type of document referred to as an "Independent Submission" elsewhere in this document. The RFC Editor
以下の材料は、単一の場所にIETF、IETF Administrative Support Activity(IASA)、IETF Trust、またはインターネット協会の前兆(ISOC)で製作された技術的な出版物、Standards-道か他のIETFドキュメントの周りでそれらと無党派Submissionsの議論を切り離す過程を初期化するためにすべての無党派Submission情報を得るためにBCP78[RFC3978][RFC4748]の関連セクションから抽出されました。 従うテキストがほかの場所に本書では「独立している服従」と呼ばれた同じタイプのドキュメントについて説明するのに「RFCエディタ貢献」という用語を使用することに注意してください。 RFCエディタ
Klensin & Thaler Informational [Page 11] RFC 4846 Independent Submissions July 2007
独立している[11ページ]RFC4846差出2007年7月の情報のKlensinとターレル
may change these provisions from time to time after obtaining the advice and consent of the IETF Trust in the RFC Editor's capacity as the formal publisher of RFCs.
RFCsの正式な出版社としてRFC Editorの立場における、IETF Trustの助言と同意を得た後に、時々これらの条項を変えるかもしれません。
By submission of an RFC Editor Contribution, each person actually submitting the RFC Editor Contribution, and each named co- Contributor, is deemed to agree to the following terms and conditions, and to grant the following rights, on his or her own behalf and on behalf of the organization the Contributor represents or is sponsored by (if any) when submitting the RFC Editor Contribution.
RFC Editor Contributionの服従で、以下の条件に同意して、実際にRFC Editor Contributionを提出する各人、およびそれぞれの命名された共同貢献者がその人の自己の代理とRFC Editor Contributionを提出するときContributorが表すか、または(もしあれば)後援される組織を代表して以下の権利を与えると考えられます。
a. For Internet-Drafts that are expected to be submitted as RFC
Editor Contributions: To the extent that an RFC Editor
Contribution or any portion thereof is protected by copyright and
other rights of authorship, the Contributor, and each named co-
Contributor, and the organization he or she represents or is
sponsored by (if any) grant an irrevocable, non-exclusive,
royalty-free, world-wide right and license to the IETF Trust and
the IETF under all intellectual property rights in the RFC Editor
Contribution for at least the life of the Internet-Draft, to
copy, publish, display, and distribute the RFC Editor
Contribution as an Internet-Draft.
a。 RFC Editor Contributionsとして提出すると予想されるインターネット草稿のために: RFC Editor Contributionかそれのどんな部分も著述業、Contributor、それぞれの命名された共同貢献者、およびその人が代理をする組織の著作権と他の権利によって保護されるか、または(もしあれば)交付金によって後援されるという範囲、呼び戻せなくて、非排他的です; ロイヤリティのいらないです、世界的な権利とIETF Trustへのライセンスと少なくともコピーへのインターネット草稿の人生のためのRFC Editor Contributionのすべての知的所有権の下におけるIETFはインターネット草稿としてRFC Editor Contributionを発行して、表示して、分配します。
b. For an RFC Editor Contribution submitted for publication as an
RFC, and to the extent described above, the Contributor, each
named co-Contributor, and the organizations represented above
grant the same license to those organizations and to the
community as a whole to copy, publish, display, and distribute
the RFC Editor Contribution irrevocably and in perpetuity and,
also irrevocably and in perpetuity, grant the rights listed below
to those organizations and entities and to the community:
b。 取消不能と永続ではも、公表のためにRFCと、上で説明された範囲と、Contributorと、それぞれの命名された共同貢献者と、上で代理をされた組織に提出されたRFC Editor Contributionに関しては、コピーするために全体でそれらの組織と、そして、共同体に同じライセンスを与えてください、そして、発行してください、そして、表示してください、そして、取消不能と永続でRFC Editor Contributionを分配してください、そして、以下にそれらの組織と実体と、そして、共同体に記載された権利を与えてください:
A. to prepare or allow the preparation of translations of the
RFC into languages other than English,
A. RFCに関する翻訳の準備を英語以外の言語に準備するか、または許すために
B. unless explicitly disallowed in the notices contained in an
RFC Editor Contribution, to prepare derivative works (other
than translations) that are based on or incorporate all or
part of the RFC Editor Contribution, or comment upon it. The
license to such derivative works shall not grant the IETF
Trust, the IETF, or other party preparing a derivative work
any more rights than the license to the original RFC Editor
Contribution, and
B. RFC Editor Contributionに含まれた通知で明らかに禁じられない場合、派生している作品(翻訳を除いた)にそれを準備するには、RFC Editor Contributionのすべてか一部、またはそれのコメントをに基づいているか、または取り入れてください。 そしてそのような派生している作品へのライセンスがIETF Trust、IETF、またはオリジナルのRFC Editor Contributionへのライセンス以外のそれ以上の権利を派生著作物に準備しているパーティーを与えないものとする。
C. to reproduce any trademarks, service marks, or trade names
that are included in the RFC Editor Contribution solely in
connection with the reproduction, distribution, or
またはC. どんな商標も再生させるために、RFC Editor Contributionに唯一再現に関して含まれているマーク、または商号を修理してください、分配。
Klensin & Thaler Informational [Page 12] RFC 4846 Independent Submissions July 2007
独立している[12ページ]RFC4846差出2007年7月の情報のKlensinとターレル
publication of the RFC Editor Contribution and derivative
works thereof as permitted by this paragraph. Any entity
reproducing RFC Editor Contributions will, as a condition of
permission of such reproduction, preserve trademark and
service mark identifiers used by the Contributor of the RFC
Editor Contribution, including (TM) and (R) where
appropriate.
RFC Editor Contributionと派生物の公表はこのパラグラフによって受入れられるようにそれについて働いています。 そのような再現の許可の状態として、RFC Editor Contributionsを再生させるどんな実体も識別子がRFC Editor ContributionのContributorで使用した商標とサービスマークを保存するでしょう、適切であるところに(TM)と(R)を含んでいて。
D. The Contributor grants the IETF Trust and the IETF,
permission to reference the name(s) and address(es) of the
Contributor(s) and of the organization(s) s/he represents or
is sponsored by (if any).
D. ContributorはIETF TrustとIETF、その人が代理をするか、または(もしあれば)後援されるContributor(s)と組織の参照の名前とアドレス(es)への許可を与えます。
9. Security Considerations
9. セキュリティ問題
This document specifies an RFC Editor (and, indirectly, IETF) administrative and publication procedure. It has no specific security implications.
このドキュメントはRFC Editor(間接的にIETF)管理と公表手順を指定します。 それには、どんな特定のセキュリティ意味もありません。
10. Acknowledgments
10. 承認
Special thanks are due to Bob Hinden and Craig Partridge, who made several suggestions for improved text in earlier versions of this document, and to Stewart Bryant, Scott Bradner, Brian Carpenter, Vint Cerf, Leslie Daigle, and Olaf Kolkman, who made a number of useful suggestions about the organization and content of subsequent versions. We also express our appreciation to the IETF and Scott Bradner, Editor, for the material extracted from BCP 78 [RFC3978] and used in Section 8.
特別な感謝はボブHindenとクレイグPartridgeのためです。(Partridgeはこのドキュメントの以前のバージョンと、スチュワートへの改良されたテキストのためのいくつかの提案を組織に関する多くの役に立つ提案とその後のバージョンの内容を作ったブライアント、スコット・ブラドナー、ブライアンCarpenter、Vintサーフ、レスリーDaigle、およびオラフKolkmanにしました)。 また、私たちはIETFとスコット・ブラドナーに感謝を申し上げます、Editor、BCP78[RFC3978]から抽出されて、セクション8で使用される材料のために。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC
Authors", RFC 2223, October 1997.
[RFC2223] ポステル、J.、およびJ.レイノルズ、「指示、RFCが書く、」、RFC2223、10月1997日
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents:
Procedures", BCP 92, RFC 3932, October 2004.
[RFC3932] Alvestrand、H.、「IESGとRFCエディタは以下を記録します」。 「手順」、BCP92、RFC3932、2004年10月。
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3978, March 2005.
[RFC3978] ブラドナー、S.、「貢献におけるIETF権利」、BCP78、RFC3978、2005年3月。
[RFC4748] Bradner, S., "RFC 3978 Update to Recognize the IETF
Trust", BCP 78, RFC 4748, October 2006.
[RFC4748] ブラドナー、S.、「RFC3978は、IETF信用を認識するのをアップデートする」BCP78、RFC4748、2006年10月。
Klensin & Thaler Informational [Page 13] RFC 4846 Independent Submissions July 2007
独立している[13ページ]RFC4846差出2007年7月の情報のKlensinとターレル
11.2. Informative References
11.2. 有益な参照
[IEN137] Cohen, D., "On Holy Wars and a Plea for Peace",
IEN 137, April 1980,
<ftp://ftp.rfc-editor.org/in-notes/ien/ien137.txt>.
D. [IEN137]コーエン、「平和のための聖戦と請願」のIEN137の1980年4月<ftp://ftp.rfc-editor.org/注意している/ien/ien137.txt>。
[RFC0021] Cerf, V., "Network meeting", RFC 21, October 1969.
[RFC0021] サーフ、V.、「ネットワークミーティング」、RFC21、1969年10月。
[RFC1109] Cerf, V., "Report of the second Ad Hoc Network
Management Review Group", RFC 1109, August 1989.
[RFC1109] サーフ、V.、「第2Ad Hoc Network Management Review Groupのレポート」、RFC1109、1989年8月。
[RFC1591] Postel, J., "Domain Name System Structure and
Delegation", RFC 1591, March 1994.
[RFC1591] ポステルと、J.と、「ドメインネームシステム構造と代表団」(RFC1591)は1994を行進させます。
[RFC1810] Touch, J., "Report on MD5 Performance", RFC 1810,
June 1995.
接触、J.が「MD5パフォーマンスに関して報告する」[RFC1810]、RFC1810、1995年6月。
[RFC2223BIS] Reynolds, J., Ed. and R. Braden, Ed., "Instructions to
Request for Comments (RFC) Authors", Work in Progress,
August 2004.
エド[RFC2223BIS]レイノルズ、J.、R.ブレーデン、エド、8月2004、「(RFC)が書くコメントのために要求する指示」は進行中で働いています。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26,
RFC 2434, October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC2441] Cohen, D., "Working with Jon Tribute delivered at UCLA,
October 30, 1998", RFC 2441, November 1998.
D. [RFC2441]コーエン、RFC2441、「UCLA、1998年10月30日に届けられたジョンTributeと共に働いている」11月1998日
[RFC2555] Braden, R., Reynolds, J., Crocker, S., Cerf, V.,
Feinler, J., and C. Anderson, "30 Years of RFCs",
RFC 2555, April 1999.
[RFC2555]ブレーデンとR.とレイノルズとJ.とクロッカーとS.とサーフとV.とFeinler、J.とC.アンダーソン、「30年間のRFCs」RFC2555(1999年4月)。
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum
of Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860,
June 2000.
[RFC2860] 大工、B.、ベイカー、F.、およびM.ロバーツ、「インターネットの技術的な仕事に関する了解覚書は数の権威を割り当てました」、RFC2860、2000年6月。
[RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF
Technical Publication Service", RFC 4714, October 2006.
[RFC4714] マンキンとA.とS.ヘイズ、「IETF技術刊行物サービスのための要件」、RFC4714、2006年10月。
[RFC4844] Daigle, L., Ed. and IAB, "The RFC Series and RFC
Editor", RFC 4844, July 2007.
エド[RFC4844]Daigle、L.、IAB、「RFCシリーズとRFCエディタ、」、RFC4844、7月2007日
Klensin & Thaler Informational [Page 14] RFC 4846 Independent Submissions July 2007
独立している[14ページ]RFC4846差出2007年7月の情報のKlensinとターレル
Appendix A. IAB Members at the Time of Approval
承認時点の付録A.IABメンバー
Bernard Aboba Loa Andersson Brian Carpenter Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman Kurtis Lindqvist David Meyer David Oran Eric Rescorla Dave Thaler Lixia Zhang
バーナードAboba Loaアンデションブライアン大工レスリーDaigle ElwynデイヴィースケビンFallオラフ・Kolkmanカーティス・リンクヴィスト・デヴィッド・マイヤー・デヴィッド・オラン・エリック・レスコラ・デーヴ・ターレルLixiaチャン
Authors' Addresses
作者のアドレス
John C Klensin (editor) 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
ジョンC Klensin(エディタ)1770マサチューセッツAve、#322ケンブリッジ、MA02140米国
Phone: +1 617 491 5735 EMail: john-ietf@jck.com
以下に電話をしてください。 +1 5735年の617 491メール: john-ietf@jck.com
Dave Thaler (editor) One Microsoft Way Redmond, WA 98052 USA
デーヴThaler、(エディタ)1つのマイクロソフト道のワシントン98052レッドモンド(米国)
Phone: +1 425 703 8835 EMail: dthaler@microsoft.com
以下に電話をしてください。 +1 8835年の425 703メール: dthaler@microsoft.com
Klensin & Thaler Informational [Page 15] RFC 4846 Independent Submissions July 2007
独立している[15ページ]RFC4846差出2007年7月の情報のKlensinとターレル
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Klensin & Thaler Informational [Page 16]
Klensinとターレル情報です。[16ページ]
一覧
スポンサーリンク
