Network Working Group P. Hoffman
Request for Comments: 4677 VPN Consortium
FYI: 17 S. Harris
Obsoletes: 3160 University of Michigan
Category: Informational September 2006
The Tao of IETF: A Novice's Guide to
the Internet Engineering Task Force
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. It is not a formal IETF process document but instead an informational overview.
この文書は、IETF会議や作業グループの内部の仕組みを説明するIETFに関連する組織について説明し、標準化プロセスを導入しています。これは、正式なIETFプロセス文書ではなく、情報の概要ではありません。
Table of Contents
目次
1. Introduction ....................................................4
2. Acknowledgements ................................................5
3. What Is the IETF? ...............................................5
3.1. Humble Beginnings ..........................................6
3.2. The Hierarchy ..............................................7
3.2.1. ISOC (Internet Society) .............................7
3.2.2. IESG (Internet Engineering Steering Group) ..........8
3.2.3. IAB (Internet Architecture Board) ..................10
3.2.4. IANA (Internet Assigned Numbers Authority) .........11
3.2.5. RFC Editor .........................................11
3.2.6. IETF Secretariat ...................................12
3.3. IETF Mailing Lists ........................................12
4. IETF Meetings ..................................................13
4.1. Registration ..............................................14
4.2. Take the Plunge and Stay All Week! ........................15
4.3. Newcomer Training .........................................16
4.4. Dress Code ................................................16
4.5. Seeing Spots Before Your Eyes .............................16
4.6. Terminal Room .............................................17
4.7. Meals and Other Delights ..................................17
4.8. Social Event ..............................................18
4.9. Agenda ....................................................18
4.10. EDU to the Rescue ........................................19
4.11. Where Do I Fit In? .......................................19
4.11.1. IS Managers .......................................19
4.11.2. Network Operators and ISPs ........................19
4.11.3. Networking Hardware and Software Vendors ..........20
4.11.4. Academics .........................................20
4.11.5. Computer Trade Press ..............................20
4.12. Proceedings ..............................................21
4.13. Other General Things .....................................21
5. Working Groups .................................................22
5.1. Working Group Chairs ......................................23
5.2. Getting Things Done in a Working Group ....................24
5.3. Preparing for Working Group Meetings ......................25
5.4. Working Group Mailing Lists ...............................26
5.5. Interim Working Group Meetings ............................27
6. BOFs ...........................................................27
7. New to the IETF and Coming to a Meeting? STOP HERE!
(Temporarily) ..................................................28
8. RFCs and Internet Drafts .......................................29
8.1. Getting an RFC Published ..................................29
8.2. Letting Go Gracefully .....................................30
8.3. Internet Drafts ...........................................31
8.3.1. Recommended Reading for Writers ....................32
8.3.2. Filenames and Other Matters ........................33
8.4. Standards-Track RFCs ......................................34
8.4.1. Telling It Like It Is -- Using MUST and SHOULD
and MAY ............................................35
8.4.2. Normative References in Standards ..................36
8.4.3. IANA Considerations ................................37
8.4.4. Security Considerations ............................37
8.4.5. Patents in IETF Standards ..........................37
8.5. Informational and Experimental RFCs .......................38
9. How to Contribute to the IETF ..................................39
9.1. What You Can Do ...........................................39
9.2. What Your Company Can Do ..................................40
10. IETF and the Outside World ....................................40
10.1. IETF and Other Standards Groups ..........................40
10.2. Press Coverage of the IETF ...............................41
11. Security Considerations .......................................42
Appendix A. Related Information ...................................43
A.1. Why "the Tao"? ............................................43
A.2. Useful Email Addresses ....................................43
A.3. Useful Documents and Files ................................44
A.4. Acronyms and Abbreviations Used in the Tao ................44
Appendix B. IETF Guiding Principles ...............................45
B.1. General ...................................................45
B.2. Management and Leadership .................................45
B.3. Process ...................................................46
B.4. Working Groups ............................................46
B.5. Documents .................................................47
Informative References ............................................48
Since its early years, attendance at Internet Engineering Task Force (IETF) face-to-face meetings has grown phenomenally. Many of the attendees are new to the IETF at each meeting, and many of those go on to become regular attendees. When the meetings were smaller, it was relatively easy for a newcomer to get into the swing of things. Today, however, a newcomer meets many more new people, some previously known only as the authors of documents or thought-provoking email messages.
その年の初め以来、IETF（Internet Engineering Task Force）の対面会議への出席は、驚異的に成長してきました。参加者の多くは、各会合でIETFに新しいもの、そしてそれらの多くは、定期的な参加者になるために行きます。会議が小さかったとき、それは物事のスイングに入るために新人のために比較的簡単でした。今日は、しかし、新人はより多くの新しい人々、あらかじめ文書のみまたは示唆に富む電子メールメッセージの作者として知られているいくつかを満たしています。
This document describes many aspects of the IETF, with the goal of explaining to newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting and the Working Group discussions more productive for everyone.
この文書は、IETFがどのように機能するかを新参者に説明することを目標に、IETFの多くの側面を説明しています。これは、彼らに暖かい、ファジー感を与え、皆のための会議や作業部会の議論がより生産的にすることを可能にします。
Of course, it's true that many IETF participants don't go to the face-to-face meetings at all. Instead, they're active on the mailing list of various IETF Working Groups. Since the inner workings of Working Groups can be hard for newcomers to understand, this document provides the mundane bits of information that newcomers will need in order to become active participants.
もちろん、それは多くのIETFの参加者がすべてで対面のミーティングに行っていないというのは本当です。その代わりに、彼らは様々なIETFワーキンググループのメーリングリスト上でアクティブにしています。新規参入者が理解するための作業部会の内部の仕組みは難しいことができますので、このドキュメントでは、新規参入者が積極的に参加になるために必要となることを情報の平凡なビットを提供します。
The IETF is always in a state of change. Although the principles in this document are expected to remain largely the same over time, practical details may well have changed by the time you read it; for example, a web-based tool may have replaced an email address for requesting some sort of action.
IETFは、変更の状態に常にあります。この文書の原則は、時間の経過とともにほぼ同じままと予想されるものの、実用的な詳細がうまく、あなたがそれを読んで、時間によって変化していることがあり、例えば、Webベースのツールは、何らかのアクションを要求するための電子メールアドレスを交換している可能性があります。
Many types of IETF documentation are mentioned in the Tao, from BCPs to RFCs and FYIs and STDs. BCPs make recommendations for Best Current Practices in the Internet; RFCs are the IETF's main technical documentation series, politely known as "Requests for Comments"; FYIs provide topical and technical overviews that are introductory or appeal to a broad audience; and STDs are RFCs identified as "standards". See Section 8 for more information.
IETFドキュメントの多くのタイプののBCPからRFCとFYIにと性感染症に、タオに記載されています。 BCPは、インターネットで最も良い現在のプラクティスのための提言を行います。 RFCは、丁寧に「コメントを求める要求」として知られているIETFの主要な技術文書シリーズ、です。 FYIには、導入されているか、幅広い視聴者にアピールする局所および技術的な概要を提供すること。と性感染症は、「基準」として特定のRFCです。詳細については、セクション8を参照してください。
The acronyms and abbreviations used in this document are usually expanded in place and are explained fully in Appendix A.
この文書で使用されている頭字語や略語は、通常の場所に展開され、付録Aに十分に説明されています
This document is intended to obsolete FYI 17, RFC 3160. See Section 3.2.5 for information on what it means for one RFC to obsolete another.
この文書は、それが別の時代遅れに1 RFCのために何を意味するのかについては、廃止されたFYI 17、RFC 3160を参照してくださいセクション3.2.5に意図されます。
The original version of this document, published in 1994, was written by Gary Malkin. His knowledge of the IETF, insights, and unmatched writing style set the standard for this later revision, and his contributions to the current document are also much appreciated. Paul Hoffman wrote significant portions of this revision and provided encouragement, expertise, and much-needed guidance. Other contributors include Brian Carpenter, Scott Bradner, Michael Patton, Donald E. Eastlake III, Tony Hansen, Pekka Savola, Lisa Dusseault, the IETF Secretariat, members of the User Services Working Group, and members of the PESCI design team.
1994年に出版され、このドキュメントのオリジナルバージョンは、ゲーリーマルキンによって書かれました。 IETFの彼の知識は、洞察力、および比類のない文体は、この後の改正のための標準を設定し、現在の文書への貢献にも感謝しています。ポール・ホフマンは、この改正の重要な部分を書き、励まし、専門知識、および大いに必要なガイダンスを提供します。その他の貢献者はブライアン・カーペンター、スコット・ブラッドナー、マイケル・パットン、ドナルドE.イーストレイクIII、トニー・ハンセン、ペッカSavola、リサDusseault、IETF事務局、ユーザサービスワーキンググループのメンバー、およびペシ設計チームのメンバーが含まれます。
The Internet Engineering Task Force is a loosely self-organized group of people who contribute to the engineering and evolution of Internet technologies. It is the principal body engaged in the development of new Internet standard specifications. The IETF is unusual in that it exists as a collection of happenings, but is not a corporation and has no board of directors, no members, and no dues; see [BCP95], "A Mission Statement for the IETF", for more detail.
インターネットエンジニアリングタスクフォースは、インターネット技術のエンジニアリングと進化に貢献し、人々の緩く自己組織グループです。これは、新しいインターネットの標準仕様の開発に従事する主要なボディです。それは出来事の集合体として存在するが、企業ではなく、取締役のないボード、メンバーを持たない、無会費を持っていないという点で、IETFは珍しいです。詳細については、[BCP95]、「IETFのためのミッション・ステートメント」を参照してください。
Its mission includes the following:
その使命は、次のものが含まれます。
o Identifying, and proposing solutions to, pressing operational and technical problems in the Internet
インターネットで運用し、技術的な問題を特定し、解決策を提案し、押しO
o Specifying the development or usage of protocols and the near-term architecture to solve such technical problems for the Internet
インターネットのために、このような技術的問題を解決するためのプロトコルと短期的なアーキテクチャの開発や使用方法を指定するO
o Making recommendations to the Internet Engineering Steering Group (IESG) regarding the standardization of protocols and protocol usage in the Internet
インターネットにおけるプロトコルの標準化とプロトコルの使用に関するインターネットエンジニアリング運営グループ（IESG）に勧告を行うO
o Facilitating technology transfer from the Internet Research Task Force (IRTF) to the wider Internet community
より広いインターネットコミュニティにインターネットResearch Task Force（IRTF）からの技術移転の促進O
o Providing a forum for the exchange of information within the Internet community between vendors, users, researchers, agency contractors, and network managers
ベンダー、ユーザー、研究者、代理業者、およびネットワーク管理者の間でインターネットコミュニティ内の情報交換の場を提供するO
The IETF meeting is not a conference, although there are technical presentations. The IETF is not a traditional standards organization, although many specifications are produced that become standards. The IETF is made up of volunteers, many of whom meet three times a year to fulfill the IETF mission.
技術的なプレゼンテーションがありますが、IETF会議は、会議ではありません。多くの仕様が標準となっている製造されているが、IETFは、伝統的な標準化団体ではありません。 IETFは、IETFの使命を果たすために年3回を満たすため、多くの人のボランティア、から構成されています。
There is no membership in the IETF. Anyone may register for and attend any meeting. The closest thing there is to being an IETF member is being on the IETF or Working Group mailing lists (see Section 3.3). This is where the best information about current IETF activities and focus can be found.
IETFにはメンバーシップはありません。誰でものために登録して、任意の会議に出席することができます。 IETFメンバーであることにあります最も近いものは、IETFやワーキンググループメーリングリストにされている（3.3節を参照してください）。現在IETF活動やフォーカスの最適な情報を見つけることができる場所です。
Of course, no organization can be as successful as the IETF is without having some sort of structure. In the IETF's case, that structure is provided by other organizations, as described in [BCP11], "The Organizations Involved in the IETF Standards Process". If you participate in the IETF and read only one BCP, this is the one you should read.
もちろん、何の組織は、構造体のいくつかの並べ替えをせずにIETFがあるとして成功することはできません。 「IETF標準化プロセスに関与する組織」、[BCP11]で説明されるようにIETFの場合、その構造は、他の組織によって提供されます。あなたがIETFに参加し、唯一のBCPを読めば、これはあなたが読むべきものです。
In many ways, the IETF runs on the beliefs of its members. One of the "founding beliefs" is embodied in an early quote about the IETF from David Clark: "We reject kings, presidents and voting. We believe in rough consensus and running code". Another early quote that has become a commonly-held belief in the IETF comes from Jon Postel: "Be conservative in what you send and liberal in what you accept".
いろいろな意味では、IETFは、そのメンバーの信念で実行されます。 「創業信念」の一つは、デビッド・クラークからIETFについて、早期の引用に具現化されています。「私たちは、王、大統領や投票を拒否我々はラフコンセンサスとコードの実行を信じています。」。 IETFで一般的に開催された信念となっているもう一つの初期の引用は、ジョン・ポステルから来ている：「あなたが受け入れるものにあなたが送るものに保守的でリベラルう」。
The IETF is really about its members. Because of the unrestrictive membership policies, IETF members come from all over the world and from many different parts of the Internet industry. See Section 4.11 for information about the ways that many people fit into the IETF.
IETFは、そのメンバーについて実際にあります。そのため制限のないメンバーシップ・ポリシーの、IETFのメンバーは世界中からやインターネット業界のさまざまな部分から来ます。多くの人がIETFに収まる方法の詳細については、セクション4.11を参照してください。
One more thing that is important for newcomers: the IETF in no way "runs the Internet", despite what some people mistakenly might say. The IETF makes standards that are often adopted by Internet users, but it does not control, or even patrol, the Internet. If your interest in the IETF is because you want to be part of the overseers, you may be badly disappointed by the IETF.
新参者のために重要であるもう一つ：決してIETFは、何人かの人々が誤って言うかもしれないものにもかかわらず、「インターネットを実行します」。 IETFは、多くの場合、インターネットユーザーによって採用されている基準を作るが、それは制御し、あるいはパトロール、インターネットはありません。あなたが監督の一部になりたいので、IETFにご関心がある場合、あなたはひどくIETFによって失望することができます。
The first IETF meeting was held in January 1986 at Linkabit in San Diego, with 21 attendees. The 4th IETF, held at SRI in Menlo Park in October 1986, was the first that non-government vendors attended. The concept of Working Groups was introduced at the 5th IETF meeting at the NASA Ames Research Center in California in February 1987. The 7th IETF, held at MITRE in McLean, Virginia, in July 1987, was the first meeting with more than 100 attendees.
最初のIETF会議は21人の参加者と、サンディエゴでLinkabitで1986年1月に開催されました。 1986年10月にメンロパークにSRIで開催された第4回IETFは、非政府ベンダーが参加した最初でした。ワーキンググループの概念は2月1987年にカリフォルニア州NASAエイムズ研究センターの第5回IETF会合で導入されたマクリーン、バージニア州では、MITREで開催された第7回IETFは、1987年7月には、100人の以上の参加者との最初の会議でした。
The 14th IETF meeting was held at Stanford University in July 1989. It marked a major change in the structure of the IETF universe. The IAB (then Internet Activities Board, now Internet Architecture Board), which until that time oversaw many "task forces", changed its structure to leave only two: the IETF and the IRTF. The IRTF is tasked to consider long-term research problems in the Internet. The IETF also changed at that time.
第14回IETFミーティングは、それがIETF宇宙の構造に大きな変化をマーク1989年7月にスタンフォード大学で開催されました。それまで多くの「タスクフォース」を監督しIAB（その後、インターネット活動委員会、今やインターネットアーキテクチャ委員会）は、2つだけを残して、その構造を変更：IETFとIRTFを。 IRTFはインターネットでの長期的な研究課題を検討する使命を帯びています。 IETFは、その時に変更しました。
After the Internet Society (ISOC) was formed in January 1992, the IAB proposed to ISOC that the IAB's activities should take place under the auspices of the Internet Society. During INET92 in Kobe, Japan, the ISOC Trustees approved a new charter for the IAB to reflect the proposed relationship.
インターネット協会（ISOC）は1992年1月に結成された後、IABは、IABの活動は、インターネット協会の後援で行われるべきであることをISOCに提案しました。神戸、日本でINET92中、ISOC管理委員会は、提案された関係を反映するためにIABのための新たな憲章を承認しました。
The IETF met in Amsterdam, The Netherlands, in July 1993. This was the first IETF meeting held in Europe, and the US/non-US attendee split was nearly 50/50. About one in three IETF meetings are now held in Europe or Asia, and the number of non-US attendees continues to be high -- about 50%, even at meetings held in the United States.
IETFは、これはヨーロッパで開催された第1回IETFミーティングだった7月、1993年に、アムステルダム、オランダで会った、と米国/米国以外の出席者のスプリットは、ほぼ50/50でした。約1〜3でのIETFミーティングは現在ではヨーロッパやアジアで開催されており、米国以外の参加者の数が高くなり続けて - 約50％、さらに米国で開催された会議で。
The Internet Society is an international, non-profit, membership organization that fosters the expansion of the Internet. One of the ways that ISOC does this is through financial and legal support of the other "I" groups described here, particularly the IETF. ISOC provides insurance coverage for many of the people in the IETF process and acts as a public relations channel for the times that one of the "I" groups wants to say something to the press. The ISOC is one of the major unsung (and under-supported) heroes of the Internet.
インターネット協会は、インターネットの拡大を促進国際的、非営利、会員組織です。 ISOCがこれを行う方法の一つは、ここで説明する他の「I」のグループ、特にIETFの財務および法律上の支援を通じてです。 ISOCはIETFプロセスの人々の多くのための保険を提供し、「I」グループの一つがマスコミに何かを言いたいことを時間の広報チャンネルとして機能します。 ISOCは、インターネットの主要な陰（アンダーサポート）英雄の一つです。
Starting in spring 2005, the ISOC also became home base for the IETF's directly employed administrative staff. This is described in more detail in [BCP101], "Structure of the IETF Administrative Support Activity (IASA)". The staff initially includes only an Administrative Director (IAD) who works full-time overseeing IETF meeting planning, operational aspects of support services (the secretariat, IANA (the Internet Assigned Numbers Authority), and the RFC Editor, which are described later in this section), and the budget. He or she (currently it's a he) leads the IETF Administrative Support Activity (IASA), which takes care of tasks such as collecting meeting fees and paying invoices, and also supports the tools for the work of IETF working groups, the IESG, the IAB, and the IRTF (more about these later in this section).
2005年春以降、ISOCもIETFの直接雇用管理スタッフのためのホームベースになりました。これは[BCP101]、「IETF管理サポート活動（IASA）の構造」に詳細に記載されています。スタッフは当初、IETFミーティングの企画、これに後述されているサポートサービスの運用面（事務局、は、IANA（Internet Assigned Numbers Authority）、およびRFC Editorを、監督フルタイムで働く唯一の管理ディレクター（IAD）が含まセクション）、および予算。彼または彼女（現在はそれが彼だ）、このような会議の手数料を収集し、請求書を支払うなどのタスクの世話をし、また、IETFワーキンググループの作業、IESGのためのツールをサポートIETF行政支援活動（IASA）を、リード、 IAB、およびIRTF（これらの詳細については、このセクションの後半で）。
As well as staff, the IASA comprises volunteers and ex officio members from the ISOC and IETF leadership. The IASA and the IAD are directed by the IETF Administrative Oversight Committee (IAOC), which is selected by the IETF community. Here's how all this looks:
同様にスタッフとして、IASAはボランティアとISOCとIETFリーダーシップから充て職を含みます。 IASAとIADは、IETFコミュニティによって選択されたIETF管理監視委員会（IAOC）、監督されています。ここでは、このすべてがどのように見えるかです：
Internet Society
|
IAOC
|
IASA
|
IAD
Neither the IAD nor the IAOC have any influence over IETF standards development, which we turn to now.
IADもIAOCどちらも私たちが今まで回すIETF標準の開発、オーバーどんな影響を与えています。
The IESG is responsible for technical management of IETF activities and the Internet standards process. It administers the process according to the rules and procedures that have been ratified by the ISOC Trustees. However, the IESG doesn't do much direct leadership, such as the kind you will find in many other standards organizations. As its name suggests, its role is to set directions rather than to give orders. The IESG ratifies or corrects the output from the IETF's Working Groups (WGs), gets WGs started and finished, and makes sure that non-WG drafts that are about to become RFCs are correct.
IESGは、IETFの活動とインターネット標準化プロセスの技術的な管理を担当しています。これはISOC受託者によって承認されているルールと手順に従った処理を管理します。しかし、IESGは、あなたが他の多くの標準化団体で見つけるようなものとして、多くの直接的なリーダーシップを行いません。その名前が示すように、その役割は方向性を設定するのではなく注文を与えることです。 IESGは、批准またはIETFのワーキンググループ（作業部会）からの出力を補正し、各WGが開始と終了を取得、およびRFCになろうとしている非WGドラフトが正しいことを確認します。
The IESG consists of the Area Directors (ADs), who are selected by the Nominations Committee (which is usually called "the NomCom") and are appointed for two years. The process for choosing the members of the IESG is detailed in [BCP10], "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees".
IESGは、（通常は「NomCom」と呼ばれている）指名委員会によって選択され、2年間のために任命されているエリアディレクター（ADS）、から構成されています。 IESGのメンバーを選択するための方法は、[BCP10]、「：指名とリコール委員会の操作IABとIESG選択、確認、およびリコールプロセス」に詳述されています。
The current areas and abbreviations are shown below.
現在の領域と略号を以下に示します。
Area Description
-----------------------------------------------------------------
Applications (APP) Protocols seen by user programs, such as
email and the web
General (GEN) Catch-all for WGs that don't fit in other areas (which is very few)
一般（GEN）キャッチ他のすべてのエリアに収まらないのWGのために（非常に少数です）
Internet (INT) Different ways of moving IP packets and DNS information
インターネット（INT）IPパケットおよびDNS情報を移動するさまざまな方法
Operations and Operational aspects, network monitoring, Management (OPS) and configuration
操作と運用面、ネットワーク監視、管理（OPS）と設定
Real-time Delay-sensitive interpersonal Applications and communications Infrastructure (RAI)
リアルタイムの遅延に敏感な対人アプリケーションと通信インフラストラクチャ（RAI）
Routing (RTG) Getting packets to their destinations
ルーティング（RTG）その宛先にパケットを取得します
Security (SEC) Authentication and privacy
セキュリティ（SEC）の認証とプライバシー
Transport (TSV) Special services for special packets
交通（TSV）特別なパケットのための特別なサービス
Because the IESG has a great deal of influence on whether Internet Drafts become RFCs, many people look at the ADs as somewhat godlike creatures. IETF participants sometimes reverently ask Area Directors for their opinion on a particular subject. However, most ADs are nearly indistinguishable from mere mortals and rarely speak from mountaintops. In fact, when asked for specific technical comments, the ADs may often defer to members at large whom they feel have more knowledge than they do in that area.
IESGは、インターネットドラフトは、RFCになっているかどうかに影響を大量に持っているので、多くの人は多少神のような生き物としてのADを見てください。 IETFの参加者は、時々うやうやしく特定のテーマについて自分の意見をエリアディレクターをお願いします。しかし、ほとんどの広告は単なる人間とほとんど区別がつかないとめったに山頂から話すん。実際には、特定の技術的なコメントを求めたとき、広告はしばしば、彼らがその地域で行うよりもより多くの知識を持っていると感じ大型のメンバーに延期することがあります。
The ADs for a particular area are expected to know more about the combined work of the WGs in that area than anyone else. On the other hand, the entire IESG reviews each Internet Draft that is proposed to become an RFC. Any AD may record a "DISCUSS" ballot position against a draft if he or she has serious concerns. If these concerns cannot be resolved by discussion, an override procedure is defined such that at least two IESG members must express concerns before a draft can be blocked from moving forward. These procedures help ensure that an AD's "pet project" doesn't make it onto the standards track if it will have a negative effect on the rest of the IETF protocols and that an AD's "pet peeve" cannot indefinitely block something.
特定の地域の広告は、誰よりもその領域でのWGの組み合わせ作業についての詳細を知ることが予想されます。一方、全体IESGは、RFCになるために提案されている各インターネットドラフトをレビュー。彼または彼女は深刻な懸念を持っている場合、任意のADは、草案に対する「DISCUSS」投票用紙位置を記録することができます。これらの懸念を議論することで解決できない場合は、上書き手順はドラフトが前進を阻止することができます前に、少なくとも2人のIESGのメンバーが懸念を表明しなければならないように定義されます。これらの手順は、IETFプロトコルの残りの部分にマイナスの効果を有し、ADの「ペットのpeeveは」無期限に何かをブロックすることはできませんことをするかどうかの基準は、トラックにADの「ペットのプロジェクトは、」それをしないことを確実にするのに役立ちます。
This is not to say that the IESG never wields power. When the IESG sees a Working Group veering from its charter, or when a WG asks the IESG to make the WG's badly designed protocol a standard, the IESG will act. In fact, because of its high workload, the IESG usually moves in a reactive fashion. It eventually approves most WG requests for Internet Drafts to become RFCs, and usually only steps in when something has gone very wrong. Another way to think about this is that the ADs are selected to think, not to just run the process. The quality of the IETF standards comes both from the review they get in the Working Groups and the scrutiny that the WG review gets from the ADs.
これは、IESGはを振るったことがないということではありません。 IESGが見るときにワーキンググループは、その憲章から方向転換、またはWGは、WGの悪い設計されたプロトコルの標準にするためにIESGを要求したとき、IESGが動作します。実際には、その高いワークロードの、IESGは、通常、反応性形で動きます。それは最終的にインターネットドラフトのための最もWG要求がRFCになることを承認し、何かが非常に間違っていたときにのみ通常の手順。これについて考える別の方法は、広告がちょうどプロセスを実行するのではなく、考えるように選択されていることです。 IETF標準の品質は、彼らがワーキンググループに入るレビューとWGの検討は広告からの取得精査の両方から来ます。
The IETF is run by rough consensus, and it is the IESG that judges whether a WG has come up with a result that has community consensus. (See Section 5.2 for more information on WG consensus.) Because of this, one of the main reasons that the IESG might block something that was produced in a WG is that the result did not really gain consensus in the IETF as a whole, that is, among all of the Working Groups in all areas. For instance, the result of one WG might clash with a technology developed in a different Working Group. An important job of the IESG is to watch over the output of all the WGs to help prevent IETF protocols that are at odds with each other. This is why ADs are supposed to review the drafts coming out of areas other than their own.
IETFはラフコンセンサスによって運営されており、それはWGがコミュニティのコンセンサスを持っている結果が出ているかどうかという判断IESGです。 （WGコンセンサスの詳細については、セクション5.2を参照してください。）このため、IESGはWGで生産されたものをブロックする可能性があることを主な理由の一つは、結果は本当に全体としてIETFでの合意を得ていなかったということである、ということすべての分野でワーキンググループの全ての中で、あります。例えば、1 WGの結果は、異なるワーキンググループで開発された技術と衝突することがあります。 IESGの重要な仕事は、互いに対立しているIETFプロトコルを防ぐために、すべてのWGの出力を見守ることです。広告は、独自の以外の領域から出てくる草稿を見直すことになっている理由はここにあります。
The IAB is responsible for keeping an eye on the "big picture" of the Internet, and it focuses on long-range planning and coordination among the various areas of IETF activity. The IAB stays informed about important long-term issues in the Internet, and it brings these topics to the attention of people it thinks should know about them. The IAB web site is at http://www.iab.org/.
IABは、インターネットの「全体像」に目を維持する責任があり、そしてそれはIETF活動の様々な領域のうち長期計画との調整に焦点を当てています。 IABは、インターネット上で重要な長期的な問題について知らされたままになり、そしてそれはそれらについて知っておくべきと考える人々の注意にこれらのトピックをもたらします。 IABのウェブサイトはhttp://www.iab.org/です。
IAB members pay special attention to emerging activities in the IETF. When a new IETF Working Group is proposed, the IAB reviews its charter for architectural consistency and integrity. Even before the group is chartered, the IAB members are more than willing to discuss new ideas with the people proposing them.
IABのメンバーは、IETFの新興活動に特別な注意を払います。新しいIETFワーキンググループが提案されている場合、IABは、建築一貫性と整合性のための憲章を見直しています。グループがチャーターされていても前に、IABのメンバーは、人々がそれらを提案して新しいアイデアを議論するために喜ん以上です。
The IAB also sponsors and organizes the Internet Research Task Force and convenes invitational workshops that provide in-depth reviews of specific Internet architectural issues. Typically, the workshop reports make recommendations to the IETF community and to the IESG.
IABはまた、スポンサーやインターネット研究タスクフォースを組織し、具体的なインターネットアーキテクチャの問題の詳細なレビューを提供招待ワークショップを招集します。一般的に、ワークショップの報告書は、IETFコミュニティへとIESGへの提言を行います。
The IAB also:
また、IAB：
o Approves NomCom's IESG nominations
O NomComのIESGの指名を承認
o Acts as the appeals board for appeals against IESG actions
IESGアクションに対する控訴のため控訴ボードとしてO行為
o Appoints and oversees the RFC Editor
O任命およびRFCエディタを監督
o Approves the appointment of the IANA
oはIANAの任命を承認します
o Acts as an advisory body to ISOC
ISOCの諮問機関として、O行為
o Oversees IETF liaisons with other standards bodies
oは他の標準化団体とのIETFリエゾンを監督します
Like the IESG, the IAB members are selected for multi-year positions by the NomCom and are approved by the ISOC Board of Trustees.
IESGのように、IABのメンバーがNomComによる複数年の位置のために選択され、評議員のISOC理事会で承認されています。
The core registrar for the IETF's activities is the IANA. Many Internet protocols require that someone keep track of protocol items that were added after the protocol came out. Typical examples of the kinds of registries needed are for TCP port numbers and MIME types. The IAB has designated the IANA organization to perform these tasks, and the IANA's activities are financially supported by ICANN, the Internet Corporation for Assigned Names and Numbers.
IETFの活動の中核レジストラはIANAです。多くのインターネット・プロトコルは、誰かが、プロトコルが出てきた後に追加されたプロトコルの項目を追跡することが必要です。必要なレジストリの種類の典型的な例は、TCPポート番号とMIMEタイプのためのものです。 IABは、これらのタスクを実行するためにIANA組織を指定している、とIANAの活動を財政的に割り当てられた名前と番号についてはICANN、インターネット株式会社がサポートされています。
Ten years ago, no one would have expected to see the IANA mentioned on the front page of a newspaper. IANA's role had always been very low key. The fact that IANA was also the keeper of the root of the domain name system forced it to become a much more public entity, one that was badly maligned by a variety of people who never looked at what its role was. Nowadays, the IETF is generally no longer involved in the IANA's domain name and IP address assignment functions, which are overseen by ICANN.
10年前、誰もIANAは、新聞のフロントページに記載さ見込まなかっただろう。 IANAの役割は、常に非常に低いキーでした。 IANAは、ドメインネームシステムのルートのキーパーだったという事実は、それがはるか公共団体、ひどくその役割は何であったかを見たことがない人々の様々な中傷したものになることを余儀なくされました。今日では、IETFは、一般的に、もはやICANNによって監督されているIANAのドメイン名とIPアドレス割り当て機能に関与していません。
Even though being a registrar may not sound interesting, many IETF participants will testify to how important IANA has been for the Internet. Having a stable, long-term repository run by careful and conservative operators makes it much easier for people to experiment without worrying about messing things up. IANA's founder, Jon Postel, was heavily relied upon to keep things in order while the Internet kept growing by leaps and bounds, and he did a fine job of it until his untimely death in 1998.
レジストラであることは興味深い鳴らないかもしれないが、多くのIETFの参加者は、IANAは、インターネットのためになっているかが重要に証言します。慎重かつ保守的な事業者が運営し、長期安定的なリポジトリを持つことは、それははるかに簡単に人々は物事をめちゃくちゃ気にせずに実験できるようになります。インターネットは飛躍的に成長を続けながら、IANAの創設者、ジョン・ポステルは、多額の順序で物事を保つために依拠して、彼は1998年に彼の早すぎる死までの細かい仕事をしました。
The RFC Editor edits, formats, and publishes Internet Drafts as RFCs, working in conjunction with the IESG. An important secondary role is to provide one definitive repository for all RFCs (see http://www.rfc-editor.org). Once an RFC is published, it is never revised. If the standard it describes changes, the standard will be re-published in another RFC that "obsoletes" the first.
RFC Editorは、編集フォーマット、およびIESGと一緒に働いて、RFCとしてインターネットドラフトを公開しています。重要な二次的な役割は、すべてのRFC（http://www.rfc-editor.orgを参照）ごとに1つの決定的なリポジトリを提供することです。 RFCが公開されたら、それが改訂されることはありません。それは変化を記述する標準の場合、標準では、最初に「廃止」という別のRFCで再公開されます。
One of the most popular misconceptions in the IETF community is that the role of the RFC Editor is performed by IANA. In fact, the RFC Editor is a separate job, although both the RFC Editor and IANA involved the same people for many years. The IAB approves the organization that will act as RFC Editor and the RFC Editor's general policy. The RFC Editor is funded by IASA and can be contacted by email at mailto:rfc-editor@rfc-editor.org.
IETF共同体の中で最も人気のある誤解の一つは、RFC編集者の役割はIANAによって行われていることです。 RFCエディタとIANAの両方が長年にわたって同じ人を関与が実際には、RFC Editorは、別の仕事です。 IABはRFCエディタとRFC編集者の一般的な方針として機能する組織を承認します。 RFC EditorはIASAによって運営されているとのmailtoにEメールで連絡することができます：rfc-editor@rfc-editor.org。
There are, in fact, a few people who are paid to maintain the IETF. The IETF Secretariat provides day-to-day logistical support, which mainly means coordinating face-to-face meetings and running the IETF-specific mailing lists (not the WG mailing lists). The Secretariat is also responsible for keeping the official Internet Drafts directory up to date and orderly, maintaining the IETF web site, and helping the IESG do its work. It provides various tools for use by the community and the IESG. The IETF Secretariat is under contract to IASA, which in turn is financially supported by the fees of the face-to-face meetings.
IETFを維持するために支払われる少数の人々は、実際には、があります。 IETF事務局は、主に（WGメーリングリストではない）対面会議をコーディネートし、IETF特有のメーリングリストを実行していること、日々の後方支援を提供します。事務局はまた、IETFのWebサイトを維持し、IESGはその作業を行う手助け、最新かつ秩序公式のインターネットドラフトのディレクトリを維持する責任があります。それは、コミュニティとIESGで使用するための様々なツールを提供しています。 IETF事務局は、順番に財政対面会議の手数料によってサポートされているIASA、との契約下にあります。
Anyone who plans to attend an IETF meeting should join the IETF announcement mailing list, mailto:ietf-announce@ietf.org. This is where all of the meeting information, RFC announcements, and IESG Protocol Actions and Last Calls are posted. People who would like to "get technical" may also join the IETF general discussion list, ietf@ietf.org. This is where discussions of cosmic significance are held (Working Groups have their own mailing lists for discussions related to their work). Another mailing list, mailto:i-d-announce@ietf.org, announces each new version of every Internet Draft as it is published.
ietf-announce@ietf.org：IETFミーティングに出席することを計画し、誰でもIETFアナウンスメーリングリスト、mailtoのに参加する必要があります。アクションとラストコール会議情報、RFCの発表のすべて、およびIESG議定書が掲載されているところです。 「技術的な取得」したい人も、IETF一般的な議論リスト、ietf@ietf.orgに参加することができます。宇宙の重要性の議論は（ワーキンググループ自分の仕事に関連した議論のために、独自のメーリングリストを持っている）に保持されている場所です。別のメーリングリストは、MAILTO：それは公開されているようi-d-announce@ietf.org、すべてのインターネットドラフトの各新バージョンを発表しました。
Subscriptions to these and other IETF-run mailing lists are handled by a program called "mailman". Mailman can be somewhat finicky about the format of subscription messages, and sometimes interacts poorly with email programs that make all email messages into HTML files. Mailman will treat you well, however, if you format your messages just the way it likes.
これらおよび他のIETFランメーリングリストへのサブスクリプションは、「郵便配達人」と呼ばれるプログラムによって処理されます。 Mailmanは、サブスクリプション・メッセージのフォーマットについてやや気難しいこと、そして時にはHTMLファイルにすべての電子メールメッセージを作成し、電子メールプログラムと悪い相互作用することができます。あなたはそれが好きなだけの方法あなたのメッセージをフォーマットする場合Mailmanは、しかし、あなたによく扱います。
To join the IETF announcement list, for example, send email to mailto:ietf-announce-request@ietf.org. Enter the word 'subscribe' (without the quotes) in the Subject line of the message and in the message body. To join the IETF discussion list, send email to <mailto:ietf-request@ietf.org> and enter the word 'subscribe' as explained above. If you decide to withdraw from either list, use the word 'unsubscribe'. Your messages to mailman should have nothing other than the commands 'subscribe' or 'unsubscribe' in them. Both lists are archived on the IETF web site, http://www.ietf.org/maillist.html.
ietf-announce-request@ietf.org：IETFお知らせリストに参加するには、例えば、mailtoのに電子メールを送信。メッセージの件名行にし、メッセージ本文に（引用符なし）単語「サブスクライブ」を入力します。 IETFディスカッションリストに参加するには、にメールを送っ<MAILTO：ietf-request@ietf.org>と前述したように言葉は「購読」を入力。あなたはどちらのリストから撤退することを決定した場合は、「中止」の単語を使用しています。郵便配達のあなたのメッセージは「購読する」またはそれらに「中止」コマンド以外は何もないはずです。どちらのリストは、IETFのWebサイト、http://www.ietf.org/maillist.htmlにアーカイブされます。
Do not, ever, under any circumstances, for any reason, send a request to join a list to the list itself! The thousands of people on the list don't need, or want, to know when a new person joins. Similarly, when changing email addresses or leaving a list, send your request only to the "-request" address, not to the main list. This means you!!
これまで、どのような状況の下で、何らかの理由で、リスト自体にリストに参加するための要求を送信しないでください！リスト上の何千人もの人々は、新しい人が参加したときに知って、必要がある、またはしたくありません。メールアドレスを変更したり、リストを出るときも同様に、しないメインリストに、唯一の「-request」アドレスにリクエストを送信します。これはあなたの意味します！
The IETF discussion list is unmoderated. This means that all can express their opinions about issues affecting the Internet. However, it is not a place for companies or individuals to solicit or advertise, as noted in [BCP45], "IETF Discussion List Charter". It is a good idea to read the whole RFC (it's short!) before posting to the IETF discussion list. Actually, the list does have two "sergeants at arms" who keep an eye open for inappropriate postings, and there is a process for banning persistent offenders from the list, but fortunately this is extremely rare.
IETF議論リストがモデレートなしです。これは、すべてがインターネットに影響を与える問題について自分の意見を表現できることを意味します。 [BCP45]、「IETFディスカッションリスト憲章」で述べたようにしかし、それは、勧誘または広告する企業や個人のための場所ではありません。 IETFディスカッションリストに投稿する前に、（それは短いです！）全体のRFCを読むことをお勧めします。実際には、リストには不適切な投稿のために開いた目を離さない「アームで軍曹」2を持っているし、リストから永続的な犯罪者を禁止するためのプロセスがありますが、幸いこれは非常にまれです。
Only the Secretariat and certain IETF office holders can approve messages sent to the announcement list, although those messages can come from a variety of people.
これらのメッセージは、人々の様々なから来ることができますが、事務局と特定のIETFオフィスの所有者のみが、アナウンスメントリストに送信されたメッセージを承認することができます。
Even though the IETF mailing lists "represent" the IETF membership at large, it is important to note that attending an IETF meeting does not mean you'll be automatically added to either mailing list.
IETFメーリングリストは大でIETFのメンバーシップ「を表す」にもかかわらず、IETFミーティングに参加すると自動的にメーリングリストのいずれかに追加されます意味しないことに注意することは重要です。
The computer industry is rife with conferences, seminars, expositions, and all manner of other kinds of meetings. IETF face-to-face meetings are nothing like these. The meetings, held three times a year, are week-long "gatherings of the tribes" whose primary goal is to reinvigorate the WGs to get their tasks done, and whose secondary goal is to promote a fair amount of mixing between the WGs and the areas. The cost of the meetings is paid by the people attending and by the corporate host for each meeting (if any), although IASA kicks in additional funds for things such as the audio broadcast of some Working Group sessions.
コンピュータ業界は、会議、セミナー、展示会、および会議の他の種類のすべての方法でいっぱいです。 IETFフェイスツーフェイスの会議では、これらのような何もありません。年3回開催された会議は、第一の目標であるのWGを再活性化するために自分のタスクを成し遂げるために、そしてその第2の目標のWGとの間の混合のかなりの量を促進することである一週間の「部族の集まり」ですエリア。 IASAは、このようないくつかのワーキンググループセッションの音声放送としてのもののための追加資金でキックが会議のコストは、各会議（もしあれば）のために出席し、企業のホストによって人々によって支払われます。
For many people, IETF meetings are a breath of fresh air when compared to the standard computer industry conferences. There is no exposition hall, few tutorials, and no big-name industry pundits. Instead, there is lots of work, as well as a fair amount of time for socializing. IETF meetings are of little interest to sales and marketing folks, but of high interest to engineers and developers.
多くの人々のために、IETFミーティングは、標準的なコンピュータ業界の会議に比べて新鮮な空気の息です。何の博覧会会場、いくつかのチュートリアル、および無ビッグネームの業界の専門家はありません。代わりに、多くの作業だけでなく、社交のためにかなりの時間があります。 IETFミーティングはなく、エンジニアや開発者に関心の高い、販売およびマーケティングの人々にはほとんど関心があります。
Most IETF meetings are held in North America, because that's where most of the participants are from; however, meetings are held on other continents about once every year. The past few meetings have had about 1,300 attendees. There have been more than 65 IETF meetings so far, and a list of upcoming meetings is available on the IETF web pages, http://www.ietf.org/meetings/0mtg-sites.txt.
参加者のほとんどがからあるところそれはですので、ほとんどのIETF会議は、北米で開催されています。しかし、会議が一度毎年について他の大陸で開催されています。過去数会議はおよそ1300の参加者がありました。そここれまでに65回の以上のIETF会合して、および今後の会議のリストには、http://www.ietf.org/meetings/0mtg-sites.txtをIETFのWebページで提供されています。
Newcomers to IETF face-to-face meetings are often in a bit of shock. They expect them to be like other standards bodies, or like computer conferences. Fortunately, the shock wears off after a day or two, and many new attendees get quite animated about how much fun they are having. One particularly jarring feature of recent IETF meetings is the use of wireless Internet connections throughout the meeting space. It is common to see people in a WG meeting apparently reading email or perusing the web during presentations they find uninteresting. Remember, however, that they may also be consulting the drafts under discussion, looking up relevant material online, or following another meeting using instant messaging.
IETF対面会議への新規参入者は、衝撃のビットであることが多いです。彼らは、他の標準化団体等のコンピュータ会議のようなことを期待しています。幸いなことに、ショックは一日か二日後に切れる、と多くの新しい参加者は、彼らが持っているどのくらいの楽しみについてかなりのアニメーションを取得します。特に最近のIETF会議の機能を耳障り一つは、ミーティングスペース全体で無線インターネット接続を使用することです。 WG会議の人々は明らかに電子メールを読んだり、彼らはつまらない見つけるプレゼンテーション中にウェブを熟読参照するのが一般的です。彼らはまた、議論の下でドラフトに相談するオンライン関連の材料を見上げ、またはインスタントメッセージングを使用して別の会議を下記のこと、しかし、覚えておいてください。
To attend an IETF meeting, you have to register and you have to pay the registration fee. The meeting site and advance registration are announced about two months ahead of the meeting -- earlier if possible. An announcement goes out via email to the IETF-announce mailing list, and information is posted on the IETF web site, http://www.ietf.org, that same day.
IETF会議に出席するためには、登録する必要があり、あなたが登録料を支払わなければなりません。会議のサイトや事前登録は、約2カ月先の会議の発表している - 以前の可能であれば。発表は、IETF-announceメーリングリストに電子メールを介して出て行く、との情報は、IETFのWebサイト、http://www.ietf.org、その同じ日に掲載されています。
To pre-register, you must submit your registration on the web. You may pre-register and pre-pay, pre-register and return to the web site later to pay with a credit card, pre-register and pay on-site at the meeting, or register and pay on-site. To get a lower registration fee, you must pay by the early registration deadline (about one week before the meeting). The registration fee covers all of the week's meetings, the Sunday evening reception (cash bar), daily continental breakfasts, and afternoon coffee and snack breaks.
するには事前登録は、Web上で登録を提出しなければなりません。あなたは、事前に登録し、プリペイド、事前に登録して、クレジットカードでのお支払い事前に登録して、会議でオンサイト支払い、または登録し、オンサイトで支払うために、後のウェブサイトに戻ることができます。下の登録料を取得するには、（会議の前に一週間程度）早期登録期限までに支払わなければなりません。登録料は、一週間の会議、日曜日の夜のレセプション（現金バー）、毎日のコンチネンタルブレックファースト、アフタヌーンコーヒーや軽食休憩のすべてをカバーしています。
Credit card payments on the web are encrypted and secure, or, if you prefer, you can use Pretty Good Privacy (PGP) to send your payment information to the Registrar (mailto:ietf-registrar@ietf.org).
（：ietf-registrar@ietf.org mailtoの）ウェブ上のクレジットカードでのお支払いはお好みであれば、あなたが登録にお支払い情報を送信するためにプリティグッドプライバシー（PGP）を使用することができ、暗号化され、安全な、またはされています。
Registration is open throughout the week of the meeting. However, the Secretariat highly recommends that attendees arrive for early registration, usually beginning at noon on Sunday and continuing throughout the Sunday evening reception. The reception is a popular event where you can get a small bite to eat and socialize with other early arrivals.
登録は会議の週を通してオープンしています。しかし、事務局は非常参加者は通常、日曜日の正午に始まり、日曜日の夜のレセプションを通じて継続、早期登録のために到着することをお勧めします。レセプションでは、小さな一口食べると、他の早期到着と交流するために得ることができる人気のイベントです。
Registered attendees (and there aren't any other kind) receive a registration packet. It contains much useful information, including a general orientation sheet, the most recent agenda, and a name tag.
登録された参加者は、（および他の種類はありません）登録パケットを受け取ります。これは、一般的なオリエンテーションシート、最新の議題、および名札を含む多くの有用な情報が含まれています。
Attendees who pre-paid will also find their receipt in their packet. It's worth noting that neither attendee names and addresses nor IETF mailing lists are ever offered for sale.
-支払わ事前参加者はまた、彼らのパケットに自分のレシートを見つけます。これは、どちらの出席者の名前と住所もIETFメーリングリストがこれまで販売のために提供されていることは注目に値します。
In your registration packet is a sheet titled "Note Well". You should indeed read it carefully because it lays out the rules for IETF intellectual property rights.
ご登録パケットでは「まあ注意してください」というタイトルシートです。それはIETF知的財産権のルールをレイアウトするので、あなたは確かにそれを注意深く読んでください。
If you need to leave messages for other attendees, you can do so at the cork boards that are often near the registration desk. These cork boards will also have last-minute meeting changes and room changes.
あなたが他の参加者にメッセージを残すために必要がある場合は、登録デスクの近くにあることが多いコルクボードで行うことができます。これらのコルクボードはまた、直前のミーティングの変更や部屋の変更を持っています。
You can also turn in lost-and-found items to the registration desk. At the end of the meeting, anything left over from the lost and found will usually be turned over to the hotel or brought back to the Secretariat's office.
また、登録デスクへ遺失物アイテムに変えることができます。会議の終わりに、何が失われたから残され、通常のホテルに引き渡されるか、事務局のオフィスに戻されますました。
Incidentally, the IETF registration desk is often a convenient place to arrange to meet people. If someone says "meet me at registration", they almost always mean the IETF registration desk, not the hotel registration desk.
ちなみに、IETF登録デスクでは、多くの場合、人に会うように手配するのに便利な場所です。誰かが「登録時に私に会う」と言うならば、彼らはほとんど常にIETF登録デスクではなく、ホテルの登録デスクを意味します。
IETF meetings last from Monday morning through Friday lunchtime. Associated meetings often take place on the preceding or following weekends. It is best to plan to be present the whole week, to benefit from cross-fertilization between Working Groups and from corridor discussions. As noted below, the agenda is fluid, and there have been many instances of participants missing important sessions due to last-minute scheduling changes after their travel plans were fixed. Being present the whole week is the only way to avoid this annoyance.
IETF会議は金曜日のランチタイム月曜の朝から続きます。関連会合は、多くの場合、前後の週末に行われます。これは、ワーキンググループ間や廊下の議論からのクロス受精の恩恵を受けるために、一週間に存在することを計画してするのがベストです。以下に述べたように、議題は流体であり、そして彼らの旅行計画を固定した後、最後の分のスケジュール変更に伴う重要なセッションを逃す、参加者の多くのインスタンスがありました。一週間存在であることは、この煩わしさを回避するための唯一の方法です。
If you cannot find meetings all week to interest you, you can still make the most of the IETF meeting by working between sessions. Most IETF attendees carry laptop computers, and it is common to see many of them in the terminal room or in the hallways working during meeting sessions. There is often good wireless Internet coverage in many places of the meeting venue (restaurants, coffee shops, and so on), so catching up on email when not in meetings is a fairly common task for IETFers.
あなたが興味を起こさするすべての週会議を見つけることができない場合でも、セッション間で働くことによってIETFミーティングを最大限に活用することができます。ほとんどのIETFの参加者は、ラップトップコンピュータを運ぶ、そして、端末ルームまたはセッションを会議中に作業廊下でそれらの多くを見ることが一般的です。会場（ようにレストラン、コーヒーショップなど）の多くの場所で良い無線インターネットカバレッジは会議でIETFersためのかなり一般的なタスクではないときに、電子メールに追いつく、しばしばあります。
Newcomers are encouraged to attend the Newcomer Training, which is especially designed for first-time attendees. The orientation is organized and conducted by the IETF EDU team and is intended to provide useful introductory information. The session covers what's in the attendee packets, what all the dots on name tags mean, the structure of the IETF, and many other essential and enlightening topics for new IETFers.
新人は、特に初めての参加者のために設計された新人研修に出席することが奨励されています。オリエンテーションを整理し、IETF EDUチームによって行われ、有用な入門情報を提供することを目的としています。セッションは、出席者のパケットに何があるかカバー、ネームタグ上のすべてのドットが何を意味するか、IETFの構造、および新しいIETFersための多くの他の必須および啓発のトピック。
Immediately following the Newcomers' Training is the IETF Standards Process Orientation. This session demystifies much of the standards process by explaining what stages a document has to pass through on its way to becoming a standard, and what has to be done to advance to the next stage.
すぐに新人養成以下のIETF標準化プロセスのオリエンテーションがあります。このセッションでは、ドキュメントが標準になりつつに向かう途中で通過しなければならない、そして次の段階に進めるために行われなければならないものをステージ何説明することによって、標準化プロセスの多くをわかりやすく説明します。
There is usually ample time at the end for questions. The Secretariat provides hard copies of the slides of the "IETF Structure and Internet Standards Process" presentation -- these very useful slides are also available online at www.ietf.org under "Educational Materials".
質問のための終わりに十分な時間は、通常はあります。事務局は、「IETF構造とインターネット標準化プロセス」のプレゼンテーションのスライドのハードコピーを提供します - これらの非常に便利なスライドは、「教材」の下でも、www.ietf.orgからオンラインで入手できます。
The orientation is normally held on Sunday afternoon, along with tutorials of interest to newcomers and old-timers alike. Check the agenda for exact times and locations.
オリエンテーションは通常、同様の新規参入者と古いタイマーへの関心のチュートリアルと一緒に、日曜日の午後に開催されます。正確な時間と場所の議題を確認してください。
Since attendees must wear their name tags, they must also wear shirts or blouses. Pants or skirts are also highly recommended. Seriously though, many newcomers are often embarrassed when they show up Monday morning in suits, to discover that everybody else is wearing T-shirts, jeans (shorts, if weather permits) and sandals. There are those in the IETF who refuse to wear anything other than suits. Fortunately, they are well known (for other reasons) so they are forgiven this particular idiosyncrasy. The general rule is "dress for the weather" (unless you plan to work so hard that you won't go outside, in which case, "dress for comfort" is the rule!).
参加者が自分の名札を着用しなければならないので、彼らはまた、シャツやブラウスを着用しなければなりません。パンツやスカートも強くお勧めします。彼らは他のみんなは、Tシャツ、ジーンズ（パンツ、天候が許せば）とサンダルを履いていることを発見するために、スーツに月曜日の朝に現れたときに冗談はさておき、多くの新規参入者は、多くの場合、恥ずかしいです。スーツ以外のものを着用することを拒否者IETFのものがあります。幸いなことに、彼らは十分に（他の理由のために）知られているので、彼らは、この特定の特異性を赦され。一般的なルールは、「天気のためのドレス」（あなたが、その場合には、「快適さのためのドレスは」ルールです、外に行かないように努力する予定がない限り！）です。
Some of the people at the IETF will have a little colored dot on their name tag. A few people have more than one. These dots identify people who are silly enough to volunteer to do a lot of extra work. The colors have the meanings shown here.
IETFでの人々の中には、自分の名前タグにはほとんど色のドットを持つことになります。少数の人々は、1以上のものを持っています。これらの点は、余分な作業の多くを行うためにボランティアするのに十分な愚かな人を識別します。色は、ここに示した意味を持ちます。
Color Meaning
--------------------------------------
Blue Working Group/BOF chair
Green Host group
Red IAB member
Yellow IESG member
Orange Nominating Committee member
(Members of the press wear orange-tinted badges.)
（プレス摩耗オレンジがかったバッジのメンバー。）
Local hosts are the people who can answer questions about the terminal room, restaurants, and points of interest in the area.
ローカルホストは、端末室、レストラン、そして地域への関心のポイントについての質問に答えることができる人です。
It is important that newcomers to the IETF not be afraid to strike up conversations with people who wear these dots. If the IAB and IESG members and Working Group and BOF chairs didn't want to talk to anybody, they wouldn't be wearing the dots in the first place.
IETFへの新規参入者がこれらのドットを着る人との会話を打つことを恐れてはいけないことが重要です。 IABとIESGメンバーやワーキンググループとBOF椅子は誰にも話をしたくなかった場合、彼らは最初の場所にドットを身に着けていることはありません。
One of the most important (depending on your point of view) things the host does is provide Internet access for the meeting attendees. In general, wired and wireless connectivity is excellent. This is entirely due to the Olympian efforts of the local hosts and their ability to beg, borrow, and steal. The people and companies that donate their equipment, services, and time are to be heartily congratulated and thanked.
ホストはありません（あなたの視点に応じて）最も重要なことの一つは、会議の参加者のためのインターネットアクセスを提供します。一般的には、有線および無線接続性に優れています。これは、オリンピアローカルホストの努力と、物乞い借り、そして盗むする能力に全くによるものです。自社の機器、サービス、および時間を寄付する人や企業は、心から祝福と感謝されることになります。
Although preparation far in advance of the meeting is encouraged, there may be some unavoidable "last minute" things that can be accomplished in the terminal room. It may also be useful to people who need to make trip reports or status reports while things are still fresh in their minds.
これまでの会議の事前準備が奨励されているが、ターミナルの部屋で達成することができますいくつかの避けられない「土壇場」のものがあるかもしれません。また、物事が彼らの心にはまだ新鮮ですしながら、旅行レポートやステータスレポートを作成するために必要とする人々に有用である可能性があります。
You need to be wearing your badge in order to get into the terminal room. The terminal room provides lots of power strips, lots of Ethernet ports for laptops, wireless (for the people who don't need Ethernet but want power), usually a printer for public use, and sometimes workstations. What it doesn't provide are terminals; the name is historical. The help desk in the terminal room is a good place to ask questions about network failures, although they might point you off to different networking staff.
あなたは、端末の部屋に入るためにあなたのバッジを身に着けていることが必要です。端末室は、電源タップ、ラップトップ用のイーサネットポートをたくさん、（イーサネットを必要とするが、電源をしたくない人のための）無線、公共の使用のために通常のプリンタ、そして時にはワークステーションの多くを提供します。それは提供されませんどのような端末です。名前は歴史的なものです。ターミナル客室内にヘルプデスクは、異なるネットワークのスタッフにあなたを指している可能性がありますが、ネットワーク障害についての質問をするには良い場所です。
Marshall Rose once remarked that the IETF was a place to go for "many fine lunches and dinners". Although it is true that some people eat very well at the IETF, they find the food on their own; lunches and dinners are not included in the registration fee. The Secretariat does provide appetizers at the Sunday evening reception (not meant to be a replacement for dinner), continental breakfast every morning, and (best of all) cookies, brownies, and other yummies during afternoon breaks.
マーシャルローズはかつてIETFは、「多くの素晴らしいランチやディナー」のために行く場所だったと述べました。それは一部の人々はIETFで非常によく食べることは事実ですが、彼らは自分で食べ物を見つけます。ランチとディナーは、登録料に含まれていません。事務局は、午後の休憩中（夕食の代替となるものではありません）日曜日の夜のレセプションで、前菜、コンチネンタルブレックファースト毎朝、および（すべての最高の）クッキー、ブラウニー、およびその他のyummiesを提供します。
If you prefer to get out of the hotel for meals, the local host usually provides a list of places to eat within easy reach of the meeting site.
あなたが食事のためにホテルを出ることを好む場合は、ローカルホストは、通常、会議のサイトを簡単に手の届くところに食事をする場所のリストを提供します。
Another of the most important things organized and managed by the host is the IETF social event. Sometimes, the social event is a computer- or high-tech-related event. At one Boston IETF, for example, the social was dinner at the Computer Museum. Other times, the social might be a dinner cruise or a trip to an art gallery. Note, however, that not all IETF meetings have social events.
ホストによって組織され、管理最も重要なことのもう一つは、IETFの社会的なイベントです。時には、社会的なイベントは、コンピュータやハイテク関連のイベントです。 1ボストンIETFで、例えば、社会的には、コンピュータ博物館で夕食でした。他の回は、社会的にはディナークルーズやアートギャラリーへの旅かもしれません。いないすべてのIETF会議は社会的なイベントを持っていること、しかし、注意してください。
Newcomers to the IETF are encouraged to attend the social event. All are encouraged to wear their name tags and leave their laptops behind. The social event is designed to give people a chance to meet on a social, rather than technical, level.
IETFへの新規参入者は、社会的なイベントに参加することが奨励されています。すべては自分の名札を着用し、背後にある自分のノートパソコンを残すことをお勧めします。社会的なイベントは人々に、社会的ではなく、技術的なレベルで会う機会を与えるように設計されています。
The agenda for the IETF meetings is a very fluid thing. It is typically sent to the IETF announcement list a few times prior to the meeting, and it is also available on the web. The final agenda is included in the registration packets. Of course, "final" in the IETF doesn't mean the same thing as it does elsewhere in the world. The final agenda is simply the version that went to the printer. The Secretariat will post agenda changes on the bulletin board near the IETF registration desk (not the hotel registration desk). These late changes are not capricious: they are made "just in time" as session chairs and speakers become aware of unanticipated clashes. The IETF is too dynamic for agendas to be tied down weeks in advance.
IETF会議の議題は非常に流動的なものです。これは通常の会議に数回前にIETFアナウンスメントリストに送信され、そしてそれはまた、ウェブ上で利用可能です。最後の議題は、登録パケットに含まれています。もちろん、IETFでの「最終」とは、世界各地で同じように同じことを意味するものではありません。最後の議題は、単にプリンタへ行ってきましたバージョンです。事務局は、IETF登録デスク（ないホテルの登録デスク）付近の掲示板に議題の変更を掲載します。これらの最新の変更は気まぐれではありません。彼らは、セッションチェアとスピーカーが予期せぬ衝突に気付いとして「ジャストインタイム」作られています。 IETFは、事前に数週間縛られる課題はあまりにもダイナミックです。
Assignments for breakout rooms (where the Working Groups and BOFs meet) and a map showing the room locations are also shown on the agenda. Room assignments can change as the agenda changes. Some Working Groups meet multiple times during a meeting, and every attempt is made to have a Working Group meet in the same room for each session.
ブレイクアウト（ワーキンググループとBOFsが出会う）部屋と部屋の場所を示すマップの割り当ても議題に示されています。部屋の割り当ては、議題の変更として変更することができます。いくつかのワーキンググループは、会議中に複数回を満たし、かつすべての試みは、各セッションのために同じ部屋で作業部会の出会いを持つように作られています。
If certain aspects of the IETF still mystify you (even after you finish reading the Tao), you'll want to drop in on the on-site training offered by the Education (EDU) team. These informal classes are designed for newcomers and seasoned IETFers alike. In addition to the Newcomer Training, the EDU team offers workshops for document editors and Working Group chairs, plus an in-depth security tutorial that's indispensable for both novices and longtime IETF attendees. EDU sessions are generally held on Sunday afternoons. You'll find more about the EDU team at http://edu.ietf.org/.
IETFの特定の側面は、まだ（あなたはタオを読み終えた後でも）あなたを神秘場合は、教育（EDU）のチームが提供するオンサイトトレーニングに立ち寄りたいと思うでしょう。これらの非公式のクラスは、同様の新規参入者とベテランIETFersのために設計されています。新人研修に加えて、EDUチームは、文書の編集者やワーキンググループチェア、プラス初心者と長年のIETFの参加者の両方のために不可欠だの深いセキュリティチュートリアルのためのワークショップを提供しています。 EDUセッションは、一般的に日曜日の午後に開催されています。あなたはhttp://edu.ietf.org/でEDUチームについての詳細を見つけることができます。
The IETF is different things to different people. There are many people who have been very active in the IETF who have never attended an IETF meeting. You should not feel obligated to come to an IETF meeting just to get a feel for the IETF. The following guidelines (based on stereotypes of people in various industries) might help you decide whether you actually want to come and, if so, what might be the best use of your time at your first meeting.
IETFは、人によって異なるものです。 IETFミーティングに出席したことがありませんIETFで非常に活躍されている多くの人々があります。あなただけのIETFの感触を得るために、IETFミーティングに来てする義務を感じるべきではありません。 （様々な業界の人々の固定観念に基づいて）次のガイドラインは、あなたが実際に来てと、もしそうなら、何があなたの最初の会議で、あなたの時間を最大限に活用かもしれないかどうかを決定するのに役立つかもしれません。
As discussed throughout this document, an IETF meeting is nothing like any trade show you have attended. IETF meetings are singularly bad places to go if your intention is to find out what will be hot in the Internet industry next year. You can safely assume that going to Working Group meetings will confuse you more than it will help you understand what is happening, or will be happening, in the industry.
この文書を通して議論したように、IETFミーティングでは、参加したすべてのトレードショーのようなものは何もありません。 IETFミーティングはあなたの意図は、インターネット業界来年中にホットになるものを見つけるのであればどこへ行くか、単独悪い場所です。あなたは安全に作業部会の会合に行くことあなたにそれはあなたが何が起こっているかを理解するのに役立ちます、または業界では、起こっされるよりも多くを混同すると仮定することができます。
This is not to say that no one from the industry should go to IETF meetings. As an IS manager, you might want to consider sending specific people who are responsible for technologies that are under development in the IETF. As these people read the current Internet Drafts and the traffic on the relevant Working Group lists, they will get a sense of whether or not their presence would be worthwhile for your company or for the Working Groups.
これは、産業界からの誰もがIETFミーティングに行くべきではないということではありません。 ISマネージャは、IETFで開発が進められている技術を担当している特定の人を送ることを検討する必要があります。これらの人々は、現在のインターネットドラフトおよび関連するワーキンググループリスト上のトラフィックを読むと、彼らは彼らの存在は、あなたの会社のためやワーキンググループのために価値があるだろうかどうかの感覚を取得します。
Running a network is hard enough without having to grapple with new protocols or new versions of the protocols with which you are already dealing. If you work for the type of network that is always using the very latest hardware and software, and you are following the relevant Working Groups in your copious free time, you could certainly find participating in the IETF valuable. A fair amount of IETF work also covers many other parts of operations of ISPs and large enterprises, and the input of operators is quite valuable to keep this work vibrant and relevant. Many of the best operations documents from the IETF come from real-world operators, not vendors and academics.
ネットワークを実行すると、新しいプロトコルまたはすでに扱っているとプロトコルの新しいバージョンに取り組むことなく、十分に懸命です。あなたはいつも非常に最新のハードウェアおよびソフトウェアを使用しているネットワークのタイプのために働く、そしてあなたがあなたの豊富な自由な時間に関連するワーキンググループを以下している場合、あなたは確かにIETF貴重に参加して見つけることができます。 IETF仕事のかなりの量はまた、ISPや大企業の業務の他の多くの部分をカバーし、オペレータの入力は、活気に満ちた、関連するこの仕事を続けることは非常に貴重です。 IETFから最高業務文書の多くは、実世界の事業者ではなく、ベンダーや学者から来ます。
The image of the IETF being mostly ivory tower academics may have been true in the past, but the jobs of typical attendees are now in industry. In most areas of the IETF, employees of vendors are the ones writing the protocols and leading the Working Groups, so it's completely appropriate for vendors to attend. If you create Internet hardware or software, and no one from your company has ever attended an IETF meeting, it behooves you to come to a meeting if for no other reason than to tell the others how relevant the meeting was or was not to your business.
IETFは、ほとんどが象牙の塔の学者であることのイメージは過去に真であったかもしれないが、典型的な参加者の仕事は、業界になりました。 IETFのほとんどの地域では、ベンダーの従業員は、それはベンダーが参加するのは完全に適切ですので、プロトコルを書き込み、ワーキンググループをリードするものです。あなたは、インターネットのハードウェアやソフトウェアを作成し、あなたの会社から、誰もIETF会議に出席していない場合、それは会議があったか、またはあなたのビジネスにはなかったどのように関連する他の人に伝えるためによりも、他の理由であれば、会議に来て、あなたを不可欠な時代。
This is not to say that companies should close up shop during IETF meeting weeks so everyone can go to the meeting. Marketing folks, even technical marketing folks, are usually safe in staying away from the IETF as long as some of the technical people from the company are at the meeting. Similarly, it isn't required, or likely useful, for everyone from a technical department to go, particularly if they are not all reading the Internet Drafts and following the Working Group mailing lists. Many companies have just a few designated meeting attendees who are chosen for their ability to do complete and useful trip reports. In addition, many companies have internal coordination efforts and a standards strategy. If a company depends on the Internet for some or all of its business, the strategy should probably cover the IETF.
これは、誰もが会議に行くことができるので、企業はIETFミーティング週間の間、店を閉めなければならないということではありません。マーケティングの人々、でも技術的なマーケティングの人々は、限り、企業からの技術的な人々の何人かが会議であると離れIETFから滞在中は通常安全です。彼らはすべてのインターネットドラフトを読んで、ワーキンググループのメーリングリストを以下でない場合は特に、行くために技術部門から皆のために、同様に、必要とされていない、または可能性が便利。多くの企業は、完全かつ有益な旅行レポートを実行する能力に関して選択され、わずか数指定された会議の参加者があります。また、多くの企業は、内部の調整努力と基準戦略を持っています。同社は事業の一部またはすべてのためにインターネットに依存している場合、戦略はおそらく、IETFをカバーする必要があります。
IETF meetings are often excellent places for computer science folks to find out what is happening in the way of soon-to-be-deployed protocols. Professors and grad students (and sometimes overachieving undergrads) who are doing research in networking or communications can get a wealth of information by following Working Groups in their specific fields of interest. Wandering into different Working Group meetings can have the same effect as going to symposia and seminars in your department. Researchers are also, of course, likely to be interested in IRTF activities.
IETFミーティングは、多くの場合、すぐツー・展開されたプロトコルの方法で何が起こっているのかを知るためにコンピュータサイエンスの人々のための優れた場所です。ネットワークまたは通信の研究を行っている教授や大学院生（そして時にはoverachieving学部生）は、興味のある特定の分野でワーキンググループを以下により豊富な情報を得ることができます。別のワーキンググループの会合にさまようことはあなたの部署のシンポジウムやセミナーに行くのと同じ効果を持つことができます。研究者たちは、もちろん、また、IRTFの活動に興味がある可能性が高いです。
If you're a member of the press and are considering attending IETF, we've prepared a special section of the Tao just for you -- please see Section 10.2.
10.2節を参照してください - あなたは、プレスの一員だとIETFに参加して検討している場合、私たちはあなたのためだけタオの特別なセクションを用意しました。
IETF proceedings are compiled in the two months following each meeting and are available on the web and on CD. Be sure to look through a copy -- the proceedings are filled with information about IETF that you're not likely to find anywhere else. For example, you'll find snapshots of most WG charters at the time of the meeting, giving you a better understanding of the evolution of any given effort.
IETFの手続は、各会合後2ヶ月でコンパイルされ、ウェブ上やCDで利用できます。コピーに目を通すようにしてください - 議事は、あなたがどこにも見つけることはそうじゃないIETFの情報で満たされています。たとえば、あなたはあなたの任意の努力の進化の理解を与えて、会議の時に最もWG憲章のスナップショットを見つけることができます。
The proceedings sometimes start with an informative (and highly entertaining) message. Each volume contains the final (hindsight) agenda, an IETF overview, area and Working Group reports, and slides from the protocol and technical presentations. The Working Group reports and presentations are sometimes incomplete, if the materials haven't been turned in to the Secretariat in time for publication.
議事録は、時々有益な（そして非常に面白い）メッセージで始まります。各ボリュームは、最終的な（結果論）議題、IETFの概要、地域及び作業部会報告書が含まれており、プロトコルおよび技術的なプレゼンテーションからスライド。材料は、出版のための時間に事務局になっていない場合は作業部会の報告書やプレゼンテーションは、時々不完全です。
An attendee list is also included, which contains names and affiliations as provided on the registration form. For information about obtaining copies of the proceedings, see the web listing at http://www.ietf.org/proceedings/directory.html.
出席者リストにも登録フォームに提供される名前と所属を含む、含まれています。議事録のコピーの取得については、http://www.ietf.org/proceedings/directory.htmlでウェブのリストを参照してください。
The IETF Secretariat, and IETFers in general, are very approachable. Never be afraid to approach someone and introduce yourself. Also, don't be afraid to ask questions, especially when it comes to jargon and acronyms.
一般的にIETF事務局、およびIETFersは、非常に親しみやすいです。誰かに近づき、自分自身を紹介することを恐れてはいけません。また、それは専門用語と略語に来る場合は特に、質問をすることを恐れてはいけません。
Hallway conversations are very important. A lot of very good work gets done by people who talk together between meetings and over lunches and dinners. Every minute of the IETF can be considered work time (much to some people's dismay).
廊下での会話は非常に重要です。非常に良い多くの作業は、会議の間とランチとディナーの上に一緒に話を人々によって行われます。 IETFの毎分は、（一部の人々の落胆に多くの）作業時間とみなすことができます。
A "bar BOF" is an unofficial get-together, usually in the late evening, during which a lot of work gets done over drinks. Bar BOFs spring up in many different places around an IETF meeting, such as restaurants, coffee shops, and (if we are so lucky) pools.
「バーBOFは」多くの作業が飲み物を介して行われますその間、通常、夜遅くに、非公式の集まりです。バーBOFsは、レストラン、コーヒーショップ、および（私たちはとても幸運であれば）プールとしてIETFミーティングの周りのさまざまな場所に跳ね上がります。
It's unwise to get between a hungry IETFer (and there isn't any other kind) and coffee break brownies and cookies, no matter how interesting a hallway conversation is.
それは空腹IETFer間で取得するために賢明だ（およびその他の種類はありません）、コーヒーに関係なく、廊下の会話がどのように面白い、ブラウニーやクッキーを壊しません。
IETFers are fiercely independent. It's safe to question opinions and offer alternatives, but don't expect an IETFer to follow orders.
IETFersは激しく独立しています。それは意見を疑問視し、代替案を提供していますが、命令に従うためにIETFerを期待していないために安全です。
The IETF meetings, and the plenary session in particular, are not places for vendors to try to sell their wares. People can certainly answer questions about their company and its products, but bear in mind that the IETF is not a trade show. This does not preclude people from recouping costs for IETF-related T-shirts, buttons, and pocket protectors.
IETFミーティング、特に本会議では、自社製品を販売しようとするベンダーの場ではありません。人々は確かに自分の会社とその製品についての質問に答えるが、IETFは、トレードショーではないことを心に留めすることができます。これは、IETF関連のTシャツ、ボタン、ポケットプロテクターのためのコストをrecoupingから人々を妨げるものではありません。
There is always a "materials distribution table" near the registration desk. This desk is used to make appropriate information available to the attendees (e.g., copies of something discussed in a Working Group session, descriptions of online IETF-related information). Please check with the Secretariat before placing materials on the desk; the Secretariat has the right to remove material that he or she feels is not appropriate.
登録デスクの近くに「材料分布表は、」常にあります。この机は、出席者に適切な情報を利用できるようにするために使用される（例えば、ワーキンググループセッションで議論何かのコピー、オンラインIETF関連情報の記述）。机の上に材料を配置する前に、事務局に確認してください。事務局は、彼または彼女が適切ではないと感じる物質を除去する権利を有します。
If you rely on your laptop during the meeting, it is a good idea to bring an extra battery. It is not always easy to find a spare outlet in some meeting rooms, and using the wireless access can draw down your battery faster than you might expect. If you are sitting near a power-strip in a meeting room, expect to be asked to plug and unplug for others around you. Many people bring an extension cord with spare outlets, which is a good way to make friends with your neighbor in a meeting. If you need an outlet adapter, you should try to buy it in advance because the one you need is usually easier to find in your home country.
あなたが会議中にあなたのラップトップに依存している場合、予備のバッテリーを持参することをお勧めします。いくつかの会議室で予備コンセントを見つけ、そしてより速くあなたが想像するよりあなたのバッテリーを下に描くことができ、ワイヤレスアクセスを使用することは必ずしも容易ではありません。あなたが会議室でパワーストリップの近くに座っている場合は、プラグインとあなたの周りの他の人のために抜くように頼まれることを期待します。多くの人が会議にあなたの隣人で友達を作るための良い方法である、予備コンセントに延長コードを持参します。あなたはコンセントアダプタが必要な場合は、あなたが必要とする1は通常、自分の国で見つけることは簡単ですので、事前にそれを購入してみてください。
The vast majority of the IETF's work is done in many Working Groups; at the time of this writing, there are about 115 different WGs. (The term "Working Group" is often seen capitalized, but probably not for any good reason.) [BCP25], "IETF Working Group Guidelines and Procedures", is an excellent resource for anyone participating in WG discussions.
IETFの仕事の大半は、多くのワーキンググループで行われます。この記事の執筆時点で、約115異なるのWGがあります。 [BCP25]、「IETFワーキンググループガイドラインと手順」（「ワーキンググループ」が、多くの場合、何らかの正当な理由のために大文字で見て、おそらくされていません。用語）は、WGの議論に参加する人のための優れたリソースです。
A WG is really just a mailing list with a bit of adult supervision. You "join" the WG by subscribing to the mailing list; all mailing lists are open to anyone. Anyone can post to a WG mailing list, although most lists require non-subscribers to have their postings moderated. Each Working Group has one or two chairs.
WGは本当に大人の監督のビットを持つだけのメーリングリストです。あなたは、メーリングリストに加入することにより、WGを「参加します」。すべてのメーリングリストは誰にでも開かれています。ほとんどのリストは自分の投稿を司会持っているために、非加入者を必要とするが、誰もが、WGメーリングリストに投稿することができます。各ワーキンググループは、1つのまたは2つの椅子を持っています。
More important, each WG has a charter that the WG is supposed to follow. The charter states the scope of discussion for the Working Group, as well as its goals. The WG's mailing list and face-to-face meetings are supposed to focus on just what is in the charter and not to wander off on other "interesting" topics. Of course, looking a bit outside the scope of the WG is occasionally useful, but the large majority of the discussion should be on the topics listed in the charter. In fact, some WG charters actually specify what the WG will not do, particularly if there were some attractive but nebulous topics brought up during the drafting of the charter. The list of all WG charters makes interesting reading for folks who want to know what the different Working Groups are supposed to be doing.
さらに重要なのは、各WGは、WGが続くことになっている憲章を持っています。憲章は、ワーキンググループの議論の範囲だけでなく、その目標を述べています。 WGのメーリングリストと対面会議がチャーターしているだけで何に集中し、他の「面白い」話題にそれるしないようになっています。もちろん、WGの範囲外のビットを探して時には便利ですが、議論の大部分は、憲章に記載されて話題にする必要があります。実際には、いくつかのWGは、憲章の起草中に育っいくつかの魅力が、漠然とした話題があった場合は特に、実際に、WGはないだろうかを指定チャーター。すべてのWGのチャーターのリストは、異なるワーキンググループがやっていることになっているかを知りたい人々のための興味深い読書になります。
The role of the WG chairs is described in both [BCP11] and [BCP25]. The IETF EDU team also offers special training for WG chairs on Sunday afternoons preceding IETF.
WGチェアの役割は、[BCP25]の両方[BCP11]に記載されています。 IETF EDUチームはまた、IETFの前の日曜日の午後にWGチェアのための特別な訓練を提供しています。
As volunteer cat-herders, a chair's first job is to determine the WG consensus goals and milestones, keeping the charter up to date. Next, often with the help of WG secretaries or document editors, the chair must manage WG discussion, both on the list and by scheduling meetings when appropriate. Sometimes discussions get stuck on contentious points and the chair may need to steer people toward productive interaction and then declare when rough consensus has been met and the discussion is over. Sometimes chairs also manage interactions with non-WG participants or the IESG, especially when a WG document approaches publication. Chairs have responsibility for the technical and non-technical quality of WG output. As you can imagine given the mix of secretarial, interpersonal, and technical demands, some Working Group chairs are much better at their jobs than others.
ボランティア猫飼いとして、椅子の最初の仕事は、最新のチャーターを保ち、WGコンセンサス目標とマイルストーンを決定することです。次に、多くの場合、WG幹事または文書の編集者の助けを借りて、椅子はリストにし、必要に応じて会議をスケジュールすることによって、両方の、WGの議論を管理する必要があります。時には議論が論争のポイントにはまり込むと椅子が生産的な相互作用に向けて人々を操縦して、ラフコンセンサスが満たされているとの議論が終わった時に宣言する必要があるかもしれません。時にはまた、WG文書が公表に近づいた場合は特に、非WGの参加者やIESGとの相互作用を管理する椅子。議長は、WG出力の技術的および非技術的な品質に責任を持っています。あなたは、秘書対人、および技術的な要求のミックス与えられた想像できるように、いくつかの作業部会の議長は他よりも自分の仕事に非常に優れています。
When a WG has fulfilled its charter, it is supposed to cease operations. (Most WG mailing lists continue on after a WG is closed, still discussing the same topics as the Working Group did.) In the IETF, it is a mark of success that the WG closes up because it fulfilled its charter. This is one of the aspects of the IETF that newcomers who have experience with other standards bodies have a hard time understanding. However, some WG chairs never manage to get their WG to finish, or keep adding new tasks to the charter so that the Working Group drags on for many years. The output of these aging WGs is often not nearly as useful as the earlier products, and the messy results are sometimes attributed to what's called "degenerative Working Group syndrome".
WGは、その憲章を満たした場合は、操作を中止することになっています。 （WGを閉じた後、ほとんどWGメーリングリストはワーキンググループが行ったように、まだ同じトピックを議論、続行。）IETFでは、その憲章を満たしているため、それは、WGがアップ閉じることの成功の印です。これにより、他の標準化団体での経験を持っている新規参入者が苦労の理解を持っているIETFの側面の1つです。しかし、いくつかのWGチェアが終了、またはワーキンググループは、長年にわたって上のドラッグようにチャーターに新しいタスクを追加し続けるために彼らのWGを取得するために管理することはありません。これらの老化のWGの出力は、多くの場合、以前の製品ほど有用ではありません、そして厄介な結果は時々「退行性ワーキンググループ症候群」と呼ばれるものに起因しています。
There is an official distinction between WG drafts and independent drafts, but in practice, sometimes there is not much procedural difference. For example, many WG mailing lists also discuss independent drafts (at the discretion of the WG chair). Procedures for Internet Drafts are covered in much more detail later in this document.
WGドラフトと独立したドラフトの間、公式の区別はありますが、実際には、時には多くの手続きの違いはありません。例えば、多くのWGメーリングリストも（WGチェアの裁量で）独立したドラフトを議論します。インターネットドラフトの手順は、このドキュメントの後半ではるかに詳細に覆われています。
WG chairs are strongly advised to go to the WG leadership training that usually happens on the Sunday preceding the IETF meeting. There is also usually a WG chairs lunch mid-week during the meeting where chair-specific topics are presented and discussed. If you're interested in what they hear there, take a look at the slides at http://edu.ietf.org/.
WGチェアが強く、通常はIETFミーティングの前の日曜日に起こるWGリーダーシップ研修に行くことをお勧めします。通常、WGは、椅子、特定のトピックを提示し、議論されている会議中に昼食週半ばの椅子もあります。あなたは、彼らがそこに聞くに興味があるなら、http://edu.ietf.org/でスライドを見てみましょう。
One fact that confuses many novices is that the face-to-face WG meetings are much less important in the IETF than they are in most other organizations. Any decision made at a face-to-face meeting must also gain consensus on the WG mailing list. There are numerous examples of important decisions made in WG meetings that are later overturned on the mailing list, often because someone who couldn't attend the meeting pointed out a serious flaw in the logic used to come to the decision. Finally, WG meetings aren't "drafting sessions", as they are in some other standards bodies: in the IETF, drafting is done elsewhere.
多くの初心者を混乱一つの事実が対面WG会議は、彼らが他のほとんどの組織であるよりも、IETFにそれほど重要なことです。対面会議で行われたすべての決定はまた、WGメーリングリスト上の合意を得なければなりません。会議に出席することができませんでした誰かが意思決定に来るために使用されるロジックに重大な欠陥を指摘が多いので、後に、メーリングリストで覆されWGの会合で行われた重要な意思決定の多くの例があります。彼らは他のいくつかの標準化団体である最後に、WGの会合では、「製図セッション」ではありません：IETFで、起草は別の場所で行われます。
Another aspect of Working Groups that confounds many people is the fact that there is no formal voting. The general rule on disputed topics is that the Working Group has to come to "rough consensus", meaning that a very large majority of those who care must agree. The exact method of determining rough consensus varies from Working Group to Working Group. Sometimes consensus is determined by "humming" -- if you agree with a proposal, you hum when prompted by the chair; if you disagree, you keep your silence. Newcomers find it quite peculiar, but it works. It is up to the chair to decide when the Working Group has reached rough consensus.
多くの人々を困惑ワーキンググループの別の態様は、正式な議決権が存在しないという事実です。係争のトピックに関する一般的なルールは、ワーキンググループが気にこれらの非常に大多数が同意しなければならないことを意味し、「ラフコンセンサス」に来ているということです。ラフコンセンサスを決定する正確な方法は、作業部会にワーキンググループによって異なります。時々、コンセンサスは「ハミング」によって決定されます - あなたは提案に同意する場合は、ハムは椅子によって求められたとき。あなたが同意しない場合、あなたはあなたの沈黙を保ちます。新人はそれが非常に独特見つけるが、それは動作します。これは、ワーキンググループがラフコンセンサスに達したときを決定するために椅子に任されています。
The lack of formal voting has caused some very long delays for some proposals, but most IETF participants who have witnessed rough consensus after acrimonious debates feel that the delays often result in better protocols. (And, if you think about it, how could you have "voting" in a group that anyone can join, and when it's impossible to count the participants?) Rough consensus has been defined in many ways; a simple version is that it means that strongly held objections must be debated until most people are satisfied that these objections are wrong.
正式な議決権の欠如は、いくつかの提案のためのいくつかの非常に長い遅延が発生しているが、辛辣な議論の後にラフコンセンサスを目撃した最もIETFの参加者は、遅延は、多くの場合、よりよいプロトコルになると感じています。 （そして、あなたはそれについて考える場合、どのように誰もが参加できるというグループに「投票」を持って、それは参加者をカウントすることは不可能だときだろうか？）ラフコンセンサスが多くの方法で定義されています。シンプルなバージョンは、それはほとんどの人がこれらの異議が間違っていることを満足するまで強く開催異議を議論しなければならないことを意味していることです。
Some Working Groups have complex documents or a complex set of documents (or even both). Shaking all the bugs out of one or more complex documents is a daunting task. In order to help relieve this problem, some Working Groups use "issue trackers", which are online lists of the open issues with the documents, the status of the issue, proposed fixes, and so on. Using an issue tracker not only helps the WG not to forget to do something important, it helps when someone asks a question later about why something was done in a particular fashion.
いくつかのワーキンググループは、複雑な文書または文書（あるいはその両方）の複雑なセットを持っています。一つ以上の複雑な文書のうち、すべてのバグを振ることは困難な作業です。この問題を和らげるためには、いくつかのワーキンググループには、コンピュータ上の文書、問題の状況、提案の修正、およびオープンな問題のオンラインリストである「課題追跡」を、使用しています。課題追跡を使用すると、重要な何かをすることを忘れないようにWGを助け、誰かが何かを特定の方法で行われた理由については、後で質問をするときに役立つだけでなく。
Another method that some Working Groups adopt is to have a Working Group "secretary" to handle the juggling of the documents and the changes. The secretary can run the issue tracker if there is one, or can simply be in charge of watching that all of the decisions that are made on the mailing list are reflected in newer versions of the documents.
いくつかのワーキンググループが採用してもう一つの方法は、文書や変更のジャグリングを処理するためにワーキンググループ「秘書」を持つことです。秘書は1がある場合、問題追跡を実行することができ、または単にメーリングリストで行われている意思決定の全てが文書の新しいバージョンに反映されていることを見ているの担当することができます。
One thing you might find helpful, and possibly even entertaining, during Working Group sessions is to follow the running commentary on the Jabber room associated with that Working Group. The running commentary is often used as the basis for the minutes of the meeting, but it can also include jokes, sighs, and other extraneous chatter. Jabber is a free, streaming XML technology mainly used for instant messaging. You can find pointers to Jabber clients for many platforms at http://www.jabber.org. The Jabber chatrooms have the name of the Working Group followed by "@jabber.ietf.org". Those rooms are, in fact, available year-round, not just during IETF meetings, and some are used by active Working Group participants during protocol development.
あなたはワーキンググループセッション中、便利、そして可能性も面白いかもしれません一つは、そのワーキンググループに関連付けられているJabberの部屋に実行されている解説に従うことです。実行中の論評は、多くの場合、会議の議事録のための基礎として使用されるが、それはまた、ジョーク、ため息、および他の外来おしゃべりを含めることができます。 Jabberのは、主にインスタントメッセージングのために使用されるフリー、ストリーミングXML技術です。あなたはhttp://www.jabber.orgで多くのプラットフォーム用のJabberクライアントへのポインタを見つけることができます。 Jabberチャットルームには、「@ jabber.ietf.org」に続くワーキンググループの名前を持っています。これらの部屋は、実際には、IETFミーティング中だけで利用できる年間、ではない、といくつかは、プロトコルの開発中にアクティブなワーキンググループの参加者によって使用されています。
The most important thing that everyone (newcomers and seasoned experts) should do before coming to a face-to-face meeting is to read the Internet Drafts and RFCs ahead of time. WG meetings are explicitly not for education: they are for developing the group's documents. Even if you do not plan to say anything in the meeting, you should read the group's documents before attending so you can understand what is being said.
皆（新規参入者とベテランの専門家）が対面会議に来る前にやるべきことが最も重要なことは、事前にインターネットドラフトやRFCを読むことです。 WG会議は、教育のために、明示的ではありません。彼らはグループのドキュメントを開発するためのものです。あなたが会議で何も言うことを計画していない場合でも、あなたが言われていることを理解することができるように参加する前に、グループのドキュメントをお読みください。
It's up to the WG chair to set the meeting agenda, usually a few weeks in advance. If you want something discussed at the meeting, be sure to let the chair know about it. The agendas for all the WG meetings are available in advance (see http://www.ietf.org/meetings/wg_agenda_xx.html, where 'xx' is the meeting number), but many WG chairs are lax (if not totally negligent) about turning them in.
これは、会議の議題、事前に通常は数週間を設定するには、WGの議長次第です。あなたが会議で議論何かをしたい場合は、議長はそれについて知っているようにしてください。すべてのWG会議の議題は、（ 'xxは会の数であり、http://www.ietf.org/meetings/wg_agenda_xx.htmlを参照してください）事前に用意されていますが、多くのWGいすは完全に過失はない場合（緩いです）でそれらを回しについて。
The Secretariat only schedules WG meetings a few weeks in advance, and the schedule often changes as little as a week before the first day. If you are only coming for one WG meeting, you may have a hard time booking your flight with such little notice, particularly if the Working Group's meeting changes schedule. Be sure to keep track of the current agenda so you can schedule flights and hotels. But, when it comes down to it, you probably shouldn't be coming for just one WG meeting. It's likely that your knowledge could be valuable in a few WGs, assuming that you've read the drafts and RFCs for those groups.
事務局は、唯一のスケジュールWG会議事前に数週間、およびスケジュールは、多くの場合、最初の日の前の週のようにほとんど変化しません。あなたが唯一のWG会議のために来ている場合は、作業部会の会議はスケジュールを変更する場合は特に、そのような少し予告でフライトをご予約の苦労を有することができます。あなたはフライトとホテルをスケジュールすることができるように、現在の議題を追跡してください。それはそれまで来るときしかし、あなたはおそらくちょうど1回のWGの会合のために来てはいけません。それはあなたの知識は、あなたがそれらのグループのためのドラフトやRFCを読んだと仮定して、いくつかのWGに貴重であることができると思われます。
If you are on the agenda at a face-to-face meeting, you should probably come with a few slides prepared. But don't come with a tutorial; people are supposed to read the drafts in advance. Projectors for laptop-based presentations are available in all the meeting rooms.
あなたは対面会議で議題にしている場合は、おそらく準備いくつかのスライドが付属していなければなりません。しかし、チュートリアルが付属していません。人は、事前にドラフトを読むことになっています。ラップトップ・ベースのプレゼンテーションのためのプロジェクターは、すべての会議室でご利用いただけます。
And here's a tip for your slides in WG or plenary presentations: don't put your company's logo on every one, even though that is a common practice outside the IETF. The IETF frowns on this kind of corporate advertising (except for the meeting sponsor in the plenary presentation), and most presenters don't even put their logo on their opening slide. The IETF is about technical content, not company boosterism. Slides are often plain black and white for legibility, with color used only when it really adds clarity. Again, the content is the most important part of the slides, not how it's presented.
そして、ここでWGや本会議のプレゼンテーションでのスライドのためのヒントです：それはIETF外の一般的な方法であるにも関わらず、一人一人に会社のロゴを入れてはいけません。 （総会のプレゼンテーションでの会議のスポンサーを除く）企業広告のこの種のIETFしかめ面、そしてほとんどのプレゼンターも自分のオープニングスライドに自分のロゴを入れていません。 IETFは、技術的な内容ではなく、会社のboosterismについてです。スライドはそれが本当に明快を追加した場合にのみ使用されるカラーで、多くの場合、読みやすさのための無地の黒と白です。ここでも、コンテンツは、それが提示していますではないか、スライドの最も重要な部分です。
As we mentioned earlier, the IETF announcement and discussion mailing lists are the central mailing lists for IETF activities. However, there are many other mailing lists related to IETF work. For example, every Working Group has its own discussion list. In addition, there are some long-term technical debates that have been moved off of the IETF list onto lists created specifically for those topics. It is highly recommended that you follow the discussions on the mailing lists of the Working Groups that you wish to attend. The more work that is done on the mailing lists, the less work that will need to be done at the meeting, leaving time for cross pollination (i.e., attending Working Groups outside one's primary area of interest in order to broaden one's perspective).
我々は先に述べたように、IETF発表と議論メーリングリストはIETF活動の中心的なメーリングリストです。しかし、IETF仕事に関連する他の多くのメーリングリストがあります。たとえば、すべてのワーキンググループは、独自のディスカッションリストを持っています。また、これらのトピックのために特別に作成したリストにIETFリストの外に移動されているいくつかの長期的な技術の議論があります。非常にあなたが参加を希望するワーキンググループのメーリングリストでの議論に従うことをお勧めします。メーリングリスト上で行われているより多くの仕事、（すなわち、自分の視野を広げるための関心の一つの主要エリア外の作業部会への出席）他家受粉のための時間を残して、会議で実行する必要があります少ない作業。
The mailing lists also provide a forum for those who wish to follow, or contribute to, the Working Groups' efforts, but can't attend the IETF meetings. That's why IETF procedures require all decisions to be confirmed "on the list" and you will often hear a WG chair say, "Let's take it to the list" to close a discussion.
メーリングリストも続く、またはワーキンググループの努力に貢献したい人のためのフォーラムを提供しますが、IETF会合に出席することはできません。 IETFの手順は、「リストに」を確認するすべての決定が必要とし、多くの場合、WGの議長は討論を閉じるには「のリストにそれを見てみましょう」、言うのを聞くだろう理由です。
Many IETF discussion lists use either mailman or another list manager, Majordomo. They usually have a "-request" address that handles the administrative details of joining and leaving the list. (See Section 3.3 for more information on mailman.) It is generally frowned upon when such administrivia appears on the discussion mailing list.
多くのIETFディスカッションリストは、郵便配達や他のリストマネージャ、Majordomoのいずれかを使用します。彼らは通常、リストに参加して去るの管理詳細を処理する「-request」のアドレスを持っています。 （郵便配達の詳細については、セクション3.3を参照してください。）これは、一般的に、このようなadministriviaディスカッションメーリングリストに表示されたときにひんしゅくを買うされます。
Most IETF discussion lists are archived. That is, all of the messages sent to the list are automatically stored on a host for anonymous HTTP or FTP access. Many such archives are listed online at ftp://ftp.ietf.org/ietf-mail-archive/ or they are in a web-based archive. If you don't find the list you're looking for, send a message to the list's "-request" address (not to the list itself!). The Working Group charter listings at http://www.ietf.org/html.charters/wg-dir.html are a useful source; note that the page has links to old, concluded WGs.
ほとんどのIETF議論リストがアーカイブされます。これは、リストに送信されたメッセージのすべてが自動的に匿名のHTTPまたはFTPアクセスのためのホスト上に格納されている、です。多くのそのようなアーカイブはftp://ftp.ietf.org/ietf-mail-archive/でオンラインでリストされているか、彼らはウェブベースのアーカイブにあります。あなたが探しているリストが見つからない場合は、リストの「-request」アドレス（ないリスト自体に！）にメッセージを送信します。 http://www.ietf.org/html.charters/wg-dir.htmlのワーキンググループのチャーターリストは便利なソースです。ページが古いへのリンクを持っていることに注意し、各WG結論付けました。
Some WG lists apply size limits on messages, particularly to avoid large documents or presentations landing in everyone's mailbox. It is well worth remembering that participants do not all have broadband connections (and even those with broadband connections sometimes get their mail on slow connections when they travel), so shorter messages are greatly appreciated. Documents can be posted as Internet Drafts; presentation material can be posted to a web site controlled by the sender or sent personally to people who ask for it. Some WGs set up special sites to hold these large documents so that senders can post there first, then just send to the list the URL of the document.
いくつかのWGリストは、特に大規模な文書やすべての人のメールボックスに着陸プレゼンテーションを避けるために、メッセージのサイズ制限を適用します。短いメッセージが大幅に高く評価されているので、参加者はすべての接続をブロードバンドれていない（と彼らが旅行するときにも、これらのブロードバンド接続では時々低速接続で自分のメールを取得する）ことを覚えておく価値があります。ドキュメントはインターネットドラフトとして掲載することができます。プレゼンテーション資料は、送信者によって制御されるウェブサイトに掲載またはそれを求める人に個人的に送信することができます。いくつかのWGは、送信者が最初にそこに投稿できるように、これらの大規模な文書を保持し、その後リストだけにドキュメントのURLを送信するために特別なサイトを設定しました。
Working Groups sometimes hold interim meetings between IETFs. Interim meetings aren't a substitute for IETF meetings, however -- a group can't decide to skip a meeting in a location they're not fond of and meet in Cancun (or even someplace mundane) three weeks later, for example. Interim meetings require AD approval and need to be announced at least one month in advance. Location and timing need to allow fair access for all participants. Like regular IETF meetings, someone needs to take notes and send them to mailto:proceedings@ietf.org, and the group needs to take attendance. Decisions tentatively made during an interim WG meeting still must be ratified on the mailing list.
ワーキンググループは時々IETFs間の中間会合を開催しています。暫定会議はしかし、IETFミーティングに代わるものではありません - 基としては、例えば、彼らは好きじゃない場所で会議をスキップし、3週間後にカンクン（あるいはどこか世俗的な）に適合するように決定することはできません。暫定会議はADの承認を必要とし、事前に少なくとも1ヶ月に発表する必要があります。場所とタイミングがすべての参加者のための公平なアクセスを許可する必要があります。通常のIETFミーティングのように、誰かがノートを取り、MAILTOにそれらを送信する必要がある：proceedings@ietf.org、およびグループは、出席を取る必要があります。仮に暫定WG会議中に行われた決定はまだメーリングリストで批准されなければなりません。
In order to form a Working Group, you need a charter and someone who is able to be chair. In order to get those things, you need to get people interested so that they can help focus the charter and convince an Area Director that the project is worthwhile. A face- to-face meeting is useful for this. In fact, very few WGs get started by an Area Director; most start after a face-to-face BOF because attendees have expressed interest in the topic.
ワーキンググループを形成するためには、チャーターと椅子もすることができます誰かを必要としています。彼らはチャーターを集中支援し、プロジェクトが価値があるというエリアディレクターを説得できるように、それらのものを得るために、あなたは、人々が興味を取得する必要があります。顔面への対面会議は、この場合に便利です。実際には、非常に少数のWGは、エリアディレクターによって始めます。参加者は、トピックへの関心を表明しているので、ほとんどが対面BOF後に開始します。
A Birds of a Feather (BOF) meeting has to be approved by the Area Director in the relevant area before it can be scheduled. If you think you really need a new WG, approach an AD informally with your proposal and see what he or she thinks. The next step is to request a meeting slot at the next face-to-face meeting. Of course, you don't need to wait for that meeting to get some work done, such as setting up a mailing list and starting to discuss a charter.
フェザー（BOF）会議の鳥は、それがスケジュールされる前に、関連する領域に地域ディレクターによって承認されなければなりません。あなたが本当に新しいWGが必要だと思う場合は、あなたの提案を非公式にADに近づくと、彼または彼女が考えるものを参照してください。次のステップは、次対面会議で会議のスロットを要求することです。もちろん、あなたは、このようなメーリングリストを設定し、憲章を議論するために出発物質として、いくつかの作業を成し遂げるためにそのミーティングのを待つ必要はありません。
BOF meetings have a very different tone than do WG meetings. The purpose of a BOF is to make sure that a good charter with good milestones can be created and that there are enough people willing to do the work needed in order to create standards. Some BOFs have Internet Drafts already in process, whereas others start from scratch.
BOFの会合は、WG会議を行うよりも非常に異なるトーンを持っています。 BOFの目的は、優れたマイルストーンとの良好なチャーターを作成できることや規格を作成するために必要な作業を行うには喜んで十分な人がいることを確認することです。他の人がゼロから始めるのに対し、いくつかのBOFsは、プロセスですでにインターネットドラフトを持っています。
An advantage of having a draft before the BOF is to help focus the discussion. On the other hand, having a draft might tend to limit what the other folks in the BOF want to do in the charter. It's important to remember that most BOFs are held in order to get support for an eventual Working Group, not to get support for a particular document.
BOFの前に草案を持つことの利点は、議論の焦点を合わせる支援することです。一方、ドラフトを有するBOF内の他の人々が憲章に何をしたいかを制限する傾向があるかもしれません。これは、最もBOFsが特定の文書のためのサポートを得るためではなく、最終的なワーキンググループのサポートを得るために開催されていることを覚えておくことが重要です。
Many BOFs don't turn into WGs for a variety of reasons. A common problem is that not enough people can agree on a focus for the work. Another typical reason is that the work wouldn't end up being a standard -- if, for example, the document authors don't really want to relinquish change control to a WG. (We'll discuss change control later in this document.) Only two meetings of a BOF can be scheduled on a particular subject; either a WG has to form or the topic should be dropped.
多くのBOFsは、様々な理由のためのWGに変わりはありません。一般的な問題は十分ではない人々が仕事のための焦点に同意できることです。例えば、文書の作成者は本当にWGへの変更の制御を放棄したくない、場合 - 別の典型的な理由は仕事が標準になってしまうではないだろうということです。 （私たちは、このドキュメントの変更管理について説明します。）BOFの2つだけのミーティングは、特定の対象にスケジュールすることができます。 WGは、形成するために持っているか、話題は廃棄されなければならないのいずれか。
If you're new to the IETF and this is the only reference you plan to read before coming to the meeting, stop here -- at least temporarily. Then, on your flight home, read the rest of the Tao. By that time you'll be ready to get actively involved in the Working Groups that interested you at the meeting, and the Tao will get you started on your way.
あなたがIETFに新しいしていると、これはあなたが会議に来る前に読むことを計画して参照のみであれば、ここで停止 - 少なくとも一時的に。次に、あなたの飛行家で、タオの残りの部分をお読みください。その時まで、あなたは会議で興味があること、積極的ワーキンググループに参加する準備ができているよ、とタオはあなたがあなたの方法で起動されます。
If you're planning to participate in the IETF remotely, through reading email lists and the proceedings, read on!
あなたが読んで電子メールリストと手続きを通じて、リモートでIETFに参加することを計画している場合は、上読んでください！
If you're a new IETF participant and are looking for a particular RFC or Internet Draft, go to the RFC Editor's web pages, http://www.rfc-editor.org/rfc.html. That site also has links to other RFC collections, many with search capabilities. If you know the number of the RFC you're looking for, go to the IETF RFC pages, http://www.ietf.org/rfc.html. For Internet Drafts, the best resource is the IETF web site, http://www.ietf.org/ID.html, where you can search by title and keyword.
あなたは新しいIETF参加していると、特定のRFCやインターネットドラフトを探している場合は、RFC編集者のWebページ、http://www.rfc-editor.org/rfc.htmlに行きます。そのサイトは、検索機能を備えた他の多くのRFCコレクションへのリンクを、持っています。あなたが探しているRFCの番号がわかっている場合は、IETFのRFCページ、http://www.ietf.org/rfc.htmlに行きます。インターネットドラフトのために、最適なリソースを使用すると、タイトルやキーワードで検索できIETFのWebサイト、http://www.ietf.org/ID.html、です。
One of the most common questions seasoned IETFers hear from newcomers is, "How do I get an IETF standard published?" A much better question is, "Should I write an IETF standard?" since the answer is not always "yes." If you do decide to try to write a document that becomes an IETF standard, be warned that the overall process may be arduous, even if the individual steps are fairly straightforward. Lots of people get through the process unscathed, though, and there's plenty of written guidance that helps authors emerge with their ego more or less intact.
ベテランIETFersは新参者から話を聞くの最も一般的な質問の一つは、「どのように私は、IETF標準が公開され得るのですか？」であり、より良い質問は、「私はIETF標準を書くべきですか？」、です答えは「はい。」常にではありませんので、あなたはIETF標準となった文書を書いてみることにしたならば、個々のステップはかなり簡単であっても、全体のプロセスは困難であり得ることを警告されます。多くの人々は、しかし、無傷のプロセスを介して取得し、著者は自分のエゴ多かれ少なかれそのままで出てくることができます書かれた指導がたくさんあります。
Every IETF standard is published as an RFC (a "Request for Comments," but everyone just calls them RFCs), and every RFC starts out as an Internet Draft (often called an "I-D"). The basic steps for getting something published as an IETF standard are as follows:
すべてのIETF標準はRFCとして公開（「要求のコメント、」誰もがちょうどそれらのRFCを呼び出し）、およびすべてのRFCは、（多くの場合、「I-D」と呼ばれる）のインターネットドラフトとして開始されます。次のようにIETF標準として公表何かを取得するための基本的な手順は次のとおりです。
5. Ask an Area Director to take the draft to the IESG (if it's an individual submission). If the draft is an official Working Group product, the WG chair asks the AD to take it to the IESG.
5.（それは、個々の提出の場合）IESGに草案を取るためにエリアディレクターをして下さい。ドラフトが公式のワーキンググループの製品の場合は、WGの議長は、IESGにそれを取るためにADを要求します。
6. Make any changes deemed necessary by the IESG (this might include giving up on becoming a standard).
6. IESG（これが標準になりつつにあきらめ含まれる場合があります）が必要と認めたすべての変更を行います。
A much more complete explanation of these steps is contained in [BCP9], "The Internet Standards Process". Those who write drafts that they hope will become IETF standards must read BCP 9 so that
これらの工程のより完全な説明は、「インターネット標準化プロセス」、[BCP9]に含まれています。ように、彼らはIETFの標準になることを願っています草稿を書く人は、BCP 9を読まなければなりません
they can follow the path of their document through the process. BCP 9 (and various other documents that update it) goes into great detail on a topic that is very often misunderstood, even by seasoned IETF participants: different types of RFCs go through different processes and have different rankings. There are six kinds of RFCs:
彼らは、プロセスを介して自分のドキュメントのパスをたどることができます。 （それを更新し、他のさまざまな文書）BCP 9でもベテランIETFの参加者が、非常にしばしば誤解されて話題に非常に詳細に入る：RFCの異なる種類が異なるプロセスを経ると異なるランキングを持っています。 RFCの6種類があります。
o Proposed standards
O規格を提案
o Draft standards
Oドラフト規格
o Internet standards (sometimes called "full standards")
Oインターネット標準（時には「フル規格」と呼ばれます）
o Informational documents
O情報の文書
o Experimental protocols
O実験プロトコル
o Historic documents
歴史的文書O
Only the first three (proposed, draft, and full) are standards within the IETF. A good summary of this can be found in the aptly titled [RFC1796], "Not All RFCs Are Standards".
最初の3つだけ（提案、ドラフト、およびフル）IETF内の規格です。これの良い要約は、「すべてのRFCが標準化されるわけではありません」、適切題し[RFC1796]で見つけることができます。
There are also three sub-series of RFCs, known as FYIs, BCPs, and STDs. The For Your Information RFC sub-series was created to document overviews and topics that are introductory or that appeal to a broad audience; however, that series has not been added to in a long time. Best Current Practice documents describe the application of various technologies in the Internet. The STD RFC sub-series was created to identify RFCs that do in fact specify Internet standards. Some STDs are actually sets of more than one RFC, and the "standard" designation applies to the whole set of documents.
FYIに、のBCP、および性感染症として知られているRFCの三つのサブシリーズは、もあります。あなたの情報RFCサブシリーズ用文書の概要と紹介や幅広い視聴者へのアピールされているトピックに作成されました。しかし、そのシリーズは長時間にに追加されていません。最も良い現在の練習の文書がインターネットに様々な技術の応用を説明します。 STD RFCサブシリーズは、実際にはインターネット標準を指定しないRFCを識別するために作成されました。いくつかの性感染症は、実際には、複数のRFCのセットであり、「標準」の指定は、文書のセット全体に適用されます。
The biggest reason some people do not want their documents put on the IETF standards track is that they must give up change control of the protocol. That is, as soon as you propose that your protocol become an IETF standard, you must fully relinquish control of the protocol. If there is general agreement, parts of the protocol can be completely changed, whole sections can be ripped out, new things can be added, and the name can be changed.
一部の人々は彼らの文書はIETF標準トラックに乗せたくない最大の理由は、彼らは、プロトコルの変更管理を放棄しなければならないということです。それは、すぐにあなたのプロトコルはIETF標準になることを提案しているとして、あなたは完全にプロトコルの制御を放棄しなければならない、です。一般的な合意がある場合は、プロトコルの部分は完全に変更することができ、全体のセクションでは、新しいものを追加することができ、リッピングすることができ、そして名前を変更することができます。
Some authors find it very hard to give up control of their pet protocol. If you are one of those people, don't even think about trying to get your protocol to become an IETF standard. On the other hand, if your goal is the best standard possible with the widest implementation, then you might find the IETF process to your liking.
一部の著者は、それは非常に難しい彼らのペットプロトコルの制御を放棄することを見つけます。あなたがその一人であれば、あなたも、プロトコルはIETF標準になることを取得しようと考えていません。一方、あなたの目標は最も広い実装で可能な最高の基準がある場合、あなたはあなたの好みに合わせてIETFプロセスを見つけるかもしれません。
Incidentally, the change control on Internet standards doesn't end when the protocol is put on the standards track. The protocol itself can be changed later for a number of reasons, the most common of which is that implementors discover a problem as they implement the standard. These later changes are also under the control of the IETF, not the editors of the standards document.
プロトコルが標準化過程の上置かれたときにところで、インターネット標準の変更管理は終わりません。プロトコル自体は実装者は、彼らが標準を実装するなどの問題を発見することで、最も一般的なものはいくつかの理由のために後から変更することができます。これら以降の変更は、規格文書の編集者、IETFの管理下にもありません。
IETF standards exist so that people will use them to write Internet programs that interoperate. They don't exist to document the (possibly wonderful) ideas of their authors, nor do they exist so that a company can say, "We have an IETF standard". If a standards-track RFC only has one implementation (whereas two are required for it to advance on the standards track), it was probably a mistake to put it on the standards track in the first place.
人々は相互運用インターネットプログラムを書くためにそれらを使用するように、IETFの標準が存在します。同社は「私たちはIETF標準を持っている」、と言うことができるように彼らは彼らの作者の（おそらく素晴らしい）アイデアを文書化するために存在していない、また彼らが存在します。標準トラックRFCのみ（それが標準化過程の上進めるためにのために2が必要とされるのに対し）1つの実装を持っている場合は、標準にそれを置くことはおそらく間違いだった最初の場所で追跡します。
First things first. Every document that ends up in the RFC repository starts life as an Internet Draft. Internet Drafts are tentative documents -- they're meant for readers to comment on, so authors can mull over those comments and decide which ones to incorporate in the draft. In order to remind folks of their tentativeness, Internet Drafts are automatically removed from the online directories after six months. They are most definitely not standards or even specifications. As [BCP9] says:
まず最初のもの。 RFCリポジトリで終わるすべてのドキュメントはインターネットドラフトとしての生活を開始します。インターネットドラフトは暫定的な文書である - 彼らは著者がそれらのコメント熟考し、草案に盛り込むするものを決めることができますので、上のコメントを読者のためのものです。そのtentativenessの人々を思い出させるためには、インターネットドラフトは自動的に6ヶ月後にオンラインディレクトリから削除されます。彼らはほとんど間違いなく規格あるいは仕様ではありません。 [BCP9]言います：
"An Internet Draft is NOT a means of 'publishing' a specification; specifications are published through the RFC mechanism.... Internet Drafts have no formal status, and 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, nor should a vendor claim compliance with an Internet Draft".
「インターネットドラフト仕様 『出版』の手段ではありません。仕様はRFC機構を介して公開されている....インターネットドラフトは正式な地位を持っていないし、いつでも変更または削除される場合がありますいかなる状況においても、インターネットべきです。ドラフトは任意の紙、レポート、または要求-ため、提案によって参照、またすべきであるインターネットドラフトで、ベンダーの請求遵守」します。
You can always tell a person who doesn't understand the IETF (or is intentionally trying to fool people) when he or she brags about having published an Internet Draft; it takes no significant effort.
あなたは、常に彼または彼女はインターネットドラフトを公開した自慢ときIETFを理解していない（または故意に人を欺くしようとしている）人に伝えることができます。それには多大な労力を要しません。
When you submit an Internet Draft, you give some publication rights to the IETF. This is so that your Internet Draft is freely available to everyone who wants to read and comment on it. The rights you do and don't give to the IETF are described in [BCP78], "IETF Rights in Contributions".
あなたはインターネットドラフトを提出するときは、IETFにはいくつかの出版権を与えます。インターネットドラフトは、読んで、それについてコメントすることを望んでいる誰にでも自由に利用できるようにするためです。あなたが行うとIETFに与えていない権利は、「貢献度にIETFの権利」、[BCP78]で説明されています。
There is a very useful checking tool at http://tools.ietf.org/tools/idnits/idnits.pyht. Using this tool before you turn in an Internet Draft will help prevent the draft from being rejected due to errors in form and formatting.
http://tools.ietf.org/tools/idnits/idnits.pyhtで非常に便利なチェックツールがあります。あなたはインターネットドラフトで電源を入れる前に、このツールを使用することにより、形式や書式にエラーに拒否されてからドラフトを防ぐことができます。
An I-D should have approximately the same format as an RFC. Contrary to many people's beliefs, an I-D does not need to look exactly like an RFC, but if you can use the same formatting procedures used by the RFC Editor when you create your I-Ds, it will simplify the RFC Editor's work when your draft is published as an RFC. [RFC2223], "Instructions to RFC Authors", describes the nroff formatting used by the RFC Editor. There is also a tool called "xml2rfc", available from http://xml.resource.org/, that takes XML-formatted text and turns it into a valid Internet Draft.
I-Dは、RFCとほぼ同じ形式を持つ必要があります。多くの人々の信念に反して、IDはRFCとまったく同じように見える必要はありませんが、あなたはI-DSを作成するときは、RFCエディタで使用されるのと同じ書式設定の手順を使用することができれば、それはとき下書きRFC編集者の仕事を簡素化しますRFCとして公開されています。 [RFC2223]、「RFC作者への指示」は、RFCエディタによって使用されるフォーマットのnroffを記載します。 XML形式のテキストを取り、有効なインターネットドラフトに変換しますhttp://xml.resource.org/から入手可能な「xml2rfc」と呼ばれるツールは、もあります。
An Internet Draft can be either a Working Group draft or an individual submission. Working Group drafts are usually reviewed by the Working Group before being accepted as a WG item, although the chairs have the final say.
インターネットドラフトは、ワーキンググループのドラフトまたは個々の提出のいずれかになります。椅子が最終決定権を持っているものの、ワーキンググループの草案は、通常、WGアイテムとして受け入れられる前にワーキンググループで検討されています。
If you're interested in checking the status of a particular draft, or can't remember its exact name, or want to find out which drafts a WG is working on, two handy tools are available. The "Internet Drafts Database Interface", at https://datatracker.ietf.org/public/idindex.cgi, lets you search for a draft by author, Working Group, date, or filename. The "I-D Tracker", at https://datatracker.ietf.org/public/pidtracker.cgi, is especially useful for authors who want to track the progress of their draft as it makes its way through the publication process.
あなたが特定のドラフトの状態をチェックするに興味を持っている、またはその正確な名前を覚えているか、WGが取り組んで立案したのを確認したいことができない場合は、2つの便利なツールが用意されています。 「インターネットドラフトデータベースインターフェイス」は、https://datatracker.ietf.org/public/idindex.cgiで、あなたは著者によって草案を検索することができます、ワーキンググループ、日付、またはファイル名。 「I-Dトラッカー」、https://datatracker.ietf.org/public/pidtracker.cgiで、それが公開プロセスを通して方法を作るとして、その草案の進捗状況を追跡する著者のために特に便利です。
There are some informal rules for Internet Draft naming that have evolved over the years. Internet Drafts that revise existing RFCs often have draft names with "bis" in them, meaning "again" or "twice"; for example, a draft might be called "draft-someone-rfc2345bis-00.txt".
長年にわたって進化してきたインターネットドラフトの命名のためのいくつかの非公式のルールがあります。既存のRFCを改訂するインターネットドラフトは、多くの場合、「再び」または「二度」の意味、その中の「ビス」とドラフト名を持ちます。例えば、草案は「ドラフト誰か-rfc2345bis-00.txt」と呼ばれるかもしれません。
Before you create the first draft of your Internet Draft, you should read four documents:
あなたがあなたのインターネットドラフトの最初のドラフトを作成する前に、次の4つの文書をお読みください：
o More important than just explaining formatting, [RFC2223] also explains what needs to be in an Internet Draft before it can become an RFC. This document describes all the sections and notices that will need to be in your document, and it's good to have them there from the beginning so that readers aren't surprised when you put them in later versions.
ただのフォーマットを説明するよりももっと重要なO、[RFC2223]も、それはRFCになることができる前に、インターネットドラフトにする必要があるものについて説明します。この文書では、あなたの文書にする必要がありますすべてのセクションおよび通知について説明し、あなたがそれ以降のバージョンでそれらを置くときには、読者は驚かないように、最初からそこにそれらを持って良いことです。
o [BCP22], "Guide for Internet Standards Writers", provides tips that will help you write a standard that leads to interoperability. For instance, it explains how to choose the right number of protocol options, how to respond to out-of-spec behavior, and how to show state diagrams.
O [BCP22]、「インターネット規格作家のためのガイド」、あなたは相互運用性につながる標準を作成するのに役立ちますヒントを提供します。例えば、それは仕様外の行動にどのように応答するかを、プロトコルオプションの権利数を選択する方法について説明し、どのような状態図を示しています。
o The online "Guidelines to Authors of Internet Drafts", http://www.ietf.org/ietf/1id-guidelines.txt, has up-to-date information about the process for turning in Internet Drafts, as well as the most current boilerplate information that has to be included in each Internet Draft.
http://www.ietf.org/ietf/1id-guidelines.txt、オンライン「インターネットドラフトの作者にガイドライン」O、だけでなく、インターネットドラフトに回すためのプロセスに関する最新情報を提供してい各インターネットドラフトに含まれなければなら最新の定型情報。
o When you think you are finished with the draft process and are ready to request that the draft become an RFC, you should definitely read "Checklist for Internet Drafts (I-Ds) Submitted for RFC Publication", http://www.ietf.org/ID-Checklist.html, a list of common issues that have been known to stop documents in the IESG. In fact, you should probably read that document well before you are finished, so that you don't have to make a bunch of last-minute changes.
あなたはドラフト・プロセスを終了していると思うとドラフトがRFCになるように要求する準備ができたら、O、あなたは間違いなく、HTTPを「RFCの出版のために提出インターネットドラフト（I-DS）のためのチェックリスト」をお読みください：//www.ietfを.ORG / ID-Checklist.html、IESGで文書を停止することが知られている一般的な問題のリスト。あなたは直前の変更の束を行う必要がないように実際には、あなたはおそらく、あなたが終了する前によくその文書をお読みください。
Also, you should visit the IETF Tools web pages, http://tools.ietf.org, where you'll find pointers to other tools that will automate some of your work for the IETF.
また、あなたはIETFのための作業の一部を自動化します他のツールへのポインタを見つけることができますIETFツールWebページ、http://tools.ietf.orgを、訪問するべきです。
When you're ready to turn in your Internet Draft, send it to the Internet Drafts administrator at mailto:internet-drafts@ietf.org. There is a real person at the other end of this mail address, whose job is to make sure you've included the minimum items you need for the Internet Draft to be published. When you submit the first version of the draft, you also tell the draft administrator your proposed filename for the draft. If the draft is an official Working Group product, the name will start with "draft-ietf-" followed by the designation of the WG, followed by a descriptive word or two, followed by "00.txt".
internet-drafts@ietf.org：あなたのインターネットドラフトに回転する準備ができたら、mailtoのではインターネットドラフトの管理者に送信します。仕事あなたがインターネットドラフトが公開されるために必要な最低限の項目を含めましたことを確認することです。このメールアドレスのもう一方の端にある実在の人物です。あなたがドラフトの最初のバージョンを送信すると、あなたはまた、ドラフト管理者がドラフトのためのあなたの提案ファイル名を教えてください。ドラフトが公式のワーキンググループの製品であれば、名前は「ドラフト-ietf-」WGの指定に続いて、説明的な単語または2に続いて、「00.txt」に続いて開始します。
For example, a draft in the S/MIME WG about creating keys might be named "draft-ietf-smime-keying-00.txt". If it's not the product of a Working Group, the name will start with "draft-" and the last name of one of the authors followed by a descriptive word or two, followed by "00.txt". For example, a draft that someone named Smith wrote might be named "draft-smith-keying-00.txt". If a draft is an individual submission but relates to a particular Working Group, authors sometimes follow their name with the name of the Working Group, such as "draft-smith-smime-keying-00.txt". You are welcome to suggest names; however, it is up to the Internet Drafts administrator (and, if it is an official WG draft, the WG chair) to come up with the filename. If you follow the naming guidelines given at http://www.ietf.org/ietf/1id-guidelines.txt, chances are quite good that your suggested filename will be fine.
たとえば、キーの作成についてのS / MIME WGでのドラフトは、「ドラフト-IETF-SMIMEキーイング-00.txt」と命名されるかもしれません。それは作業部会の製品ではありません場合は、名前が「draft-」と「00.txt」に続く、記述の単語または2に続く著者の一人、最後の名前で始まります。たとえば、Smithという名前の誰かが書いた草案は、「ドラフト・スミス・キーイング-00.txt」と命名されるかもしれません。ドラフトは、個々の提出ですが、特定の作業部会に関連する場合、著者は、時々、このような「ドラフト・スミス - SMIMEキーイング-00.txt」として、ワーキンググループの名前と自分の名前に従ってください。名前を提案を歓迎しています。ファイル名を思い付くために（それが公式のWGドラフト、WGチェアがあれば、と）しかし、それはインターネットドラフト管理者に任されています。あなたはhttp://www.ietf.org/ietf/1id-guidelines.txtで与えられた命名ガイドラインに従った場合、チャンスはあなたの提案のファイル名は罰金になることは非常に良いです。
After the first edition of a draft, the number in the filename is incremented; for instance, the second edition of the S/MIME draft named above would be "draft-ietf-smime-keying-01.txt". Note that there are cases where the filename changes after one or more versions, such as when a personal effort is pulled into a Working Group; when a draft has its filename changed, the number reverts to -00. Be sure to let the Internet Drafts administrator know the previous name of the draft when such a name change occurs so that the databases can be kept accurate.
草案の初版後、ファイル名に番号がインクリメントされます。例えば、上記の名前S / MIMEのドラフトの第二版は、「ドラフト-IETF-SMIMEキーイング-01.txt」になります。パーソナル努力がワーキンググループに引き込まれたときのように1つまたは複数のバージョンの後にファイル名の変更、場合があることに注意してください。草案は、そのファイル名が変更されたとき、数は-00に戻ります。そのような名前の変更が発生したときにデータベースが正確に保つことができるように、インターネットドラフトの管理者は、ドラフトの以前の名前を知っているようにしてください。
The procedure for creating and advancing a standard is described in [BCP9]. After an Internet Draft has been sufficiently discussed and there is rough consensus that what it says would be a useful standard, it is presented to the IESG for consideration. If the draft is an official WG draft, the WG chair sends it to the appropriate Area Director after it has gone through Working Group last call. If the draft is an individual submission, the draft's author or editor submits it to the appropriate Area Director. BCP 9 also describes the appeals process for people who feel that a Working Group chair, an AD, or the IESG has made the wrong decision in considering the creation or advancement of a standard.
標準を作成し、前進させるための手順は、[BCP9]に記載されています。インターネットドラフトは十分に議論されているとそれが言うことは役に立つ標準であろうとラフコンセンサスがあったら、それは検討のためにIESGに提示されます。ドラフトが公式のWGドラフトであれば、それはワーキンググループの最後の呼び出しを経た後に、WGの議長は、適切なエリアディレクターに送信します。草案は、個々の提出がある場合は、ドラフトの著者や編集者は、適切なエリアディレクターにそれを提出します。 BCP 9はまた、作業部会の議長、AD、またはIESGが標準の作成や発展を考える上で間違った決断をしたと感じている人のための控訴手続きを説明しています。
After the I-D is submitted to the IESG, the IESG announces an IETF-wide last call. This helps get the attention of people who weren't following the progress of the draft, and it can sometimes cause further changes to the draft. It is also a time when people in the WG who feel that they weren't heard can make their comments to everyone. The IETF last call is two weeks for drafts coming from WGs and four weeks for individual submissions.
I-Dは、IESGに提出された後、IESGは、IETF全体の最後の呼び出しを発表しました。これは草案の進捗状況を、次のいなかった人々の注目を得ることができますし、それは時々案にさらに変更を引き起こす可能性があります。それはまた、彼らは聞いていなかったことを感じWGの人々が皆に彼らのコメントを作ることができる時間です。 IETF最後の呼び出しは、各WGからドラフト2週間、個々の提出のために4週間です。
If the IESG approves the draft to become an Internet standard, they ask the RFC Editor to publish it as a Proposed standard. After it has been a Proposed standard for at least six months, the RFC's author (or the appropriate WG chair) can ask for it to become a Draft standard. Before that happens, however, someone needs to convince the appropriate Area Director that there are at least two independent, interoperable implementations of each part of the standard. This is a good test of the usefulness of the standard as a whole, as well as an excellent way to check if the standard was really readable.
IESGは、インターネット標準になるための草案を承認した場合、彼らは提案された標準として公開するRFC Editorをお願いします。それは、RFCの作者（または適切なWGの議長）は、少なくとも6ヶ月間の基準案された後、それがドラフト標準になることを求めることができます。それが起こる前に、しかし、誰かが標準の各部分の少なくとも2つの独立した、相互運用可能な実装があることが適切なエリアディレクターを説得する必要があります。これは、全体として、標準の有用性の良いテストと同様に、標準が本当に読みだったかどうかを確認するための優れた方法です。
A few things typically happen at this point. First, it's common to find that some of the specifications in the standard need to be reworded because one implementor thought they meant one thing whereas another implementor thought they meant something else. Another common occurrence is that none of the implementations actually tried to implement a few of the features of the standard; these features get removed not just because no one tested them but also because they weren't needed.
いくつかのことは、一般的に、この時点で起こります。まず、それが標準で仕様の一部が1つの実装者は、別の実装者は、彼らが何かを意味思ったのに対し、彼らは一つのことを意味考えたので、言い換えする必要があることを発見するのが一般的です。別の一般的な発生は、実装のどれが実際に標準の機能のいくつかを実装しようとしないことです。これらの機能は、誰もがそれらをテストしていないだけでなく、それらが必要なかったためという理由だけではない削除されます。
Don't be surprised if a particular standard doesn't progress from Proposed to Draft. In fact, most of the standards in common use are Proposed standards and never move forward. This may be because no one took the time to try to get them to Draft, or some of the normative references in the standard are still at Proposed standard, or it may be that everyone found more important things to do.
ドラフトするために提案さから特定の標準が進まない場合も驚かないでください。実際には、一般的に使用されている規格のほとんどは基準を提案し、前方に移動されることはありません。誰もがそれらをドラフトして取得しようとする時間がかかっていない、または標準で引用規格の一部が提案された標準に残っているので、これはあり得るか、またはそれは誰もが行うにはもっと重要なことを見つけている可能性があります。
A few years after a document has been a Draft standard, it can become an Internet standard, also known as "full standard" (it can happen in as little as four months, but this is rare). This doesn't happen often, and it is usually reserved for protocols that are absolutely required for the Internet to function. The IESG goes over the document with a fine-tooth comb and looks for evidence of widespread deployment before making a Draft standard an Internet standard.
文書はドラフト標準となっている数年後、それはまた、「完全な標準」として知られているインターネット標準、（それは、わずか4ヶ月で発生する可能性がありますが、これは稀である）になることができます。これは、多くの場合、発生しません、それは通常、インターネットが機能するために絶対的に必要とされるプロトコルのために予約されています。 IESGは、細かい歯の櫛で文書の上に行くとドラフト標準のインターネット標準行う前に、広範囲の展開の証拠を探します。
Writing specifications that get implemented the way you want is a bit of an art. You can keep the specification very short, with just a list of requirements, but that tends to cause implementors to take too much leeway. If you instead make the specification very wordy with lots of suggestions, implementors tend to miss the requirements (and often disagree with your suggestions anyway). An optimal specification is somewhere in between.
あなたが望むように実装されます仕様を書くことは芸術のビットです。あなたは、要件のリストだけで、非常に短い仕様を保つことができるが、それは実装があまりにも多くの余裕を取るために生じる傾向があります。あなたが代わりに提案の多くが付いている仕様は非常に長ったらしい作る場合は、実装者は、要件を欠場する傾向がある（そして多くの場合、いずれにせよ、あなたの提案に反対します）。最適な仕様は、間のどこかにあります。
One way to make it more likely that developers will create interoperable implementations of standards is to be clear about what's being mandated in a specification. Early RFCs used all kinds of expressions to explain what was needed, so implementors didn't always know which parts were suggestions and which were requirements. As a result, standards writers in the IETF generally agreed to limit their wording to a few specific words with a few specific meanings.
開発者は標準の相互運用可能な実装を作成すること、それはより多くの可能性を高めるための一つの方法は、仕様で義務付けされているものを明確にすることがあります。初期のRFCが必要だったかを説明するための式のすべての種類を使用し、その実装は常に提案しており、要件そのうちどの部分知りませんでした。その結果、IETFで標準作家は、一般的にいくつかの特定の意味を持ついくつかの特定の単語に彼らの文言を制限することに合意しました。
[STD3], "Requirements for Internet Hosts -- Application and Support", written way back in 1989, had a short list of words that had appeared to be useful, namely, "must", "should", and "may". These definitions were updated and further refined in [BCP14], "Key words for use in RFCs to Indicate Requirement Levels", which is widely referenced in current Internet standards. BCP 14 also specifically defines "must not" and "should not", and it lists a few synonyms for the words defined.
[STD3]、「インターネットホストのための要件 - 、アプリケーションとサポート、」帰り1989年に書かれたが、「べき」、便利な、すなわち、「必須」であるように思われていた言葉の短いリストを持っていて、「かもしれません」。これらの定義は広く、現在のインターネット標準で参照されている「要件レベルを示すためにRFCsにおける使用のためのキーワード」、[BCP14]に更新され、さらに洗練されました。 BCP 14はまた、特に「いけません」と「すべきでない」を定義し、それが定義された単語の数同義語を示しています。
In a standard, in order to make it clear that you're using the definitions from BCP 14, you should do two things. First, refer to BCP 14 (although most people refer to it as RFC 2119, because that's what BCP 14 tells you to do), so that the reader knows how you're defining your words. Second, you should point out which instances of the words you are using come from BCP 14. The accepted practice for this is to capitalize the words. That is why you see "MUST" and "SHOULD" capitalized in IETF standards.
標準では、あなたがBCP 14からの定義を使用していること、それを明確にするためには、次の2つのことを行う必要があります。あなたがあなたの言葉を定義している方法を読者が知っているように、まず、BCP 14（つまりは、BCP 14はあなたがするよう指示するものですので、ほとんどの人は、RFC 2119としてそれを参照してくださいが）を参照してください。第二に、あなたはこのために練習を受け入れたBCP 14.から来たあなたが使っている言葉のインスタンス指摘しなければならない言葉を活用することです。あなたは「MUST」とは、IETF標準で大文字「すべきである」を参照してください理由です。
BCP 14 is a short document, and it should be read by everyone who is reading or writing IETF standards. Although the definitions of "must" and "must not" are fairly clear, the definitions of "should" and "should not" cause a great deal of discussion in many WGs. When reviewing an Internet Draft, the question is often raised, "Should that sentence have a MUST or a SHOULD in it?" This is, indeed, a very good question, because specifications shouldn't have gratuitous MUSTs, but also should not have SHOULDs where a MUST is needed for interoperability. This goes to the crux of the question of over-specifying and under-specifying requirements in standards.
BCP 14は、短い文書であり、そしてそれはIETF標準を読んだり、書いている誰もが読むべきです。かなり明確であるの定義は、と、の定義は、多くのWGでの議論の多くを引き起こす「いけません」「すべきである」「してはならない」「しなければならない」けれども。インターネットドラフトを検討すると、質問がしばしば提起され、「その文は、それにMUSTやSHOULDを持っていますか？」これは、仕様が無償マストを持つべきではないので、確かに、非常に良い質問ですが、またMUSTは、相互運用性のために必要とされるSHOULDsを持つべきではありません。これは、指定オーバーとアンダーの指定基準の要件の問題の核心に行きます。
One aspect of writing IETF standards that trips up many novices (and quite a few long-time IETF folks) is the rule about how to make "normative references" to non-IETF documents or to other RFCs in a standard. A normative reference is a reference to a document that must be followed in order to implement the standard. A non-normative reference (sometimes called an "informative reference") is one that is helpful to an implementor but is not needed.
多くの初心者（とかなりの数の長時間IETF人々を）アップトリップIETF標準を書くの一の態様は、非IETF文書または標準で他のRFCへの「引用規格」を作る方法についてのルールです。引用規格は、標準を実装するために従わなければならない文書への参照です。 （時々「参考参照」と呼ばれる）非引用規格は、実装者に便利ですが、必要とされていないものです。
An IETF standard may make a normative reference to any other standards-track RFC that is at the same standards level or higher, or to any "open standard" that has been developed outside the IETF. The "same level or higher" rule means that before a standard can move from Proposed to Draft, all of the RFCs for which there is a normative reference must also be at Draft or Internet standard. This rule gives implementors assurance that everything in a Draft standard or Internet standard is quite stable, even the things referenced outside the standard. This can also delay the publication of the Draft or Internet standard by many months (sometimes even years) while the other documents catch up.
IETF標準は、同じ基準レベル以上である任意の他の標準トラックRFCに規定基準、またはIETFの外に開発された任意の「オープンスタンダード」を行うことができます。 「同じレベル以上」ルールは、標準ドラフトすることが提案から移動することができる前に、RFCの全てが対象の引用規格はまた、ドラフト又はインターネット標準でなければならない存在であることを意味します。この規則は、ドラフト標準またはインターネット標準のすべてが非常に安定していることを実装保証、標準外で参照しても、物事を与えます。他の文書は、キャッチアップしながらも、何ヶ月（時には年）によって、ドラフトやインターネット標準の公表を遅らせることができます。
There is no hard-and-fast rule about what is an "open standard", but generally this means a stable standard that anyone can get a copy of (although they might have to pay for it) and that was made by a generally recognized standards group. If the external standard changes, you have to reference the particular instantiation of that standard in your specification, as with a designation of the date of the standard. Some external standards bodies don't make old standards available, which is a problem for IETF standards that need to be used in the future. When in doubt, a draft author should ask the WG chair or appropriate Area Director if a particular external standard can be used in an IETF standard.
「オープンな標準」であるが、一般的に、これは（彼らはそれを支払う必要があるかもしれませんが）誰でものコピーを得ることができることを安定標準を意味し、それは一般的に認識によって作られたものについての厳格とルールはありません標準グループ。外部標準が変化した場合は、標準の日付の指定と同様に、あなたの仕様で、標準の特定のインスタンスを参照する必要があります。いくつかの外部の標準化団体は、将来的に使用する必要があるIETF標準のための問題である、古い規格が利用できるようにしないでください。疑わしい場合、特定の外部標準は、IETF標準で使用できるのであれば、ドラフト作成者は、WGの議長または適切なエリアディレクターを依頼する必要があります。
More and more IETF standards require the registration of various protocol parameters, such as named options in the protocol. As we noted in Section 3.2.4, the main registry for all IETF standards has long been IANA. Because of the large and diverse kinds of registries that standards require, IANA needs to have specific information about how to register parameters, what not to register, who (if anyone) will decide what is to be registered, and so on.
より多くのIETF標準は、そのようなプロトコルの名前付きのオプションなどのさまざまなプロトコルパラメータの登録が必要です。私たちは3.2.4項で述べたように、すべてのIETF標準化のための主要なレジストリは長いIANAてきました。そのための規格が必要レジストリの大規模かつ多様な種類の、IANAは（誰かの）ように登録するかを決める、とする人、登録していないものを、パラメータを登録する方法についての具体的な情報を持っている必要があります。
Anyone writing an Internet standard that may need a new IANA registry or new values in a current IANA registry needs to read [BCP26], "Guidelines for Writing an IANA Considerations Section in RFCs", which describes how RFC authors should properly ask for IANA to start or take over a registry. IANA also maintains registries that were started long before BCP 26 was produced.
現在のIANAレジストリに新しいIANAレジストリまたは新しい値が必要になる場合があり、インターネット標準を書いて誰もがRFCの作者が適切にIANAにを頼むべきかを説明し、[BCP26]、「RFCsにIANA問題部に書くためのガイドライン」をお読みする必要があります開始またはレジストリを引き継ぎます。 IANAはまた、BCP 26を作製したずっと前に開始されたレジストリを維持します。
One thing that's required in every RFC and Internet Draft is a "Security Considerations" section. This section should describe any known vulnerabilities of the protocol, possible threats, and mechanisms or strategies to address them. Don't gloss over this section -- in particular, don't say, "Here's our protocol, if you want security, just use IPsec". This won't do at all, because it doesn't answer the question of how IPsec interacts with your protocol, and vice versa. Be sure to check with your Working Group chair if you're not sure how to handle this section in your draft. See [BCP72], "Guidelines for Writing RFC Text on Security Considerations", for more information on writing good security considerations sections.
すべてのRFCおよびインターネットドラフトに必要なの一つは、「セキュリティの考慮事項」セクションです。このセクションでは、任意のプロトコルの既知の脆弱性、脅威の可能性、およびそれらに対処するための仕組みや戦略を記述する必要があります。このセクションをごまかすしないでください - 特に、「あなただけのIPsecを使用し、セキュリティをしたい場合はここで、私たちのプロトコルだ」、言うことはありません。それはIPsecをあなたのプロトコル、およびその逆とどのように相互作用するかの質問に答えていないので、これは、全くしないだろう。あなたのドラフトで、このセクションを処理する方法がわからない場合は、あなたの作業部会の議長に確認してください。優れたセキュリティ上の考慮事項のセクションの記述の詳細については、[BCP72]、「セキュリティの考慮事項の書き方RFCテキストのためのガイドライン」を参照してください。
The problems of intellectual property have cropped up more and more often in the past few years, particularly with respect to patents. The goal of the IETF is to have its standards widely used and validated in the marketplace. If creating a product that uses a standard requires getting a license for a patent, people are less likely to implement the standard. Not surprisingly, then, the general rule has been "use good non-patented technology where possible".
知的財産の問題は、特に特許に関して、過去数年間でますます頻繁に巻き起こっています。 IETFの目標は、広く使用されており、市場で検証され、その基準を持つことです。標準特許のライセンスを取得する必要が使用する製品を作成する場合は、人々は標準を実装する可能性が低いです。驚くことではないが、その後、一般的なルールは、「可能な限り良い非特許技術を使用する」となっています。
Of course, this isn't always possible. Sometimes patents appear after a standard has been established. Sometimes there's a patent on something that is so valuable that there isn't a non-patented equivalent. Sometimes the patent holder is generous and promises to give all implementors of a standard a royalty-free license to the patent, thereby making it almost as easy to implement as it would have been if no patent existed.
もちろん、これは常に可能ではありません。時には特許は標準が確立された後に表示されます。時々、非特許取得済みの等価がないほど貴重である何かの特許があります。時には、特許権者は寛大で、それによって何の特許が存在しない場合、それはされているだろうと、それはほとんどのように簡単に実装すること、特許に標準のすべての実装者にロイヤリティフリーのライセンスを与えることを約束します。
The IETF's methods for dealing with patents in standards are a subject of much debate. The official rules for all intellectual property rights (IRP) in IETF documents (not just patents) are covered in [BCP78] and [BCP79], "Intellectual Property Rights in IETF Technology". Everyone who participates in IETF Working Groups will probably find these documents interesting because they lay out the rules that everyone agrees to follow.
標準で特許を扱うためのIETFの方法は、多くの議論の対象となっています。 IETF文書内のすべての知的財産権（IRP）（だけではなく、特許）のための公式ルールは、[BCP79]、「IETF技術の知的財産権」[BCP78]で覆われています。彼らは誰もが従うことに同意するというルールをレイアウトするため、IETFのワーキンググループに参加するすべての人は、おそらく、これらの文書は興味深いでしょう。
Patent holders who freely allow their patents to be used by people implementing IETF standards often get a great deal of goodwill from the folks in the IETF. Such generosity is more common than you might think. For example, RFC 1822 is a license from IBM for one of its security patents, and the security community has responded very favorably to IBM for this (whereas a number of other companies have made themselves pariahs for their intractability on their security patents).
自由に特許がIETF標準を実装する人々によって使用することを可能にする特許保有者は、多くの場合、IETFでの人々からののれんの多くを取得します。そのような寛大さは、あなたが思うよりも一般的です。たとえば、RFC 1822には、そのセキュリティ特許のいずれかのIBMからライセンスされ、（他の企業の数は、セキュリティの特許にその扱いにくさのために自分自身にpariahsを行っているのに対し）セキュリティコミュニティは、このためにIBMに非常に好意的に対応してきました。
If you are writing an Internet Draft and you know of a patent that applies to the technology you're writing about, don't list the patent in the document. Instead, consult the IETF IPR Disclosure Page linked off the main IETF web site to determine how to proceed. Intellectual property rights aren't mentioned in RFCs because RFCs never change after they are published, but knowledge of IPR can change at any time. Therefore, an IPR list in an RFC could be incomplete and mislead the reader. [BCP9] provides specific text that should be added to RFCs where the author knows of IPR issues.
あなたは、インターネットドラフトを書いているし、あなたがについて書いている技術に適用された特許を知っている場合は、文書内の特許は表示されません。代わりに、処理方法を決定する主なIETFのWebサイトをオフに連動IETF IPRの開示のページを参照してください。知的財産権は、それらが公開された後RFCは変更されませんので、RFCで言及されていないが、IPRの知識はいつでも変更することができます。したがって、RFCにおけるIPRリストが不完全であると読者に誤解を与える可能性があります。 [BCP9]著者が知的財産権の問題を知っているのRFCに追加する必要がある特定のテキストを提供します。
As we noted earlier, not all RFCs are standards. In fact, plenty of important RFCs are not on the standards track at all. Currently, there are two designations for RFCs that are not meant to be standards: Informational, like the Tao, and Experimental. (There is actually a third designation, Historic, but that is reserved for documents that were on the standards track and have been removed due to lack of current use, or that more recent thinking indicates the technology is actually harmful to the Internet.)
我々は先に述べたように、必ずしもすべてのRFCが標準です。実際には、重要なのRFCの多くは、すべての標準化過程の上ではありません。情報、タオ、そして実験のように：現在、標準化することを意図していないRFCのための2つの名称があります。 （そこ歴史第三の指定は、実際には、それは標準化過程の上だったドキュメントのために予約されており、より多くの最近の考え方は、技術が実際にインターネットに有害であることを示していることに起因する現在の使用の不足のために削除、またはされています。）
The role of Informational RFCs is often debated in the IETF. Many people like having them, particularly for specifications that were created outside the IETF but are referenced by IETF documents. They are also useful for specifications that are the precursors for work being done by IETF Working Groups. On the other hand, some people refer to Informational RFCs as "standards" even though the RFCs are not standards, usually to fool the gullible public about something that the person is selling or supporting. When this happens, the debate about Informational RFCs is renewed.
情報RFCの役割は、多くの場合、IETFで議論されます。特にIETFの外部で作成されたが、IETF文書によって参照されている仕様については、それらを持つような多くの人々。彼らはまた、IETFのワーキンググループによって行われている作業のための前駆体である仕様に便利です。一方、一部の人々は通常、人が販売またはサポートしている何かについてだまされやすい国民を欺くために、RFCが規定するものではありませんにもかかわらず、「基準」として、情報のRFCを参照してください。この場合、情報のRFCについての議論が更新されます。
Experimental RFCs are for specifications that may be interesting, but for which it is unclear if there will be much interest in implementing them, or whether they will work once deployed. That is, a specification might solve a problem, but if it is not clear that many people think that the problem is important, or think that they will bother fixing the problem with the specification, the specification might be labeled an Experimental RFC. If, later, the specification becomes popular (or proves that it works well), it can be re-issued as a standards-track RFC. Experimental RFCs are also used to get people to experiment with a technology that looks like it might be standards-track material, but for which there are still unanswered questions.
実験的RFCは面白いかもしれ仕様のためですが、そこにそれらの実装に多くの関心となり、または、彼らは一度に展開動作するかどうかあればそのためかは不明です。これは仕様では、問題を解決する可能性があります、ですが、それは多くの人が問題が重要であると考えて、または、彼らは仕様に問題を修正邪魔になると考えていることが明らかでない場合は、仕様が実験的RFCを標識することがあります。 、後に、仕様が普及（またはそれがうまく機能することを証明している）場合は、標準トラックRFCとして再発行することができます。実験のRFCはまた、人々はそれが標準トラック材料であってもよいが、そのために、まだ未回答の質問があるかもしれないように見える技術を実験するために取得するために使用されています。
The IESG has created guidelines on how it chooses between Informational and Experimental status: http://www.ietf.org/u/ietfchair/info-exp.html. If you are creating a document that you think might become an Experimental RFC, knowing the current thinking will help you justify your proposed choice.
http://www.ietf.org/u/ietfchair/info-exp.html：IESGはそれは情報と実験状態の間で選択する方法についてのガイドラインを作成しました。あなたが実験的RFCになるかもしれないと思う文書を作成する場合は、現在の考え方を知ることは、あなたの提案の選択を正当化するのに役立ちます。
*Read* -- Review the Internet Drafts in your area of expertise and comment on them in the Working Groups. Participate in the discussion in a friendly, helpful fashion, with the goal being the best Internet standards possible. Listen much more than you speak. If you disagree, debate the technical issues: never attack the people.
* *読む - 専門知識のお住まいの地域でのインターネットドラフトを確認し、ワーキンググループでそれらにコメント。目標は、可能な限り最高のインターネット標準であることで、フレンドリーで親切なやり方で議論に参加します。あなたが話すよりもはるかに多くを聞きます。あなたが同意しない場合は、技術的な問題を討論：人を攻撃することはありません。
*Implement* -- Write programs that use the current Internet standards. The standards aren't worth much unless they are available to Internet users. Implement even the "minor" standards, since they will become less minor if they appear in more software. Report any problems you find with the standards to the appropriate Working Group so that the standard can be clarified in later revisions. One of the oft-quoted tenets of the IETF is "running code wins", so you can help support the standards you want to become more widespread by creating more running code.
*実装* - 現在のインターネット標準を使用して書き込みプログラム。彼らはインターネットユーザーに利用可能でない限り、基準はあまり価値がありません。彼らはより多くのソフトウェアに表示された場合より少ないマイナーになるだろうから、でも「マイナー」の規格を実装します。標準は、後の改正で明らかにすることができるように、あなたは適切なワーキンググループの基準に見つけた問題を報告します。 IETFのOFT引用符で囲まれた教義の一つは、「実行中のコードの勝利」であるので、あなたは、あなたがより多くのランニングコードを作成することで、より広範囲になりたい規格をサポートすることができます。
*Write* -- Edit or co-author Internet Drafts in your area of expertise. Do this for the benefit of the Internet community, not to get your name (or, even worse, your company's name) on a document. Draft authors are subject to all kinds of technical (and sometimes personal) criticism; receive it with equanimity and use it to improve your draft in order to produce the best and most interoperable standard.
*書き込み* - 編集や専門知識のお住まいの地域で共同執筆者のインターネットドラフト。文書に名前（または、さらに悪いことに、あなたの会社の名前）を取得するのではなく、インターネットコミュニティの利益のためにこれを行います。ドラフト著者は、技術的な（そして時には個人的な）批判のすべての種類の対象となっています。平静でそれを受け取り、最良かつ最も相互運用性の標準を生成するために、下書きを向上させるためにそれを使用。
*Share* -- Avoid proprietary standards. If you are an implementor, exhibit a strong preference for IETF standards. If the IETF standards aren't as good as the proprietary standards, work to make the IETF standards better. If you're a purchaser, avoid products that use proprietary standards that compete with the open standards of the IETF and tell the companies you buy from that you are doing so.
*シェア* - 独自の基準を避けてください。あなたが実装されている場合は、IETF標準の強い優先性を示します。 IETF標準は独自規格のように良いものではありません場合は、より良いIETF標準を作るために働きます。あなたが購入している場合は、IETFのオープンな標準と競合し、あなたがそうしていることから、購入企業を教えて独自の基準を使用した製品を避けます。
*Open Up* -- If your company controls a patent that is used in an IETF standard, convince the company to make the patent available at no cost to everyone who is implementing the standard. In the past few years, patents have caused a lot of serious problems for Internet standards because they prevent some companies from being able to freely implement the standards. Fortunately, many companies have generously offered unlimited licenses for particular patents in order to help the IETF standards flourish. These companies are usually rewarded with positive publicity for the fact that they are not as greedy or short-sighted as other patent-holders.
* *開く - あなたの会社は、IETF標準で使用されている特許を制御している場合、標準を実装しているすべての人に無償で特許を利用できるようにするために会社を説得。彼らは自由の規格を実装することができることから、いくつかの企業を防ぐため、過去数年間では、特許はインターネット標準のための深刻な問題の多くを引き起こしています。幸いなことに、多くの企業が寛大IETF標準が繁栄を支援するために、特定の特許の無制限ライセンスを提供してきました。これらの企業は通常、彼らが他の特許保有者のように貪欲や近視眼的ではないという事実のために正の宣伝で報われています。
*Join* -- Become a member of ISOC. More important, urge any company that has benefited from the Internet to become a corporate member of ISOC, since this has the greatest financial benefit for the group. It will, of course, also benefit the Internet as a whole.
* *参加 - ISOCのメンバーになります。さらに重要なことは、これはグループにとって最大の金銭的利益を持っているので、ISOCの法人会員になるために、インターネットの恩恵を受けているすべての企業を強くお勧めします。それは、もちろん、また、全体としてのインターネットの利益になります。
As much as many IETF participants would like to think otherwise, the IETF does not exist in a standards vacuum. There are many (perhaps too many) other standards organizations whose decisions affect the Internet. There are also a fair number of standards bodies that ignored the Internet for a long time and now want to get a piece of the action.
同じくらい多くのIETFの参加者がそう考えてみたいと、IETFは標準真空中に存在していません。その決断インターネットに影響を与える多くの（おそらくあまりにも多くの）他の標準化団体があります。長い時間のためにインターネットを無視し、現在のアクションの一部を取得したいの標準化団体のかなりの数があります。
In general, the IETF tries to have cordial relationships with other significant standards bodies. This isn't always easy, since many other bodies have very different structures than the IETF does, and the IETF is mostly run by volunteers who would probably prefer to write standards rather than meet with representatives from other bodies. Even so, some other standards bodies make a great effort to interact well with the IETF despite the obvious cultural differences.
一般的に、IETFは、他の重要な標準化団体との誠心誠意の関係を持つようにしようとします。 IETFはよりも、他の多くの機関が非常に異なる構造を持っているので、これは、必ずしも容易ではない、とIETFは、主に、おそらく標準を書くのではなく、他の機関からの代表者と会うことを好むボランティアによって運営されています。たとえそうであっても、他のいくつかの標準化団体は、明らかな文化の違いにもかかわらず、IETFとよく対話するための偉大な努力をします。
At the time of this writing, the IETF has some liaisons with large standards bodies, including the ITU (International Telecommunication Union), the W3C, the Unicode Consortium, and ISO/IEC JTC1 (Joint Technical Committee of the International Organization for Standardization and International Electrotechnical Commission). As stated in the IAB Charter [BCP39], "Liaisons are kept as informal as possible and must be of demonstrable value in improving the quality of IETF specifications". In practice, the IETF prefers liaisons to take place directly at Working Group level, with formal relationships and liaison documents in a backup role.
この記事の執筆時点では、IETFが標準化と国際のための国際機関のITU（国際電気通信連合）、W3C、ユニコードコンソーシアム、およびISO / IEC JTC1（合同技術委員会を含む大規模な標準化団体、といくつかのリエゾンを持っています電気技術委員会）。 IAB憲章[BCP39]で述べたように、「リエゾンはできるだけ非公式保持され、IETF仕様の品質を向上させることで実証値でなければなりません」。実際には、IETFは、バックアップの役割で正式な関係とリエゾン文書で、ワーキンググループレベルで直接場所を取るためにリエゾンを好みます。
Some of these liaison tasks fall to the IESG, whereas others fall to the IAB. Detail-oriented readers will learn much about the formal methods for dealing with other standards bodies in [BCP102], "IAB Processes for Management of IETF Liaison Relationships", and [BCP103], "Procedures for Handling Liaison Statements to and from the IETF". The best place to check to see whether the IETF has any formal liaison at all is the list of IETF liaisons, www.ietf.org/liaisonActivities.html. The list shows that there are many different liaisons to ISO/IEC JTC1 subcommittees.
他の人がIABに落ちるのに対し、これらのリエゾンタスクのいくつかは、IESGに落ちます。詳細指向の読者は[BCP102]、「IETFリエゾン関係の管理のためのIABプロセス」、および[BCP103]、「IETFへとから連絡文を処理するための手順」で他の標準化団体に対処するための正式な方法について多くを学びます。 IETFはすべての正式な連絡窓口を持っているかどうかを確認するのに最適な場所はIETFリエゾン、www.ietf.org/liaisonActivities.htmlの一覧です。リストは、ISO / IEC JTC1の分科会には多くの異なるリエゾンがあることを示しています。
Given that the IETF is one of the best-known bodies that is helping move the Internet forward, it's natural for the computer press (and even the trade press) to want to cover its actions. In recent years, a small number of magazines have assigned reporters and editors to cover the IETF in depth over a long period of time. These reporters have ample scars from articles that they got wrong, incorrect statements about the status of Internet Drafts, quotes from people who are unrelated to the IETF work, and so on.
IETFが前方にインターネットを動かす手助けされる最もよく知られている団体の一つであることを考えると、それはそのアクションをカバーしたいコンピュータプレス（とさえ貿易プレス）のための自然なことです。近年では、雑誌の数が少ないが、長期間にわたって深さでIETFをカバーする記者や編集者が割り当てられています。これらの記者は、彼らがそうで、インターネットドラフトの状態について間違っている、間違った文を得たIETF仕事に関係のない人からの引用、および記事から十分な傷を持っています。
Major press errors fall into two categories: saying that the IETF is considering something when in fact there is just an Internet Draft in a Working Group, and saying that the IETF approved something when all that happened was that an Informational RFC was published. In both cases, the press is not fully to blame for the problem, since they are usually alerted to the story by a company trying to get publicity for a protocol that they developed or at least support. Of course, a bit of research by the reporters would probably get them in contact with someone who could straighten them out, such as a WG chair or an Area Director. The default press contact for the IETF is the IAD, who can be reached at mailto:iad@ietf.org.
主なプレスエラーは、2つのカテゴリに分類されます。実際にはそこだけインターネットドラフトは、ワーキンググループであり、そしてそれは起こったすべての情報のRFCが発行されたということであったとき、IETFが何かを承認したことを言ったときにIETFが何かを検討しているという。彼らは通常、彼らが開発したプロトコルまたは少なくとも支援のための宣伝を取得しようとしている会社によって物語に警告されているので、どちらの場合も、プレスは、問題に責任が完全ではありません。もちろん、記者の研究のビットは、おそらく、このようなWGチェアやエリアディレクターとして、それらをまっすぐことができる誰かに接触してそれらを得るだろう。 iad@ietf.org：IETFのデフォルトの圧接は、MAILTOで到達することができますIAD、です。
The fact that those reporters who've gotten it wrong once still come back to IETF meetings shows that it is possible to get it right eventually. However, IETF meetings are definitely not for reporters who are naive about the IETF process (although if you are a reporter the fact that you are reading this document is a very good sign!). Furthermore, if you think that you'll get a hot story from attending an IETF meeting, you are likely to be disappointed.
一度、それは間違って得ているそれらの記者はまだIETF会議に戻ってくるという事実は、正しい最終的にそれを得ることが可能であることを示しています。しかし、IETFミーティングはIETFプロセス（あなたがレポーターいる場合は、この文書を読んでいるという事実は非常に良い兆候ですが！）についてナイーブされている記者のために間違いはありません。あなたはIETFミーティングに出席熱い物語を得るだろうと思われる場合さらに、あなたは失望する可能性があります。
Considering all this, it's not surprising that some IETFers would prefer to have the press stay as far away from meetings as possible. Having a bit of press publicity for protocols that are almost near completion and will become significant in the industry in the next year can be a good thing. However, it is the rare reporter who can resist over-hyping a nascent protocol as the next savior for the Internet. Such stories do much more harm than good, both for the readers of the article and for the IETF.
このすべてを考慮すると、それはいくつかのIETFersはできるだけ離し会議からのプレス滞在を持っていることを好むだろうことは驚くべきことではないのです。ほぼ完成に近いですし、良いことができ、次の年に業界で重要になるだろうなプロトコルのためのプレス広報のビットを持ちます。しかし、それはインターネットのための次の救世主としての新生プロトコルをオーバーhyping抵抗することができます珍しいレポーターです。そのような話は記事の読者のためとIETFの両方に、良いよりもはるかに多くの害を行います。
The main reason why a reporter might want to attend an IETF meeting is not to cover hot technologies (since that can be done in the comfort of your office by reading the mailing lists) but to meet people face-to-face. Unfortunately, the most interesting people are the ones who are also the busiest during the IETF meeting, and some folks have a tendency to run away when they see a press badge. However, IETF meetings are excellent places to meet and speak with document authors and Working Group chairs; this can be quite valuable for reporters who are covering the progress of protocols.
記者はIETF会議に出席することができます主な理由は、（それがメーリングリストを読むことによってあなたのオフィスの快適さで行うことができるので）、ホットな技術をカバーするのではなく、人々が対面満たすことではありません。残念ながら、最も興味深いの人々はまたIETF会議中に忙しいですなものであり、一部の人々は、彼らは、プレスバッジを見るとすぐに実行する傾向があります。しかし、IETFミーティングは会うと、文書の作成者やワーキンググループチェアと話すための優れた場所です。これは、プロトコルの進捗状況をカバーしている記者のために非常に貴重であることができます。
Reporters who want to find out about "what the IETF is doing" on a particular topic would be well-advised to talk to more than one person who is active on that topic in the IETF, and should probably try to talk to the WG chair in any case. It's impossible to determine what will happen with a draft by looking at the draft or talking to the draft's author. Fortunately, all WGs have archives that a reporter can look through for recent indications about what the progress of a draft is; unfortunately, few reporters have the time or inclination to do this kind of research. Because the IETF doesn't have a press liaison, magazines or newspapers that run a story with errors won't hear directly from the IETF and therefore often won't know what they did wrong, so they might easily do it again later.
特定のトピックの「IETFが何をしているか」について知りたい記者はIETFでそのトピックにアクティブになっている複数の人に話をよくお勧めだろう、おそらくWGの議長に話をしてみてくださいとにかく。これは、ドラフトを見ているかのドラフトの作成者に話をすることによってドラフトで何が起こるかを決定することは不可能です。幸いなことに、すべてのWGは、レポーターは、ドラフトの進展があるかについて、最近の適応症のために目を通すことができますアーカイブを持っています。残念ながら、いくつかの記者は、このような研究を行うには時間や傾きを持っています。 IETFは、プレスリエゾンを持っていないので、エラーで物語を実行する雑誌や新聞がIETFから直接聞くことはありませんので、多くの場合、彼らは間違って何をしたかを知ることができませんので、彼らは簡単に、後で再びそれを行う可能性があります。
Section 8.4.4 explains why each RFC is required to have a Security Considerations section and gives some idea of what it should and should not contain. Other than that information, this document does not touch on Internet security.
8.4.4項では、各RFCは、Security Considerations部を有することが必要である理由を説明し、それはして含有してはならないべきかのいくつかのアイデアを提供します。その情報以外にも、この文書は、インターネットのセキュリティには触れていません。
Appendix A. Related Information
付録A.関連情報
A.1. Why "the Tao"?
A.1。なぜ「タオ」？
Pronounced "dow", Tao is the basic principle behind the teachings of Lao-tse, a Chinese master. Its familiar symbol is the black-and-white yin-yang circle. Taoism conceives the universe as a single organism, and human beings as interdependent parts of a cosmic whole. Tao is sometimes translated "the way", but according to Taoist philosophy the true meaning of the word cannot be expressed in words.
「ダウ」と発音、タオは、老子、中国のマスターの教えの基本原理です。そのおなじみのシンボルは、白黒陰陽円です。道教は、宇宙全体の相互依存一部として単一生物としてユニバースを考案し、そして人間。タオは時々「道」に翻訳されていますが、道教の哲学に基づいて言葉の本当の意味は、言葉で表現することはできません。
A.2. Useful Email Addresses
A.2。便利な電子メールアドレス
Some useful email addresses are listed here. These addresses may change from time to time, and it's a good idea to check the IETF web pages for the correct address before sending your mail.
いくつかの有用な電子メールアドレスがここに表示されます。これらのアドレスは随時変更されることがあり、それはあなたのメールを送信する前に、正しいアドレスのIETFのWebページをチェックすることをお勧めします。
Address Description
-----------------------------------------------------------------
agenda@ietf.org Requests for agenda slots at IETF
meetings
ietf-action@ietf.org Requests for things to be done when you don't know exactly where to send the request
あなたは場所を正確にリクエストを送信するかわからないときに行うべきもののためにietf-action@ietf.org要求
ietf-info@ietf.org General questions about the IETF
IETFに関する一般的な質問をietf-info@ietf.org
ietf-registrar@ietf.org Questions about registration, meeting locations, and fees
登録、会議の場所、および料金についてietf-registrar@ietf.org質問
ietf-request@ietf.org Requests to join/leave IETF lists
IETFリストを残す/参加するietf-request@ietf.org要求
ietf-secretary@ietf.org Questions for the Secretariat
事務局ietf-secretary@ietf.org質問
ietf-web@ietf.org Questions or comments about the IETF web site
IETFのWebサイトに関するご質問やコメントietf-web@ietf.org
internet-drafts@ietf.org Internet Draft submissions and queries
internet-drafts@ietf.orgインターネットドラフトの提出およびクエリ
proceedings@ietf.org Where to send Working Group minutes and slides for the IETF Proceedings
proceedings@ietf.orgどこIETF議事のために作業部会の分とスライドを送信します
iana@iana.org Internet Assigned Numbers Authority
iana@iana.orgインターネット割り当て番号機関
rfc-editor@rfc-editor.org RFC Editor statements@ietf.org Incoming liaison statements from other organizations
他の組織からrfc-editor@rfc-editor.org RFCエディタstatements@ietf.org着信リエゾンステートメント
Online upload pages are planned for the future to facilitate submission of Internet Drafts, Proceedings, and Liaison statements.
オンラインアップロードページはインターネットドラフト、議事録、および連絡文の提出を容易にするために、将来のために計画されています。
A.3. Useful Documents and Files
A.3。便利なドキュメントとファイル
The IETF web site, http://www.ietf.org, is the best source for information about meetings, Working Groups, Internet Drafts, RFCs, IETF email addresses, and much more. Click on "Additional Information" to find a variety of helpful links. Internet Drafts and other documents are also available in the "ietf" directory on anonymous FTP sites worldwide. For a listing of these sites, see http://www.ietf.org/shadow.html.
IETFのWebサイトhttp://www.ietf.orgは、会議、ワーキンググループ、インターネットドラフト、RFCは、IETFの電子メールアドレス、およびより多くの情報のための最高のソースです。便利なリンクの様々を見つけるために、「追加情報」をクリックします。インターネットドラフトおよびその他の文書は、世界中の匿名FTPサイト上の「IETF」ディレクトリにも利用できます。これらのサイトの一覧については、http://www.ietf.org/shadow.htmlを参照してください。
Check the IESG web pages, http://www.ietf.org/iesg.html, to find up-to-date information about drafts processed, RFCs published, and documents in Last Call, as well as the monthly IETF status reports.
処理された草稿、公表のRFC、およびドキュメントラストコールでは、だけでなく、毎月のIETFステータスレポートに関する最新の情報を見つけるために、http://www.ietf.org/iesg.html、IESGのWebページをチェックしてください。
A.4. Acronyms and Abbreviations Used in the Tao
A.4。タオで使用される略語
Some of the acronyms and abbreviations from this document are listed below.
このドキュメントの頭字語や略語のいくつかを以下に記載されています。
Term Meaning
-----------------------------------------------------------------
AD Area Director
BCP Best Current Practice
BOF Birds of a Feather
FAQ Frequently Asked Question(s)
FYI For Your Information (RFC)
IAB Internet Architecture Board
IAD IETF Administrative Director
IANA Internet Assigned Numbers Authority
IAOC IETF Administrative Oversight Committee
IASA IETF Administrative Support Activity
ICANN Internet Corporation for Assigned Names and
Numbers, http://www.icann.org/
I-D Internet Draft
IESG Internet Engineering Steering Group,
http://www.ietf.org/iesg.html
IETF Internet Engineering Task Force,
http://www.ietf.org/
INET Internet Society Conference,
http://www.isoc.org/isoc/conferences/inet/
IPR Intellectual property rights
IRTF Internet Research Task Force, http://www.irtf.org/
ISO International Organization for Standardization, http://www.iso.ch/ ISO-IEC/JTC1 Joint Technical Committee of the International Organization for Standardization and International Electrotechnical Commission, http://www.jtc1.org/ ISOC Internet Society, http://www.isoc.org ITU International Telecommunication Union, http://www.itu.int RFC Request for Comments STD Standard (RFC) W3C World Wide Web Consortium, http://www.w3.org/ WG Working Group
標準化のためのISO国際、http://www.iso.ch/ ISO-IEC /国際標準化機構及び国際電気のJTC1合同技術委員会、http://www.jtc1.org/ ISOCインターネット協会は、http ：ITU国際電気通信連合//www.isoc.org、http://www.itu.int RFC要求のコメントのためのSTD標準（RFC）W3C World Wide Webコンソーシアム、http://www.w3.org/ WGワーキンググループ
Appendix B. IETF Guiding Principles
付録B. IETF指針
If you've gotten this far in the Tao, you've learned a lot about how the IETF works. What you'll find in this appendix summarizes much of what you've read and adds a few new points to ponder. Be sure to read through all the principles; taken as a whole, they'll give you a new slant on what makes the IETF work.
あなたはタオでここまで得ている場合は、IETFがどのように機能するかについて多くのことを学びました。あなたは、この付録で見つけることはあなたが読んだものの多くを要約し、熟考するためにいくつかの新しいポイントを追加します。すべての原則を通じて必ずお読みください。全体として、彼らはあなたのIETF仕事を作るもので、新たな傾斜を与えるでしょう。
B.1. General
B.1。一般的な
P1. The IETF works by an open process and by rough consensus. This applies to all aspects of the operation of the IETF, including creation of IETF documents and decisions on the processes that are used. But the IETF also observes experiments and running code with interest, and this should also apply to the operational processes of the organization.
P1。 IETFは、オープンなプロセスによってラフコンセンサスによって動作します。これは、使用されているプロセスに関するIETF文書や意思決定の作成などIETFの動作のすべての側面に適用されます。しかし、IETFはまた、実験や関心を持って実行しているコードを観察し、これは、組織の業務プロセスに適用されるべきです。
P2. The IETF works in areas where it has, or can find, technical competence.
P2。 IETFは、それが持っている分野で働く、または見つけることができ、技術的能力。
P3. The IETF depends on a volunteer core of active participants.
P3。 IETFは、積極的な参加者のボランティアのコアに依存します。
P4. Membership of the IETF or of its WGs is not fee-based or organizationally defined, but is based upon self-identification and active participation by individuals.
P4。 IETFのまたはのWGのメンバーシップは、手数料ベースまたは組織的に定義されていないが、自己識別及び個人による積極的な参加に基づいています。
B.2. Management and Leadership
B.2。マネジメントとリーダーシップ
P5. The IETF recognizes leadership positions and grants power of decision to the leaders, but decisions are subject to appeal.
P5。 IETFは、リーダーシップの位置を認識し、指導者への意思決定の力を付与しますが、決定は上訴することがあります。
P6. Delegation of power and responsibility are essential to the effective working of the IETF. As many individuals as possible will be encouraged to take on leadership of IETF tasks.
P6。パワーと責任の委任は、IETFの効果的な作業に不可欠です。できるだけ多くの人々は、IETFの作業のリーダーシップを取ることが奨励されます。
P7. Dissent, complaint, and appeal are a consequence of the IETF's nature and should be regarded as normal events, but ultimately it is a fact of life that certain decisions cannot be effectively appealed.
P7。反対意見、苦情、そして魅力は、IETFの自然の結果であると通常のイベントとみなされるべきであるが、最終的には、特定の意思決定が効果的に上訴することができないという人生の事実です。
P8. Leadership positions are for fixed terms (although we have no formal limitation on the number of terms that may be served).
P8。 （私たちが提供することができる条件の数には正式な制限はないが）リーダーシップの位置は固定用語のためのものです。
P9. It is important to develop future leaders within the active community.
P9。アクティブなコミュニティ内で将来のリーダーを開発することが重要です。
P10. A community process is used to select the leadership.
P10。コミュニティプロセスがリーダーシップを選択するために使用されます。
P11. Leaders are empowered to make the judgment that rough consensus has been demonstrated. Without formal membership, there are no formal rules for consensus.
P11。リーダーは荒いコンセンサスが実証された判断をするために権限を与えています。正式な会員がなければ、合意のための正式なルールはありません。
B.3. Process
B.3。処理する
P12. Although the IETF needs clear and publicly documented process rules for the normal cases, there should be enough flexibility to allow unusual cases to be handled according to common sense. We apply personal judgment and only codify when we're certain. (But we do codify who can make personal judgments.)
P12。 IETFは、通常のケースについて公に明確にし、文書化されたプロセスルールを必要とするが、珍しい例は常識に従って処理することを可能にするのに十分な柔軟性があるはずです。私たちは、個人的な判断を適用し、我々は特定している場合にのみ成文化。 （しかし、我々は個人的な判断を下すことができる人成文化します。）
P13. Technical development work should be carried out by tightly chartered and focused Working Groups.
P13。技術的な開発作業はしっかりチャーターによって行われ、ワーキンググループを集中する必要があります。
P14. Parts of the process that have proved impractical should be removed or made optional.
P14。非現実的であることが証明されているプロセスの一部が削除またはオプションなされるべきです。
B.4. Working Groups
B.4。ワーキンググループ
P15. Working Groups (WGs) should be primarily responsible for the quality of their output, and therefore for obtaining early review; WG chairs as WG leaders, backed up by the IETF leadership, should act as a quality backstop.
P15。ワーキンググループ（作業部会）は、その出力の品質を主に担当し、したがって、早期審査を得るためである必要があります。 IETFのリーダーシップによってバックアップされたWGのリーダーとして、WGの議長は、品質のバックストップとして行動しなければなりません。
P16. WGs should be primarily responsible for assessing the negative impact of their work on the Internet as a whole, and therefore for obtaining cross-area review; the IETF leadership should act as a cross-area backstop.
P16。 WGは全体として、インターネット上で自分の仕事のマイナスの影響を評価するために主に責任があるので、クロスエリアの見直しを取得するための必要があります。 IETFリーダーシップは、クロスエリアのバックストップとして行動しなければなりません。
P17. Early review of documents is more effective in dealing with major problems than late review.
P17。文書の初期のレビューは遅くレビューより大きな問題に対処する上でより効果的です。
P18. Area Directors (ADs) are responsible for guiding the formation and chartering of WGs, for giving them direction as necessary, and for terminating them.
P18。エリアディレクター（ADS）は、それらを必要に応じて方向性を与えるため、のWGの形成及び用船を案内するため、それらを終了させる責任があります。
P19. WG chairs are responsible for ensuring that WGs execute their charters, meet their milestones, and produce deliverables that are ready for publication.
P19。 WGチェアのWGは、彼らのチャーターを実行し、そのマイルストーンを満たし、かつ公開のための準備ができている成果を生み出すことを保証する責任があります。
P20. ADs are responsible for arranging backstop review and final document approval.
P20。広告はバックストップのレビューと最終文書の承認を配置するための責任があります。
B.5. Documents
B.5。ドキュメント
P21. IETF documents often start as personal drafts, may become WG drafts, and are approved for permanent publication by a leadership body independent of the WG or individuals that produced them.
P21。 IETF文書は、多くの場合、WGの草稿になることがあり、個人的なドラフトとして開始し、WGまたはそれらを生産し、個人の独立したリーダーシップの体によって永久出版のために承認されています。
P22. IETF documents belong to the community, not to their authors. But authorship is recognized and valued, as are lesser contributions than full authorship.
P22。 IETF文書はない彼らの作者に、コミュニティに属しています。フル原作者よりも低い貢献しているようしかし、原作者は、認識され、評価されています。
P23. Technical quality and correctness are the primary criteria for reaching consensus about documents.
P23。技術的な品質と正確には文書に関する合意に到達するための主要な基準です。
P24. IETF specifications may be published as Informational, Experimental, Standards Track, or Best Current Practice.
P24。 IETF仕様は情報、実験、標準化過程、あるいは最も良い現在の練習として公開することができます。
P25. IETF Standards Track specifications are not considered to be satisfactory standards until interoperable independent implementations have been demonstrated. (This is the embodiment of the "running code" slogan.) But, on legal advice, the IETF does not take responsibility for interoperability tests and does not certify interoperability.
P25。 IETF標準化過程仕様は、相互運用可能な独立した実装が実証されているまで、満足のいく水準ではないと考えています。法律上の助言に、IETFは、相互運用性テストのための責任を負いません。また、相互接続性を認証するものではない、（これが。「実行されるコード」のスローガンの実施例である）。しかし。
P26. IETF processes are currently published as Best Current Practice documents.
P26。 IETFのプロセスは、現在、最も良いCurrent Practiceドキュメントとして公開されています。
P27. Useful information that is neither a specification nor a process may be published as Informational.
P27。仕様もプロセスでもない有用な情報は、情報として公開することができます。
P28. Obsolete or deprecated specifications and processes may be downgraded to Historic.
P28。廃止されたまたは非推奨仕様やプロセスは、歴史的にダウングレードすることができます。
P29. The standards track should distinguish specifications that have been demonstrated to interoperate.
P29。標準トラックは相互運用することが実証されている仕様を区別する必要があります。
P30. Standards Track and Best Current Practice documents must be subject to IETF wide rough consensus (Last Call process). WG rough consensus is normally sufficient for other documents.
P30。標準化過程とベストプラクティス現在の文書は、IETFの広いラフコンセンサス（ラストコールプロセス）を受けなければなりません。 WG荒いコンセンサスは他の文書のために、通常は十分です。
P31. Substantive changes made after a document leaves a WG must be referred back to the WG.
P31。文書は、WGを離れた後に行われた実質的な変更は、WGに戻って言及する必要があります。
P32. The IETF determines requirements for publication and archiving of its documents.
P32。 IETFはその文書の出版とアーカイブのための要件を決定します。
Informative References
参考文献
[BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[BCP9]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026 1996年10月。
[BCP10] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 3777, June 2004.
[BCP10]ガルビン、J.、 "IABとIESG選択、確認、およびリコール処理：指名とリコール委員会の操作"、BCP 10、RFC 3777、2004年6月。
[BCP11] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.
[BCP11] Hovey、R.およびS.ブラドナー、 "IETF標準化プロセスに関与する組織"、BCP 11、RFC 2028、1996年10月。
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP14]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[BCP22] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP22]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[BCP25] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.
[BCP25]ブラドナーの、S.、 "IETFワーキンググループガイドラインと手順"、BCP 25、RFC 2418、1998年9月。
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
、BCP 26、RFC 2434、1998年10月[BCP26] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"。
[BCP39] Internet Architecture Board and B. Carpenter, "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000.
[BCP39]インターネットアーキテクチャ委員会とB.大工、 "インターネットアーキテクチャ委員会（IAB）の憲章"、BCP 39、RFC 2850、2000年5月。
[BCP45] Harris, S., "IETF Discussion List Charter", BCP 45, RFC 3005, November 2000.
[BCP45]ハリス、S.、 "IETF議論リスト憲章"、BCP 45、RFC 3005、2000年11月。
[BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[BCP72]レスコラ、E.とB.コーバー、 "セキュリティの考慮事項の書き方RFCテキストのためのガイドライン"、BCP 72、RFC 3552、2003年7月。
[BCP78] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
[BCP78]ブラドナーの、S.、 "質問の投稿IETF権"、BCP 78、RFC 3978、2005年3月。
[BCP79] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
[BCP79]ブラドナーの、S.、 "IETFテクノロジーにおける知的財産権"、BCP 79、RFC 3979、2005年3月。
[BCP95] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, October 2004.
[BCP95] Alvestrand、H.、 "IETFのためのミッション・ステートメント"、BCP 95、RFC 3935、2004年10月。
[BCP101] Austein, R. and B. Wijnen, "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, April 2005.
[BCP101] AusteinととR.とB. Wijnen、 "IETF管理サポート活動（IASA）の構造"、BCP 101、RFC 4071、2005年4月。
[BCP102] Daigle, L. and Internet Architecture Board, "IAB Processes for Management of IETF Liaison Relationships", BCP 102, RFC 4052, April 2005.
〔BCP102] Daigle氏、L.およびインターネットアーキテクチャ委員会、BCP 102、RFC 4052 2005年4月 "IETFリエゾン関係の管理のためのIABのプロセス"。
[BCP103] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for Handling Liaison Statements to and from the IETF", BCP 103, RFC 4053, April 2005.
[BCP103]トローブリッジ、S.、ブラドナー、S.、およびF.ベイカー、 "IETFへとから連絡文を処理するための手順"、BCP 103、RFC 4053、2005年4月。
[RFC1796] Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are Standards", RFC 1796, April 1995.
[RFC1796]のHuitema、C.、ポステル、J.、およびS.クロッカー、 "すべてのRFCが標準わけではありません"、RFC 1796、1995年4月。
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC2223]ポステル、J.、およびJ.レイノルズ、RFC 2223、1997年10月 "RFC作者への指示"。
[STD3] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[STD3]ブレーデン、R.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
Authors' Addresses
著者のアドレス
Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 US
ポール・ホフマンVPNコンソーシアム127セグレ場所サンタクルス、CA 95060米国
EMail: paul.hoffman@vpnc.org
メールアドレス：paul.hoffman@vpnc.org
Susan Harris 1722 Chandler Road Ann Arbor, MI 48104 US
スーザン・ハリス1722チャンドラーの道アナーバー、ミシガン48104米国
EMail: srh@umich.edu
メールアドレス：srh@umich.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。