[要約] RFC 4677は、IETF（Internet Engineering Task Force）の初心者向けガイドであり、IETFの目的とプロセスについて説明しています。このRFCの目的は、新参者がIETFに参加し、効果的に貢献するための指針を提供することです。
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
IETFのタオ：インターネットエンジニアリングタスクフォースの初心者のガイド
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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）の対面会議への出席は驚異的に成長しました。参加者の多くは、各会議で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ドキュメントは、BCPSからRFCSおよびFYISおよびSTDまで、TAOに記載されています。BCPは、インターネットでの最良の現在のプラクティスについて推奨を行います。RFCは、IETFの主要な技術文書シリーズであり、「コメントのリクエスト」として丁寧に知られています。FYIは、幅広い視聴者に紹介またはアピールするトピックおよび技術的な概要を提供します。また、STDは「標準」として識別される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.
このドキュメントは、FYI 17、RFC 3160を廃止することを目的としています。あるRFCが別のRFCを廃止することの意味については、セクション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年に公開されたこのドキュメントの元のバージョンは、Gary Malkinによって書かれました。IETF、洞察、および比類のない執筆スタイルに関する彼の知識は、この後の改訂の基準を設定し、現在の文書への貢献も大歓迎です。ポール・ホフマンはこの改訂の大部分を書き、励まし、専門知識、そして非常に必要なガイダンスを提供しました。その他の貢献者には、ブライアン・カーペンター、スコット・ブラッドナー、マイケル・パットン、ドナルド・E・イーストレイクIII、トニー・ハンセン、ペッカ・サヴォラ、リサ・デュセー、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
o インターネットでのプロトコルの標準化とプロトコルの使用に関するインターネットエンジニアリングステアリンググループ（IESG）に推奨事項を作成する
o Facilitating technology transfer from the Internet Research Task Force (IRTF) to the wider Internet community
o インターネットリサーチタスクフォース（IRTF）からより広いインターネットコミュニティへの技術移転の促進
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ほど成功する組織はありません。IETFの場合、その構造は、[BCP11]に記載されているように、他の組織によって提供されています。「IETF標準プロセスに関与する組織」。IETFに参加して、1つの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はメンバーの信念を実行します。「設立信念」の1つは、David ClarkのIETFについての初期の引用で具体化されています。IETFに対する一般的に保有されている信念となった別の初期の引用は、Jon Postelから来ています。
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.
新人にとって重要なもう1つのこと：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会議は、1986年1月にサンディエゴのLinkabitで開催され、21人の参加者がいます。1986年10月にメンロパークのSRIで開催された第4 IETFは、非政府ベンダーが出席した最初のものでした。ワーキンググループの概念は、1987年2月にカリフォルニアのNASA Ames Research Centerで開催された第5回IETF会議で導入されました。
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会議は、1989年7月にスタンフォード大学で開催されました。これは、IETFユニバースの構造の大きな変化を示しています。IAB（当時のインターネットアクティビティボード、現在はインターネットアーキテクチャボード）は、それまで多くの「タスクフォース」を監督していたため、IETFとIRTFの2つだけを残すように構造を変更しました。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.
1992年1月にインターネット協会（ISOC）が設立された後、IABはISOCにIABの活動がインターネット協会の後援の下で行われるべきであることを提案しました。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は、1993年7月にオランダのアムステルダムで会合しました。これはヨーロッパで開催された最初のIETF会議であり、米国/非出席者の分割はほぼ50/50でした。現在、3つのIETF会議がヨーロッパまたはアジアで開催されており、米国で開催された会議でさえ、米国以外の参加者の数は引き続き高くなっています。
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がこれを行う方法の1つは、ここで説明する他の「I」グループ、特にIETFの財政的および法的支援を通じてです。ISOCは、IETFプロセスの多くの人々に保険の補償を提供し、「I」グループの1つがマスコミに何かを言いたい時代の広報チャネルとして機能します。ISOCは、インターネットの主要な（およびサポートされていない）ヒーローの1つです。
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会議計画、サポートサービスの運用面（INATERIAT（インターネットに割り当てられた番号当局）の運用的側面）をフルタイムで監督する管理ディレクター（IAD）のみが含まれます。セクション）、および予算。彼または彼女（現在はHE）は、IETF管理サポートアクティビティ（IASA）をリードしています。これは、会議料金の収集や請求書の支払いなどのタスクの処理を行い、IETFワーキンググループ、IESG、The The Workのツールをサポートしています。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のワーキンググループ（WGS）からの出力を批准または修正し、WGSを開始および終了し、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年間任命されているエリアディレクター（広告）で構成されています。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)
他の領域に収まらないWGSの一般（gen）キャッチオール（非常に少ない）
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になるかどうかに大きな影響を与えているため、多くの人々は広告をやや神のような生き物と見なしています。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.
特定の領域の広告は、他の誰よりもそのエリアでのWGSの組み合わせ作業についてもっと知ることが期待されています。一方、IESG全体では、RFCになることが提案されている各インターネットドラフトをレビューします。どんな広告も、深刻な懸念がある場合、ドラフトに対して「議論」の投票ポジションを記録する場合があります。これらの懸念を議論によって解決できない場合、オーバーライド手順が定義され、少なくとも2人のIESGメンバーがドラフトが前進するのをブロックする前に懸念を表明する必要があります。これらの手順は、IETFプロトコルの残りにマイナスの影響を与える場合、広告の「PETプロジェクト」が標準の追跡に巻き込まれないことを保証し、広告の「Pet Peeve」が無期限に何かをブロックできないことを保証します。
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がIESGにWGの不適切に設計されたプロトコルに標準にするように依頼するとき、IESGは行動します。実際、ワークロードが高いため、IESGは通常、反応的な方法で動きます。最終的には、インターネットドラフトがRFCになるためのほとんどのWG要求を承認し、通常、何かが非常に間違っている場合にのみ介入します。これについて考える別の方法は、プロセスを実行するだけでなく、広告が考えるように選択されることです。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で作成されたものをブロックする主な理由の1つは、結果がIETF全体で実際にコンセンサスを得られなかったこと、すべての分野のすべてのワーキンググループの中で。たとえば、1つのWGの結果は、異なるワーキンググループで開発された技術と衝突する可能性があります。IESGの重要な仕事は、すべてのWGSの出力を監視して、互いに対立しているIETFプロトコルを防ぐことです。これが、広告が自分以外のエリアから出てくるドラフトを確認することになっている理由です。
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 Webサイトは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
o IESGアクションに対する控訴の控訴委員会として行動する
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
o ISOCのアドバイザリーボディとして機能します
o Oversees IETF liaisons with other standards bodies Like the IESG, the IAB members are selected for multi-year positions by the NomCom and are approved by the ISOC Board of Trustees.
o IESGのような他の標準団体を持つIETFリエゾンを監督し、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がドメイン名システムのルートのキーパーでもあったという事実は、それをはるかに公的な実体にすることを余儀なくされました。現在、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の創設者であるJon Postelは、インターネットが飛躍的に成長し続けている間、物事を整頓するために大きく依存しており、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エディターは、IESGと連携して作業して、インターネットドラフトをRFCとして編集、フォーマット、および公開しています。重要な二次的な役割は、すべてのRFCに1つの決定的なリポジトリを提供することです（http://www.rfc-editor.orgを参照）。RFCが公開されると、修正されることはありません。標準が変更を記述した場合、標準は別の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コミュニティで最も人気のある誤解の1つは、RFCエディターの役割がIANAによって実行されることです。実際、RFCエディターは別の仕事ですが、RFCエディターとIANAの両方が長年同じ人々を巻き込んでいます。IABは、RFCエディターおよびRFCエディターの一般ポリシーとして機能する組織を承認します。RFCエディターはIASAによって資金提供されており、Mailto：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事務局は、日々のロジスティックサポートを提供します。これは、主に対面会議の調整とIETF固有のメーリングリスト（WGメーリングリストではなく）を実行することを意味します。事務局はまた、公式のインターネットドラフトディレクトリを最新かつ秩序ある状態に保ち、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会議に参加する予定の人なら誰でも、ietFアナウンスメーリングリスト（Mailto：ietf-announce@ietf.org）に参加する必要があります。これは、すべての会議情報、RFCアナウンス、およびIESGプロトコルアクションと最後の呼び出しが投稿される場所です。「技術を取得したい」人は、IETF一般的なディスカッションリスト、ietf@itf.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」というプログラムによって処理されます。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アナウンスリストに参加するには、MailTo：ietf-announce-request@ietf.orgにメールを送信します。メッセージの件名とメッセージ本文に「subscribe」（引用符なし）という言葉（引用符なし）を入力します。IETFディスカッションリストに参加するには、<mailto：ietf-request@ietf.org>にメールを送信し、上記のように「subscribe」という単語を入力します。どちらのリストから撤回することにした場合は、「登録解除」という単語を使用します。Mailmanへのメッセージには、コマンドが「サブスクライブ」または「登録解除」以外に何も持たないはずです。両方のリストは、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回開催された会議は、WGSを再活性化してタスクを実行することであり、WGSとWGSとの間のかなりの量の混合を促進することです。エリア。会議の費用は、出席者と各会議の企業ホスト（もしあれば）によって支払われますが、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会議は北米で開催されます。なぜなら、それがほとんどの参加者の出身地だからです。ただし、会議は他の大陸で毎年約1回開催されます。過去数回の会議では、約1,300人の参加者がいました。これまでに65回以上のIETFミーティングがあり、今後の会議のリストがIETF Webページhttp://www.ietf.org/meetings/0mtg-sites.txtで入手できます。
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の対面会議の新人は、しばしば少しショックを受けています。彼らは、彼らが他の基準団体のように、またはコンピューター会議のようになることを期待しています。幸いなことに、ショックは1日か2日後に消え、多くの新しい参加者は、彼らがどれほど楽しんでいるかについて非常にアニメーション化されます。最近のIETFミーティングの特に耳障りな機能の1つは、会議スペース全体でワイヤレスインターネット接続を使用することです。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に送信する必要があります。登録と事前給与、事前登録、事前登録、後でウェブサイトに戻るために、クレジットカードで支払い、会議でオンサイトで支払うか、オンサイトで登録して支払うことができます。登録料を下げるには、早期登録期限（会議の約1週間前）までに支払う必要があります。登録料は、週のすべての会議、日曜日の夜のレセプション（キャッシュバー）、毎日の大陸の朝食、午後のコーヒーとスナックの休憩をカバーしています。
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).
ウェブ上のクレジットカードの支払いは暗号化されて安全です。または、必要に応じて、かなり優れたプライバシー（PGP）を使用して、レジストラ（Mailto：ietf-Registrar@ietf.org）に支払い情報を送信できます。
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.
登録は会議の1週間を通して開かれています。ただし、事務局は、通常は日曜日の正午から、日曜日の夕方のレセプションを通して続く早期登録に参加者が到着することを強く推奨しています。レセプションは人気のあるイベントで、他の早期到着と一緒に食事をしたり、交流したりできる人気のあるイベントです。
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.
登録パケットには、「Note Well」というタイトルのシートがあります。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ミーティングは、月曜日の朝から金曜日の昼食までの最後です。関連する会議は、多くの場合、前後の週末に行われます。ワーキンググループ間の相互受精と廊下の議論から利益を得るために、1週間を通して出席することを計画するのが最善です。以下に示すように、アジェンダは流動的であり、旅行計画が修正された後の土壇場のスケジューリングの変更により、参加者が重要なセッションを逃している多くの事例がありました。一週間を存在することが、この迷惑を避ける唯一の方法です。
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.
興味を持って会議を1週間見つけることができない場合でも、セッションの合間に作業することで、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の構造、および新しいIETFERのための他の多くの重要で啓発的なトピックをカバーしています。
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の一部の人々は、名前タグに少し色の付いたドットを持っています。数人が複数います。これらの点は、多くの余分な仕事をするためにボランティアをするのに十分なほど愚かな人々を識別します。色にはここに示されている意味があります。
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.
ホストが行う最も重要なことの1つ（あなたの視点に応じて）は、会議の参加者にインターネットアクセスを提供することです。一般に、有線およびワイヤレス接続は優れています。これは、地元のホストのオリンピアンの努力と、懇願、借り、盗む能力によるものです。機器、サービス、および時間を寄付する人々と企業は、心から祝福され、感謝することです。
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で非常によく食べるのは事実ですが、彼らは自分で食べ物を見つけます。昼食と夕食は登録料には含まれていません。事務局は、日曜日の夕方のレセプション（夕食の代わりになることではありません）、毎朝のコンチネンタルブレックファースト、および午後の休憩中のクッキー、ブラウニー、その他のヤミーで前菜を提供します。
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.
ホストによって組織され管理されている最も重要なことのもう1つは、IETFソーシャルイベントです。時には、ソーシャルイベントはコンピューターまたはハイテク関連のイベントです。たとえば、あるボストン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アナウンスリストに送信され、Webでも入手できます。最終アジェンダは登録パケットに含まれています。もちろん、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.
ブレイクアウトルーム（ワーキンググループとBOFが会う場所）の割り当てと、部屋の場所を示すマップもアジェンダに表示されます。アジェンダが変更されると、部屋の割り当てが変更される可能性があります。一部のワーキンググループは、会議中に複数回会合し、各セッションの同じ部屋でワーキンググループを開催するためにあらゆる試みが行われます。
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の特定の側面がまだあなたを神秘化する場合（TAOを読み終えた後でも）、教育（EDU）チームが提供するオンサイトトレーニングに立ち寄ることをお勧めします。これらの非公式のクラスは、新人とベテランのアイトファー向けに設計されています。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会議に来る義務を感じるべきではありません。以下のガイドライン（さまざまな業界の人々のステレオタイプに基づいて）は、実際に来たいかどうか、そしてもしそうなら、最初の会議であなたの時間を最大限に活用するのに役立つかもしれません。
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作業は、ISPSおよび大企業の他の多くの運用部分もカバーしており、この作業を活気に満ちた関連性を維持するには、オペレーターの入力が非常に価値があります。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会議は、コンピューターサイエンスの人々が間もなく展開されるプロトコルの方法で何が起こっているかを知るのに最適な場所です。ネットワーキングやコミュニケーションの研究を行っている教授や卒業生（そして時には学士号を取得することもあります）は、特定の関心分野でワーキンググループをフォローすることで豊富な情報を得ることができます。さまざまなワーキンググループ会議にさまようことは、あなたの部門でシンポジウムやセミナーに行くのと同じ効果をもたらすことができます。もちろん、研究者は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.
あなたがマスコミのメンバーであり、IETFに参加することを検討している場合、私たちはあなたのためだけにタオの特別なセクションを準備しました - セクション10.2を参照してください。
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か月で編集され、Webおよび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のWebリストを参照してください。
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の1分ごとに、仕事時間と見なすことができます（一部の人々の落胆には）。
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.
「Bar 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シャツ、ボタン、ポケットプロテクターのコストの回収を妨げるものではありません。
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.
会議中にラップトップに依存している場合は、追加のバッテリーを持参することをお勧めします。一部の会議室で予備のアウトレットを見つけるのは必ずしも簡単ではありません。ワイヤレスアクセスを使用すると、予想よりも速くバッテリーを引き下げることができます。会議室のパワーストリップの近くに座っている場合は、周囲の他の人のためにプラグとプラグを抜くように求められることを期待してください。多くの人が予備のコンセントを備えた延長コードを持ってきます。これは、会議で隣人と友達を作る良い方法です。アウトレットアダプターが必要な場合は、必要なものは通常、母国で見つけやすいので、事前に購入してみてください。
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椅子の役割は、[BCP11]と[BCP25]の両方で説明されています。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を完了させることができず、ワーキンググループが長年にわたってドラッグするようにチャーターに新しいタスクを追加し続けることができません。これらの老化したWGSの出力は、多くの場合、以前の製品ほど有用ではなく、乱雑な結果は「変性ワーキンググループ症候群」と呼ばれるものに起因することがあります。
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.
多くの初心者を混乱させるという事実の1つは、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.
正式な投票の欠如は、いくつかの提案にいくつかの非常に長い遅延を引き起こしましたが、rim慢な議論の後に大まかなコンセンサスを目撃したほとんどの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.
一部のワーキンググループには、複雑なドキュメントまたは複雑なドキュメントセット（またはその両方）があります。1つ以上の複雑なドキュメントからすべてのバグを振るのは困難な作業です。この問題を緩和するために、一部のワーキンググループは、ドキュメントに関するオープンな問題のオンラインリスト、問題のステータス、提案された修正などを使用しています。問題トラッカーを使用すると、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つの方法は、ワーキンググループ「秘書」を持ち、ドキュメントのジャグリングと変更を処理することです。秘書は、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.
ワーキンググループセッション中に、役立つ、そしておそらく面白いと思われるかもしれないことの1つは、そのワーキンググループに関連するJabber Roomの実行中の解説に従うことです。実行中の解説は、多くの場合、会議の議事録の基礎として使用されますが、ジョーク、ため息、その他の外部のおしゃべりを含めることもできます。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ミーティングのアジェンダは事前に入手できます（http://www.ietf.org/meetings/wg_agenda_xx.htmlを参照してください。）それらをめくることについて。
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会議のみをスケジュールし、スケジュールは初日の1週間前にわずかに変化することがよくあります。WGミーティングのみに来る場合は、特にワーキンググループの会議がスケジュールを変更する場合は、そのような通知でフライトを予約するのに苦労するかもしれません。フライトやホテルをスケジュールできるように、現在のアジェンダを追跡してください。しかし、それが結局のところ、あなたはおそらく1回のWGミーティングのために来るべきではないでしょう。これらのグループのドラフトとRFCを読んだと仮定して、いくつかのWGSであなたの知識が価値がある可能性があります。
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は、会社のブースター主義ではなく、技術的なコンテンツに関するものです。スライドは、しばしば読みやすくするために白黒であり、色が実際に明確になる場合にのみ使用されます。繰り返しますが、コンテンツはスライドの最も重要な部分であり、提示方法ではありません。
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ディスカッションリストは、Mailmanまたは別のリストマネージャーであるMajordomoのいずれかを使用しています。彼らは通常、リストに参加して離れることの管理の詳細を処理する「-request」アドレスを持っています。（Mailmanの詳細については、セクション3.3を参照してください。）一般的に、そのような管理者がディスカッションメーリングリストに登場したときに眉をひそめます。
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/でオンラインでリストされているか、Webベースのアーカイブにあります。探しているリストが見つからない場合は、リストの「-request」アドレスにメッセージを送信します（リスト自体ではありません！）。http://www.ietf.org/html.charters/wg-dir.htmlのワーキンググループチャーターリストは有用なソースです。ページには古いものへのリンクがあることに注意してください、とWGSは結論付けました。
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リストは、特に全員のメールボックスに着陸する大きなドキュメントやプレゼンテーションを避けるために、メッセージにサイズ制限を適用します。参加者はすべての人がブロードバンド接続を持っているわけではないことを覚えておく価値があります（そして、ブロードバンド接続を持つ人でさえ、旅行時に遅い接続でメールを取得することがあります）。ドキュメントはインターネットドラフトとして投稿できます。プレゼンテーション資料は、送信者によって制御されるWebサイトに投稿したり、それを求める人に個人的に送信することができます。一部の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.
ワーキンググループは、IETF間の暫定会議を開催することがあります。暫定会議はIETFミーティングの代わりではありませんが、グループは、3週間後にカンクン（またはどこか平凡な）で会うことができず、会う場所で会議をスキップすることを決定することはできません。暫定会議には広告承認が必要であり、少なくとも1か月前に発表する必要があります。場所とタイミングは、すべての参加者に公正なアクセスを可能にする必要があります。定期的なIETFミーティングのように、誰かがメモを取ってMailto：Proceedings@itf.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.
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が本当に必要だと思う場合は、提案を非公式に広告にアプローチし、彼または彼女がどう思うかを確認してください。次のステップは、次の対面会議でミーティングスロットをリクエストすることです。もちろん、メーリングリストの設定や憲章について話し合うなど、その会議がいくつかの仕事を成し遂げるのを待つ必要はありません。
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の目的は、良好なマイルストーンを備えた優れたチャーターを作成し、標準を作成するために必要な作業を喜んで行うことを望んでいることを確認することです。一部のBOFには、すでに進行中のインターネットドラフトがありますが、他のBOFはゼロから始まります。
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の他の人々がチャーターでやりたいことを制限する傾向があるかもしれません。特定のドキュメントのサポートを得るのではなく、最終的なワーキンググループのサポートを得るためには、ほとんどのBOFが保持されていることを覚えておくことが重要です。
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.
多くのBOFは、さまざまな理由でWGSになりません。一般的な問題は、十分な人が仕事の焦点に同意できることは十分ではないということです。もう1つの典型的な理由は、作業が標準にならないことです。たとえば、ドキュメントの著者が実際にWGに変更制御を放棄したくない場合です。（このドキュメントの後半でChange Controlについて説明します。）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を初めて使用する場合、これが会議に来る前に読む予定の唯一のリファレンスである場合は、少なくとも一時的にここに停止してください。その後、家に帰るときに、タオの残りの部分を読んでください。その時までに、あなたは会議に興味を持っているワーキンググループに積極的に関与する準備ができており、TAOはあなたの道を始めます。
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.
新人から聞いた最も一般的な質問の1つは、「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標準として公開されたものを取得するための基本的な手順は次のとおりです。
1. Publish the document as an Internet Draft.
1. ドキュメントをインターネットドラフトとして公開します。
2. Receive comments on the draft.
2. ドラフトに関するコメントを受け取ります。
3. Edit your draft based on the comments.
3. コメントに基づいてドラフトを編集します。
4. Repeat steps 1 through 3 a few times.
4. 手順1〜3を数回繰り返します。
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に持ち込むように依頼します。
6. Make any changes deemed necessary by the IESG (this might include giving up on becoming a standard).
6. IESGが必要とみなす変更を行います（これには、標準になることをあきらめることが含まれる場合があります）。
7. Wait for the document to be published by the RFC Editor.
7. ドキュメントがRFCエディターによって公開されるのを待ちます。
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 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:
これらの手順のより完全な説明は、[BCP9]、「インターネット標準プロセス」に含まれています。IETF標準になることを望んでいるドラフトを書く人は、プロセスを通じてドキュメントのパスに従うことができるように、BCP 9を読む必要があります。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内の標準です。これの良い要約は、適切にタイトルの[RFC1796]に記載されています。「すべてのRFCが標準ではない」。
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.
また、FYIS、BCPS、およびSTDとして知られるRFCの3つのサブシリーズもあります。あなたの情報のために、RFCサブシリーズは、紹介または幅広い視聴者にアピールする概要とトピックを文書化するために作成されました。ただし、そのシリーズは長い間追加されていません。最新の実践文書は、インターネット内のさまざまなテクノロジーの適用について説明しています。STD RFCサブシリーズは、実際にインターネット標準を指定するRFCを特定するために作成されました。一部のSTDは実際には複数の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には1つの実装しかない場合（標準トラックで進むには2つが必要です）、最初に標準トラックにそれを置くのは間違いでした。
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リポジトリに終わるすべてのドキュメントは、インターネットドラフトとしての生活を開始します。インターネットドラフトは暫定的なドキュメントです - 読者がコメントするためのものなので、著者はそれらのコメントを熟考し、ドラフトに組み込むものを決定することができます。人々に暫定性を思い出させるために、インターネットドラフトは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".
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に与える権利は、[BCP78]、「貢献におけるIETFの権利」に記載されています。
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とほぼ同じ形式が必要です。多くの人々の信念に反して、I-DはRFCとまったく同じように見える必要はありませんが、I-DSを作成するときにRFCエディターが使用するのと同じフォーマット手順を使用できれば、ドラフト時にRFCエディターの作業が簡素化されますRFCとして公開されています。[RFC2223]、「RFC著者への指示」は、RFCエディターが使用するNROFFフォーマットについて説明しています。http://xml.resource.org/から入手可能な「xml2rfc」と呼ばれるツールもあり、xml-formattedテキストを撮影し、有効なインターネットドラフトに変換します。
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の「Internet Drafts Database Interface」は、著者、ワーキンググループ、日付、またはファイル名によるドラフトを検索できます。https://datatracker.ietf.org/public/pidtracker.cgiの「i-dトラッカー」は、出版プロセスを経てドラフトの進捗を追跡したい著者にとって特に役立ちます。
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を改訂するインターネットドラフトには、「再び」または「2回」を意味する「bis」を含むドラフト名があることがよくあります。たとえば、ドラフトは「Draft-someone-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.
o インターネットドラフトの著者へのオンライン「ガイドライン」、http：//www.ietf.org/ietf/1id-guidelines.txtには、インターネットドラフトをターンするプロセスに関する最新の情報があります。各インターネットドラフトに含める必要がある現在のボイラープレート情報。
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.
o ドラフトプロセスが終了し、ドラフトがRFCになることを要求する準備ができたら、「RFC出版物のために提出されたインターネットドラフト（I-DS）のチェックリスト」、http：//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ツールのWebページhttp://tools.ietf.orgにアクセスする必要があります。ここでは、IETFの作業の一部を自動化する他のツールへのポインターが見つかります。
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".
インターネットドラフトを提出する準備ができたら、Mailto：Internet-drafts@ietf.orgのインターネットドラフト管理者に送信します。このメールアドレスのもう一方の端には実在の人物がいます。その仕事は、インターネットドラフトに必要な最小アイテムを公開することを確認することです。ドラフトの最初のバージョンを送信するとき、ドラフトの提案されたファイル名をドラフト管理者に伝えます。ドラフトが公式のワーキンググループ製品である場合、名前は「ドラフト」から始まり、次にWGの指定が続き、その後に記述的な単語が続き、その後に「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のドラフトには、「Draft-Iitf-Smime-Keying-00.txt」という名前が付けられている場合があります。ワーキンググループの産物ではない場合、名前は「ドラフト」と著者の姓とその後に記述的な単語が続き、その後に「00.txt」が続きます。たとえば、スミスという名前の誰かが書いたドラフトには、「ドラフトスミスキーイング-00.txt」という名前が付けられている可能性があります。ドラフトが個別の提出物であるが特定のワーキンググループに関連する場合、著者は「ドラフトスミススミメキーイング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ドラフトの第2版は「Draft-ITETF-SMIME-KEYING-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は、ワーキンググループの椅子、広告、または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の最後の呼び出しは、WGSからのドラフトで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エディターに提案された標準として公開するように依頼します。少なくとも6か月間提案された基準になった後、RFCの著者（または適切なWG椅子）は、ドラフト基準になるように要求できます。しかし、それが起こる前に、誰かが適切なエリアディレクターに、標準の各部分に少なくとも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.
通常、この時点でいくつかのことが起こります。第一に、ある実装者は自分が意味すると考えていたのに対し、別の実装者が何か他のことを意味すると考えたため、標準の仕様の一部を言い換える必要があることを見つけるのが一般的です。別の一般的な発生は、実装のどれも実際に標準のいくつかの機能を実装しようとしなかったことです。これらの機能は、誰もそれらをテストしなかっただけでなく、必要ではなかったために削除されます。
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.
開発者が相互運用可能な標準の実装を作成する可能性を高める1つの方法は、仕様で義務付けられているものを明確にすることです。初期の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年に書かれた方法で、有用であると思われる単語の短いリストがありました。これらの定義は更新され、[BCP14]、「RFCで使用するためのキーワードが要件レベルを示すキーワード」でさらに洗練されました。これは、現在のインターネット標準で広く参照されています。また、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を参照してください（ほとんどの人はそれをRFC 2119と呼んでいますが、それはBCP 14があなたにそうするように言っているためです）。第二に、あなたが使用している単語のどのインスタンスがBCP 14から来るかを指摘する必要があります。これのために受け入れられたプラクティスは、単語を大文字化することです。そのため、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標準を読んだり書いたりしているすべての人が読む必要があります。「必須」と「必須ではない」の定義はかなり明確ですが、「すべき」と「すべきではない」の定義は、多くのWGSで多くの議論を引き起こします。インターネットのドラフトをレビューするとき、質問が提起されます。仕様には無償の必需品があるべきではなく、相互運用性のために必要な場合に必要な場合は、これは非常に良い質問です。これは、標準における過度に指定されていない要件の問題の核心にもたらされます。
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標準を作成する1つの側面は、標準の非ITF文書または他の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レジストリまたは新しい値を必要とする可能性のあるインターネット標準を書いている人は誰でも[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およびインターネットドラフトで必要なことの1つは、「セキュリティ上の考慮事項」セクションです。このセクションでは、プロトコルの既知の脆弱性、可能な脅威、およびそれらに対処するためのメカニズムまたは戦略について説明する必要があります。このセクションに光沢を与えないでください。特に、「セキュリティが必要な場合は、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）の公式規則は、[BCP78]および[BCP79]、「IETFテクノロジーの知的財産権」でカバーされています。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はセキュリティ特許の1つのIBMからのライセンスであり、セキュリティコミュニティはこれに対して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は公開された後も変わらないため、RFCSで知的財産権は言及されていませんが、IPRの知識はいつでも変わる可能性があります。したがって、RFCのIPRリストは不完全であり、読者を誤解させる可能性があります。[BCP9]は、著者がIPRの問題を知っているRFCSに追加する必要がある特定のテキストを提供します。
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.) 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が標準であるわけではありません。実際、多くの重要なRFCは標準の追跡にまったく載っていません。現在、RFCには標準ではないことを意図していない2つの指定があります。タオのような情報と実験です。（実際には歴史的な3番目の指定がありますが、それは標準の軌跡にあり、現在の使用の欠如のために削除されたドキュメントのために予約されています。情報提供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.
IESGは、情報状況と実験的ステータスの間でどのように選択するかについてのガイドラインを作成しました：http：//www.ietf.org/u/ietfchair/info-exp.html。実験的な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の頻繁に引用された教義の1つは「実行中のコードWins」です。そのため、ランニングコードをより多く作成することで、より広く普及したい標準をサポートできます。
*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基準が繁栄するのを助けるために、特定の特許に無制限のライセンスをgeneしみなく提供しています。これらの企業は通常、他の特許保有者ほど貪欲でも近視眼的でもないという事実に対する前向きな宣伝で報われます。
*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、Unicodeコンソーシアム、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.
これらの連絡タスクのいくつかはIESGに落ちますが、他の人はIABに落ちます。ディテール指向の読者は、[BCP102]、「IETF連絡関係の管理のためのIABプロセス」、[BCP103]、「IETFへのリエゾンステートメントを処理する手順」[BCP103]、「IETFリエゾン関係の管理プロセス」の正式な方法について多くを学びます。。IETFが正式なリエゾンを持っているかどうかを確認するのに最適な場所は、IETF liaisons、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がインターネットを前進させるのに役立つ最も有名な団体の1つであることを考えると、コンピュータープレス（および貿易プレス）がその行動をカバーしたいと思うのは自然です。近年、少数の雑誌が、長期にわたって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つのカテゴリに分類されます。実際、ワーキンググループにインターネットドラフトだけがある場合、IETFが何かを検討していると言って、IETFが発生したときに何かを承認したと言って、情報RFCが公開されたということだけでした。どちらの場合も、マスコミは問題を完全に責めることはありません。なぜなら、彼らは通常、開発した、または少なくともサポートするプロトコルの宣伝を得ようとする企業によってストーリーに警告されているからです。もちろん、記者による少しの研究は、おそらくWGチェアやエリアディレクターなど、彼らをまっすぐにすることができる人と連絡を取るでしょう。IETFのデフォルトのプレス連絡先はIADで、Mailto：iad@ietf.orgでアクセスできます。
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.
これらすべてを考慮すると、いくつかのIETFERがミーティングから可能な限り遠く離れて滞在することを好むことは驚くことではありません。ほぼ完成に近づき、来年に業界で重要になるプロトコルに対して少し報道機関の宣伝をすることは良いことです。しかし、インターネットの次の救世主として、初心者の発生プロトコルを過度に促進できるのは珍しい記者です。このような物語は、記事の読者と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椅子と話をするべきだと思います。いかなる場合でも。ドラフトを見たり、ドラフトの著者と話したりすることで、ドラフトで何が起こるかを判断することは不可能です。幸いなことに、すべてのWGSには、レポーターがドラフトの進捗状況が何であるかについての最近の兆候を調べることができるアーカイブがあります。残念ながら、この種の研究を行う時間や傾向がある記者はほとんどいません。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がセキュリティ上の考慮事項をセクションにする必要がある理由を説明し、それが何を封じ込めるべきか、すべきではないものについて何らかのアイデアを提供します。その情報以外に、このドキュメントはインターネットセキュリティに触れていません。
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.
「ダウ」と発音されるタオは、中国のマスターであるラオスの教えの背後にある基本原則です。その馴染みのあるシンボルは、白黒の陰陽のサークルです。道教は、宇宙を単一の生物として、人間は宇宙全体の相互依存の部分として考えています。タオは時々「道」と翻訳されますが、道教の哲学によれば、言葉の真の意味は言葉で表現することはできません。
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-compict@ietf.orgリクエストを正確に送信する場所がわからない場合に行われることのリクエスト
ietf-info@ietf.org General questions about the IETF
ietf info@ietf.org IETFに関する一般的な質問
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-Request@ietf.orgは、IETFリストに参加/残すリクエストを要求します
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.org IETF Webサイトに関する質問またはコメント
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 Proceedingsのためにワーキンググループの議事録とスライドを送信する場所
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 Editor Statement@ietf.org他の組織からのリエゾンステートメント
Online upload pages are planned for the future to facilitate submission of Internet Drafts, Proceedings, and Liaison statements.
オンラインアップロードページは、インターネットドラフト、手続き、およびリエゾンステートメントの提出を容易にするために、将来のために計画されています。
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.
IESG Webページhttp://www.ietf.org/iesg.htmlを確認して、処理されたドラフト、RFCSの公開、および最後のコールのドキュメントに関する最新情報、および毎月のIETFステータスレポートを確認してください。
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
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.
TAOでこれまでに到達した場合、IETFがどのように機能するかについて多くのことを学びました。この付録にあなたが見つけるものは、あなたが読んだものの多くをまとめたものであり、熟考するためにいくつかの新しいポイントを追加します。必ずすべての原則を読んでください。全体として、彼らはあなたにIETFを機能させるものに新しい傾斜を与えます。
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またはそのWGSのメンバーシップは、料金ベースまたは組織的に定義されていませんが、個人による自己識別と積極的な参加に基づいています。
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。リーダーは、大まかなコンセンサスが実証されているという判断を下す権限を与えられています。正式なメンバーシップがなければ、コンセンサスに関する正式なルールはありません。
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。非現実的であると証明されたプロセスの一部は、削除またはオプションにする必要があります。
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。ワーキンググループ（WGS）は、主にその出力の品質、したがって早期のレビューを取得するために責任を負う必要があります。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。WGSは、インターネット全体での作業のマイナスの影響を評価すること、したがって、エリアクロスレビューを取得するために、主に責任を負う必要があります。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）は、WGSの形成とチャーターを導き、必要に応じて方向性を与え、終了する責任があります。
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チェアは、WGSがチャーターを実行し、マイルストーンを満たし、出版準備が整った成果物を生産することを保証する責任があります。
P20. ADs are responsible for arranging backstop review and final document approval.
P20。広告は、バックストップのレビューと最終的なドキュメントの承認を手配する責任があります。
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プロセスは現在、最高の現在の練習文書として公開されています。
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] Bradner、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] Galvin、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. Bradner、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[BCP25] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.
[BCP25] Bradner、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.
[BCP26] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[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] Harris、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] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[BCP78] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
[BCP78] Bradner、S。、「貢献におけるIETFの権利」、BCP 78、RFC 3978、2005年3月。
[BCP79] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
[BCP79] Bradner、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。およびInternet Architecture Board、「IETFリエゾン関係の管理のためのIABプロセス」、BCP 102、RFC 4052、2005年4月。
[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] Trowbridge、S.、Bradner、S。、およびF. Baker、「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.、Postel、J。、およびS. Crocker、「すべてのRFCが標準ではない」、RFC 1796、1995年4月。
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC2223] Postel、J。およびJ. Reynolds、「RFC著者への指示」、RFC 2223、1997年10月。
[STD3] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[STD3] Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
Authors' Addresses
著者のアドレス
Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 US
ポールホフマンVPNコンソーシアム127セグレプレイスサンタクルス、カリフォルニア州95060米国
EMail: paul.hoffman@vpnc.org
Susan Harris 1722 Chandler Road Ann Arbor, MI 48104 US
スーザンハリス1722チャンドラーロードアナーバー、ミシガン州48104米国
EMail: srh@umich.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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）によって提供されます。