RFC1310 日本語訳
1310 The Internet Standards Process. L. Chapin. March 1992. (Format: TXT=54738 bytes) (Obsoleted by RFC1602) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Internet Activities Board
Request for Comments: 1310 Lyman Chapin, Chair
March 1992
委員会がコメントのために要求するワーキンググループインターネット活動をネットワークでつないでください: 1310 ライマン・チェーピン、1992年の議長March
The Internet Standards Process
インターネット標準化過程
Status of this Memo
このMemoの状態
This informational memo presents the current procedures for creating and documenting Internet Standards. Distribution of this memo is unlimited.
この情報のメモはインターネットStandardsを作成して、記録するための現在の手順を提示します。 このメモの分配は無制限です。
TABLE OF CONTENTS
目次
1. INTRODUCTION ................................................. 2
1.1. Internet Standards ....................................... 2
1.2. Organization ............................................. 3
2. THE INTERNET STANDARDS PROCESS ............................... 4
2.1. Introduction ............................................. 4
2.2. The Internet Standards Track ............................. 5
2.3. Requests for Comments (RFCs) ............................. 5
2.4. Internet Drafts .......................................... 6
2.5. Internet Assigned Number Authority (IANA) ................ 7
2.6. Review and Approval ...................................... 8
2.7. Entering the Standards Track ............................. 9
2.8. Advancing in the Standards Track ......................... 9
2.9. Revising a Standard ...................................... 10
3. NOMENCLATURE ................................................. 10
3.1 Types of Specifications .................................. 10
3.2 Standards Track Maturity Levels .......................... 12
3.3 Non-Standards Track Maturity Levels ...................... 13
3.4 Requirement Levels ....................................... 14
4. EXTERNAL STANDARDS AND SPECIFICATIONS ........................ 15
5. INTELLECTUAL PROPERTY RIGHTS ................................. 17
6. PATENT POLICY ................................................ 17
6.1 Statement from Patent Holder ............................. 18
6.2 Record of Statement ...................................... 18
6.3 Notice ................................................... 18
6.4 Identifying Patents ...................................... 19
7. ACKNOWLEDGMENTS AND REFERENCES ............................... 19
APPENDIX A: GLOSSARY ............................................. 20
APPENDIX B: UNRESOLVED ISSUES .................................... 21
Security Considerations .......................................... 23
Author's Address ................................................. 23
1. 序論… 2 1.1. インターネット規格… 2 1.2. 組織… 3 2. インターネット規格は処理されます… 4 2.1. 序論… 4 2.2. インターネット規格は追跡されます… 5 2.3. コメント(RFCs)を求める要求… 5 2.4. インターネット草稿… 6 2.5. ISOCの機関の一つで(IANA)… 7 2.6. レビューと承認… 8 2.7. 規格を入れて、追跡してください… 9 2.8. 規格で進んで、追跡してください… 9 2.9. 規格を改訂します… 10 3. 用語体系… 10 3.1のタイプの仕様… 10 3.2の規格が成熟レベルを追跡します… 12 3.3 非標準化過程成熟レベル… 13 3.4 要件レベル… 14 4. 外部の規格と仕様… 15 5. 知的所有権はまっすぐになります… 17 6. 方針の特許をとってください… 17 特許所有権者からの6.1声明… 18 声明に関する6.2記録… 18 6.3 注意してください… 18 6.4 特許を特定します… 19 7. 承認AND参照… 19 付録A: 用語集… 20 付録B: 未定の問題… 21 セキュリティ問題… 23作者のアドレス… 23
IAB [Page 1] RFC 1310 Internet Standards Process March 1992
IAB[1ページ]RFC1310インターネット規格は1992年3月に処理されます。
1. INTRODUCTION
1. 序論
1.1 Internet Standards
1.1 インターネット規格
This memo documents the process currently used for the
standardization of Internet protocols and procedures.
このメモは現在インターネットプロトコルと手順の標準化に使用されている過程を記録します。
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, that
are not connected to the Internet but use the Internet Standards.
The architecture and technical specifications of the Internet are
the result of numerous research and development activities
conducted over a period of two decades, performed by the network
R&D community, by service and equipment vendors, and by government
agencies around the world.
インターネット(自治の、そして、インタコネクトされたネットワークの緩く組織化された国際協力)は、インターネットStandardsによって定義されたプロトコルと手順を開くために自発的の固守でホスト間通信を支持します。 また、多くの孤立しているインターネット、すなわち、インターネットに関連づけられませんが、インターネットStandardsを使用する相互接続ネットワークのセットがあります。 インターネットに関する構造と技術仕様書はネットワーク研究開発共同体によって実行された20年間の期間にわたってサービスと設備業者、および世界中の政府機関によって行われた頻繁な研究開発活動の結果です。
In general, an Internet Standard is a specification that is stable
and well-understood, is technically competent, has multiple,
independent, and interoperable implementations with operational
experience, enjoys significant public support, and is recognizably
useful in some or all parts of the Internet.
一般に、インターネットStandardは安定した仕様であり、よく分かって、技術的に有能であり、運用経験による複数の、そして、独立していて、共同利用できる実現を持って、重要な公的支援を楽しんで、インターネットのいくつかかすべての地域で認識可能に役に立ちます。
The principal set of Internet Standards is commonly known as the
"TCP/IP protocol suite". As the Internet evolves, new protocols
and services, in particular those for Open Systems Interconnection
(OSI), have been and will be deployed in traditional TCP/IP
environments, leading to an Internet that supports multiple
protocol suites. This document concerns all protocols,
procedures, and conventions used in the Internet, not just the
TCP/IP protocols.
インターネットStandardsの主要なセットは「TCP/IPプロトコル群」として一般的に知られています。 インターネットが発展するとき、新しいプロトコルとサービス(オープン・システム・インターコネクション(OSI)のための特にそれら)は、あって、伝統的なTCP/IP環境で配備されるでしょう、複数のプロトコル群を支えるインターネットに通じて。 このドキュメントはTCP/IPプロトコルだけではなく、インターネットで用いられたすべてのプロトコル、手順、およびコンベンションに関係があります。
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
perhaps revision based upon experience, is adopted as a Standard
by the appropriate body (see below), and is published.
アウトラインでは、インターネットStandardを作成する過程は簡単です: 仕様は、インターネットコミュニティと恐らく経験に基づく改正で開発の一区切りとレビューのいくつかの繰り返しを受けて、Standardとして適切なボディー(以下を見る)によって採用されて、発表されます。
In practice, the process is somewhat more complicated, due to (1)
the number and type of possible sources for specifications; (2)
the need to prepare and revise a specification in a manner that
preserves the interests of all of the affected parties; (3) the
importance of establishing widespread community agreement on its
technical content; and (4) the difficulty of evaluating the
utility of a particular specification for the Internet community.
実際には、過程は(1) 仕様のための可能なソースの数とタイプのためにいくらか複雑です。 (2) 影響を受けた当事者のすべての関心を保存する方法による仕様を準備して、改訂する必要性。 (3) 技術的な内容の広範囲の共同体協定を確立する重要性。 (4) そして、インターネットコミュニティのための特記仕様書に関するユーティリティを評価するという困難。
IAB [Page 2] RFC 1310 Internet Standards Process March 1992
IAB[2ページ]RFC1310インターネット規格は1992年3月に処理されます。
Some specifications that are candidates for Internet
standardization are the result of organized efforts directly
within the Internet community; others are the result of work that
was not originally organized as an Internet effort, but which was
later adopted by the Internet community.
インターネット標準化の候補であるいくつかの仕様がインターネットコミュニティの直接中の組織化された努力の結果です。 他のものは元々、インターネットの努力として組織化されませんでしたが、後でインターネットコミュニティによって採用された仕事の結果です。
From its inception, the Internet has been, and is expected to
remain, an evolving system whose participants regularly factor new
requirements and technology into the design and implementation of
the global Internet. Users of the Internet and providers of the
equipment, software, and services that support it should
anticipate and embrace this adaptability 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 improvement in these
procedures.
本書では説明された手順は成長とますます多様なインターネットコミュニティの必要性、および経験で運転された3年間の発展の結果です。 コメントと提案はこれらの手順における改良に招待されます。
1.2 Organization
1.2 組織
The Internet Activities Board (IAB) is the primary coordinating
committee for Internet design, engineering, and management [1].
The IAB has delegated to its Internet Engineering Task Force
(IETF) the primary responsibility for the development and review
of potential Internet Standards from all sources. The IETF forms
Working Groups to pursue specific technical issues, frequently
resulting in the development of one or more specifications that
are proposed for adoption as Internet Standards.
インターネットActivities Board(IAB)はインターネットデザイン、工学、および管理[1]のための第一の協調委員会です。 IABはすべてのソースから潜在的インターネットStandardsの開発とレビューへの責務をインターネット・エンジニアリング・タスク・フォース(IETF)へ代表として派遣しました。 IETFは特定の専門的な問題を追求するためにWorking Groupsを形成します、頻繁に採用のためにインターネットStandardsとして提案される1つ以上の仕様の開発をもたらして。
Final decisions on Internet standardization are made by the IAB,
based upon recommendations from the Internet Engineering Steering
Group (IESG), the leadership body of the IETF. IETF Working
Groups are organized into areas, and each area is coordinated by
an Area Director. The Area Directors and the IETF Chairman are
included in the IESG.
インターネット標準化の最終決定はIABによってされます、インターネットEngineering Steering Group(IESG)(IETFのリーダーシップボディー)から推薦に基づきます。 IETF Working Groupsは領域に組織化されます、そして、各領域はAreaディレクターによって調整されます。 AreaディレクターとIETF委員長はIESGに含まれています。
Any member of the Internet community with the time and interest is
urged to attend IETF meetings and to participate actively in one
or more IETF Working Groups. 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; most IETF members agree that the greatest
benefit for all members of the Internet community results from
cooperative development of technically superior protocols and
services.
IETFミーティングに出席して、時間と関心を伴うインターネットコミュニティのどんなメンバーも1IETF Working Groupsで活躍するよう促されます。 参加が組織の公式代表よりむしろ個々の技術貢献者のそばにあります。 IETF Working Groupsが高度の技術的成熟度と同様に共同の精神を表示するので、過程は利きます。 ほとんどのIETFメンバーが、インターネットコミュニティのすべてのメンバーのための最もすばらしい利益が技術的に優れたプロトコルの、そして、サービスの共同開発から生じるのに同意します。
IAB [Page 3] RFC 1310 Internet Standards Process March 1992
IAB[3ページ]RFC1310インターネット規格は1992年3月に処理されます。
A second body under the IAB, the Internet Research Task Force
(IRTF), 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, it is processed through the IETF.
IABの下の2番目のボディー(インターネットResearch Task Force(IRTF))は、インターネット標準化の対象になるように不確実過ぎるか、高度過ぎるか、または不十分によく理解されていると考えられた話題を、調査します。 IRTF活動がインターネット標準化のために考えられるのにおいて十分安定した仕様を発生させるとき、それはIETFを通して処理されます。
Section 2 of this document describes the process and rules for
Internet standardization. Section 3 presents the nomenclature for
different kinds and levels of Internet standard technical
specifications and their applicability. Section 4 defines how
relevant externally-sponsored specifications and practices that
are developed and controlled by other bodies or by vendors are
handled in the Internet standardization process. Section 5
presents the requirement for prior disclosure of the existence of
intellectual property rights. Section 6 describes the rules for
Internet Standards that involve patents.
このドキュメントのセクション2はインターネット標準化のための過程と規則について説明します。 セクション3はインターネット標準技術仕様書と彼らの適用性の異種とレベルのために用語体系を提示します。 セクション4は関連外部的に後援された仕様と他のボディーか業者によって開発されて、制御される習慣がインターネット標準化過程でどう扱われるかを定義します。 セクション5は知的所有権の存在の先の公開のための要件を提示します。 セクション6は特許にかかわるインターネットStandardsのために規則について説明します。
2. THE INTERNET STANDARDS PROCESS
2. インターネット標準化過程
2.1. Introduction
2.1. 序論
The procedures described in this document are intended to provide
a clear, open, and objective basis for developing, evaluating, and
adopting Internet Standards for protocols and services. The
procedures provide ample opportunity for participation and comment
by all interested parties. Before an Internet Standard is
adopted, it is repeatedly discussed (and perhaps debated) in open
open meetings and/or public electronic mailing lists, and it is
available for review via world-wide on-line directories.
本書では説明された手順が展開する明確で、開いていて、客観的な基礎を提供することを意図します、プロトコルとサービスのためにインターネットStandardsを評価して、採用して。 手順は参加の十分な機会と関係者一同によるコメントを提供します。 インターネットStandardが採用される前に、開いている公開の会議、そして/または、公共のメーリング・リストで繰り返してそれについて議論します、そして、(そして、恐らく討論されます)レビューに、世界的なオンラインディレクトリで、利用可能です。
These procedures are explicitly aimed at developing and adopting
generally-accepted practices. Thus, a candidate for Internet
standardization 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.
これらの手順は明らかに一般に慣例を開発して、採用するのを目的とされます。 したがって、インターネット標準化の候補は、正しい操作と相互運用性がないかどうか複数の、そして、独立しているパーティーによって実行されて、テストされて、ますます環境を要求する際に利用されます、インターネットStandardとしてそれを採用できる前に。
The procedures that are described here provide a great deal of
flexibility to adapt to the wide variety of circumstances that
occur in the Internet standardization process. Experience has
shown this flexibility to be vital in achieving the following
goals for Internet standardization:
ここで説明される手順は、インターネット標準化過程で現れる広いバラエティーの事情に順応するために多くの柔軟性を提供します。 経験は、この柔軟性がインターネット標準化の以下の目標を達成するのにおいて重大であることを示しました:
IAB [Page 4] RFC 1310 Internet Standards Process March 1992
IAB[4ページ]RFC1310インターネット規格は1992年3月に処理されます。
* high quality,
* 高品質
* prior implementation and testing,
* 先の実現とテスト
* openness and fairness, and
* そして風通しの良さと公正である。
* timeliness.
* タイムリー。
2.2. The Internet Standards Track
2.2. インターネット標準化過程
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で定義されます。
2.3. Requests for Comments (RFCs)
2.3. コメントを求める要求(RFCs)
Each distinct version of a specification is published as part of
the "Request for Comments" (RFC) document series.
仕様のそれぞれの異なったバージョンは「コメントを求める要求」(RFC)ドキュメントシリーズの一部として発行されます。
RFCs form a series of publications of networking technical
documents, begun in 1969 as part of the original DARPA 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 to status memos about the
Internet. The IAB views the RFC publication process to be
sufficiently important to warrant including the RFC Editor in the
IAB membership.
RFCsは1969年にオリジナルのDARPA広い領域ネットワーク(アルパネット)プロジェクトの一部として始められたネットワーク技術文献の一連の刊行物を形成します(頭文字語の用語集に関してAppendix Aを見てください)。 RFCsは新しい研究概念の早めの議論からインターネットに関する状態メモまでさまざまな話題をカバーしています。 IABは、IAB会員資格にRFC Editorを含んでいるのを保証できるくらい重要になるようにRFC公表の過程を見ます。
The status of specifications on the Internet standards track is
summarized periodically in a summary RFC entitled "IAB Official
Protocol Standards" [2]. This RFC shows the level of maturity and
other helpful information for each Internet protocol or service
specification.
インターネット標準化過程に関する仕様の状態は概要RFC題している「IABの公式のプロトコル標準」[2]に定期的にまとめられます。 このRFCはそれぞれのインターネットプロトコルかサービス仕様のための円熟と他の役立つ情報のレベルを示しています。
IAB [Page 5] RFC 1310 Internet Standards Process March 1992
IAB[5ページ]RFC1310インターネット規格は1992年3月に処理されます。
********************************************************
* The "IAB Official Protocol Standards" RFC is the *
* authoritative statement of the status of any *
* particular Internet specification, *
********************************************************
******************************************************** * 「IABの公式のプロトコル標準」RFCはどんな**特定のインターネット仕様の状態の**権威ある声明です、*********************************************************
and it is the "Publication of Record" with respect to Internet
standardization.
そして、それはインターネット標準化に関する「記録の公表」です。
The STD documents form a subseries of the RFC series. When a
specification has been adopted as a Standard, its RFC is labeled
with a STDxxx number [9] in addition to its RFC number.
STDドキュメントはRFCシリーズの「副-シリーズ」を形成します。 仕様がStandardとして採用されたとき、RFCはRFC番号に加えたSTDxxx番号[9]でラベルされます。
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. These RFCs will be
marked as "Experimental" or "Informational" (see section 3.3).
すべてのインターネットのためのプロトコルの、または、サービスの仕様が、なるべきであるというわけではありませんし、またインターネットStandardsになるというわけではないでしょう。 そのような非標準化過程仕様はインターネット標準化のための規則を受けることがありません。 一般に、それらは直接RFCsとしてRFCエディタの裁量で発行されるでしょう。 これらのRFCsは「実験的である」か「情報」としてマークされるでしょう(セクション3.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 *
* Standard. *
********************************************************
******************************************************** * すべてのRFCs**がどんな標準化過程ドキュメントであり、**規格のレベルに達しないのをすべての**標準化過程ではなく、それが、記録する覚えているのは重要です。 * ********************************************************
2.4. Internet Drafts
2.4. インターネット草稿
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の「インターネット草稿」ディレクトリにそれらを置くことによって非公式のレビューとコメントに利用可能にします。 これで、レビューと改正のプロセスを容易にして、発展の働くドキュメントは広い聴衆には容易に利用可能になります。
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.
作者と認識力がある作業部会の満足への完成の後に、インターネット標準化過程で入るか、または進むと予想されるドキュメントを、インターネットDraftとして利用可能にするものとします。 それはしばらく役に立つ共同体が見直すその許可証、少なくとも2週間インターネットDraftとして残っているものとします、IESGへの服従の前に。
An Internet Draft that is published as an RFC is removed from the
Internet Draft directory. A document 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
RFCとして発行されるインターネットDraftはインターネットDraftディレクトリから取り外されます。 公表のためにIESGによるお勧めであることのない6カ月以上RFCとしてインターネットDraftsディレクトリで変わりがなかったドキュメントはインターネットDraftディレクトリから単に取り外されます。 何時でも
IAB [Page 6] RFC 1310 Internet Standards Process March 1992
IAB[6ページ]RFC1310インターネット規格は1992年3月に処理されます。
Internet Draft may be replace by a more recent version of the same
specification, restarting the six-month timeout period.
インターネットDraftは6カ月のタイムアウト時間を同じ仕様、再開の、より最近のバージョンに取り替えることであるかもしれません。
An Internet Draft is NOT a means of "publishing" a specification;
specifications are published through the RFC mechanism described
in the next section. Internet Drafts have no formal status, and
are not part of the permanent archival record of Internet
activity, and they are subject to change or removal at any time.
Under no circumstances should an Internet Draft be referenced by
any paper, report, or Request for Proposal.
インターネットDraftは仕様の「発行」である手段ではありません。 仕様は次のセクションで説明されたRFCメカニズムを通して発表されます。 インターネットDraftsはどんな正式な状態も持たないで、またインターネット活動の永久的な履歴の一部ではありません、そして、彼らはいつでも、変化か取り外しを被りやすいです。 紙、レポート、またはいずれのもRequestがProposalのためにインターネットDraftに決して、参照をつけるはずがありません。
2.5. Internet Assigned Number Authority (IANA)
2.5. 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" [8].
多くのプロトコル仕様が唯一割り当てなければならない数、キーワード、および他のパラメタを含んでいます。 例はバージョン番号、プロトコル番号、ポートナンバー、およびMIB番号を含んでいます。 IABはインターネットAssigned民数記Authority(IANA)へのインターネットのためのそのようなプロトコルパラメタを割り当てるタスクを代表として派遣しました。 IANAは「規定番号」[8]と題をつけられたRFCsのすべての現在割り当てられた数とパラメタのテーブルを発行します。
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.
規定番号の各カテゴリは標準化過程の上にあるか、インターネット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 guess the next unassigned value of a
parameter; both are hazardous.
カオスがパラメタ値の偶然の闘争から生じるかもしれないので、私たちは、あらゆるプロトコルパラメタが公共の、または、個人的な用法のためにIANAによって明らかに割り当てられるよう促します。 個人的なプロトコルはしばしば公共になります。 しばしば「無作為」の値を選ぶか、またはプログラマがパラメタの次の割り当てられなかった値を推測するように誘惑されます。 両方が危険です。
The IANA is tasked 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ページ)の短い記事が課題にまだ必要です。
To contact the IANA for information or to request a number,
情報のためにIANAに連絡するか、または数を要求するために
IAB [Page 7] RFC 1310 Internet Standards Process March 1992
IAB[7ページ]RFC1310インターネット規格は1992年3月に処理されます。
keyword or parameter assignment send an email message to
"iana@isi.edu".
キーワードかパラメタ課題が" iana@isi.edu "にメールメッセージを送ります。
2.6. Review and Approval
2.6. レビューと承認
A standards action -- entering a particular specification into, or
advancing it within, the standards track -- shall be recommended
to the appropriate IETF Area Director, or to the Chairman of the
IETF, by the individual or group that is responsible for the
specification. Usually, the recommendation will come from an IETF
Working Group. The Area Director or IETF chairman, in
consultation with the IESG, shall determine if an independent
technical review of the specification is required, and shall
commission one if necessary.
規格動作(標準化過程の中で特記仕様書を入力するか、またはそれを進める)は適切なIETF Areaディレクター、または、IETFの委員長に推薦されるものとします、仕様に責任がある個人かグループで。 通常、推薦はIETF作業部会から来るでしょう。 IESGとの相談では、AreaディレクターかIETF議長が、仕様の独立している技術審査が必要であり、必要なら、1つを任命するだろうかどうかと決心しているものとします。
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 a special 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. Furthermore, when the criteria for
advancement along the standards track for an important class of
specifications (e.g., routing protocols [6]) are not universally
recognized, the IESG shall commission the development and
publication of category-specific acceptance criteria.
仕様がインターネットの上、または、インターネットプロトコルのスイートの上で可能性のある衝撃で十分重要であるときに、IESGは、仕様の評価を準備するために特別なレビューと分析委員会を形成するものとします。 そのような委員会が仕様が前進の準備ができているというインターネットコミュニティの中の協定に使途別分類を提供するように任命されます。 その上、規格に沿った前進の評価基準であるときには重要なクラスの仕様のために追跡してください。(例えばルーティング・プロトコル[6])は一般に認識されないで、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) and shall communicate its findings to
the IETF to permit a final review by the general Internet
community. This IETF notification shall be via electronic mail to
the IETF mailing list; in addition, there will often 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.
IESGは、仕様がお勧めの動作の適用基準を満たすかどうか(このドキュメントのセクション3.2と3.3を見てください)決定して、一般的なインターネットコミュニティで最終審査を可能にするために調査結果をIETFに伝えるものとします。 IETFメーリングリストへの電子メールを通してこのIETF通知はあるものとします。 さらに、適切なワーキンググループかAreaディレクターによるプレゼンテーションか声明がIETF全体会議の間、しばしばあるでしょう。 仕様の開発の間に満足に解決されていないどんな重要な問題もこのとき、最終的な解決のためにIESGによって提起されるかもしれません。
The IESG shall communicate to the IAB its recommendation for
action, with a citation to the most current version of the
document. The IETF shall be notified by email of any such
recommendation. If the IAB finds a significant problem, or needs
clarification on a particular point, it shall resolve the matter
with the Working Group and its chairperson and/or the document
author, with the assistance and concurrence of the IESG and the
relevant IETF Area Director.
IESGは動作のための推薦をIABに伝えるものとします、ドキュメントの最新版への引用で。 どんなそのような推薦のメールでもIETFは通知されるものとします。 IABが重大な問題を見つけるか、または特定のポイントの上で明確化を必要とするなら、作業部会と議長、そして/または、ドキュメント作者の問題を解決するものとします、IESGで支援と合意と関連IETF Areaディレクターと共に。
IAB [Page 8] RFC 1310 Internet Standards Process March 1992
IAB[8ページ]RFC1310インターネット規格は1992年3月に処理されます。
Following IAB 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.
IAB承認とどんな必要な編集の仕事にも続いて、RFC EditorはRFCとして仕様を発表するものとします。 そして、仕様はインターネットDraftsディレクトリから取り除かれるものとします。
2.7. Entering the Standards Track
2.7. 標準化過程に入ります。
A specification that is potentially an Internet Standard may
originate from:
潜在的にインターネットStandardである仕様は以下から起因するかもしれません。
(a) an IAB-sponsored effort (typically an IETF Working Group),
(a) IABによって後援された取り組み(通常IETF作業部会)
(b) independent activity by individuals, or
または(b) 個人による独立している活動。
(c) an external organization.
(c) 外部の組織。
In cases (b) and (c), the work might be tightly integrated with
the work of an existing IETF Working 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 context will be submitted to an
appropriate Working Group for evaluation and refinement; if
necessary, an appropriate Working Group will be created.
場合(b)と(c)では、仕事が既存のIETF作業部会の仕事についてしっかり統合しているかもしれませんか、または標準化のために先の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. 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ディレクターが外部仕様のレビューがどんなであるも何であるかを必要な状態で決心する責任とそれがどう行われるものとするかということです。
2.8. Advancing in the Standards Track
2.8. 標準化過程で、進みます。
A specification shall remain at the Proposed Standard level for at
least 6 months and at the Draft Standard level for at least 4
months.
仕様は少なくとも4カ月少なくとも6カ月とDraft StandardレベルにおけるProposed Standardレベルに残るものとします。
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, and they will
not affect advancement through the standards track. A significant
revision may require that the specification accumulate more
仕様がそうである、(本当に、ありそうである、)、標準化過程を通って進むので、復習しました。 そして、必要なら、各段階で、IESGは改正の範囲と意味を仕様に決定するものとします、そして、適切であることで、お勧めの動作を変更してください。 小さい方の改正は予想されます、そして、それらは標準化過程を通る前進に影響しないでしょう。 重要な改正は、仕様がさらに蓄積するのを必要とするかもしれません。
IAB [Page 9] RFC 1310 Internet Standards Process March 1992
IAB[9ページ]RFC1310インターネット規格は1992年3月に処理されます。
experience at its current maturity level before progressing.
Finally, if the specification has been changed very significantly,
the IESG may decide to treat the revision as if it were a new
document, re-entering the standards track at the beginning.
進歩をする前の現在の成熟レベルの経験。 最終的に、仕様を非常にかなり変えたなら、IESGは、まるでそれが新しいドキュメントであるかのように改正を扱うと決めるかもしれません、始めに標準化過程に再入して。
A specification that has not reached the maturity level of
Standard within twenty-four months of first becoming a Proposed
Standard shall be reviewed for viability by the IESG, which shall
recommend either termination or continuation of the development
effort to the IAB. Such a recommendation 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 legitimate and active Working Group
efforts, but rather to provide an administrative mechanism for
terminating a moribund effort.
最初にの24カ月以内にProposed StandardになりながらStandardの成熟レベルに達していない仕様は生存力のためにIESGによって再検討されるものとします。(IESGは開発努力の終了か継続のどちらかをIABに推薦するものとします)。 そのような推薦は、コメントする機会をインターネットコミュニティに許容するためにIETFメーリングリストへの電子メールを通してIETFに伝えられるものとします。 正統の、そして、アクティブな作業部会取り組みを脅かすことを意図するのではなく、この支給は、むしろ瀕死の取り組みを終えるのに管理機構を提供するために意図します。
2.9. Revising a Standard
2.9. 規格を改訂します。
A recommendation to revise an established Internet Standard shall
be evaluated by the IESG with respect to the operational impact of
introducing a new version while the previous version is still in
use. If the IESG accepts the recommendation, the new version must
progress through the full Internet standardization process as if
it were a completely new specification.
確立したインターネットStandardを改訂するという推薦は旧バージョンがまだ使用中である間、新しいバージョンを紹介する操作上の影響に関してIESGによって評価されるものとします。 IESGが推薦を受け入れるなら、新しいバージョンはまるでそれが完全に新しい仕様であるかのように完全なインターネット標準化過程で進歩をしなければなりません。
Once the new version has reached the Standard level, it may
immediately replace the previous version. In some cases, both
versions may remain as Internet Standards to honor the
requirements of an installed base; however, 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 3.1.2).
新しいバージョンがいったんStandardレベルに達すると、それはすぐに、旧バージョンを置き換えるかもしれません。 いくつかの場合、両方のバージョンはインストールされたベースの要件を光栄に思うためにインターネットStandardsとして残るかもしれません。 しかしながら、新しいバージョンのテキストか別の適切なドキュメントに明らかに前のバージョンと新しいバージョンとの関係を述べなければなりません(例えば、Applicability Statement; セクション3.1.2を見てください)。
3. NOMENCLATURE
3. 用語体系
3.1. Types of Specifications
3.1. 仕様のタイプ
The specifications subject to the Internet standardization process
fall into two categories: Technical Specifications (TS) and
Applicability Statements (AS).
インターネット標準化過程を条件とした仕様は2つのカテゴリになります: 仕様書(ts)と適用性証明(AS)。
3.1.1. Technical Specification (TS)
3.1.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
仕様書はプロトコル、サービス、手順、コンベンション、または形式のあらゆる記述です。 それが対象の関連局面のすべてについて完全に説明するかもしれませんか、またはそれは1つ以上のパラメタかオプションを不特定のままにするかもしれません。 TSが完全に自己充足的であるかもしれませんか、またはそれは材料を組み込むかもしれません。
IAB [Page 10] RFC 1310 Internet Standards Process March 1992
IAB[10ページ]RFC1310インターネット規格は1992年3月に処理されます。
from other specifications by reference to other documents
(which may or may not be Internet Standards).
他のドキュメントの参照(インターネット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によって定義されます。
3.1.2. Applicability Statement (AS)
3.1.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
particular class of Internet systems [3,4,5], such as Internet
routers or Internet hosts.
ASの最も広いタイプは一般的に「要件ドキュメント」と呼ばれる、包括的な順応仕様です、特定のクラスのインターネット・システム[3、4、5]のために、インターネットルータやインターネット・ホストのように。
An AS may not have a higher maturity level in the standards
track than any 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 an AS at the
Standard level. Like a TS, an AS does not come into effect
until it reaches Standard level.
ASは標準化過程にASが適用するどんなTSよりも高い成熟レベルを持っていないかもしれません。 例えば、Draft StandardレベルにおけるTSはStandardレベルにおけるASではなく、Proposed StandardかDraft StandardレベルにおけるASによって参照をつけられるかもしれません。 TSのように、Standardレベルに達するまで、ASは実施しません。
Although TSs and ASs are conceptually separate, in practice an
Internet Standard RFC may include elements of both an AS and one
or more TSs in a single document. For example, Technical
Specifications that are developed specifically and exclusively for
some particular domain of applicability, e.g., for mail server
TSsとASsは概念的に別々ですが、実際には、インターネットStandard RFCはただ一つのドキュメントにASと1TSsの両方の要素を含むかもしれません。 例えば特に、そして、排他的な何らかの特定の適用領域、例えば、メールサーバのために開発される仕様書
IAB [Page 11] RFC 1310 Internet Standards Process March 1992
IAB[11ページ]RFC1310インターネット規格は1992年3月に処理されます。
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.
ホストはただ一つの仕様の中にしばしば関連ASとTS情報のすべてを含んでください。 そのような場合、ただ正式なAS/TS区別を保存するために故意にいくつかのドキュメントに情報を分配することによって、どんな役に立つ目的も役立たれないでしょう。 しかしながら、1つ以上の適用領域に適用しそうなTSは、複数のASsによる編入を容易にするためにモジュール方式で開発されるべきです。
3.2. Standards Track Maturity Levels
3.2. 標準化過程成熟レベル
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. The general
procedures for developing a specification and processing it
through the maturity levels along the standards track were
discussed in Section 2 above.
このセクションは各レベルで成熟レベルと仕様の予想された特性について説明します。 上のセクション2で標準化過程に沿った成熟レベルを通して仕様を開発して、それを処理するための基本手順について議論しました。
3.2.1. Proposed Standard
3.2.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.
標準化過程へのエントリーレベル円熟は「提案された標準」です。 Proposed Standard仕様は、一般に、安定していて、知られているデザイン選択を決議して、よく理解されていると信じられていて、重要な共同体レビューを受け取って、貴重であると考えることができるくらいの共同体関心を楽しむように見えます。
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. Furthermore, the IAB 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 in
the Experimental state (see below), which is not part of the
standards track, and moved to the standards track only after
sufficient implementation or operational experience has been
obtained.
通常、実装も運用経験も仕様の名称にProposed Standardとして必要ではありません。 しかしながら、そのような経験は、非常に望ましく、通常、Proposed Standard名称を支持して強い議論を表すでしょう。 その上、物質的にコアインターネットプロトコルに影響するか、またはインターネットで重要な操作上の影響を与えるかもしれない振舞いを指定する仕様への状態をProposed Standardに与える前に、IABは実装、そして/または、運用経験を必要とするかもしれません。 十分な実装か運用経験を得た後にだけ、そのような仕様を通常、初めはExperimental状態(以下を見る)で発表して、標準化過程に動かすでしょう。(状態は標準化過程の一部ではありません)。
A Proposed Standard should have no known technical omissions
with respect to the requirements placed upon it. In some
cases, the IESG may recommend that the requirements be
explicitly reduced in order to allow a protocol to advance into
Proposed Standardには、それに置かれた要件に関してどんな知られている技術的な省略もあるはずがありません。 いくつかの場合、IESGは、要件が進むプロトコルを許容するために明らかに減らされることを勧めるかもしれません。
IAB [Page 12] RFC 1310 Internet Standards Process March 1992
IAB[12ページ]RFC1310インターネット規格は1992年3月に処理されます。
the Proposed Standard state. This can happen if the
specification is considered to be useful and necessary (and
timely), even absent the missing features. For example, some
protocols have been advanced by explicitly deciding to omit
security features at the Proposed Standard level, since an
overall security architecture was still under development.
Proposed Standard状態。 なくなった特徴さえのない役に立つのと必要、そして、仕様が(タイムリー)であると考えられるなら、これは起こることができます。 例えば、Proposed Standardレベルにおけるセキュリティ機能を省略すると明らかに決めることによって、いくつかのプロトコルが唱えられました、総合的なセキュリティー体系がまだ開発中であったので。
3.2.2. Draft Standard
3.2.2. 草稿規格
A specification from which at least two independent and
interoperable implementations have been developed, and for
which adequate 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
demonstrate unforeseen behavior when subjected to large-scale
use in production environments.
意味論と実装を開発する基礎としてよく理解していなければならなくて、かなり安定しているのが知られているDraft Standard。 Draft Standardはまだ追加しているか、より広範囲の実地経験を必要としているかもしれません、Draft Standard仕様に基づく実装に、予期しない振舞いを実稼動環境における大規模な使用にかけられると示すのが可能であるので。
3.2.3. Standard
3.2.3. 規格
A specification for which significant implementation and
operational experience has been obtained may be elevated to the
Standard level. 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は特徴付けられます。
3.3. Non-Standards Track Maturity Levels
3.3. 非標準化過程成熟レベル
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. Such specifications are labeled with one of three
"non-standards track" maturity levels: "Historic", "Experimental",
and "Informational".
あらゆるTSかどんなASも標準化過程のそうであるというわけではありません。 それは、標準化過程に入る準備ができている状態でTSがインターネットStandardであることを意図しないかもしれませんか、最後の標準化のために意図しますが、またはやがて、意図するかもしれないというわけではありません。 TSかASが、より最近のインターネットStandardsによって取って代わられたか、そうでなければ、不要になったかもしれません、または疎んじてください。 そのような仕様は3「非標準化過程」成熟レベルの1つでラベルされます: 「歴史的」と、「実験的」と、「情報です」。
3.3.1. Historic
3.3.1. 歴史的
A TS or AS that has been superseded by a more recent
specification or is for any other reason considered to be
それが持っているTSかASは、より最近の仕様で取って代わられるか、または考えられたいかなる他の理由でもあります。
IAB [Page 13] RFC 1310 Internet Standards Process March 1992
IAB[13ページ]RFC1310インターネット規格は1992年3月に処理されます。
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.)
時代遅れ、「歴史的な」レベルに割り当てられます。 (純粋主義者は、単語が「歴史的であるべきである」と示唆しました; しかしながら、ここに、「歴史的」の使用は歴史的です。)
3.3.2. Experimental
3.3.2. 実験的
The "Experimental" designation on a TS permits widespread
dissemination (through publication according to the procedures
defined by this document) with explicit caveats: it may
specify behavior that has not been thoroughly analyzed or is
poorly understood; it may be subject to considerable change;
it may never be a candidate for the formal standards track;
and it may be discarded in favor of some other proposal.
TSにおける「実験的な」名称は明白な警告で広範囲の普及(このドキュメントによって定義された手順に従った公表を通した)を可能にします: それは徹底的に分析されなかった、また不十分に理解されていない振舞いを指定するかもしれません。 それは著しい変化を被りやすいかもしれません。 それは決して正規の標準規格道の候補でないかもしれません。 そして、それはある他の提案を支持して捨てられるかもしれません。
Any TS that is not an immediate candidate for Internet
standardization is appropriate for publication as Experimental.
Interested parties are thereby given the opportunity to gain
experience with implementations and to report their findings to
the community of interest, but the specification is explicitly
not recommended for general production use.
公表に、インターネット標準化の即座の候補でないどんなTSもExperimentalとして適切です。 その結果、実装と共に経験を積んで、それらの調査結果を利益共同体に報告する機会を利害関係者に与えますが、一般的な生産使用のために明らかに仕様を推薦しません。
3.3.3. Informational
3.3.3. 情報
An "Informational" specification is published for the general
information of the Internet community, and does not represent
an Internet community consensus or recommendation.
「情報」の仕様は、インターネットコミュニティの一般情報のために発行されて、インターネットコミュニティコンセンサスか推薦を表しません。
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. Such
a document is not an Internet Standard in any sense.
インターネットコミュニティの外で準備されて、セクション4に関する条項のいずれによってもインターネット標準化過程に組み入れられない仕様はInformational RFCsとして発表されるかもしれません、所有者の許可で。 そのようなドキュメントはどんな意味でインターネットStandardではありません。
3.4. Requirement Levels
3.4. 要件レベル
An AS may apply one of the following "requirement levels" to each
of the TSs to which it refers:
ASは以下の「要件レベル」の1つをそれが参照されるそれぞれのTSsに適用するかもしれません:
(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
(b)は推薦しました: 参照をつけられたTSの実装は最小量の順応に必要ではありませんが、経験、そして/または、一般に、受け入れられた技術上の知恵はASの適用領域に願わしさを示します。 そしてベンダーが機能、特徴を含んでいるよう強く奨励される。
IAB [Page 14] RFC 1310 Internet Standards Process March 1992
IAB[14ページ]RFC1310インターネット規格は1992年3月に処理されます。
protocols of Recommended TSs in their products, and should
omit them only if the omission is justified by some special
circumstance.
彼らの製品の中の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.5, 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.5に述べられるように、したがって、ないか、標準化過程から退職した、必要で、または標準化過程でお勧めでない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 "IAB 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.
「IABの公式のプロトコル標準」RFCは各TSのために一般的な要件レベルを記載します、このセクションで定義された用語体系を使用して。 多くの場合、特定のプロトコルの要件レベルとプロトコルの個々の特徴の、より詳細な記述は適切なASsで見つけられるでしょう。
4. EXTERNAL STANDARDS AND SPECIFICATIONS
4. 外部の規格と仕様
Many de facto and de jure standards groups other than the IAB/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.
IAB/IETF以外の多くの事実上の、そして、法律上の規格グループが、ネットワーク・プロトコルとサービスのための規格文書を作成して、発表します。 これらの外部仕様がインターネットで重要な役割を果たすとき、それらの用法で一般的な合意に達するのは望ましいです--すなわち、これらの外部仕様に関連するインターネットStandardsを証明するために。
There are two categories of external specifications:
外部仕様の2つのカテゴリがあります:
(1) Open Standards
(1) オープンスタンダード
Accredited national and international standards bodies, such as
公認の国家的、そして、国際的な標準化団体で、あれほどです。
IAB [Page 15] RFC 1310 Internet Standards Process March 1992
IAB[15ページ]RFC1310インターネット規格は1992年3月に処理されます。
ANSI, ISO, IEEE, and CCITT, develop a variety of protocol and
service specifications that are similar to Technical
Specifications (see glossary in Appendix A). These
specifications are generally de jure standards. Similarly,
national and international groups 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、およびCCITT)は仕様書と同様のさまざまなプロトコルとサービス仕様を開発します(Appendix Aの用語集を見てください)。 一般に、これらの仕様はデジュリスタンダードです。 同様に、国家的、そして、国際的なグループはApplicability Statementsに類似の「実装者間協定」を発行します、彼らの規格の実用化に関する実装時固有事項のボディーをキャプチャして。
(2) Vendor Specifications
(2) メーカー仕様
A vendor-specific specification that has come to be widely used
in the Internet may be treated by the Internet community as a de
facto "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. There are, however, 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" [7].
例えば、多くのインターネットStandardsが参照でANSI規格文字集合「ASCII」[7]を取り入れます。
(b) Incorporation of a Vendor Specification
(b) メーカー仕様の編入
Vendor-proprietary specifications may also be incorporated, by
reference to a specific version of the vendor standard. If the
vendor-proprietary specification is not widely and readily
available, the IAB may request that it be published as an
Informational RFC.
また、ベンダーメーカー独自仕様はベンダー規格の特定のバージョンの参照で取り入れられるかもしれません。 ベンダーメーカー独自仕様が広さと容易に利用可能でないなら、IABは、それがInformational RFCとして発行されるよう要求するかもしれません。
In order for a vendor-proprietary specification to be
incorporated within the Internet standards process, the
proprietor must agree in writing to the IAB that "right to use"
licenses will be available on a non-discriminatory basis and at
そして所有者が、ベンダーメーカー独自仕様がインターネット標準化過程の中に組み込んでいるためにそんなに「使用するために正しい」IABに書く際にライセンスが非差別しているベースで利用可能になるのに同意しなければならない。
IAB [Page 16] RFC 1310 Internet Standards Process March 1992
IAB[16ページ]RFC1310インターネット規格は1992年3月に処理されます。
a reasonable cost. See also Sections 5 and 6.
手頃な費用。 また、セクション5と6を見てください。
In addition, the IAB/IETF will generally not favor a particular
vendor's proprietary specification over the technically
equivalent and competing specifications of other vendors by
making it "required" or "recommended".
一般に、さらに、それが「必要である」、または「推薦されること」を作ることによって、IAB/IETFは他のベンダーの技術的に同等で競争している仕様より特定のベンダーのメーカー独自仕様を好まないでしょう。
(c) Assumption
(c) 仮定
An IETF Working Group may start with a vendor's (or other
body's) voluntarily contributed specification, and independently
evolve the specification into a TS or AS. Here "independently"
means that the IETF work is not constrained by conditions
imposed by the owner of the original specification; however,
the continued participation of the original owner in the IETF
work is likely to be valuable, and is encouraged. The IAB must
receive a formal delegation of responsibility from the original
owner that gives the IAB/IETF responsibility for evolution of
the specification.
IETF作業部会は、ベンダー(または、ボディーの他のもの)の自発的に寄付された仕様から始まって、独自にTSかASに仕様を発展するかもしれません。 ここの、「独自に」というIETFが扱う手段は正式仕様書の所有者によって課された状態によって抑制されません。 しかしながら、IETF仕事への最初の所有者の継続的な参加は、貴重であることがありそうであり、奨励されます。 IABは仕様の発展へのIAB/IETF責任を与える最初の所有者から責任の正式な委譲を受けなければなりません。
As provided by section 3.1.2, an AS that specifies how an external technical specification should be applied in the Internet, incorporating the external specification by reference, may become an Internet Standard.
セクション3.1.2提供するように、参照で外部仕様を取り入れて、外部の技術仕様書がインターネットでどう適用されるべきであるかを指定するASはインターネットStandardになるかもしれません。
5. INTELLECTUAL PROPERTY RIGHTS
5. 知的所有権
Prior to the approval of a specification as a Proposed Standard, all interested parties are required to disclose to the IAB the existence of any intellectual property right claims known to them that might apply to any aspect of the Proposed Standard.
Proposed Standardとしての仕様の承認の前に、関係者一同はそれらにおいて知られていて、それがProposed Standardのどんな局面にも適用されるかもしれないというどんな知的所有権クレームの存在もIABに明らかにしなければなりません。
This requirement refers specifically to disclosure of the *existence* of a current or anticipated claim of an intellectual property right, not the details of the asserted right itself.
この要件は特に断言された権利自体の詳細ではなく、知的所有権の現在の、または、予期されたクレームの*存在*の公開について言及します。
6. PATENT POLICY
6. 特許政策
This section is tentative, subject to legal review.
このセクションは法的なレビューを条件として一時的です。
There is no objection in principle to drafting an Internet Standard in terms that include an item or items subject to patent rights that may have been asserted in one or more countries, if it is considered that technical reasons justify this approach. In such cases the procedure described in this section shall be followed.
原則として1つ以上の国で主張されたかもしれない特許権を条件として項目か項目を含んでいる用語でインターネットStandardを作成することへの異論が全くありません、技術的な理由がこのアプローチを正当化すると考えられるなら。 そのような場合このセクションで説明された手順は従われるものとします。
IAB [Page 17] RFC 1310 Internet Standards Process March 1992
IAB[17ページ]RFC1310インターネット規格は1992年3月に処理されます。
6.1 Statement from Patent Holder
6.1 特許所有権者からの声明
Prior to approval of the specification as a Proposed Standard, the
IAB shall receive from the known patent holders, in a form
acceptable to and approved by the IAB, either (a) assurance in the
form of a general disclaimer to the effect that the patent holder
does not hold and does not anticipate holding any right that would
be violated as a consequence of conformance to the standard, or
(b) assurance that
Proposed Standardとしての仕様の承認の前に、IABによって許容できて承認されていた状態で、IABはフォームで知られている特許所有権者から受信するものとします、特許所有権者が、成立しないで、また順応の結果として規格、または(b)保証に違反されるどんな権利も保持すると予期しないという効果への一般的な注意書きの形におけるどちらかの(a)保証、それ
(1) a license will be made available without compensation to all
applicants desiring to utilize the patented items for the
purpose of implementing the standard, or
または(1) ライセンスを補償なしで規格を実行する目的に特許をとられた項目を利用することを望んでいるすべての応募者にとって利用可能にする。
(2) a license will be made available to applicants under
specified reasonable terms and conditions that are, to the
satisfaction of the IAB, demonstrably free of any unfair
discrimination.
(2) 指定された無理のない条件と条件のもとでライセンスを応募者にとって利用可能にするでしょう、IABの満足に、どんな不当な差別からも論証できて自由です。
The terms and conditions of any license falling under (1) or (2)
shall be submitted to the IAB for review, together with a
statement of the number of independent licenses, if any, that have
accepted or indicated their acceptance of the terms and conditions
of the license.
レビューのために(1)か(2)の下に下がるどんなライセンスに関する条件もIABに提出するものとします、もしあれば彼らのライセンスに関する条件の承認を受け入れるか、または示した独立しているライセンスの数の声明と共に。
In addition, the letter to the IAB must contain (c) assurance that
the patent holder does have the right to grant the license, and
(d) a notification of any other patent licenses that are required,
or else the assurance that no other licenses are required.
さらに、IABへの手紙は(c) 特許所有権者には必要であるいかなる他の特許ライセンスの通知、または他のライセンスが全く必要でないという保証もライセンス、および(d)に承諾する権利があるという保証を含まなければなりません。
6.2 Record of Statement
6.2 声明に関する記録
A record of the patent holder's statement (and a statement from
the IAB of the basis for considering such terms and conditions to
be free of any unfair discrimination) shall be placed and retained
in the files of the IAB.
特許所有権者の声明(そして、そのような条件には少しの不当な差別もないと考える基礎のIABからの声明)に関する記録は、IABのファイルで置かれて、保有されるものとします。
6.3 Notice
6.3 通知
When the IAB receives from a patent holder the assurance set forth
in section 5.1(1) or 5.1(2), the corresponding Internet Standard
shall include a note as follows:
IABが先へ特許所有権者からセクションの5.1(1)か5.1(2)で保証セットを受けるとき、対応するインターネットStandardは以下の注意を含んでいるものとします:
"NOTE: The user's attention is called to the possibility that
compliance with this standard may require the use of an invention
or work covered by patent claims.
「以下に注意してください」 ユーザの注意はこの規格への承諾が特許請求の範囲でカバーされた発明か仕事の使用を必要とするかもしれない可能性に呼ばれます。
"By publication of this standard, no position is taken with
「この公表で、規格、立場を全く取りません」
IAB [Page 18] RFC 1310 Internet Standards Process March 1992
IAB[18ページ]RFC1310インターネット規格は1992年3月に処理されます。
respect to the validity of this claim or of any patent rights in
connection therewith. The patent holder has, however, filed a
statement of willingness to grant a license under these rights, on
reasonable and nondiscriminatory terms and conditions, to
applicants desiring to obtain such a license. Details may be
obtained from the IAB."
このクレームかどんな特許の正当性への敬意もそのほかに接続でまっすぐになります。 しかしながら、特許所有権者はこれらの権利の下で鑑札を下付する意欲の声明をファイルしました、妥当、そして、nondiscriminatory条件で、そのような免許を取得することを望んでいる応募者に。 「IABから詳細を得るかもしれません。」
6.4 Identifying Patents
6.4 特許を特定すること。
The IAB shall not be responsible for identifying all patents for
which a license may be required by an Internet Standard, nor for
conducting inquiries into the legal validity or scope of those
patents that are brought to its attention.
IABはライセンスがインターネットStandardによって必要とされるかもしれないすべての特許を特定して、その注目していただかれるそれらの特許の法的有効性か範囲への問い合せを行うのに責任がないでしょう。
7. ACKNOWLEDGMENTS AND REFERENCES
7. 承認と参照
This document represents the combined output of the Internet Activities Board and the Internet Engineering Steering Group, the groups charged with managing the processes described in this document. Major contributions to the text were made by Bob Braden, Vint Cerf, Lyman Chapin, Dave Crocker, and Barry Leiner. Helpful comments and suggestions were made by a number of IETF members.
このドキュメントはインターネットActivities BoardとインターネットEngineering Steering Groupの結合した出力を表します、とグループは過程を管理するのについて本書では説明される告発しました。 テキストへの主要な貢献はボブ・ブレーデン、Vintサーフ、ライマン・チェーピン、デーヴ・クロッカー、およびバリーLeinerによってされました。 役に立つコメントと提案は多くのIETFメンバーによってされました。
[1] Cerf, V., "The Internet Activities Board", RFC 1160, IAB, May
1990.
[1] サーフ(V.、「インターネット活動板」、RFC1160、IAB)は1990がそうするかもしれません。
[2] Postel, J., "IAB Official Protocol Standards", RFC 1280, IAB,
March 1992.
[2] ポステル、J.、「IABの公式のプロトコル標準」、RFC1280、IAB、1992年3月。
[3] Braden, R., Editor, "Requirements for Internet Hosts --
Communication Layers", RFC 1122, IETF, October 1989.
[3] ブレーデン、R.、エディタ、「インターネットホストのための要件--コミュニケーションは層にする」、RFC1122、IETF、10月1989日
[4] Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support", RFC 1123, IETF, October 1989.
[4] ブレーデン、R.、エディタ、「インターネットホストのための要件--、アプリケーションとサポート、」、RFC1123、IETF、10月1989日
[5] Almquist, P., Editor, "Requirements for IP Routers", in
preparation.
[5]Almquist、P.、Editor、準備における「IPルータのための要件。」
[6] Hinden, R., "Internet Engineering Task Force Internet Routing
Protocol Standardization Criteria", RFC 1264, BBN, October 1991.
[6]Hinden、R.、「インターネット・エンジニアリング・タスク・フォースインターネットルーティング・プロトコル標準化評価基準」、RFC1264、BBN、1991年10月。
[7] ANSI, Coded Character Set -- 7-Bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[7]ANSI、コード化文字集合--7ビットの情報交換用米国標準コード、ANSI X3.4-1986。
[8] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060, ISI,
March 1990.
[8] レイノルズ、J.とJ.ポステル、「規定番号」、RFC1060、ISI、1990年3月。
IAB [Page 19] RFC 1310 Internet Standards Process March 1992
IAB[19ページ]RFC1310インターネット規格は1992年3月に処理されます。
[9] Postel, J., "Introduction to the STD Notes", RFC 1311, ISI,
March 1992.
[9] ポステル、J.、「STD注意への序論」、RFC1311、ISI、1992年3月。
APPENDIX A: GLOSSARY
付録A: 用語集
ANSI: American National Standards Institute
ANSI: American National Standards Institut
CCITT: Consultative Committee for International Telephone and
Telegraphy.
CCITT: 国際電話と電信のための諮問委員会。
A part of the UN Treaty Organization: the International
Telecommunications Union (ITU).
国連Treaty Organizationの一部: 国際電気通信組合(ITU)。
DARPA: (U.S.) Defense Advanced Research Projects Agency
DARPA: (米国) 国防高等研究計画庁
ISO: International Organization for Standardization
ISO: 国際標準化機構
IAB [Page 20] RFC 1310 Internet Standards Process March 1992
IAB[20ページ]RFC1310インターネット規格は1992年3月に処理されます。
APPENDIX B: FUTURE ISSUES
付録B: 将来の問題
This memo resulted from an effort to document the current standards procedures in the Internet community. At the time of publication, Sections 5 and 6 are still undergoing legal review. In addition, there are important issues under consideration of how to handle copyrights and other issues of intellectual property. This memo is being published with these matters unresolved, due to its importance.
このメモは現在の規格手順をインターネットコミュニティに記録するための努力から生じました。 公表時点で、セクション5と6はまだ法的なレビューを受けています。 さらに、切迫した課題がどう著作権を扱うかに関する考慮と知的所有権の他の問題の下にあります。 これらの件が未定の状態でこのメモは重要性のため発表されています。
Pre-publication review of this document resulted in a number of useful suggestions from members of the Internet community, and opened up several new issues. The IAB and IESG will continue to consider these questions and attempt to resolve these issues; the results will be be incorporated in future versions of this memo.
このドキュメントのプレ公表レビューは、インターネットコミュニティのメンバーからの多くの役に立つ提案をもたらして、いくつかの新規発行を開けました。 IABとIESGはこれらの質問を考えて、これらの問題を解決するのを試み続けるでしょう。 結果はこのメモの法人組織のコネ将来のバージョンであるためにことになるでしょう。
For future reference, this appendix records the outstanding suggestions and issues.
後日のために、この付録は傑出している提案と問題を記録します。
It has been suggested that additional procedures in the following areas should be considered.
以下の領域の追加手順が考えられるべきであると示唆されました。
o Appeals Procedure
o 上告手順
Should there be some formal appeals procedure for correcting
abuses or procedural failures, at each decision point in the
process?
何らかの正式な上告手順が、それぞれの決定ポイントで過程で乱用か手続き上の失敗を修正するものであるべきですか?
o Tracking Procedure
o 追跡手順
Should there 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.
仕様が標準化過程を通って動くので、問題点の追跡と変更要求のための正式手順があるべきですか? そのような手順は文書による回答か単にバージョンの間の変化を記載したデータベースを含むかもしれません。(文書による回答は、カタログに載せられて、広められました)。
o Rationale Documentation
o 原理ドキュメンテーション
Should the procedures require written documentation of the
rationale for the design decisions behind each specification at
the Draft Standard and Standard levels?
手順は各仕様の後ろのデザイン決定のためにDraft StandardとStandardレベルで原理の書かれたドキュメンテーションを必要とするべきですか?
o Application-Layer Standards
o 応用層規格
Should there be some way to "standardize" application-layer
protocols that are not going to become Internet Standards?
インターネットStandardsにならない応用層プロトコルを「標準化する」何らかの方法があるべきですか?
There were suggestions for fine-tuning of the existing procedures:
既存の手順の微調整のための提案がありました:
IAB [Page 21] RFC 1310 Internet Standards Process March 1992
IAB[21ページ]RFC1310インターネット規格は1992年3月に処理されます。
o Increase minimum time in Internet Draft directory from 2 weeks
to 1 month.
o 最小の時間、2週間から1カ月までインターネットDraftディレクトリを増やしてください。
o Place explicit time limit, on IESG and IAB action on suggested
standards changes. Limits suggested: three months.
o 提案された規格変化へのIESGとIAB動作に明白なタイムリミットを置いてください。 限界は示されました: 3カ月。
If it were necessary to extend the time for some reason, the
IETF would have to be explicitly notified.
それがある理由で期間を延長するのに必要であるなら、IETFは明らかに通知されなければならないでしょうに。
o Change minimum time at Draft Standard from 4 to 5 months, to
ensure that an IETF meeting will intervene.
o 最小の時間Draft Standardで4〜5カ月変化して、IETFミーティングに介入するのを保証してください。
o There were differing suggestions on how to balance between early
implementation of specifications available only as Internet
Drafts, and ensuring that everyone is clear that such an
Internet Draft has no official status and is subject to change
at any time. One suggestion was that vendors should not claim
compliance with an Internet Draft.
o いつでも変化するように、皆は単にインターネットDraftsとして利用可能な仕様の早めの実現と、それを確実にするときバランスをとるために、どうそのようなインターネットDraftにはどんな公式の状態もいないのが明確であり、なることがあるかに関する異なった提案がありました。 1つの提案は業者がインターネットDraftへのコンプライアンスを要求するべきでないということでした。
Finally, there were suggestions for improvements in the documentation of the standards procedures.
最終的に、規格手順のドキュメンテーションには改良のための提案がありました。
o Discuss the impact, if any, of export control laws on the
Internet standardization process.
o インターネット標準化過程で輸出管理法についてもしあれば衝撃について議論してください。
It was observed that the Requirements RFCs contain "negative"
requirement levels: MUST NOT and SHOULD NOT. Such levels are
not recognized in this Procedures document.
Requirements RFCsが「否定的な」要件レベルを含むのが観測されました: NOTはそうしなければならないべきです。 そのようなレベルはこのProceduresドキュメントで認識されません。
o Document needs to more clearly explain the criteria for choosing
the Experimental vs. Informational category for an off-track
specification. Ref. sections 3.3.2, 3.3.4.
o オフトラック仕様のために、より明確にInformationalカテゴリに対してExperimentalを選ぶ評価基準について説明する必要性を記録してください。 審判セクション3.3 .2 3.3 .4。
o Develop recommended wording for citations to Internet Drafts,
which makes clear the provisional, unofficial nature of that
document.
o 引用のためにインターネットDraftsにお勧めの言葉遣いを開発してください。(Draftsはそのドキュメントの暫定的で、非公式の本質を明らかにします)。
o Consider changing the name attached to a fully-adopted standard
from "Standard" to some qualified term like "Full Standard".
o 「完全な規格」のように「規格」から適切ないつかの用語まで付くという名前を完全に採用された規格に変えると考えてください。
o It has been suggested that the document should more strongly
encourage the use of specifications from other standards bodies,
with Internet-specific changes to be made only for compelling
reasons. Further, the justification of the compelling
requirement would be subject to special review.
o ドキュメントが、より強く他の標準化団体からの仕様の使用を奨励するはずであると示唆されました、やむにやまれない理由だけによって行われるインターネット特有の変更で。 さらに、無視できない要件の正当化は特別なレビューを受けることがあるでしょう。
IAB [Page 22] RFC 1310 Internet Standards Process March 1992
IAB[22ページ]RFC1310インターネット規格は1992年3月に処理されます。
Security Considerations
セキュリティ問題
Security issues are not substantially discussed in this memo.
このメモで実質的に安全保障問題について議論しません。
Author's Address
作者のアドレス
A. Lyman Chapin BBN Communications Corporation 150 Cambridge Park Drive Cambridge, MA 02140
A.ライマンチェーピンBBN Communications社150のケンブリッジ公園Driveケンブリッジ、MA 02140
Phone: 617-873-3133 Fax: 617-873-4086
以下に電話をしてください。 617-873-3133 Fax: 617-873-4086
Email: Lyman@BBN.COM
メール: Lyman@BBN.COM
IAB [Page 23]
IAB[23ページ]
一覧
スポンサーリンク
