RFC1602 日本語訳
1602 The Internet Standards Process -- Revision 2. InternetArchitecture Board, Internet Engineering Steering Group. March 1994. (Format: TXT=88465 bytes) (Obsoletes RFC1310) (Obsoleted by RFC2026) (Updated by RFC1871) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Internet Architecture Board and Request for Comments: 1602 Internet Engineering Steering Group Obsoletes: 1310 March 1994 Category: Informational
ワーキンググループインターネット・アーキテクチャ委員会をネットワークでつないでください、そして、コメントのために以下を要求してください。 1602年のインターネット工学運営グループは以下を時代遅れにします。 1310 1994年3月のカテゴリ: 情報
The Internet Standards Process -- Revision 2
インターネット標準化過程--改正2
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Notice
通知
This informational memo presents the current procedures for creating and documenting Internet Standards. This document is provisional, pending legal review and concurrence of the Internet Society Trustees. It is being published in this form to keep the Internet Community informed as to the current status of policies and procedures for Internet Standards work.
この情報のメモはインターネットStandardsを作成して、記録するための現在の手順を提示します。 このドキュメントは、インターネット協会Trusteesで暫定的で、未定の法的なレビューと合意です。 それは、方針の現在の状態に関して知識があるインターネット共同体と手順をStandardsが扱うインターネットに維持するためにこのフォームで発行されています。
Abstract
要約
This document is a revision of RFC 1310, which defined the official procedures for creating and documenting Internet Standards.
このドキュメントはRFC1310の改正です。(RFCはインターネットStandardsを作成して、記録するための公式の手順を定義しました)。
This revision (revision 2) includes the following major changes:
この改正(改正2)は以下の大きな変化を含んでいます:
(a) The new management structure arising from the POISED Working
Group is reflected. These changes were agreed to by the IETF
plenary and by the IAB and IESG in November 1992 and accepted by
the ISOC Board of Trustees at their December 1992 meeting.
(a) POISED作業部会から起こる新しい経営組織は反映されます。 これらの変化は、1992年11月のIETFで絶対的、そして、IABとIESGによって同意されて、彼らの1992年12月のミーティングでTrusteesのISOC Boardによって受け入れられました。
(b) Prototype status is added to the non-standards track maturity
levels (Section 2.4.1).
(b) 原型状態は非標準化過程成熟レベル(セクション2.4.1)に加えられます。
(c) The Intellectual Property Rights section is completely revised,
in accordance with legal advice. Section 5 of this document
replaces Sections 5 and 6 of RFC-1310. The new section 5 has
been reviewed by legal counsel to the Internet Society.
(c) 弁護士の意見に従って、Intellectual Property Rights部は完全に改訂されます。 このドキュメントのセクション5はRFC-1310のセクション5と6に取って代わります。 新しいセクション5はインターネット協会の弁護士によって視察されました。
IAB - IESG [Page 1] RFC 1602 Internet Standards Process March 1994
IAB--IESG[1ページ]RFC1602インターネット規格は1994年3月に処理されます。
(d) An appeals procedure is added (Section 3.6).
(d) 上告手順は加えられます(セクション3.6)。
(e) The wording of sections 1 and 1.2 has been changed to clarify
the relationships that exist between the Internet Society and
the IAB, the IESG, the IETF, and the Internet Standards process.
(e) インターネット協会と、IABと、IESGと、IETFと、インターネットStandardsの過程の間に存在する関係をはっきりさせるためにセクション1と1.2の言葉遣いを変えました。
(f) An Appendix B has been added, listing the contact points for the
RFC editor, the IANA, the IESG, the IAB and the ISOC. The
"future issues" are now listed in Appendix C.
(f) Appendix Bは加えられます、RFCエディタ、IANA、IESG、IAB、およびISOCのための接点をリストアップして。 「将来の問題」は現在、Appendix Cに記載されます。
IAB - IESG [Page 2] RFC 1602 Internet Standards Process March 1994
IAB--IESG[2ページ]RFC1602インターネット規格は1994年3月に処理されます。
TABLE OF CONTENTS
目次
1. INTRODUCTION ................................................. 3
1.1 Internet Standards. ...................................... 4
1.2 Organizations ............................................ 6
1.3 Standards-Related Publications ........................... 8
1.4 Internet Assigned Number Authority (IANA) ................ 10
2. NOMENCLATURE ................................................. 11
2.1 The Internet Standards Track ............................. 11
2.2 Types of Specifications .................................. 12
2.3 Standards Track Maturity Levels .......................... 13
2.4 Non-Standards Track Maturity Levels ...................... 15
2.5 Requirement Levels ....................................... 17
3. THE INTERNET STANDARDS PROCESS ............................... 19
3.1 Review and Approval ...................................... 19
3.2 Entering the Standards Track ............................. 20
3.3 Advancing in the Standards Track ......................... 21
3.4 Revising a Standard ...................................... 22
3.5 Retiring a Standard ...................................... 22
3.6 Conflict Resolution and Appeals .......................... 23
4. EXTERNAL STANDARDS AND SPECIFICATIONS ........................ 24
5. INTELLECTUAL PROPERTY RIGHTS ................................. 26
5.1. General Policy .......................................... 26
5.2. Definitions ............................................. 26
5.3 Trade Secret Rights ...................................... 27
5.4. Rights and Permissions .................................. 27
5.5. Notices ................................................. 30
5.6. Assurances .............................................. 31
6. REFERENCES ................................................... 34
APPENDIX A: GLOSSARY OF ACRONYMS ................................. 35
APPENDIX B: CONTACT POINTS ....................................... 35
APPENDIX C: FUTURE ISSUES ........................................ 36
Security Considerations .......................................... 37
Authors' Addresses ............................................... 37
1. 序論… 3 1.1 インターネット規格。 ...................................... 4 1.2の組織… 6 1.3 規格関連の刊行物… 8 1.4 ISOCの機関の一つで(IANA)… 10 2. 用語体系… 11 2.1 インターネット規格は追跡されます… 11 2.2のタイプの仕様… 12 2.3の規格が成熟レベルを追跡します… 13 2.4 非標準化過程成熟レベル… 15 2.5 要件レベル… 17 3. インターネット規格は処理されます… 3.1が見直す19と承認… 19 3.2 規格を入れて、追跡してください… 20 規格で進む3.3は追跡されます… 21 3.4 規格を改訂します… 22 3.5 規格を回収します… 22 3.6 紛争解決と上告… 23 4. 外部の規格と仕様… 24 5. 知的所有権はまっすぐになります… 26 5.1. 全般的執行方針… 26 5.2. 定義… 26 5.3企業秘密はまっすぐになります… 27 5.4. 権利と許容… 27 5.5. 通知… 30 5.6. 保証… 31 6. 参照… 34 付録A: 頭文字語の用語集… 35 付録B: 接点… 35 付録C: 将来の問題… 36 セキュリティ問題… 37人の作者のアドレス… 37
1. INTRODUCTION
1. 序論
This memo documents the process currently used by the Internet community for the standardization of protocols and procedures. The Internet Standards process is an activity of the Internet Society that is organized and managed on behalf of the Internet community by the Internet Architecture Board (IAB) and the Internet Engineering Steering Group.
このメモは現在プロトコルと手順の標準化にインターネットコミュニティによって使用されている過程を記録します。 インターネットStandardsの過程はインターネット・アーキテクチャ委員会(IAB)とインターネットEngineering Steering Groupのそばのインターネットコミュニティを代表して組織化されて、経営されるインターネット協会の活動です。
IAB - IESG [Page 3] RFC 1602 Internet Standards Process March 1994
IAB--IESG[3ページ]RFC1602インターネット規格は1994年3月に処理されます。
1.1 Internet Standards
1.1 インターネット規格
The Internet, a loosely-organized international collaboration of
autonomous, interconnected networks, supports host-to-host
communication through voluntary adherence to open protocols and
procedures defined by Internet Standards. There are also many
isolated internets, i.e., sets of interconnected networks, which
are not connected to the Internet but use the Internet Standards.
インターネット(自治の、そして、インタコネクトされたネットワークの緩く組織化された国際協力)は、インターネットStandardsによって定義されたプロトコルと手順を開くために自発的の固守でホスト間通信を支持します。 また、すなわち、多くの孤立しているインターネット、セットの相互接続ネットワークがあります。(インターネットに関連づけられませんが、相互接続ネットワークはインターネットStandardsを使用します)。
Internet Standards were once limited to those protocols composing
what has been commonly known as the "TCP/IP protocol suite".
However, the Internet has been evolving towards the support of
multiple protocol suites, especially the Open Systems
Interconnection (OSI) suite. The Internet Standards process
described in this document is concerned with all protocols,
procedures, and conventions that are used in or by the Internet,
whether or not they are part of the TCP/IP protocol suite. In the
case of protocols developed and/or standardized by non-Internet
organizations, however, the Internet Standards process may apply
only to the application of the protocol or procedure in the
Internet context, not to the specification of the protocol itself.
インターネットStandardsは一度「TCP/IPプロトコル群」として一般的に知られていることを構成するそれらのプロトコルに制限されました。 しかしながら、インターネットは複数のプロトコル群、特にオープン・システム・インターコネクション(OSI)スイートのサポートに向かって発展しています。 本書では説明されたインターネットStandardsの過程はインターネットかインターネットによって用いられるすべてのプロトコル、手順、およびコンベンションに関係があります、それらがTCP/IPプロトコル群の一部であるか否かに関係なく。 しかしながら、非インターネット組織によって開発される、そして/または、標準化されたプロトコルの場合では、インターネットStandardsの過程はプロトコル自体の仕様ではなく、インターネット文脈における、プロトコルか手順の適用だけに適用されるかもしれません。
In general, an Internet Standard is a specification that is stable
and well-understood, is technically competent, has multiple,
independent, and interoperable implementations with substantial
operational experience, enjoys significant public support, and is
recognizably useful in some or all parts of the Internet.
一般に、インターネットStandardは安定した仕様であり、よく分かって、技術的に有能であり、かなりの運用経験による複数の、そして、独立していて、共同利用できる実現を持って、重要な公的支援を楽しんで、インターネットのいくつかかすべての地域で認識可能に役に立ちます。
The procedures described in this document are designed to be fair,
open and objective; to reflect existing (proven) practice; and to
be flexible.
本書では説明された手順は公正で、開いて客観的になるように設計されています。 存在(立証される)を反映するには、練習してください。 そして、フレキシブルになるように。
IAB - IESG [Page 4] RFC 1602 Internet Standards Process March 1994
IAB--IESG[4ページ]RFC1602インターネット規格は1994年3月に処理されます。
o These procedures are intended to provide a fair, open, and
objective basis for developing, evaluating, and adopting
Internet Standards. They provide ample opportunity for
participation and comment by all interested parties. At each
stage of the standardization process, a specification is
repeatedly discussed and its merits debated in open meetings
and/or public electronic mailing lists, and it is made
available for review via world-wide on-line directories.
o これらの手順がインターネットStandardsを開発して、評価して、採用する公正で、開いていて、客観的な基礎を提供することを意図します。 彼らは参加の十分な機会と関係者一同によるコメントを提供します。 標準化過程の各段階では、繰り返して仕様について議論します、そして、長所は公開の会議、そして/または、公共のメーリング・リストで討論されました、そして、それを世界的なオンラインディレクトリでレビューに利用可能にします。
o These procedures are explicitly aimed at recognizing and
adopting generally-accepted practices. Thus, a candidate
specification is implemented and tested for correct operation
and interoperability by multiple independent parties and
utilized in increasingly demanding environments, before it
can be adopted as an Internet Standard.
o これらの手順は明らかに一般に慣例を認識して、採用するのを目的とされます。 したがって、候補仕様は、実行されて、正しい操作と相互運用性がないかどうか複数の独立しているパーティーによってテストされて、ますます環境を要求する際に利用されます、インターネットStandardとしてそれを採用できる前に。
o These procedures provide a great deal of flexibility to adapt
to the wide variety of circumstances that occur in the
standardization process. Experience has shown this
flexibility to be vital in achieving the goals listed above.
o これらの手順は、標準化過程で現れる広いバラエティーの事情に順応するために多くの柔軟性を提供します。 経験は、この柔軟性が上に記載された目標を達成するのにおいて重大であることを示しました。
The goal of technical competence, the requirement for prior
implementation and testing, and the need to allow all interested
parties to comment, all require significant time and effort. On
the other hand, today's rapid development of networking technology
places an urgency on timely development of standards. The
Internet standardization rules described here are intended to
balance these conflicting goals. The process is believed to be as
short and simple as possible without undue sacrifice of technical
competence, prior testing, or openness and fairness.
技術的能力の目標、先の実現とテストのための要件、および関係者一同がコメントするのを許容する必要性は重要な時間と努力をすべて必要とします。 他方では、今日のネットワーク・テクノロジーの急速現像は規格のタイムリーな開発に緊急を置きます。 ここで説明されたインターネット標準化規則がこれらの闘争目標のバランスをとることを意図します。 できるだけ技術的能力か、先のテストか、風通しの良さと公正の過度の犠牲なしで短くて、過程が簡単であると信じられています。
In summary, the goals for the Internet standards process are:
概要では、インターネット標準化過程の目標は以下の通りです。
* technical excellence;
* 技術的長所。
* prior implementation and testing;
* 先の実現とテスト。
* clear, short, and easily understandable documentation;
* 明確で、短くて、容易に理解できるドキュメンテーション。
* openness and fairness; and
* 風通しの良さと公正。 そして
* timeliness.
* タイムリー。
In outline, the process of creating an Internet Standard is
straightforward: a specification undergoes a period of development
and several iterations of review by the Internet community and
アウトラインでは、インターネットStandardを作成する過程は簡単です: そして仕様がインターネットコミュニティで開発の一区切りとレビューのいくつかの繰り返しを受ける。
IAB - IESG [Page 5] RFC 1602 Internet Standards Process March 1994
IAB--IESG[5ページ]RFC1602インターネット規格は1994年3月に処理されます。
revision based upon experience, is adopted as a Standard by the
appropriate body (see below), and is published. In practice, the
process is more complicated, due to (1) the difficulty of creating
specifications of high technical quality; (2) the need to consider
the interests of all of the affected parties; (3) the importance
of establishing widespread community consensus; and (4) the
difficulty of evaluating the utility of a particular specification
for the Internet community.
改正は、経験を基礎づけて、Standardとして適切なボディー(以下を見る)によって採用されて、発行されます。 実際には、過程は(1) 高い技術的品質の仕様を作成するという困難のために、より複雑です。 (2) 影響を受けた当事者のすべての関心を考える必要性。 (3) 広範囲の共同体コンセンサスを確立する重要性。 (4) そして、インターネットコミュニティのための特記仕様書に関するユーティリティを評価するという困難。
From its inception, the Internet has been, and is expected to
remain, an evolving system whose participants regularly factor new
requirements and technology into its design and implementation.
Users of the Internet and providers of the equipment, software,
and services that support it should anticipate and embrace this
evolution as a major tenet of Internet philosophy.
始まりから、インターネットは、あって、残っていると予想されます、関係者が定期的に新しい要件と技術を設計と実装の要因として考慮する発展システム。 インターネットのユーザとそれを支持する設備であって、ソフトウェアの、そして、サービスのプロバイダーは、インターネット哲学の主要な主義としてこの発展を予期して、迎え入れるべきです。
The procedures described in this document are the result of three
years of evolution, driven both by the needs of the growing and
increasingly diverse Internet community, and by experience.
Comments and suggestions are invited for improving these
procedures.
本書では説明された手順は成長とますます多様なインターネットコミュニティの必要性、および経験で運転された3年間の発展の結果です。 コメントと提案はこれらの手順を改良するのに招待されます。
The remainder of this section describes the organizations and
publications involved in Internet standardization. Section 2
presents the nomenclature for different kinds and levels of
Internet standard technical specifications and their
applicability. Section 3 describes the process and rules for
Internet standardization. Section 4 defines how relevant
externally-sponsored specifications and practices, developed and
controlled by other standards bodies or by vendors, are handled in
the Internet standardization process. Section 5 presents the
rules that are required to protect intellectual property rights
and to assure unrestricted ability for all interested parties to
practice Internet Standards.
このセクションの残りはインターネット標準化にかかわる組織と刊行物について説明します。 セクション2はインターネット標準技術仕様書と彼らの適用性の異種とレベルのために用語体系を提示します。 セクション3はインターネット標準化のための過程と規則について説明します。 セクション4は他の標準化団体か業者によって開発されて、制御された関連外部的に後援された仕様と習慣がインターネット標準化過程でどう扱われるかを定義します。 セクション5は知的所有権を保護して、関係者一同がインターネットStandardsを練習する無制限な能力を保証するのに必要である規則を提示します。
1.2 Organizations
1.2 組織
The following organizations are involved in the Internet standards
process.
以下の組織はインターネット標準化過程にかかわります。
* IETF
* IETF
The Internet Engineering Task Force (IETF) is a loosely self-
organized group of people who make technical and other
contributions to the engineering and evolution of the
Internet and its technologies. It is the principal body
インターネット・エンジニアリング・タスク・フォース(IETF)はインターネットとその技術の工学と発展への技術的で他の貢献をする人々の緩く自己組織化されたグループです。 それは本体です。
IAB - IESG [Page 6] RFC 1602 Internet Standards Process March 1994
IAB--IESG[6ページ]RFC1602インターネット規格は1994年3月に処理されます。
engaged in the development of new Internet Standard
specifications, although it is not itself a part of the
Internet Society. The IETF is composed of individual Working
Groups, which are grouped into Areas, each of which is
coordinated by one or more Area Directors. Nominations to
the Internet Architecture Board and the Internet Engineering
Steering Group are made by a nominating committee selected at
random from the ranks of regular IETF meeting attendees who
have volunteered to serve as nominating committee members.
それはそれ自体でインターネット協会の一部ではありませんが、新しいインターネットStandard仕様の開発に従事していました。 IETFは個々のWorking Groupsで構成されます。(Working GroupsはAreasに分類されます)。それは1人以上のAreaディレクターによってそれぞれ調整されます。 インターネット・アーキテクチャ委員会とインターネットEngineering Steering Groupへの指名がメンバーに委員会を指名するとして機能するのが買って出たレギュラーのIETFミーティング出席者のランクから無作為に選ばれた指名委員会によってされます。
* ISOC
* ISOC
Internet standardization is an organized activity of the
Internet Society (ISOC). The ISOC is a professional society
that is concerned with the growth and evolution of the
worldwide Internet, with the way in which the Internet is and
can be used, and with the social, political, and technical
issues that arise as a result. The ISOC Board of Trustees is
responsible for approving appointments to the Internet
Architecture Board from among the nominees submitted by the
IETF nominating committee.
インターネット標準化はインターネット協会(ISOC)の組織的活動です。 ISOCは世界的なインターネットの成長と発展、インターネットはあって、使用できる方法、およびその結果起こる社会的で、政治上の、そして、技術的な問題に関するプロの社会です。 TrusteesのISOC BoardはIETF指名委員会によって提出された指名された人からアポイントメントをインターネット・アーキテクチャ委員会に承認するのに責任があります。
* IESG
* IESG
The Internet Engineering Steering Group (IESG) is responsible
for technical management of IETF activities and the Internet
Standards process. As part of the Internet Society, it
administers the Internet Standards process according to the
rules and procedures given in this document, which have been
accepted and ratified by the Internet Society Trustees. The
IESG is directly responsible for the actions associated with
entry into and movement along the "standards track", as
described in section 3 of this document, including final
approval of specifications as Internet Standards. The IESG
is composed of the IETF Area Directors and the chairperson of
the IETF, who also serves as the chairperson of the IESG.
インターネットEngineering Steering Group(IESG)はIETF活動とインターネットStandardsの過程の技術管理に責任があります。 インターネット協会の一部として、本書では与えられた規則と手順によると、それはインターネットStandardsの過程を管理します。(手順は、インターネット協会Trusteesによって受け入れられて、批准されました)。 IESGは直接「標準化過程」に沿ったエントリーと動きに関連している動作に責任があります、このドキュメントのセクション3で説明されるように、インターネットStandardsとして仕様の最終承認を含んでいて。 IESGはIETFのIETF Areaディレクターと議長で構成されます。(また、IETFはIESGの議長として勤めます)。
* IAB
* IAB
The Internet Architecture Board (IAB) is a technical advisory
group of the Internet Society. It is chartered by the
Internet Society Trustees to provide oversight of the
architecture of the Internet and its protocols, and to serve
in the context of the Internet Standards process as a body to
which the decisions of the IESG may be appealed (as described
in section 3.6 of this document). The IAB is responsible for
インターネット・アーキテクチャ委員会(IAB)はインターネット協会の技術的な顧問団です。 それは、インターネットとそのプロトコルのアーキテクチャの見落としを提供して、IESGの決定が上告されるかもしれないボディーとしてインターネットStandardsプロセスの文脈で機能するようにインターネット協会Trusteesによってチャーターされます(このドキュメントのセクション3.6で説明されるように)。 IABは責任があります。
IAB - IESG [Page 7] RFC 1602 Internet Standards Process March 1994
IAB--IESG[7ページ]RFC1602インターネット規格は1994年3月に処理されます。
approving appointments to the IESG from among the nominees
submitted by the IETF nominating committee.
指名された人からアポイントメントをIESGに承認するのはIETF指名委員会に提出されました。
Any member of the Internet community with the time and interest is
urged to participate actively in one or more IETF Working Groups
and to attend IETF meetings. In many cases, active Working Group
participation is possible through email alone; furthermore,
Internet video conferencing is being used experimentally to allow
remote participation. Participation is by individual technical
contributors rather than formal representatives of organizations.
The process works because the IETF Working Groups display a spirit
of cooperation as well as a high degree of technical maturity;
IETF participants recognize that the greatest benefit for all
members of the Internet community results from cooperative
development of technically superior protocols and services.
1IETF Working Groupsで活躍して、時間と関心を伴うインターネットコミュニティのどんなメンバーもIETFミーティングに出席するよう促されます。 多くの場合、活発な作業部会の参加はメールだけで可能です。 その上、インターネットビデオ会議は、遠隔参加を許容するのに実験的に使用されています。 参加が組織の公式代表よりむしろ個々の技術貢献者のそばにあります。 IETF Working Groupsが高度合いの技術的成熟度と同様に共同の精神を表示するので、プロセスは働いています。 IETF関係者は、インターネットコミュニティのすべてのメンバーのための最もすばらしい利益が技術的に優れたプロトコルの、そして、サービスの共同開発から生じると認めます。
Members of the IESG and IAB are nominated for two-year terms by a
committee that is drawn from the roll of recent participation in
the IETF and chartered by the ISOC Board of Trustees. The
appointment of IESG and of IAB members are made from these
nominations by the IAB and by the ISOC Board of Trustees,
respectively.
IESGとIABのメンバーは2年の期間にIETFで最近の参加のロールから得られて、TrusteesのISOC Boardによってチャーターされる委員会によって指名されます。 IESGとIABメンバーのアポイントメントはIABとTrusteesのISOC Boardによってこれらの指名からそれぞれとられます。
The Internet Research Task Force (IRTF) is not directly part of
the standards process. It investigates topics considered to be
too uncertain, too advanced, or insufficiently well-understood to
be the subject of Internet standardization. When an IRTF activity
generates a specification that is sufficiently stable to be
considered for Internet standardization, the specification is
processed through the IETF using the rules in this document.
インターネットResearch Task Force(IRTF)は標準化過程を直接離れさせないことです。 それは、インターネット標準化の対象になるように不確実過ぎるか、高度過ぎるか、または不十分によく理解されていると考えられた話題を、調査します。 IRTF活動がインターネット標準化のために考えられるのにおいて十分安定した仕様を生成するとき、仕様は、IETFを通して本書では規則を使用することで処理されます。
1.3 Standards-Related Publications
1.3 規格関連の刊行物
1.3.1 Requests for Comments (RFCs)
1.3.1 コメントを求める要求(RFCs)
Each distinct version of a specification is published as part
of the "Request for Comments" (RFC) document series. This
archival series is the official publication channel for
Internet standards documents and other publications of the
IESG, IAB, and Internet community. RFCs are available for
anonymous FTP from a number of Internet hosts.
仕様のそれぞれの異なったバージョンは「コメントを求める要求」(RFC)ドキュメントシリーズの一部として発行されます。 この記録保管所のシリーズは、インターネット規格文書のための公式の公開チャネルとIESG、IAB、およびインターネットコミュニティの他の刊行物です。 RFCsは多くのインターネット・ホストからの公開FTPに利用可能です。
The RFC series of documents on networking began in 1969 as part
of the original ARPA wide-area networking (ARPANET) project
(see Appendix A for glossary of acronyms). RFCs cover a wide
range of topics, from early discussion of new research concepts
ネットワークでのドキュメントのRFCシリーズは1969年にオリジナルのARPA広い領域ネットワーク(アルパネット)プロジェクトの一部として始まりました(頭文字語の用語集に関してAppendix Aを見てください)。 RFCsは新しい研究概念の早めの議論からさまざまな話題をカバーしています。
IAB - IESG [Page 8] RFC 1602 Internet Standards Process March 1994
IAB--IESG[8ページ]RFC1602インターネット規格は1994年3月に処理されます。
to status memos about the Internet. RFC publication is the
direct responsibility of the RFC Editor, under the general
direction of the IAB.
インターネットに関する状態メモに。 RFC公表はIABが総指導者となってRFC Editorの直接の責任です。
The rules for formatting and submitting an RFC are defined in
reference [5]. Every RFC is available in ASCII text, but some
RFCs are also available in PostScript. The PostScript version
of an RFC may contain material (such as diagrams and figures)
that is not present in the ASCII version, and it may be
formatted differently.
RFCをフォーマットして、提出するための規則は参照[5]で定義されます。 あらゆるRFCがASCIIテキストで利用可能ですが、また、いくつかのRFCsもポストスクリプトで利用可能です。 RFCのポストスクリプトバージョンはASCII版に存在していない材料(ダイヤグラムや図形などの)を含むかもしれません、そして、それは異なってフォーマットされるかもしれません。
*********************************************************
* A stricter requirement applies to standards-track *
* specifications: the ASCII text version is the *
* definitive reference, and therefore it must be a *
* complete and accurate specification of the standard, *
* including all necessary diagrams and illustrations. *
* *
*********************************************************
********************************************************* * より厳しい要件は標準化過程**仕様に適用されます: ASCIIテキストバージョンは**決定的な参照です、そして、したがって、それは規格の**完全で正確な仕様であるに違いありません、**すべての必要なダイヤグラムとイラストを含んでいて。 * * * *********************************************************
The status of Internet protocol and service specifications is
summarized periodically in an RFC entitled "Internet Official
Protocol Standards" [1]. This RFC shows the level of maturity
and other helpful information for each Internet protocol or
service specification. See Section 3.1.3 below.
インターネットプロトコルとサービス仕様の状態は「インターネット公式プロトコル標準」[1]の権利を与えられたRFCに定期的にまとめられます。 このRFCはそれぞれのインターネットプロトコルかサービス仕様のための円熟と他の役立つ情報のレベルを示しています。 セクション3.1.3未満を見てください。
Some RFCs document Internet standards. These RFCs form the
'STD' subseries of the RFC series [4]. When a specification
has been adopted as an Internet Standard, it is given the
additional label "STDxxxx", but it keeps its RFC number and its
place in the RFC series.
いくつかのRFCsがインターネット標準を記録します。 これらのRFCsはRFCシリーズ[4]の'STD'「副-シリーズ」を形成します。 インターネットStandardとして仕様を採用したとき、追加ラベル"STDxxxx"をそれに与えますが、それはRFC番号とRFCシリーズにおけるその場所を保ちます。
Not all specifications of protocols or services for the
Internet should or will become Internet Standards. Such non-
standards track specifications are not subject to the rules for
Internet standardization. Generally, they will be published
directly as RFCs at the discretion of the RFC editor and the
IESG. These RFCs will be marked "Prototype", "Experimental" or
"Informational" as appropriate (see section 2.3).
すべてのインターネットのためのプロトコルの、または、サービスの仕様が、なるべきであるというわけではありませんし、またインターネットStandardsになるというわけではないでしょう。 そのような非標準化過程の仕様はインターネット標準化のための規則を受けることがありません。 一般に、それらは直接RFCsとしてRFCエディタとIESGの裁量で発行されるでしょう。 これらのRFCsは「実験的である」か「情報」の「プロトタイプ」であると適宜マークされるでしょう(セクション2.3を見てください)。
********************************************************
* It is important to remember that not all RFCs *
* are standards track documents, and that not all *
* standards track documents reach the level of *
* Internet Standard. *
********************************************************
******************************************************** * すべてのRFCs*ではなく、それを覚えているのは重要です。*標準化過程ドキュメント、およびそれはすべて*であるというわけではありません。*標準化過程ドキュメントは**インターネットStandardのレベルに達します。 * ********************************************************
IAB - IESG [Page 9] RFC 1602 Internet Standards Process March 1994
IAB--IESG[9ページ]RFC1602インターネット規格は1994年3月に処理されます。
1.3.2 Internet Drafts
1.3.2 インターネット草稿
During the development of a specification, draft versions of
the document are made available for informal review and comment
by placing them in the IETF's "Internet Drafts" directory,
which is replicated on a number of Internet hosts. This makes
an evolving working document readily available to a wide
audience, facilitating the process of review and revision.
仕様の開発の間、ドキュメントの草案バージョンを多くのインターネット・ホストで模写されるIETFの「インターネット草稿」ディレクトリにそれらを置くことによって非公式のレビューとコメントに利用可能にします。 これで、レビューと改正のプロセスを容易にして、発展の働くドキュメントは広い聴衆には容易に利用可能になります。
An Internet Draft that is published as an RFC, or that has
remained unchanged in the Internet Drafts directory for more
than six months without being recommended by the IESG for
publication as an RFC, is simply removed from the Internet
Draft directory. At any time, an Internet Draft may be
replaced by a more recent version of the same specification,
restarting the six-month timeout period.
RFCとして発行されるか、または公表のためにIESGによるお勧めであることのない6カ月以上RFCとしてインターネットDraftsディレクトリで変わりがなかったインターネットDraftはインターネットDraftディレクトリから単に取り外されます。 いつでも、インターネットDraftを同じ仕様の、より最近のバージョンに取り替えるかもしれません、6カ月のタイムアウト時間を再開して。
An Internet Draft is NOT a means of "publishing" a
specification; specifications are published through the RFC
mechanism described in the previous section. Internet Drafts
have no formal status, are not part of the permanent archival
record of Internet activity, and are subject to change or
removal at any time.
インターネットDraftは仕様の「発行」である手段ではありません。 仕様は前項で説明されたRFCメカニズムを通して発表されます。 インターネットDraftsはどんな正式な状態も持たないで、インターネット活動の永久的な履歴の一部でなく、いつでも、変化か取り外しを被りやすいです。
********************************************************
* Under no circumstances should an Internet Draft *
* be referenced by any paper, report, or Request-for-*
* Proposal, nor should a vendor claim compliance *
* with an Internet-Draft. *
********************************************************
******************************************************** * どんな紙、レポート、または*のためのRequest*提案でもインターネットDraft**に決して、参照をつけるべきではありません、そして、ベンダーはインターネット草稿で承諾が**であると主張するべきではありません。 * ********************************************************
Note: It is acceptable to reference a standards-track
specification that may reasonably be expected to be published
as an RFC using the phrase "Work in Progress", without
referencing an Internet Draft.
以下に注意してください。 それは参照へのRFCとして句を使用することで発行されると合理的に予想されるかもしれない標準化過程仕様の許容できる「処理中の作業」です、インターネットDraftに参照をつけないで。
1.4 Internet Assigned Number Authority (IANA)
1.4 ISOCの機関の一つで(IANA)
Many protocol specifications include numbers, keywords, and other
parameters that must be uniquely assigned. Examples include
version numbers, protocol numbers, port numbers, and MIB numbers.
The IAB has delegated to the Internet Assigned Numbers Authority
(IANA) the task of assigning such protocol parameters for the
Internet. The IANA publishes tables of all currently assigned
numbers and parameters in RFCs titled "Assigned Numbers" [3].
多くのプロトコル仕様が唯一割り当てなければならない数、キーワード、および他のパラメタを含んでいます。 例はバージョン番号、プロトコル番号、ポートナンバー、およびMIB番号を含んでいます。 IABはインターネットAssigned民数記Authority(IANA)へのインターネットのためのそのようなプロトコルパラメタを割り当てるタスクを代表として派遣しました。 IANAは「規定番号」[3]と題をつけられたRFCsのすべての現在割り当てられた数とパラメタのテーブルを発行します。
IAB - IESG [Page 10] RFC 1602 Internet Standards Process March 1994
IAB--IESG[10ページ]RFC1602インターネット規格は1994年3月に処理されます。
Each category of assigned numbers typically arises from some
protocol that is on the standards track or is an Internet
Standard. For example, TCP port numbers are assigned because TCP
is a Standard. A particular value within a category may be
assigned in a variety of circumstances; the specification
requiring the parameter may be in the standards track, it may be
Experimental, or it may be private. Note that assignment of a
number to a protocol is independent of, and does not imply,
acceptance of that protocol as a standard.
規定番号の各カテゴリは標準化過程の上にあるか、インターネットStandardである何らかのプロトコルから通常起こります。 例えば、TCPがStandardであるので、TCPポートナンバーは割り当てられます。 カテゴリの中の特定の値はさまざまな事情で割り当てられるかもしれません。 パラメタを必要とする仕様が標準化過程にあるかもしれませんか、それはExperimental的であるかもしれませんまたはそれが個人的であるかもしれません。 プロトコルへの数のその課題が独立していて、含意しないことに注意してください、規格としてのそのプロトコルの承認。
Chaos could result from accidental conflicts of parameter values,
so we urge that every protocol parameter, for either public or
private usage, be explicitly assigned by the IANA. Private
protocols often become public. Programmers are often tempted to
choose a "random" value or to guess the next unassigned value of a
parameter; both are hazardous.
カオスがパラメタ値の偶然の闘争から生じるかもしれないので、私たちは、あらゆるプロトコルパラメタが公共の、または、個人的な用法のためにIANAによって明らかに割り当てられるよう促します。 個人的なプロトコルはしばしば公共になります。 しばしば「無作為」の値を選ぶか、またはプログラマがパラメタの次の割り当てられなかった値を推測するように誘惑されます。 両方が危険です。
The IANA is expected to avoid frivolous assignments and to
distinguish different assignments uniquely. The IANA accomplishes
both goals by requiring a technical description of each protocol
or service to which a value is to be assigned. Judgment on the
adequacy of the description resides with the IANA. In the case of
a standards track or Experimental protocol, the corresponding
technical specifications provide the required documentation for
IANA. For a proprietary protocol, the IANA will keep confidential
any writeup that is supplied, but at least a short (2 page)
writeup is still required for an assignment.
IANAは軽薄な課題を避けて、唯一異なった課題を区別すると予想されます。 IANAは、割り当てられる値がことであるそれぞれのプロトコルかサービスの専門的説明を必要とすることによって、両方の目標を達成します。 記述の妥当性における判断はIANAと共にあります。 標準化過程かExperimentalプロトコルの場合では、対応する技術仕様書は必要書類をIANAに供給します。 固有のプロトコルのために、IANAは提供されるどんな記事も秘密にするでしょうが、少なくとも(2ページ)の短い記事が課題にまだ必要です。
2. NOMENCLATURE
2. 用語体系
2.1 The Internet Standards Track
2.1 インターネット標準化過程
Specifications that are destined to become Internet Standards
evolve through a set of maturity levels known as the "standards
track". These maturity levels -- "Proposed Standard", "Draft
Standard", and "Standard" -- are defined and discussed below in
Section 3.2.
インターネットStandardsになるように運命づけられている仕様は「標準化過程」として知られている1セットの成熟レベルを通して発展します。 セクション3.2で以下でこれらの成熟レベル(「提案された標準」、「草稿規格」、および「規格」)について、定義されて、議論します。
Even after a specification has been adopted as an Internet
Standard, further evolution often occurs based on experience and
the recognition of new requirements. The nomenclature and
procedures of Internet standardization provide for the replacement
of old Internet Standards with new ones, and the assignment of
descriptive labels to indicate the status of "retired" Internet
Standards. A set of maturity levels is defined in Section 3.3 to
cover these and other "off-track" specifications.
仕様がインターネットStandardとして採用された後にさえ、一層の発展は新しい要件の経験と認識に基づいてしばしば起こります。 インターネット標準化の用語体系と手順は、「退職した」インターネットStandardsの状態を示すために古いインターネットStandardsの新しいものへの交換品、および品質表示の課題に備えます。 1セットの成熟レベルは、これらと他の「オフトラック」仕様を含むためにセクション3.3で定義されます。
IAB - IESG [Page 11] RFC 1602 Internet Standards Process March 1994
IAB--IESG[11ページ]RFC1602インターネット規格は1994年3月に処理されます。
2.2 Types of Specifications
2.2のタイプの仕様
Specifications subject to the Internet standardization process
fall into two categories: Technical Specifications (TS) and
Applicability Statements (AS).
インターネット標準化過程を条件とした仕様は2つのカテゴリになります: 仕様書(ts)と適用性証明(AS)。
2.2.1 Technical Specification (TS)
2.2.1 技術的な仕様(ts)
A Technical Specification is any description of a protocol,
service, procedure, convention, or format. It may completely
describe all of the relevant aspects of its subject, or it may
leave one or more parameters or options unspecified. A TS may
be completely self-contained, or it may incorporate material
from other specifications by reference to other documents
(which may or may not be Internet Standards).
仕様書はプロトコル、サービス、手順、コンベンション、または形式のあらゆる記述です。 それが対象の関連局面のすべてについて完全に説明するかもしれませんか、またはそれは1つ以上のパラメタかオプションを不特定のままにするかもしれません。 TSが完全に自己充足的であるかもしれませんか、またはそれは他の仕様から他のドキュメント(インターネットStandardsであるかもしれない)の参照で材料を組み込むかもしれません。
A TS shall include a statement of its scope and the general
intent for its use (domain of applicability). Thus, a TS that
is inherently specific to a particular context shall contain a
statement to that effect. However, a TS does not specify
requirements for its use within the Internet; these
requirements, which depend on the particular context in which
the TS is incorporated by different system configurations, is
defined by an Applicability Statement.
TSは範囲の声明と使用に関する総合的目的(適用領域)を含んでいるものとします。 したがって、本来特定の文脈に特定のTSはその趣旨で声明を含むものとします。 しかしながら、TSはインターネットの中の使用のための要件を指定しません。 これらの要件(特定の文脈にTSが異系統構成によって組み込まれるよる)はApplicability Statementによって定義されます。
2.2.2 Applicability Statement (AS)
2.2.2 適用性証明(AS)
An Applicability Statement specifies how, and under what
circumstances, one or more TSs are to be applied to support a
particular Internet capability. An AS may specify uses for TSs
that are not Internet Standards, as discussed in Section 4.
Applicability Statementはその方法を指定します、そして、どんな状況で、1TSsが、特定のインターネット能力をサポートするために適用されることになっているか。 ASはセクション4で議論するようにインターネットStandardsでないTSsへの用途を指定するかもしれません。
An AS identifies the relevant TSs and the specific way in which
they are to be combined, and may also specify particular values
or ranges of TS parameters or subfunctions of a TS protocol
that must be implemented. An AS also specifies the
circumstances in which the use of a particular TS is required,
recommended, or elective.
ASは彼らが結合されていることになっている関連TSsと特定の方法を特定して、また、特定の値か範囲のTSパラメタか実装しなければならないTSプロトコルの副機能を指定するかもしれません。 また、ASは特定のTSの使用が必要であるか、お勧め、または選挙である事情を指定します。
An AS may describe particular methods of using a TS in a
restricted "domain of applicability", such as Internet routers,
terminal servers, Internet systems that interface to Ethernets,
or datagram-based database servers.
ASは制限された「適用領域」でTSを使用する特定のメソッドを説明するかもしれません、インターネットルータ、ターミナルサーバ、Ethernetsに連結するインターネット・システム、またはデータグラムベースのデータベースサーバーなどのように。
The broadest type of AS is a comprehensive conformance
specification, commonly called a "requirements document", for a
ASの最も広いタイプは一般的にaのための「要件ドキュメント」と呼ばれる包括的な順応仕様です。
IAB - IESG [Page 12] RFC 1602 Internet Standards Process March 1994
IAB--IESG[12ページ]RFC1602インターネット規格は1994年3月に処理されます。
particular class of Internet systems, such as Internet routers
or Internet hosts.
特定のクラスのインターネットルータかインターネット・ホストなどのインターネット・システム。
An AS may not have a higher maturity level in the standards
track than any standards-track TS to which the AS applies. For
example, a TS at Draft Standard level may be referenced by an
AS at the Proposed Standard or Draft Standard level, but not by
an AS at the Standard level.
ASは標準化過程にASが適用するどんな標準化過程TSよりも高い成熟レベルを持っていないかもしれません。 例えば、Draft StandardレベルにおけるTSはStandardレベルでは、Proposed StandardかDraft StandardレベルにおけるASによって参照をつけられますが、ASで参照をつけられるかもしれないというわけではありません。
An AS may refer to a TS that is either a standards-track speci-
fication or is "Informational", but not to a TS with a maturity
level of "Prototype", "Experimental", or "Historic" (see
section 2.4).
ASは「実験的である」か、「歴史的である」「プロトタイプ」の成熟レベルで標準化過程speci- ficationであるか「情報であること」の、しかし、TSに情報でないTSについて言及するかもしれません(セクション2.4を見てください)。
Although TSs and ASs are conceptually separate, in practice a
standards-track document may combine an AS and one or more related
TSs. For example, Technical Specifications that are developed
specifically and exclusively for some particular domain of
applicability, e.g., for mail server hosts, often contain within a
single specification all of the relevant AS and TS information.
In such cases, no useful purpose would be served by deliberately
distributing the information among several documents just to
preserve the formal AS/TS distinction. However, a TS that is
likely to apply to more than one domain of applicability should be
developed in a modular fashion, to facilitate its incorporation by
multiple ASs.
TSsとASsは概念的に別々ですが、実際には、標準化過程文書がASと1つを結合するかもしれませんか、または以上はTSsを関係づけました。 例えば、特に、そして、排他的な何らかの特定の適用領域、例えば、メールサーバー・ホストのために開発される仕様書はただ一つの仕様の中にしばしば関連ASとTS情報のすべてを含んでいます。 そのような場合、ただ正式なAS/TS区別を保存するために故意にいくつかのドキュメントに情報を分配することによって、どんな役に立つ目的も役立たれないでしょう。 しかしながら、1つ以上の適用領域に適用しそうなTSは、複数のASsによる編入を容易にするためにモジュール方式で開発されるべきです。
2.3 Standards Track Maturity Levels
2.3 標準化過程成熟レベル
ASs and TSs go through stages of development, testing, and
acceptance. Within the Internet standards process, these stages
are formally labeled "maturity levels".
ASsとTSsは開発段階、テスト、および承認で行きます。 インターネット標準化過程の中では、これらのステージは正式に「成熟レベル」とラベルされます。
This section describes the maturity levels and the expected
characteristics of specifications at each level.
このセクションは各レベルで成熟レベルと仕様の予想された特性について説明します。
2.3.1 Proposed Standard
2.3.1 提案された標準
The entry-level maturity for the standards track is "Proposed
Standard". A Proposed Standard specification is generally
stable, has resolved known design choices, is believed to be
well-understood, has received significant community review, and
appears to enjoy enough community interest to be considered
valuable. However, further experience might result in a change
or even retraction of the specification before it advances.
標準化過程への入社の段階円熟は「提案された標準」です。 Proposed Standard仕様は、一般に、安定していて、知られているデザイン選択を決議して、よく理解されていると信じられていて、重要な共同体レビューを受け取って、貴重であると考えることができるくらいの共同体関心を楽しむように見えます。 しかしながら、進む前にさらなる経験は仕様の変化か取消しさえもたらすかもしれません。
IAB - IESG [Page 13] RFC 1602 Internet Standards Process March 1994
IAB--IESG[13ページ]RFC1602インターネット規格は1994年3月に処理されます。
Usually, neither implementation nor operational experience is
required for the designation of a specification as a Proposed
Standard. However, such experience is highly desirable, and
will usually represent a strong argument in favor of a Proposed
Standard designation.
通常、実現も運用経験も仕様の名称にProposed Standardとして必要ではありません。 しかしながら、そのような経験は、非常に望ましく、通常、Proposed Standard名称を支持して強い議論を表すでしょう。
The IESG may require implementation and/or operational
experience prior to granting Proposed Standard status to a
specification that materially affects the core Internet
protocols or that specifies behavior that may have significant
operational impact on the Internet. Typically, such a
specification will be published initially with Experimental or
Prototype status (see below), and moved to the standards track
only after sufficient implementation or operational experience
has been obtained.
物質的にコアインターネットプロトコルに影響するか、または重要な操作上の影響をインターネットに与えるかもしれない振舞いを指定する仕様への状態をProposed Standardに与える前に、IESGは実現、そして/または、運用経験を必要とするかもしれません。 十分な実現か運用経験を得た後にだけ、そのような仕様を通常、初めはExperimentalかPrototype状態(以下を見る)で発表して、標準化過程に動かすでしょう。
A Proposed Standard should have no known technical omissions
with respect to the requirements placed upon it. However, the
IESG may recommend that this requirement be explicitly reduced
in order to allow a protocol to advance into the Proposed
Standard state, when a specification is considered to be useful
and necessary (and timely), even absent the missing features.
Proposed Standardには、それに置かれた要件に関してどんな知られている技術的な省略もあるはずがありません。 しかしながら、IESGは、この要件がプロトコルがProposed Standard状態に進むのを許容するために明らかに減らされることを勧めるかもしれません、役に立つのと必要、そして、仕様が(タイムリー)であると考えられるとき、なくなった特徴がなくても。
Implementors should treat Proposed Standards as immature
specifications. It is desirable to implement them in order to
gain experience and to validate, test, and clarify the
specification. However, since the content of Proposed
Standards may be changed if problems are found or better
solutions are identified, deploying implementations of such
standards into a disruption-sensitive customer base is not
normally advisable.
作成者は未熟な仕様としてProposed Standardsを扱うべきです。 仕様を経験を積むためにそれらを実行して、有効にして、テストして、はっきりさせるのは望ましいです。 しかしながら、問題を見つけるならProposed Standardsの内容を変えるかもしれないか、または、より良い解決策を特定するので、通常、分裂敏感な顧客ベースの中にそのような規格の実現を配備するのは賢明ではありません。
2.3.2 Draft Standard
2.3.2 草稿規格
A specification from which at least two independent and
interoperable implementations have been developed, and for
which sufficient successful operational experience has been
obtained, may be elevated to the "Draft Standard" level. This
is a major advance in status, indicating a strong belief that
the specification is mature and will be useful.
少なくとも2つの独立していて共同利用できる実現を開発してあって、十分なうまくいっている運用経験を得てある仕様、「草稿規格」レベルに登用されるかもしれません。 仕様が熟して、役に立つという強い信念を示して、これは状態の主要な進歩です。
A Draft Standard must be well-understood and known to be quite
stable, both in its semantics and as a basis for developing an
implementation. A Draft Standard may still require additional
or more widespread field experience, since it is possible for
implementations based on Draft Standard specifications to
意味論と実現を開発する基礎としてよく理解していなければならなくて、かなり安定しているのが知られているDraft Standard。 Draft Standardはまだ追加しているか、より広範囲の実地経験を必要としているかもしれません、Draft Standard仕様に基づく実現に、それが可能であるので
IAB - IESG [Page 14] RFC 1602 Internet Standards Process March 1994
IAB--IESG[14ページ]RFC1602インターネット規格は1994年3月に処理されます。
demonstrate unforeseen behavior when subjected to large-scale
use in production environments.
実稼動環境における大規模な使用にかけられたら、予期しない振舞いを示してください。
2.3.3 Internet Standard
2.3.3 インターネット規格
A specification for which significant implementation and
successful operational experience has been obtained may be
elevated to the Internet Standard level. An Internet Standard
(which may simply be referred to as a Standard) is
characterized by a high degree of technical maturity and by a
generally held belief that the specified protocol or service
provides significant benefit to the Internet community.
重要な実現とうまくいっている運用経験を得てある仕様はインターネットStandardレベルに登用されるかもしれません。 高度の技術的成熟度と指定されたプロトコルかサービスがインターネットコミュニティへの重要な利益を提供するという一般に、保持された信念によってインターネットStandard(単にStandardと呼ばれるかもしれない)は特徴付けられます。
A Draft Standard is normally considered to be a final
specification, and changes are likely to be made only to solve
specific problems encountered. In most circumstances, it is
reasonable for vendors to deploy implementations of draft
standards into the customer base.
通常、Draft Standardは最終的な仕様であると考えられます、そして、変化は行きあたられる特定の問題を単に解決させられそうです。 ほとんどの事情では、業者が草稿規格の実現を顧客ベースの中に配備するのは、妥当です。
2.4 Non-Standards Track Maturity Levels
2.4 非標準化過程成熟レベル
Not every TS or AS is on the standards track. A TS may not be
intended to be an Internet Standard, or it may be intended for
eventual standardization but not yet ready to enter the standards
track. A TS or AS may have been superseded by more recent
Internet Standards, or have otherwise fallen into disuse or
disfavor.
あらゆるTSかどんなASも標準化過程のそうであるというわけではありません。 それは、標準化過程に入る準備ができている状態でTSがインターネットStandardであることを意図しないかもしれませんか、最後の標準化のために意図しますが、またはやがて、意図するかもしれないというわけではありません。 TSかASが、より最近のインターネットStandardsによって取って代わられたか、そうでなければ、不要になったかもしれません、または疎んじてください。
Specifications not on the standards track are labeled with one of
four off-track maturity levels: "Prototype, "Experimental",
"Informational", and "Historic". There are no time limits
associated with these non-standard track labels, and the documents
bearing these labels are not Internet standards in any sense. As
the Internet grows, there is a growing amount of credible
technical work being submitted directly to the RFC Editor without
having been gone through the IETF. It is possible that such
outside submissions may overlap or even conflict with ongoing IETF
activities. In order for the best technical result to emerge for
the community, we believe that the such outside submissions should
be given the opportunity to work within IETF to gain the broadest
possible consensus.
仕様は標準化過程の上に4つのオフトラック成熟レベルの1つでラベルされません: 「「実験的で」、「情報的」、そして、「歴史的な」原型。」 これらの標準的でない道のラベルに関連しているどんなタイムリミットもありません、そして、これらのラベルを持っているドキュメントはどんな意味でインターネット標準ではありません。 インターネットが発展するとき、IETFを通して過ぎ去らないで、直接RFC Editorに提出される増加している量の確かな技術的な仕事があります。 そのような外の差出が重なるか、または進行中のIETF活動と衝突さえする、可能です。 現れる共同体に、最も良い技術的な結果において整然とします、私たちは可能な限り広いコンセンサスを獲得するためにIETFの中で働く機会があれほど外の差出に与えられるべきであると信じています。
It is also possible that supporters of a view different from the
IETF may wish to publish their divergent view. For this reason,
it is important that, ultimately, authors should have the
opportunity to publish Informational and Experimental RFCs should
また、IETFと異なった視点の支持者が彼らの異論を発行したがっているのも、可能です。 この理由で、結局、作者がInformationalを発行する機会を持つべきであり、Experimental RFCsが持っているのは重要です。
IAB - IESG [Page 15] RFC 1602 Internet Standards Process March 1994
IAB--IESG[15ページ]RFC1602インターネット規格は1994年3月に処理されます。
they wish to. However, it is also possible that this could open a
loophole in which developers could try to bypass the IETF
consensus process completely by publishing an Informational RFC
(and relying on the prestige of the RFC series to gain community
support for their document).
彼らはそうしたがっています。 しかしながら、また、これが開発者が完全にInformational RFCを発行することによってIETFコンセンサスを得るためのプロセスを迂回させようとすることができた抜け穴を開くかもしれないのも(それらのドキュメントの共同体サポートを獲得するためにRFCシリーズの威信を当てにして)、可能です。
For all these reasons, the IESG and the RFC Editor have agreed to
the following policy for publishing Info and Exp RFCs:
これらのすべての理由で、IESGとRFC Editorは出版InfoとExp RFCsのための以下の方針に同意しました:
1. The RFC Editor will bring to the attention of the IESG all
Informational and Experimental submissions that the RFC
Editor feels may be related to, or of interest to, the IETF
community.
1. RFC EditorはRFC Editorが関連して、興味があるかもしれないと感じるすべてのInformationalとExperimental差出をIESGの注意にもたらすでしょう、IETF共同体。
2. The IESG will review all such referrals within a fixed length
of time and make a recommendation on whether to publish, or
to suggest that the author bring their work within the IETF.
2. IESGは時間の固定長の中でそのようなすべての紹介を見直して、発行するか、または作者が彼らの仕事をIETFの範囲内に収めるのを示すかに関して勧告するでしょう。
3. If the IESG recommends that the work be brought within the
IETF, but the author declines the invitation, the IESG may
add disclaimer text into the standard boilerplate material
added by the RFC Editor (e.g., "Status of this memo").
3. IESGが、仕事がIETFの範囲内に収められることを勧めますが、作者が招待を断るなら、IESGはRFC Editor(例えば、「このメモの状態」)によって加えられた標準の決まり文句の材料の中に注意書きテキストを加えるかもしれません。
2.4.1 Prototype
2.4.1 原型
For new protocols which affect core services of the
Internet or for which the interactions with existing
protocols are too complex to fully assimilate from the
written specification, the IESG may request that
operational experience be obtained prior to advancement to
Proposed Standard status. In these cases, the IESG will
designate an otherwise complete specification as
"Prototype". This status permits it to be published as an
RFC before it is entered onto the standards track. In
this respect, "Prototype" is similar to "Experimental",
except that it indicates the protocol is specifically
being developed to become a standard, while "Experimental"
generally indicates a more exploratory phase of
development.
影響するか、または既存のプロトコルとの相互作用がインターネットのコアサービスが書かれた仕様から完全に同化できないくらい複雑である新しいプロトコルのために、IESGは、運用経験が前進の前にProposed Standard状態に得られるよう要求するかもしれません。 これらの場合では、IESGは「原型」としてそうでなければ、完全な仕様を指定するでしょう。 それが標準化過程に入れられる前にこの状態は、それがRFCとして発行されることを許可します。 この点で、「原型」は「実験的」と同様です、プロトコルが規格になるように明確に開発されているのを示すのを除いて、「実験的」は一般に開発の、より踏査のフェーズを示しますが。
2.4.2 Experimental
2.4.2 実験的です。
The "Experimental" designation on a TS typically denotes a
specification that is part of some research or development
effort. Such a specification is published for the general
information of the Internet technical community and as an
TSにおける「実験的な」名称は何らかの研究か開発努力の一部である仕様を通常指示します。 そしてそのような仕様がインターネット技術団体の一般情報のために発表される。
IAB - IESG [Page 16] RFC 1602 Internet Standards Process March 1994
IAB--IESG[16ページ]RFC1602インターネット規格は1994年3月に処理されます。
archival record of the work. An Experimental
specification may be the output of an organized Internet
research effort (e.g., a Research Group of the IRTF), or
it may be an individual contribution.
仕事に関する履歴。 Experimental仕様は組織化されたインターネット研究の努力(例えば、IRTFのResearch Group)の出力であるかもしれませんかそれが個人拠出であるかもしれません。
Documents intended for Experimental status should be
submitted directly to the RFC Editor for publication. The
procedure is intended to expedite the publication of any
responsible Experimental specification, subject only to
editorial considerations, and to verification that there
has been adequate coordination with the standards process.
公表のためにExperimental状態に意図するドキュメントを直接RFC Editorに提出するべきです。 手順がどんな原因となるExperimental仕様の公表も速めることを意図します、編集の問題だけと、そして、適切なコーディネートが標準化過程であった検証を受けることがあります。
2.4.3 Informational
2.4.3 情報です。
An "Informational" specification is published for the
general information of the Internet community, and does
not represent an Internet community consensus or
recommendation. The Informational designation is intended
to provide for the timely publication of a very broad
range of responsible informational documents from many
sources, subject only to editorial considerations and to
verification that there has been adequate coordination
with the standards process.
「情報」の仕様は、インターネットコミュニティの一般情報のために発行されて、インターネットコミュニティコンセンサスか推薦を表しません。 Informational名称が多くのソースから原因となる情報のドキュメントのまさしくその広い声域のタイムリーな公表に備えることを意図します、編集の問題だけと、そして、適切なコーディネートが標準化過程であった検証を受けることがあります。
Specifications that have been prepared outside of the
Internet community and are not incorporated into the
Internet standards process by any of the provisions of
Section 4 may be published as Informational RFCs, with the
permission of the owner.
インターネットコミュニティの外で準備されて、セクション4に関する条項のいずれによってもインターネット標準化過程に組み入れられない仕様はInformational RFCsとして発表されるかもしれません、所有者の許可で。
2.4.4 Historic
2.4.4 歴史的です。
A TS or AS that has been superseded by a more recent
specification or is for any other reason considered to be
obsolete is assigned to the "Historic" level. (Purists
have suggested that the word should be "Historical";
however, at this point the use of "Historic" is
historical.)
より最近の仕様で取って代わられるか、またはいかなる他の理由でも取って代わられたTSかASが、時代遅れであることが「歴史的な」レベルに割り当てられると考えました。 (純粋主義者は、単語が「歴史的であるべきである」と示唆しました; しかしながら、ここに、「歴史的」の使用は歴史的です。)
2.5 Requirement Levels
2.5 要件レベル
An AS may apply one of the following "requirement levels" to
each of the TSs to which it refers:
ASは以下の「要件レベル」の1つをそれが参照されるそれぞれのTSsに適用するかもしれません:
IAB - IESG [Page 17] RFC 1602 Internet Standards Process March 1994
IAB--IESG[17ページ]RFC1602インターネット規格は1994年3月に処理されます。
(a) Required: Implementation of the referenced TS, as specified
by the AS, is required to achieve minimal conformance. For
example, IP and ICMP must be implemented by all Internet
systems using the TCP/IP Protocol Suite.
(a)が必要です: ASによって指定される参照をつけられたTSの実現が、最小量の順応を達成するのに必要です。 例えば、すべてのインターネット・システムが、TCP/IPプロトコルSuiteを使用することでIPとICMPを実行しなければなりません。
(b) Recommended: Implementation of the referenced TS is not
required for minimal conformance, but experience and/or
generally accepted technical wisdom suggest its desirability
in the domain of applicability of the AS. Vendors are
strongly encouraged to include the functions, features, and
protocols of Recommended TSs in their products, and should
omit them only if the omission is justified by some special
circumstance.
(b)は推薦しました: 参照をつけられたTSの実現は最小量の順応に必要ではありませんが、経験、そして/または、一般に、受け入れられた技術上の知恵はASの適用領域に願わしさを示します。 業者は、彼らの製品にRecommended TSsの機能、特徴、およびプロトコルを含んでいるよう強く奨励されて、省略が何らかの特別な状況によって正当化される場合にだけ、それらを忘れるべきです。
(c) Elective: Implementation of the referenced TS is optional
within the domain of applicability of the AS; that is, the AS
creates no explicit necessity to apply the TS. However, a
particular vendor may decide to implement it, or a particular
user may decide that it is a necessity in a specific
environment.
(c)選択科目: 参照をつけられたTSの実現はASの適用領域の中で任意です。 すなわち、ASはTSを適用するどんな明白な必要性も作成しません。 しかしながら、特定の業者が、それを実行すると決めるかもしれませんか、または特定のユーザは、それが特定の環境で必要性であると決めるかもしれません。
As noted in Section 2.4, there are TSs that are not in the
standards track or that have been retired from the standards
track, and are therefore not required, recommended, or elective.
Two additional "requirement level" designations are available for
such TSs:
セクション2.4に述べられるように、したがって、ないか、標準化過程から退職した、必要で、または標準化過程でお勧めでないTSs、または選択科目があります。 2つの追加「要件レベル」名称がそのようなTSsに利用可能です:
(d) Limited Use: The TS is considered appropriate for use only
in limited or unique circumstances. For example, the usage
of a protocol with the "Experimental" designation should
generally be limited to those actively involved with the
experiment.
(d) 株式会社使用: TSは制限されたかユニークな事情だけにおける使用に適切であると考えられます。 例えば、一般に、「実験的な」名称があるプロトコルの用法は活発に実験にかかわるものに制限されるべきです。
(e) Not Recommended: A TS that is considered to be inappropriate
for general use is labeled "Not Recommended". This may be
because of its limited functionality, specialized nature, or
historic status.
(e)は推薦しませんでした: 一般的使用に不適当であると考えられるTSは「お勧めでない」とラベルされません。 これは限られた機能性、専門化している自然、または歴史的な状態のためにそうです。
The "Official Protocol Standards" RFC lists a general requirement
level for each TS, using the nomenclature defined in this section.
In many cases, more detailed descriptions of the requirement
levels of particular protocols and of individual features of the
protocols will be found in appropriate ASs.
このセクションで定義された用語体系を使用して、「公式のプロトコル標準」RFCは各TSのために一般的な要件レベルを記載します。 多くの場合、特定のプロトコルの要件レベルとプロトコルの個々の特徴の、より詳細な記述は適切なASsで見つけられるでしょう。
IAB - IESG [Page 18] RFC 1602 Internet Standards Process March 1994
IAB--IESG[18ページ]RFC1602インターネット規格は1994年3月に処理されます。
3. THE INTERNET STANDARDS PROCESS
3. インターネット標準化過程
3.1 Review and Approval
3.1 レビューと承認
A "standards action" -- entering a particular specification into,
advancing it within, or removing it from, the standards track --
must be approved by the IESG.
「規格動作」--、標準化過程--IESGが承認しなければならないのから、中でそれを進めるか、またはそれを取り除いて、特記仕様書を入力します。
3.1.1 Initiation of Action
3.1.1 動作の開始
Typically, a standards action is initiated by a recommendation
to the appropriate IETF Area Director by the individual or
group that is responsible for the specification, usually an
IETF Working Group.
通常、規格動作は仕様、通常IETF作業部会に責任がある個人かグループによって適切なIETF Areaディレクターへの推薦で開始されます。
After completion to the satisfaction of its author and the
cognizant Working Group, a document that is expected to enter
or advance in the Internet standardization process shall be
made available as an Internet Draft. It shall remain as an
Internet Draft for a period of time that permits useful
community review, at least two weeks, before submission to the
IESG with a recommendation for action.
作者と認識力がある作業部会の満足への完成の後に、インターネット標準化過程で入るか、または進むと予想されるドキュメントを、インターネットDraftとして利用可能にするものとします。 それはしばらく役に立つ共同体が見直すその許可証、少なくとも2週間インターネットDraftとして残っているものとします、IESGへの動作のための推薦による服従の前に。
3.1.2 IESG Review and Approval
3.1.2 IESGレビューと承認
The IESG shall determine whether a specification satisfies the
applicable criteria for the recommended action (see Sections
3.2 and 3.3 of this document).
IESGは、仕様がお勧めの動作の適用基準を満たすかどうか(このドキュメントのセクション3.2と3.3を見てください)決定するものとします。
The IESG shall determine if an independent technical review of
the specification is required, and shall commission one when
necessary. This may require creating a new Working Group, or
an existing group may agree to take responsibility for
reviewing the specification. When a specification is
sufficiently important in terms of its potential impact on the
Internet or on the suite of Internet protocols, the IESG shall
form an independent technical review and analysis committee to
prepare an evaluation of the specification. Such a committee
is commissioned to provide an objective basis for agreement
within the Internet community that the specification is ready
for advancement.
必要であるときに、IESGは、仕様の独立している技術審査が必要であり、1つを任命するだろうかどうか決定するものとします。 これが、新しい作業部会を創設するのを必要とするかもしれませんか、または既存のグループは、仕様を再検討することへの責任を取るのに同意するかもしれません。 仕様がインターネットの上、または、インターネットプロトコルのスイートの上で可能性のある衝撃で十分重要であるときに、IESGは、仕様の評価を準備するために独立している技術審査と分析委員会を形成するものとします。 そのような委員会が仕様が前進の準備ができているというインターネットコミュニティの中の協定に使途別分類を提供するように任命されます。
The IESG shall communicate its findings to the IETF to permit a
final review by the general Internet community. This "last-
call" notification shall be via electronic mail to the IETF
mailing list. In addition, for important specifications there
IESGは、一般的なインターネットコミュニティで最終審査を可能にするために調査結果をIETFに伝えるものとします。 IETFメーリングリストへの電子メールを通してこの「最後の呼び出し」通知はあるものとします。 そこの重要な仕様のための添加で
IAB - IESG [Page 19] RFC 1602 Internet Standards Process March 1994
IAB--IESG[19ページ]RFC1602インターネット規格は1994年3月に処理されます。
shall be a presentation or statement by the appropriate Working
Group or Area Director during an IETF plenary meeting. Any
significant issues that have not been resolved satisfactorily
during the development of the specification may be raised at
this time for final resolution by the IESG.
IETF全体会議の間の適切な作業部会かAreaディレクターによるプレゼンテーションか声明がそうでしょうか? 仕様の開発の間に満足に解決されていないどんな重要な問題もこのとき、最終的な解決のためにIESGによって提起されるかもしれません。
In a timely fashion, but no sooner than two weeks after issuing
the last-call notification to the IETF mailing list, the IESG
shall make its final determination on whether or not to approve
the standards action, and shall notify the IETF of its decision
via email.
最後の呼び出し通知をIETFメーリングリストに発行した2週間後ほど直ちに、しかし、早くないときに、IESGは規格動作を承認するかどうかに関して最終的決定をして、メールで決定についてIETFに通知するものとします。
3.1.3 Publication
3.1.3 公表
Following IESG approval and any necessary editorial work, the
RFC Editor shall publish the specification as an RFC. The
specification shall then be removed from the Internet Drafts
directory.
IESG承認とどんな必要な編集の仕事にも続いて、RFC EditorはRFCとして仕様を発表するものとします。 そして、仕様はインターネットDraftsディレクトリから取り除かれるものとします。
An official summary of standards actions completed and pending
shall appear in each issue of the Internet Society Newsletter.
This shall constitute the "journal of record" for Internet
standards actions. In addition, the IESG shall publish a
monthly summary of standards actions completed and pending in
the Internet Monthly Report, which is distributed to all
members of the IETF mailing list.
規格動作の完成して未定の公式の概要はインターネット協会ニュースレターの各問題に載っているものとします。 これはインターネット標準動作のために「記録のジャーナル」を構成するものとします。 さらに、IESGはIETFメーリングリストのすべてのメンバーに分配されるインターネットMonthly Reportで完成して未定の規格動きの毎月の概要を発表するものとします。
Finally, the IAB shall publish quarterly an "Internet Official
Protocol Standards" RFC, summarizing the status of all Internet
protocol and service specifications, both within and outside
the standards track.
最終的に、IABは四半期の「インターネット公式プロトコル標準」RFCを発行するものとします、すべてのインターネットプロトコルとサービス仕様(標準化過程と標準化過程の外の両方)の状態をまとめて
3.2 Entering the Standards Track
3.2 標準化過程に入ること。
A specification that is potentially an Internet Standard may
originate from:
潜在的にインターネットStandardである仕様は以下から由来するかもしれません。
(a) an ISOC-sponsored effort (typically an IETF Working Group),
(a) ISOCによって後援された努力(通常IETF作業部会)
(b) independent activity by individuals, or
または(b) 個人による独立している活動。
(c) an external organization.
(c) 外部の組織。
Case (a) accounts for the great majority of specifications that
enter the standards track. In cases (b) and (c), the work might
be tightly integrated with the work of an existing IETF Working
規格を入れる仕様の大多数のためのケース(a)アカウントは追跡されます。 場合(b)と(c)では、仕事は既存のIETF Workingの仕事についてしっかり統合しているかもしれません。
IAB - IESG [Page 20] RFC 1602 Internet Standards Process March 1994
IAB--IESG[20ページ]RFC1602インターネット規格は1994年3月に処理されます。
Group, or it might be offered for standardization without prior
IETF involvement. In most cases, a specification resulting from
an effort that took place outside of an IETF Working Group will be
submitted to an appropriate Working Group for evaluation and
refinement. If necessary, an appropriate Working Group will be
created.
分類してください。さもないと、標準化のために先のIETFかかわり合いなしでそれを提供するかもしれません。 多くの場合、評価と気品のためにIETF作業部会の外で行われた努力から生じる仕様を適切な作業部会に提出するでしょう。 必要なら、適切な作業部会は創設されるでしょう。
For externally-developed specifications that are well-integrated
with existing Working Group efforts, a Working Group is assumed to
afford adequate community review of the accuracy and applicability
of the specification. If a Working Group is unable to resolve all
technical and usage questions, additional independent review may
be necessary. Such reviews may be done within a Working Group
context, or by an ad hoc review committee established specifically
for that purpose. Ad hoc review committees may also be convened
in other circumstances when the nature of review required is too
small to require the formality of Working Group creation. It is
the responsibility of the appropriate IETF Area Director to
determine what, if any, review of an external specification is
needed and how it shall be conducted.
既存の作業部会の努力についてよく統合している外部的に開発された仕様に関しては、作業部会が精度の適切な共同体レビューと仕様の適用性を提供すると思われます。 作業部会が技術的にすべてを決議できないで、用法が質問されるなら、追加独立しているレビューが必要であるかもしれません。 明確にそのために確立された臨時の再調査委員会は作業部会関係以内かそのようなレビューを完了しているかもしれません。 また、必要であるレビューの本質が作業部会の創造の堅苦しさを必要とすることができないくらいわずかであるときに、臨時の再調査委員会は他の事情で召集されるかもしれません。 適切なIETF Areaディレクターが外部仕様のレビューがどんなであるも何であるかを必要な状態で決心する責任とそれがどう行われるものとするかということです。
3.3 Advancing in the Standards Track
3.3 標準化過程で進むこと。
A specification shall remain at the Proposed Standard level for at
least six (6) months.
仕様は少なくとも6(6)カ月Proposed Standardレベルに残るものとします。
A specification shall remain at the Draft Standard level for at
least four (4) months, or until at least one IETF meeting has
occurred, whichever comes later.
少なくとも4(4)カ月、または少なくとも1つのIETFミーティングが起こるまで、仕様はDraft Standardレベルに残るものとします、どれが後で来ても。
These minimum periods are intended to ensure adequate opportunity
for community review without severely impacting timeliness. These
intervals shall be measured from the date of publication of the
corresponding RFC(s), or, if the action does not result in RFC
publication, the date of IESG approval of the action.
これらの最短期が厳しくタイムリーさであるのに影響を与えないで共同体レビューの適切な機会を確実にすることを意図します。 対応するRFC(s)の公表の日付、または動作がRFC公表をもたらさないときの動作のIESG承認の日付からどんなこれらの間隔を測定しないものとします。
A specification may be (indeed, is likely to be) revised as it
advances through the standards track. At each stage, the IESG
shall determine the scope and significance of the revision to the
specification, and, if necessary and appropriate, modify the
recommended action. Minor revisions are expected, but a
significant revision may require that the specification accumulate
more experience at its current maturity level before progressing.
Finally, if the specification has been changed very significantly,
the IESG may recommend that the revision be treated as a new
document, re-entering the standards track at the beginning.
仕様がそうである、(本当に、ありそうである、)、標準化過程を通って進むので、復習しました。 そして、必要なら、各段階で、IESGは改正の範囲と意味を仕様に決定するものとします、そして、適切であることで、お勧めの動作を変更してください。 小さい方の改正は予想されますが、重要な改正は、仕様が進歩をする前に現在の成熟レベルで、より多くの経験を蓄積するのを必要とするかもしれません。 最終的に、仕様を非常にかなり変えたなら、IESGは、改正が新しいドキュメントとして扱われることを勧めるかもしれません、始めに標準化過程に再入して。
IAB - IESG [Page 21] RFC 1602 Internet Standards Process March 1994
IAB--IESG[21ページ]RFC1602インターネット規格は1994年3月に処理されます。
Change of status shall result in republication of the
specification as an RFC, except in the rare case that there have
been no changes at all in the specification since the last
publication. Generally, desired changes will be "batched" for
incorporation at the next level in the standards track. However,
deferral of changes to the next standards action on the
specification will not always be possible or desirable; for
example, an important typographical error, or a technical error
that does not represent a change in overall function of the
specification, may need to be corrected immediately. In such
cases, the IESG or RFC Editor may be asked to republish the RFC
with corrections, and this will not reset the minimum time-at-
level clock.
状態の変化はRFCとして仕様の再刊をもたらすものとします、最後の公表以来仕様には変化が全くないまれなケースを除いて。 一般に、必要な変化は編入のために標準化過程の次のレベルで"batchedする"でしょう。 しかしながら、仕様への次の規格動作への変化の延期は、いつも可能であるか、または望ましくなるというわけではないでしょう。 例えば、重要な誤字、または仕様の総括的機能における変化を表さない技術的な誤りが、すぐに修正される必要があるかもしれません。 そのような場合、IESGかRFC Editorが修正でRFCを再刊するように頼まれるかもしれなくて、これは最小の時間をリセットしないでしょう。-レベルでは、時間を計ってください。
When a standards-track specification has not reached the Internet
Standard level but has remained at the same status level for
twenty-four (24) months, and every twelve (12) months thereafter
until the status is changed, the IESG shall review the viability
of the standardization effort responsible for that specification.
Following each such review, the IESG shall approve termination or
continuation of the development. This decision shall be
communicated to the IETF via electronic mail to the IETF mailing
list, to allow the Internet community an opportunity to comment.
This provision is not intended to threaten a legitimate and active
Working Group effort, but rather to provide an administrative
mechanism for terminating a moribund effort.
標準化過程仕様が状態を変えるまでインターネットStandardレベルに達しませんが、その後何24(24)カ月、および12(12)カ月毎同じ状態レベルに残ったとき、IESGはその仕様に原因となる標準化の努力の生存力を見直すものとします。 そのような各レビューに続いて、IESGは開発の終了か継続を承認するものとします。 この決定は、コメントする機会をインターネットコミュニティに許容するためにIETFメーリングリストへの電子メールを通してIETFに伝えられるものとします。 正統の、そして、活発な作業部会の努力を脅かすことを意図するのではなく、この支給は、むしろ瀕死の努力を終えるのに管理機構を提供するために意図します。
3.4 Revising a Standard
3.4 規格を改訂すること。
A new version of an established Internet Standard must progress
through the full Internet standardization process as if it were a
completely new specification. Once the new version has reached
the Standard level, it will usually replace the previous version,
which will move to Historic status. However, in some cases both
versions may remain as Internet Standards to honor the
requirements of an installed base. In this situation, the
relationship between the previous and the new versions must be
explicitly stated in the text of the new version or in another
appropriate document (e.g., an Applicability Statement; see
Section 2.2.2).
確立したインターネットStandardの新しいバージョンはまるでそれが完全に新しい仕様であるかのように完全なインターネット標準化過程で進歩をしなければなりません。 新しいバージョンがいったんStandardレベルに達すると、通常、それは旧バージョンを置き換えるでしょう。(それは、Historic状態に動くでしょう)。 しかしながら、いくつかの場合、両方のバージョンは、インストールされたベースの要件を光栄に思うためにインターネットStandardsとして残るかもしれません。 この状況で、新しいバージョンのテキストか別の適切なドキュメントに明らかに前のバージョンと新しいバージョンとの関係を述べなければなりません(例えば、Applicability Statement; セクション2.2.2を見てください)。
3.5 Retiring a Standard
3.5 規格を回収すること。
As the technology changes and matures, it is possible for a new
Standard specification to be so clearly superior technically that
one or more existing Internet Standards for the same function
技術が変化して、熟すとき、新しいStandard仕様が明確に技術的に、同じくらいのための1既存のインターネットStandardsが機能するほど優れているのは、可能です。
IAB - IESG [Page 22] RFC 1602 Internet Standards Process March 1994
IAB--IESG[22ページ]RFC1602インターネット規格は1994年3月に処理されます。
should be retired. In this case, the IESG shall approve a change
of status of the superseded specification(s) from Standard to
Historic. This recommendation shall be issued with the same
Last-Call and notification procedures used for any other standards
action.
退職しているべきです。 この場合、IESGは取って代わられた仕様の状態のStandardからHistoricまでの変化を承認するものとします。 同じLast-呼び出しと通知手順がいかなる他の規格動作にも用いられている状態で、この推薦は発行されるものとします。
3.6 Conflict Resolution and Appeals
3.6 紛争解決と上告
IETF Working Groups are generally able to reach consensus, which
sometimes requires difficult compromises between differing
technical solutions. However, there are times when even
reasonable and knowledgeable people are unable to agree. To
achieve the goals of openness and fairness, such conflicts must be
resolved with a process of open review and discussion.
Participants in a Working Group may disagree with Working Group
decisions, based either upon the belief that their own views are
not being adequately considered or the belief that the Working
Group made a technical choice which essentially will not work.
The first issue is a difficulty with Working Group process, and
the latter is an assertion of technical error. These two kinds of
disagreements may have different kinds of final outcome, but the
resolution process is the same for both cases.
一般に、IETF Working Groupsはコンセンサスに達することができます。(それは、時々異なった技術的解決法の間の難しい妥協を必要とします)。 しかしながら、妥当で博識な人々さえ同意できない回があります。 風通しの良さと公正の目標を達成するために、公開審査と議論の過程でそのような闘争を解決しなければなりません。 作業部会の関係者は作業部会の決定と意見を異にするかもしれません、それら自身の視点が適切に考えられていないという信念か作業部会が本質的には働いていない技術選択をしたという信念に基づきます。 創刊号は作業部会の過程において困難です、そして、後者は技術的な誤りの主張です。 これらの2種類の不一致には、異種の最終的な結果があるかもしれませんが、両方のケースに、解決の過程は同じです。
Working Group participants always should first attempt to discuss
their concerns with the Working Group chair. If this proves
unsatisfactory, they should raise their concerns with an IESG Area
Director or other IESG member. In most cases, issues raised to
the level of the IESG will receive consideration by the entire
IESG, with the relevant Area Director or the IETF Chair being
tasked with communicating results of the discussion.
作業部会の関係者は、最初に、いつも作業部会いすと彼らの関心について議論するのを試みるべきです。 これが不十分であると判明するなら、彼らはIESG Areaディレクターか他のIESGメンバーと共に自分達の関心を高めるべきです。 多くの場合、IESGのレベルに提起された問題は全体のIESGによる考慮を受けるでしょう、関連AreaディレクターかIETF議長が議論の交信結果で仕事を課されている状態で。
For the general community as well as Working Group participants
seeking a larger audience for their concerns, there are two
opportunities for explicit comment. (1) When appropriate, a
specification that is being suggested for advancement along the
standards track will be presented during an IETF plenary. At that
time, IETF participants may choose to raise issues with the
plenary or to pursue their issues privately, with any of the
relevant IETF/IESG management personnel. (2) Specifications that
are to be considered by the IESG are publicly announced to the
IETF mailing list, with a request for comments.
彼らの関心のために、より大きい聴衆を探している作業部会の関係者と同様に一般的な共同体には、明白なコメントの2つの機会があります。 (1) 適切であるときに、標準化過程に沿った前進のために示されている仕様はIETFの間、絶対的な状態で提示されるでしょう。 その時、IETF関係者は、絶対的問題を提起するか、またはそれらの問題を個人的に追求するのを選ぶかもしれません、関連IETF/IESG経営幹部のいずれと共にも。 (2) IESGによって考えられることになっている仕様は公的にIETFメーリングリストに発表されます、コメントを求める要求で。
Finally, if a problem persists, the IAB may be asked to adjudicate
the dispute.
最終的に、問題が持続しているなら、IABが論争に判決を下すように頼まれるかもしれません。
IAB - IESG [Page 23] RFC 1602 Internet Standards Process March 1994
IAB--IESG[23ページ]RFC1602インターネット規格は1994年3月に処理されます。
* If a concern involves questions of adequate Working Group
discussion, the IAB will attempt to determine the actual
nature and extent of discussion that took place within the
Working Group, based upon the Working Group's written record
and upon comments of other Working Group participants.
* 関心が適切な作業部会の議論の質問にかかわると、IABは、作業部会の中で行われた議論の実際の自然と範囲を測定するのを試みるでしょう、作業部会の文書記録と他の作業部会の関係者のコメントに基づきます。
* If a concern involves questions of technical adequacy, the
IAB may convene an appropriate review panel, which may then
recommend that the IESG and Working Group re-consider an
alternate technical choice.
* 関心が技術的な妥当性の質問にかかわるなら、IABは適切な再検討委員会を召集するかもしれません。(次に、それは、IESGと作業部会が交互の技術選択を再考することを勧めるかもしれません)。
* If a concern involves a reasonable difference in technical
approach, but does not substantiate a claim that the Working
Group decision will fail to perform adequately, the Working
Group participant may wish to pursue formation of a separate
Working Group. The IESG and IAB encourage alternative points
of view and the development of technical options, allowing
the general Internet community to show preference by making
its own choices, rather than by having legislated decisions.
* 関心が技術的なアプローチの妥当な違いにかかわりますが、作業部会の決定が適切に働かないというクレームを実体化しないなら、作業部会の関係者は別々の作業部会の構成を追求したがっているかもしれません。 IESGとIABは技術的なオプションの代替の観点と開発を奨励します、一般的なインターネットコミュニティが決定を制定したことによってというよりむしろそれ自身の選択をすることによって優先するのを許容して。
4. EXTERNAL STANDARDS AND SPECIFICATIONS
4. 外部の規格と仕様
Many standards groups other than the IETF create and publish standards documents for network protocols and services. When these external specifications play an important role in the Internet, it is desirable to reach common agreements on their usage -- i.e., to establish Internet Standards relating to these external specifications.
IETF以外の多くの規格グループが、ネットワーク・プロトコルとサービスのための規格文書を作成して、発表します。 これらの外部仕様がインターネットで重要な役割を果たすとき、それらの用法で一般的な合意に達するのは望ましいです--すなわち、これらの外部仕様に関連するインターネットStandardsを証明するために。
There are two categories of external specifications:
外部仕様の2つのカテゴリがあります:
(1) Open Standards
(1) オープンスタンダード
Accredited national and international standards bodies, such as
ANSI, ISO, IEEE, and ITU-TS, develop a variety of protocol and
service specifications that are similar to Technical
Specifications defined here. National and international groups
also publish "implementors' agreements" that are analogous to
Applicability Statements, capturing a body of implementation-
specific detail concerned with the practical application of
their standards.
ANSIなどの公認の国家的、そして、国際的な標準化団体(ISO、IEEE、およびITU-TS)は、ここで定義された仕様書と同様のさまざまなプロトコルとサービス仕様を開発します。 また、国家的、そして、国際的なグループはApplicability Statementsに類似の「実装者間協定」を発行します、彼らの規格の実用化に関する実現の特定の詳細のボディーを捕らえて。
IAB - IESG [Page 24] RFC 1602 Internet Standards Process March 1994
IAB--IESG[24ページ]RFC1602インターネット規格は1994年3月に処理されます。
(2) Vendor Specifications
(2) メーカー仕様
A vendor-proprietary specification that has come to be widely
used in the Internet may be treated by the Internet community as
if it were a "standard". Such a specification is not generally
developed in an open fashion, is typically proprietary, and is
controlled by the vendor or vendors that produced it.
インターネットで広く使用されるようになった業者メーカー独自仕様はまるでそれが「規格」であるかのようにインターネットコミュニティによって扱われるかもしれません。 そのような仕様は、一般に、開いているファッションで開発されないで、通常独占であり、それを生産した業者か業者によって制御されます。
To avoid conflict between competing versions of a specification, the Internet community will not standardize a TS or AS that is simply an "Internet version" of an existing external specification unless an explicit cooperative arrangement to do so has been made. However, there are several ways in which an external specification that is important for the operation and/or evolution of the Internet may be adopted for Internet use.
仕様の競争しているバージョンの間の闘争を避けるために、したがって、する明白な協力的な措置をしていないと、インターネットコミュニティは単に「インターネットバージョン」である既存の外部仕様のTSかASを標準化しないでしょう。 しかしながら、インターネットの操作、そして/または、発展に、重要な外部仕様がインターネットの利用のために採用されるかもしれないいくつかの方法があります。
(a) Incorporation of an Open Standard
(a) オープンスタンダードの編入
An Internet Standard TS or AS may incorporate an open external
standard by reference. The reference must be to a specific
version of the external standard, e.g., by publication date or
by edition number, according to the prevailing convention of the
organization that is responsible for the specification.
インターネットStandard TSかASが参照で開いている外部の規格を取り入れるかもしれません。 例えば、外部の規格の特定のバージョン、公表日付または版の番号に従って、参照があるに違いありません、組織の仕様に責任がある行き渡っているコンベンションによると。
For example, many Internet Standards incorporate by reference
the ANSI standard character set "ASCII" [2]. Whenever possible,
the referenced specification shall be made available online.
例えば、多くのインターネットStandardsが参照でANSI規格文字の組「ASCII」[2]を取り入れます。 可能であるときはいつも、オンラインで参照をつけられた仕様を利用可能にするものとします。
(b) Incorporation of a Vendor Specification
(b) メーカー仕様の編入
Vendor-proprietary specifications may be incorporated by
reference to a specific version of the vendor standard. If the
vendor-proprietary specification is not widely and readily
available, the IESG may request that it be published as an
Informational RFC.
業者メーカー独自仕様は業者規格の特定のバージョンの参照で取り入れられるかもしれません。 業者メーカー独自仕様が広さと容易に利用可能でないなら、IESGは、それがInformational RFCとして発行されるよう要求するかもしれません。
For a vendor-proprietary specification to be incorporated within
the Internet standards process, the proprietor must meet the
requirements of section 5 below, and in general the
specification shall be made available online.
業者メーカー独自仕様がインターネット標準化過程の中に組み込んでいるために、所有者は下のセクション5に関する必要条件を満たさなければなりません、そして、一般に、オンラインで仕様を利用可能にするものとします。
The IESG shall not favor a particular vendor's proprietary
specification over the technically equivalent and competing
specifications of other vendors by making it "required" or
"recommended".
それが「必要である」、または「推薦されること」を作ることによって、IESGは他の業者の技術的に同等で競争している仕様ほど特定の業者のメーカー独自仕様を好まないものとします。
IAB - IESG [Page 25] RFC 1602 Internet Standards Process March 1994
IAB--IESG[25ページ]RFC1602インターネット規格は1994年3月に処理されます。
(c) Assumption
(c) 仮定
An IETF Working Group may start from an external specification
and develop it into an Internet TS or AS. This is acceptable if
(1) the specification is provided to the Working Group in
compliance with the requirements of section 5 below, and (2)
change control has been conveyed to IETF by the original
developer of the specification. Continued participation in the
IETF work by the original owner is likely to be valuable, and is
encouraged.
IETF作業部会は、外部仕様から始めて、インターネットTSかASにそれを開発するかもしれません。 (1) セクション5の要件に従って以下で仕様を作業部会に提供して、(2) 仕様のオリジナルの開発者が変化コントロールをIETFまで運んだなら、これは許容できます。 最初の所有者によるIETF仕事への継続的な参加は、貴重であることがありそうであり、奨励されます。
The following sample text illustrates how a vendor might convey change control to the Internet Society:
以下のサンプルテキストは業者がどう変化コントロールをインターネット協会まで運ぶかもしれないかを例証します:
"XXXX Organization asserts that it has the right to transfer to
the Internet Society responsibility for further evolution of the
YYYY protocol documented in References (1-n) below. XXXX
Organization hereby transfers to the Internet Society
responsibility for all future modification and development of
the YYYY protocol, without reservation or condition."
「XXXX Organizationは、以下のReferences(1-n)に記録されたYYYYプロトコルの一層の発展へのインターネット協会責任に移すためにそれが権利があると断言します。」 「XXXX OrganizationはこれによりYYYYプロトコルのすべての今後の変更と開発へのインターネット協会責任に移します、予約も状態なしで。」
5. INTELLECTUAL PROPERTY RIGHTS
5. 知的所有権
5.1. General Policy
5.1. 全般的執行方針
In all matters of intellectual property rights and procedures, the
intention is to benefit the Internet community and the public at
large, while respecting the legitimate rights of others.
知的所有権と手順のすべての問題に関して、意志は他のものの正当な権利を尊敬している間、インターネットコミュニティと社会全般のためになることです。
5.2. Definitions
5.2. 定義
As used in this section, the following terms have the indicated
meanings:
このセクションで使用されるように、次の用語には、示された意味があります:
o "Trade secrets" are confidential, proprietary information.
o 「企業秘密」は秘密の、そして、独占である情報です。
o "Contribution" means any disclosure of information or ideas,
whether in oral, written, or other form of expression, by an
individual or entity ("Contributor").
o 「貢献」は情報か考えのどんな公開も意味します、口頭の、または、書かれたか、他の表現形式であるか否かに関係なく、個人か実体(「貢献者」)で。
o "Standards track documents" are specifications and other
documents that have been elevated to the Internet standards
track in accordance with the Internet Standards Process.
o 「標準化過程ドキュメント」は、インターネットStandards Processに応じてインターネット標準化過程に登用された仕様と他のドキュメントです。
IAB - IESG [Page 26] RFC 1602 Internet Standards Process March 1994
IAB--IESG[26ページ]RFC1602インターネット規格は1994年3月に処理されます。
o "Copyrights" are purportedly valid claims to copyright in all
or part of a contribution to standards work, whether or not
the contribution becomes a standards track document,
including but not limited to any works by third parties that
the contribution is based on or incorporates.
o 「著作権」は標準化作業への貢献のすべてか一部の著作権への表面上有効なクレームです、貢献がいずれも貢献が基づいている第三者で扱う他を含む標準化過程ドキュメントになるか、または盛込まれることにかかわらず。
o "ISOC" refers to the Internet Society and its trustees,
officers, employees, contractors, and agents, as well as the
IAB, IETF, IESG, IRTF, IRSG, and other task forces,
committees, and groups coordinated by the Internet Society.
o "ISOC"はインターネット協会、受託者、役員、従業員、契約者、およびエージェントを示します、インターネット協会によって調整されたIAB、IETF、IESG、IRTF、IRSG、他の特別委員会、委員会、およびグループと同様に。
o "Standards work" is work involved in the creation, testing,
development, revision, adoption, or maintenance of an
Internet standard that is carried out under the auspices of
ISOC.
o 「標準化作業」はISOCの前兆で行われるインターネット標準の創造、テスト、開発、改正、採用、または維持にかかわる仕事です。
o "Internet community" refers to the entire set of persons,
whether individuals or entities, including but not limited to
technology developers, service vendors, and researchers, who
use the Internet, either directly or indirectly, and users of
any other networks which implement and use Internet
Standards.
o 「インターネットコミュニティ」は全体の人々を示します、個人か実体であることにかかわらず、インターネットStandardsを実行して、使用するいかなる他のネットワークの他の技術開発者、サービス業者、直接か間接的にインターネットを使用する研究者、およびユーザも含んでいて。
5.3 Trade Secret Rights
5.3 企業秘密権利
Except as otherwise provided under this section, ISOC will not
accept, in connection with standards work, any idea, technology,
information, document, specification, work, or other contribution,
whether written or oral, that is a trade secret or otherwise
subject to any commitment, understanding, or agreement to keep it
confidential or otherwise restrict its use or dissemination; and,
specifically, ISOC does not assume any confidentiality obligation
with respect to any such contribution.
別の方法でこのセクションの下で提供する以外に、ISOCは受け入れないでしょう、標準化作業に関して、どんな考え、技術、情報、ドキュメント、仕様、仕事、または、他の貢献、書かれているか、または口頭であり、それが何か委任への企業秘密かそれともそうでなければ、対象であるか、そして、理解、または秘密であるかそうでなくそれを保つ協定がその使用か普及を制限します。 そして、明確に、ISOCはどんなそのような貢献に関しても少しの守秘義務も引き受けません。
5.4. Rights and Permissions
5.4. 権利と許容
In the course of standards work, ISOC receives contributions in
various forms and from many persons. To facilitate the wide
dissemination of these contributions, it is necessary to establish
specific understandings concerning any copyrights, patents, patent
applications, or other rights in the contribution. The procedures
set forth in this section apply to contributions submitted after 1
April 1994. For Internet standards documents published before
this date (the RFC series has been published continuously since
April 1969), information on rights and permissions must be sought
directly from persons claiming rights therein.
標準化作業の間に、ISOCは様々なフォームと多くの人々から貢献を受けます。 これらの貢献の広い普及を容易にするために、貢献におけるどんな著作権に関する特定の疎通、特許、特許出願、または他の権利も確立するのが必要です。 このセクションで詳しく説明された手順は1994年4月1日以降提出された貢献に適用されます。 この日(1969年4月以来RFCシリーズは絶え間なく発行されている)以前発表されたインターネット標準ドキュメントに関しては、直接そこに権利を要求する人々から権利と許容の情報を求めなければなりません。
IAB - IESG [Page 27] RFC 1602 Internet Standards Process March 1994
IAB--IESG[27ページ]RFC1602インターネット規格は1994年3月に処理されます。
5.4.1. All Contributions
5.4.1. すべての貢献
By submission of a contribution to ISOC, and in consideration
of possible dissemination of the contribution to the Internet
community, a contributor is deemed to agree to the following
terms and conditions:
ISOCへの貢献の提案、インターネットコミュニティへの貢献の可能な普及およびを考慮して、貢献者が以下の条件に同意すると考えられます:
l. Contributor agrees to grant, and does grant to ISOC, a
perpetual, non-exclusive, royalty-free, world-wide right
and license under any copyrights in the contribution to
reproduce, distribute, perform or display publicly and
prepare derivative works that are based on or incorporate
all or part of the contribution, and to reproduce,
distribute and perform or display publicly any such
derivative works, in any form and in all languages, and to
authorize others to do so.
l。 貢献者は、貢献が公的に再生するか、広げるか、実行するか、または表示する貢献におけるどんな著作権の下におけるISOC、永久の、そして、非排他的で、ロイヤリティのいらなくて、世界的な右、およびライセンスに与えて、承諾して、派生しているすべてをに基づいているか、または取り入れる作品を準備するか、または離れて、どんなフォームとすべての言語でも公的にそのようなどんな派生している作品も複製するか、配布して、実行するか、または表示して、他のものがそうするのを認可するのに同意します。
2. Contributor acknowledges that ISOC has no duty to publish
or otherwise use or disseminate every contribution.
2. 貢献者は、そうでなければ、あらゆる貢献を発行するか、使用するか、または広めるためにISOCには義務が全くないと認めます。
3. Contributor grants ISOC permission to reference the
name(s) and address(s) of the contributor as well as other
persons who are named as contributors.
3. 貢献者は貢献者として命名される他の人々と同様に貢献者の参照への名前とアドレスをISOC許可に与えます。
4. Where the contribution was prepared jointly with others,
or is a work for hire, the contributor represents and
warrants that the other owner(s) of rights have been
informed of the rights and permissions granted to ISOC and
that any required authorizations have been obtained.
Copies of any such required authorizations will be
furnished to ISOC, upon request.
4. 貢献が他のものと一緒に準備されたか、または賃貸のための仕事であるところでは、貢献者は、権利の他の所有者がISOCに承諾された権利と許容において知識があって、どんな必要な承認も得てあるのを表して、保証します。 要求のときにそのようなどんな必要な承認のコピーもISOCに提供するでしょう。
5. Contributor acknowledges and agrees that ISOC assumes no
obligation to maintain any confidentiality with respect to
any aspect of the contribution, and warrants that the the
contribution does not violate the rights of others.
5. 貢献者は、ISOCが貢献のどんな局面に関してもどんな秘密性も維持する義務を全く引き受けないのに認めて、同意します、そして、貢献がする証明書は他のものの権利に違反しません。
6. All material objects in which contributions are submitted
to ISOC become the property of ISOC and need not be
returned to the contributor.
6. 貢献がISOCに提出されるすべての物質的な物はISOCの特性になって、貢献者に返さなければならないというわけではありません。
Where appropriate, written confirmation of the above terms and
conditions will be obtained in writing by ISOC, usually by
electronic mail; however, a decision not to obtain such
confirmation in a given case shall not act to revoke the prior
grant of rights and permissions with respect to the
適切であるところでは、ISOCと、通常電子メールで書く際に上の条件の確認書を得るでしょう。 しかしながら、与えられた場合における確認が権利の先の認可を取り消すために活動させないものとするそのようなものと許容を得ない決定
IAB - IESG [Page 28] RFC 1602 Internet Standards Process March 1994
IAB--IESG[28ページ]RFC1602インターネット規格は1994年3月に処理されます。
contribution as provided herein. Except as provided below, the
Executive Director of the IETF Secretariat, or a person
designated by the Executive Director, will be responsible for
obtaining written confirmations.
ここに提供される貢献。 以下に提供するのを除いて、IETF事務局の専務、または事務局長によって任命された人が確認書を得るのに責任があるでしょう。
In the case of IETF Working Groups, the responsibility for
identifying the principal contributor(s) for purposes of
obtaining written confirmation of the above rights and
permissions will be assumed by the Editor or Chair of the
particular Group. While only those persons named as principal
contributor(s) will generally be requested to provide written
confirmation, it is the responsibility of all contributors to
standards work to inform the IETF Secretariat of any
proprietary claims in any contributions and to furnish the
Secretariat with any required confirmation.
IETF Working Groupsの場合では、上の権利と許容の確認書を得る目的のために主要な貢献者を特定することへの責任は特定のGroupのEditorか議長によって負われるでしょう。 主要な貢献者として指定されたそれらの人々だけが確認書を提供するよう一般に要求されますが、どんな貢献でもどんな独占クレームについてもIETF事務局に知らせて、どんな必要な確認も事務局に備えるのは、標準化作業へのすべての貢献者の責任です。
Where any person participating in standards work asserts any
proprietary right in a contribution, it is the responsibility
of such person to so inform the Editor or Chair of the group,
promptly, in writing. The Editor or Chair will then determine
whether to list the person as a principal contributor, or to
revise the document to omit the particular contribution in
question.
標準化作業に参加するどんな人も貢献におけるどんな所有権も主張するところでは、したがって、グループについてEditorか議長に知らせるのは、即座にそのような人の責任です、文章で。 そして、Editorか議長が、主要な貢献者に人について記載するか、または問題の特定の貢献を省略するためにドキュメントを改訂するかを決心するでしょう。
5.4.2. Standards Track Documents
5.4.2. 標準化過程ドキュメント
(A) ISOC will not propose, adopt, or continue to maintain any
standards, including but not limited to standards labelled
Proposed, Draft or Internet Standards, which can only be
practiced using technology or works that are subject to
known copyrights, patents or patent applications, or other
rights, except with the prior written assurance of the
owner of rights that:
(A) ISOCは、Proposed、DraftまたはインターネットStandardsとラベルされた他の規格を含む熟練している使用技術か権利の所有者の先の書かれた保証を除いて、知られている著作権、特許、特許出願、または他の権利を受けることがある作品がそれであった場合にだけそうすることができるどんな規格であることも支持し提案するか、採用するか、または続けないでしょう:
l. ISOC may, without cost, freely implement and use the
technology or works in its standards work;
l。 ISOCは費用なしで標準化作業に技術か作品を自由に実行して、使用するかもしれません。
2. upon adoption and during maintenance of an Internet
Standard, any party will be able to obtain the right
to implement and use the technology or works under
specified, reasonable, non-discriminatory terms; and
2. 採用とインターネットStandardの維持の間、どんなパーティーも、技術を実行して、使用する権利を得ることができるか、または指定されて、妥当で、非差別している用語の下で働きます。 そして
3. the party giving the assurance has the right and
power to grant the licenses and knows of no other
copyrights, patents, patent applications, or other
3. 保証を与えるパーティーは、権利と許可を与えるパワーを持っていて、他の著作権を全く知りません、特許、特許出願、何らかの
IAB - IESG [Page 29] RFC 1602 Internet Standards Process March 1994
IAB--IESG[29ページ]RFC1602インターネット規格は1994年3月に処理されます。
rights that may prevent ISOC and members of the
Internet community from implementing and operating
under the standard.
インターネットコミュニティのISOCとメンバーが規格の下で実行して、働くことができないかもしれない権利。
(B) ISOC disclaims any responsibility for identifying the
existence of or for evaluating any copyrights, patents,
patent applications, or other rights, on behalf of or for
the benefit of any member of the Internet community, and
ISOC takes no position on the validity or scope of any
such rights. Further, ISOC will take no position on the
ownership of inventions made during standards work, except
for inventions of which an employee or agent of the
Internet Society is a joint inventor. In the latter case,
the Internet Society will make its rights available under
license to anyone in the Internet community in accordance
with the written assurances set forth below.
(B) ISOCは利益評価するか、またはどんな著作権も評価するための存在、特許、特許出願、または他の権利を特定するか、またはインターネットコミュニティのどんなメンバーの利益へのどんな責任も放棄します、そして、ISOCはどんなそのような権利の正当性か範囲の上の立場を全く取りません。 さらに、ISOCは標準化作業の間にされた発明品の所有権の立場を全く取らないでしょう、インターネット協会の従業員かエージェントが共同発明者である発明品を除いて。 後者の場合では、インターネット協会は書かれた保証に従ってだれにとっても、インターネットコミュニティでライセンスの下で利用可能な権利を以下に旅に出させるでしょう。
5.5. Notices
5.5. 通知
(A) When a written assurance has been obtained as set forth
below, the relevant standards track documents shall include
the following notice:
(A) 以下に詳しく説明されるように書かれた保証を得たとき、関連標準化過程ドキュメントは以下の通知を含んでいるものとします:
"__________(name of rights' owner) has provided written
assurance to the Internet Society that any party will be
able to obtain, under reasonable, nondiscriminatory
terms, the right to use the technology covered
by__________(list copyrights, patents, patent
applications, and other rights) to practice the
standard. A copy of this assurance may be obtained from
the Executive Director of the IETF Secretariat. The
Internet Society takes no position on the validity or
scope of the copyrights, patents, patent applications,
or other rights, or on the appropriateness of the terms
and conditions of the assurances. The Internet Society
does not make any representation there are no other
rights which may apply to the practice of this standard,
nor that it has made any effort to identify any such
rights. For further information on the Internet
Society's procedures with respect to rights in standards
and standards-related documentation, see RFC_____,
dated________."
"__________(権利の所有者の名前) どんなパーティーも妥当なnondiscriminatory諸条件で技術がカバーした使用への権利を得ることができるインターネット協会に提供された書かれた保証を持っています。__________(リスト著作権、特許、特許出願、および他の権利) 規格を練習するために。 IETF事務局事務局長からこの保証のコピーを入手するかもしれません。 インターネット協会は著作権、特許、特許出願、または他の権利の正当性か範囲の上、または、保証に関する条件の適切さの上の立場を全く取りません。 インターネット協会はこの規格の習慣に適用するかもしれなくて、それがどんなそのような権利も特定するためのどんな努力もした他の権利を全くあるどんな表現にもしません。 インターネット協会の手順に関する規格における権利に関する詳細と規格関連のドキュメンテーションに関しては、RFCを見てください。_____, デートします。________."
(B) ISOC encourages all interested parties to bring to its
attention, at the earliest possible time, the existence of
any copyrights, patents, patent applications, or other rights
(B) ISOCは時間、可能な最も前半どんな著作権の存在でもその注目していただく関係者一同、特許、特許出願、または他の権利を奨励します。
IAB - IESG [Page 30] RFC 1602 Internet Standards Process March 1994
IAB--IESG[30ページ]RFC1602インターネット規格は1994年3月に処理されます。
pertaining to Internet Standards. For this purpose, each
standards document will include the following invitation:
インターネットStandardsに関係します。 このために、各規格文書は以下の招待を含むでしょう:
"The Internet Society invites any interested party to
bring to its attention any copyrights, patents or patent
applications, or other proprietary rights which purport
to cover technology or works that may be required to
practice this standard. Please address the information
to the Executive Director of the Internet Engineering
Task Force Secretariat."
「インターネット協会はこの規格を練習しなければならないかもしれない技術か作品をカバーすることを意味するどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。」 「インターネット・エンジニアリング・タスク・フォース事務局長事務局に情報を記述してください。」
(C) When applicable, the following sentence will be included in
the notice:
(C) 適切であるときに、以下の文は通知に含まれるでしょう:
"As of __________, no information about any copyrights,
patents or patent applications, or other proprietary
rights has been received."
「」__________, 「どんな著作権、特許、特許出願、または他の所有権の情報も全く受け取っていません。」
(D) The following copyright notice and disclaimer will be
included in all ISOC standards-related documentation:
(D) 以下の版権情報と注意書きはすべてのISOCの規格関連のドキュメンテーションに含まれるでしょう:
"Copyright (c) ISOC (year date). Permission is granted
to reproduce, distribute, transmit and otherwise
communicate to the public any material subject to
copyright by ISOC, provided that credit is given to the
source. For information concerning required
permissions, please contact the Executive Director of
the Internet Engineering Task Force Secretariat."
「Copyright(c)ISOC(年の日付)。」 再生して、分配して、伝えて、そうでなければ、ISOCによる著作権を条件としてどんな材料も公衆に伝えるために許可を与えます、クレジットをソースに与えれば。 「必要な許容の情報に関して、インターネット・エンジニアリング・タスク・フォース事務局長事務局に連絡してください。」
ISOC hereby informs the Internet community and other
persons that any standards, whether or not elevated to
the Internet Standard level of maturity, or any
standards-related documentation made available under the
auspices of ISOC are provided on an "AS IS" basis and
ISOC DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY IMPLIED WARRANTY OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, OR
THAT ANY STANDARD OR DOCUMENTATION DOES NOT VIOLATE THE
RIGHTS OF OTHERS.
ISOCは、どんな規格、インターネットStandardレベルに登用されるか否かに関係なく、円熟、または利用可能である下にされたどんな規格関連のドキュメンテーションでも「そのままで」というベースでISOCの前兆を供給しても、ISOCが言い表されたか暗示しているすべての保証を放棄して、含んでいる他があらゆる商品性の黙示保証か特定目的への適合性であるかどんな規格かドキュメンテーションも他のものの権利に違反しないことをこれによりインターネットコミュニティと他の人々に知らせます。
5.6. Assurances
5.6. 保証
The agreement on assurances set forth below will normally be
entered into between the owner of rights and ISOC at the time a
standards track document in which proprietary rights are claimed
reaches the "Proposed Standard" stage of maturity:
所有権が要求される標準化過程ドキュメントが円熟の「提案された標準」ステージに達するとき、通常、権利とISOCの所有者の間で以下に詳しく説明された保証の協定に入られるでしょう:
IAB - IESG [Page 31] RFC 1602 Internet Standards Process March 1994
IAB--IESG[31ページ]RFC1602インターネット規格は1994年3月に処理されます。
This is an agreement between ______________(hereinafter
called "Rights Holder") and the Internet Society on behalf of
itself and its trustees, officers, employees, contractors and
agents, the Internet Architecture Board, Internet Engineering
Steering Group, Internet Engineering Task Force, and other task
forces, committees and groups coordinated by the Internet Society
(hereinafter called "ISOC"), and for the benefit of all users of
the Internet and users of any other networks which implement and
use Internet Standards (hereinafter together with ISOC called
"Internet community"). This agreement takes effect when signed on
behalf of the Rights Holder and the Internet Society.
間にこれは協定です。______________(以下に呼ばれた「権利所有者」) そして、それ自体を代表したインターネット協会、受託者、役員、従業員、契約者、エージェント、インターネット・アーキテクチャ委員会、インターネットEngineering Steering Group、インターネット・エンジニアリング・タスク・フォース、他の特別委員会、委員会、およびグループはインターネット協会(以下に、"ISOC"と呼ばれる)、およびインターネットのすべてのユーザとインターネット規格を実行して、使用するいかなる他のネットワークのユーザの利益(以下に、ISOCと共に「インターネットコミュニティ」と呼ばれる)のためにも調整されました。 Rights Holderとインターネット協会を代表してサインされると、この協定は実施します。
The Rights Holder represents that it has or will have rights
in patent applications, patents, copyrights, trade secrets, and
other proprietary rights in various countries (hereinafter called
"Rights") which may block or impede the ability of the Internet
community to implement and operate under the standards set forth
in ISOC standards document ____,____, and ____(the listed
standards and any similar or related standards now existing or
later developed are together hereinafter called "Standards"). The
Rights as they presently exist are listed on attached Schedule A.
The Rights Holder further agrees to review the Rights listed in
Schedule A from time to time, and, in particular, immediately
prior to the elevation of the Standards to the Internet Standard
level of maturity in accordance with the Internet Standards
Process, and to inform the Executive Director of the Internet
Engineering Task Force Secretariat promptly upon learning of any
new Rights in the Standards that should be added to the list in
Schedule A.
Rights Holderが表す、それが持っていたか、または特許出願、特許、著作権、企業秘密、およびISOC規格文書に詳しく説明された規格の下で実行して、操作するインターネットコミュニティの能力を妨げるか、または妨害するかもしれない様々な国(以下に、「権利」と呼ばれる)の他の所有権に権利を持つでしょう。____,____, そして____(以下に「規格」と呼ばれた状態で、後で現在存在するのが開発した記載された規格とどんな同様の、または、関連する規格も一緒にいます。) 彼らが現在存在して、Rightsは付属Schedule Aに記載されています; Rights HolderはそしてインターネットStandards Processに従ってStandardsの高度のすぐ前にSchedule Aに円熟のインターネットStandardレベルに時々特に記載されたRightsを見直して、Schedule Aのリストに追加されるべきであるStandardsのどんな新しいRightsも知っているときインターネット・エンジニアリング・タスク・フォース事務局について即座に事務局長に知らせるのにさらに同意します。
The Rights Holder believes and affirms that it will derive
benefits by permitting ISOC and the Internet community to
implement and operate under the Standards without interference of
any of the Rights. The policy of ISOC is not to propose, adopt,
or continue to maintain the Standards unless written assurances
are given by the Rights Holder with respect to proprietary rights.
Accordingly, in consideration of the benefits noted above and
other good and valuable consideration, the Rights Holder makes the
assurances set forth herein.
Rights Holderは、Standardsの下でRightsのどれかの干渉なしで実行して、操作するISOCを可能にして、インターネットコミュニティで利益を引き出すのを信じて、確言します。 書かれた保証が所有権に関してRights Holderによって与えられない場合、ISOCの方針は、Standardsであることを支持し提案することになっていませんし、採用するか、続けてもいます。 それに従って、上で有名な利益と他の良くて貴重な考慮を考慮して、Rights Holderは保証についてここに詳しく説明させます。
The Rights Holder grants to ISOC a cost-free, perpetual,
non-exclusive, world-wide license under the Rights with respect to
implementing and operating under the Standards. The license
extends to all activities of ISOC involving the Standards without
limit, including the rights to reproduce, distribute, propose,
test, develop, analyze, enhance, revise, adopt, maintain,
Rights HolderはRightsの下でStandardsの下で実行して、作動することに関して無料の、そして、永久の、そして、非排他的で、世界的なライセンスをISOCに与えます。 ライセンスが限界のない再生する権利を含むStandardsが分配するISOCのかかわることのすべての活動に達して、提案してくださいといって、テストしてくださいといって、展開してください、分析、機能アップ、改正が採用する、維持
IAB - IESG [Page 32] RFC 1602 Internet Standards Process March 1994
IAB--IESG[32ページ]RFC1602インターネット規格は1994年3月に処理されます。
withdraw, perform and display publicly, and prepare derivative
works in any form whatsoever and in all languages, and to
authorize others to do so. The Rights Holder also grants ISOC
permission to use the name and address of Rights Holder in
connection with the Standards.
そして、引き下がってくださいといって、実行してくださいといって、公的に表示してくださいといって、全くどんなフォームとすべての言語でも派生している作品を用意してください、他のものがそうするのを認可するために。 また、Rights HolderはStandardsでRights Holderの名前とアドレスを使用する許可をISOCに与えます。
The Rights Holder relinquishes any right or claim in any
trade secret which is part of the Rights, and makes the trade
secrets available without restriction to the Internet community.
The Rights Holder hereby acknowledges that ISOC assumes no
obligation to maintain any confidentiality with respect to any
aspect of the Standards, and warrants that the Standards do not
violate the rights of others.
Rights HolderはRightsの一部であるどんな企業秘密でもどんな権利やクレームも放棄して、制限なしで利用可能な企業秘密をインターネットコミュニティにします。 Rights Holderは、ISOCがStandardsのどんな局面に関してもどんな秘密性も維持する義務を全く引き受けないとこれにより認めます、そして、Standardsがする証明書は他のものの権利に違反しません。
The Rights Holder assures ISOC that the Rights Holder shall
grant to any member of the Internet community, as a beneficiary of
this agreement, a non-exclusive, perpetual, world-wide license
under the Rights, with respect to operating under the Standards
for a reasonable royalty and under other terms which are
reasonable considering the objective of ISOC to assure that all
members of the Internet community will be able to operate under
the Standards at a minimal cost. The license discussed in this
paragraph shall permit the licensee to make, have made, test,
enhance, implement, and use methods, works, computer programs, and
hardware as needed or desirable for operating under the Standards.
Every license shall include a clause automatically modifying the
terms of the license to be as favorable as the terms of any other
license under the Rights previously or later granted by the Rights
Holder.
Rights HolderはRights Holderがインターネットコミュニティのどんなメンバーにも与えるものとするISOCを保証します、この協定の受益者として、Rightsの下の非排他的で、永久の、そして、世界的なライセンス、ISOCの目的が、インターネットコミュニティのすべてのメンバーがStandardsの下で最小量の費用で作動できることを保証すると考える場合手頃なロイヤリティのためのStandardsと他の妥当な諸条件で作動することに関して。 このパラグラフで議論したライセンスはStandardsの下で作動するのに必要であるか望ましいとして作って、方法を作って、テストして、高めて、実行して、使用するのがいる免許所有者、作品、コンピュータ・プログラム、およびハードウェアを可能にするものとします。 あらゆるライセンスが、以前にか後でRights Holderによって与えられたRightsの下でいかなる他のライセンスの用語とも同じくらい好ましくなるように自動的に許可条件を変更する節を含んでいるものとします。
A form of the license shall always be publicly accessible on
the Internet, and shall become effective immediately when the
member of the Internet community executes it and posts it for
delivery to the Rights Holder either by mail or electronically.
The initial version of the license shall be in the form attached
as Schedule B.
ライセンスのフォームは、インターネットでいつも公的にアクセスしやすく、すぐインターネットコミュニティのメンバーがそれを実行するとき、有効になって、配送のためにメールか電子的のどちらかにRights Holderにそれを掲示します。 ライセンスの初期のバージョンがSchedule Bとして添付されたフォームにあるものとします。
The Rights Holder represents and warrants that its rights are
sufficient to permit it to grant the licenses and give the other
assurances recited in this agreement. The Rights Holder further
represents and warrants that it does not know of any rights of any
other party in any country which would block or impede the ability
of ISOC and the Internet community to implement or operate under
the Standards, or that would prevent the Rights Holder from
granting the licenses and other assurances in this agreement.
Rights Holderは、権利が許可を与えて、この合意で暗唱された他の保証を与えることを許可するために十分であることを表して、保証します。 Rights Holderは、ISOCの能力とStandardsの下で実行するか、または操作するインターネットコミュニティを妨げるか、妨害する、またはRights Holderがこの合意におけるライセンスと他の保証を承諾するのを防ぐどんな国のいかなる他のパーティーのどんな権利も知らないのをさらに表して、保証します。
IAB - IESG [Page 33] RFC 1602 Internet Standards Process March 1994
IAB--IESG[33ページ]RFC1602インターネット規格は1994年3月に処理されます。
This agreement shall not be construed to obligate the ISOC to
propose, adopt, develop, or maintain any of the Standards or any
other standard.
ISOCがStandardsのどれかかいかなる他の規格も提案するか、採用するか、開発するか、または維持するのを義務付けるためにこの協定を解釈しないものとします。
6. REFERENCES
6. 参照
[1] Postel, J., "Internet Official Protocol Standards", STD 1, RFC
1600, USC/Information Sciences Institute, March 1994.
[1] ポステル、J.、「インターネット公式プロトコル標準」、STD1、USC/情報科学が1994年3月に設けるRFC1600。
[2] ANSI, Coded Character Set -- 7-Bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[2]ANSI、コード化文字集合--7ビットの情報交換用米国標準コード、ANSI X3.4-1986。
[3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1340, USC/Information Sciences Institute, July 1992.
[3] USC/情報科学が1992年7月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1340。
[4] Postel, J., "Introduction to the STD Notes", RFC 1311,
USC/Information Sciences Institute, March 1992.
[4] ポステル、J.、「STD注意への序論」、RFC1311、科学が1992年3月に設けるUSC/情報。
[5] Postel, J., "Instructions to RFC Authors", RFC 1543,
USC/Information Sciences Institute, October 1993.
[5] ポステル、J.、「指示、RFCが書く、」、RFC1543、科学が設けるUSC/情報、10月1993日
IAB - IESG [Page 34] RFC 1602 Internet Standards Process March 1994
IAB--IESG[34ページ]RFC1602インターネット規格は1994年3月に処理されます。
APPENDIX A: GLOSSARY OF ACRONYMS
付録A: 頭文字語の用語集
ANSI: American National Standards Institute
ARPA: (U.S.) Advanced Research Projects Agency
AS: Applicability Statement
ASCII: American Standard Code for Information Interchange
ITU-T: Telecommunications Standardization sector of the International
Telecommunications Union (ITU), a UN treaty organization;
ITU-T was formerly called CCITT.
IAB: Internet Architecture Board
IANA: Internet Assigned Numbers Authority
IEEE: Institute of Electrical and Electronics Engineers
ICMP: Internet Control Message Protocol
IESG: Internet Engineering Steering Group
IETF: Internet Engineering Task Force
IP: Internet Protocol
IRTF: Internet Research Task Force
ISO: International Organization for Standardization
ISOC: Internet Society
MIB: Management Information Base
OSI: Open Systems Interconnection
RFC: Request for Comments
TCP: Transmission Control Protocol
TS: Technical Specification
ANSI: American National Standards Institutアルパ: (米国) 先端研究は以下として政府機関を映し出します。 適用性証明ASCII: 情報交換用米国標準コードITU-T: 国際Telecommunications Union(ITU)、国連条約組織のテレコミュニケーションStandardizationセクター。 ITU-Tは以前、CCITTと呼ばれました。 IAB: インターネット・アーキテクチャ委員会IANA: インターネットは数の権威IEEEを割り当てました: 米国電気電子技術者学会ICMP: インターネット・コントロール・メッセージ・プロトコルIESG: インターネット工学運営グループIETF: インターネット・エンジニアリング・タスク・フォースIP: インターネットプロトコルIRTF: インターネット研究課題力のISO: 国際標準化機構ISOC: インターネット協会MIB: 管理情報ベースOSI: 開放型システム間相互接続RFC: コメントには、TCPを要求してください: 通信制御プロトコルt: 仕様書
APPENDIX B: CONTACT POINTS
付録B: 接点
To contact the RFC Editor, send an email message to: "rfc- editor@isi.edu".
RFC Editorに連絡するために、メールメッセージを以下に送ってください。 「rfc editor@isi.edu 。」
To contact the IANA for information or to request a number, keyword or parameter assignment send an email message to: "iana@isi.edu".
情報のためにIANAに連絡するか、または数、キーワードまたはパラメタ課題を要求するために、メールメッセージを以下に送ってください。 " iana@isi.edu "。
To contact the IESG, send an email message to: "iesg@cnri.reston.va.us".
IESGに連絡するために、メールメッセージを以下に送ってください。 " iesg@cnri.reston.va.us "。
To contact the IAB, send an email message to: "iab-contact@isi.edu".
IABに連絡するために、メールメッセージを以下に送ってください。 " iab-contact@isi.edu "。
To contact the Executive Director of the ISOC, send an email message to "amr@isoc.org".
ISOCの事務局長に接触するには、" amr@isoc.org "にメールメッセージを送ってください。
IAB - IESG [Page 35] RFC 1602 Internet Standards Process March 1994
IAB--IESG[35ページ]RFC1602インターネット規格は1994年3月に処理されます。
APPENDIX C: FUTURE ISSUES
付録C: 将来の問題
It has been suggested that additional procedures in the following areas should be considered.
以下の領域の追加手順が考えられるべきであると示唆されました。
o Policy Recommendations and Operational Guidelines
o 政策提言と運用指針
Internet standards have generally been concerned with the technical
specifications for hardware and software required for computer
communication across interconnected networks. The Internet itself
is composed of networks operated by a great variety of
organizations, with diverse goals and rules. However, good user
service requires that the operators and administrators of the
Internet follow some common guidelines for policies and operations.
While these guidelines are generally different in scope and style
from protocol standards, their establishment needs a similar
process for consensus building. Specific rules for establishing
policy recommendations and operational guidelines for the Internet
in an open and fair fashion should be developed, published, and
adopted by the Internet community.
ハードウェアのための技術仕様書にインターネット標準を一般に心配させました、そして、ソフトウェアがコンピュータコミュニケーションに相互接続ネットワークの向こう側に必要です。 インターネット自体はさまざまな組織によって経営されたネットワークでさまざまの目標と規則で構成されます。 しかしながら、良いユーザサービスは、インターネットのオペレータと管理者が方針と操作のためのいくつかの一般的なガイドラインに従うのを必要とします。 これらのガイドラインはプロトコル標準からの範囲とスタイルにおいて一般に異なっていますが、彼らの設立は合意形成のための同様の過程を必要とします。 制定方針推薦のための特定の規則と開いていて公正なファッションによるインターネットのための運用指針は、インターネットコミュニティによって開発されて、発表されて、採用されるべきです。
o Industry Consortia
o 産業コンソーシアム
The rules presented in Section 4 for external standards should be
expanded to handle industry consortia.
外部の規格のためにセクション4に提示された規則は、産業コンソーシアムを扱うために広げられるべきです。
o Tracking Procedure
o 追跡手順
It has been suggested that there should be a formal procedure for
tracking problems and change requests as a specification moves
through the standards track. Such a procedure might include
written responses, which were cataloged and disseminated, or simply
a database that listed changes between versions. At the present
time, there are not sufficient resources to administer such a
procedure.
仕様が標準化過程を通って動くので問題点の追跡と変更要求のための正式手順があるべきであると示唆されました。 そのような手順は文書による回答か単にバージョンの間の変化を記載したデータベースを含むかもしれません。(文書による回答は、カタログに載せられて、広められました)。 現在には、そのような手順を管理できるくらいのリソースがありません。
A simpler proposal is to keep a change log for documents.
より簡単な提案はドキュメントのためのチェンジログを保つことです。
IAB - IESG [Page 36] RFC 1602 Internet Standards Process March 1994
IAB--IESG[36ページ]RFC1602インターネット規格は1994年3月に処理されます。
o Time Limit
o タイムリミット
An explicit time limit (e.g., 3 months) has been suggested for IESG
resolution concerning a standards action under the rules of Section
3.1.2. If it were necessary to extend the time for some reason,
the IETF would have to be explicitly notified.
明白なタイムリミット(例えば、3カ月)はIESG解決のために規格動作に関してセクション3.1.2の規則の下で示されました。 それがある理由で期間を延長するのに必要であるなら、IETFは明らかに通知されなければならないでしょうに。
o Bug Reporting
o バグレポート
There is no documented mechanism for an individual community member
to use to report a problem or bug with a standards-track
specification. One suggestion was that every standards RFC should
include an email list for the responsible Working Group.
個々の共同体のメンバーが標準化過程仕様で問題かバグを報告するのに使用する記録されたメカニズムが全くありません。 1つの提案はあらゆる規格RFCが責任がある作業部会のためのメールリストを含んでいるはずであるということでした。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Authors' Addresses
作者のアドレス
Christian Huitema, IAB Chairman INRIA, Sophia-Antipolis 2004 Route des Lucioles BP 109 F-06561 Valbonne Cedex France
クリスチャンのHuitema、IAB委員長INRIA、2004台のソフィア-Antipolis Route desルシオールBP109F-06561Valbonne Cedexフランス
Phone: +33 93 65 77 15
以下に電話をしてください。 +33 93 65 77 15
EMail: Christian.Huitema@MIRSA.INRIA.FR
メール: Christian.Huitema@MIRSA.INRIA.FR
Phill Gross, IESG Chairman Director of Broadband Engineering MCI Data Services Division 2100 Reston Parkway, Room 6001 Reston, VA 22091
フィルGross、事業部2100レストンパークウェイ、余地の6001レストン、広帯域の工学MCIデータServicesヴァージニア 22091歳のIESGディレクター議長
Phone: +1 703 715 7432 Fax: +1 703 715 7436 EMail: 0006423401@mcimail.com
以下に電話をしてください。 +1 703 715、7432Fax: +1 7436年の703 715メール: 0006423401@mcimail.com
IAB - IESG [Page 37]
IAB--IESG[37ページ]
一覧
スポンサーリンク
