Internet Engineering Task Force (IETF) N. ten Oever
Request for Comments: 9592 University of Amsterdam
Obsoletes: 6722 G. Wood
Category: Informational IETF Administration LLC
ISSN: 2070-1721 June 2024
This document retires and obsoletes the Tao of the IETF as an IETF-maintained document. This document also obsoletes RFC 6722, which describes the publication process of the Tao. Furthermore, this document describes the rationale for the retirement of the Tao. For archival purposes, the last version of the Tao is included in the appendix. Information that new participants need to engage in the work of the IETF will continue to be provided through the IETF website in a more timely and accessible manner. This is the way.
このドキュメントは、IETFに維持されたドキュメントとしてIETFのTAOを引退させ、廃止します。このドキュメントは、TAOの出版プロセスを説明するRFC 6722も廃止します。さらに、この文書は、TAOの引退の理論的根拠について説明しています。アーカイブのために、TAOの最後のバージョンは付録に含まれています。新しい参加者がIETFの作業に従事するために必要な情報は、よりタイムリーでアクセスしやすい方法でIETF Webサイトを通じて引き続き提供されます。これが方法です。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9592.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9592で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Reasons for Retirement
2.1. Infrequent Updates
2.2. Unwieldy Format
2.3. Changing Participation Modes
3. Going Forward
3.1. New Communications Opportunities
4. Conclusion
5. Security Considerations
6. IANA Considerations
7. Informative References
Appendix A. Last Edition of the Tao
Abstract
1 Introduction
1.1 Acronyms and Abbreviations Used in the Tao
2 What is the IETF?
2.1 Humble Beginnings
2.2 The Hierarchy
2.3 IETF Mailing Lists
3 IETF Meetings
3.1 Registration
3.2 Take the Plunge and Stay All Week!
3.3 Newcomer Training
3.4 Dress Code
3.5 Working Group Meetings
3.6 Seeing Spots Before Your Eyes
3.7 Terminal Room
3.8 Meals and Snacks
3.9 Social Event
3.10 Agenda
3.11 EMODIR to the Rescue
3.12 Where Do I Fit In?
3.13 Proceedings
3.14 Other General Things
3.15 Remote Participation
4 Working Groups
4.1 Working Group Chairs
4.2 Getting Things Done in a Working Group
4.3 Working Group Documents
4.4 Preparing for Working Group Meetings
4.5 Working Group Mailing Lists
4.6 Interim Working Group Meetings
5 BOFs and Dispatching
6 RFCs and Internet-Drafts
6.1 The Overall Process
6.2 Common Issues
6.3 Writing an Internet-Draft
6.4 Standards-Track RFCs
6.5 RFCs Other than Standards-Track
7 How to Contribute to the IETF
7.1 What You Can Do
7.2 What Your Company Can Do
8 IETF and the Outside World
8.1 IETF and Other SDOs
8.2 Press Coverage of the IETF
Acknowledgements
Authors' Addresses
Since its publication as [RFC1391] in 1993, The "Tao of the IETF" ("Tao") has described the inner workings of IETF meetings and Working Groups, discussed organizations related to the IETF, and introduced the working processes to new participants. The Tao never was a formal IETF process document, but rather a community-developed and maintained informational overview. After the Tao was published as an RFC for 13 years, it was published as a webpage for over a decade following the process described in [RFC6722]. However, the Tao did not keep up with the changes in the processes of the community and the organization, and thereby ceased to be a reliable source of information. We gratefully want to acknowledge all the individuals who contributed to the Tao over the years. The changing nature of IETF participation, a better understanding of how to most effectively convey information to new participants, and experience with publishing the Tao as a webpage all suggest a new approach to collecting, updating, and communicating the information that new participants need to engage in the work of the IETF successfully. This document formally retires and obsoletes the "Tao of the IETF" as a single standalone document.
1993年に[RFC1391]としての出版以来、「IETFのTAO」（「TAO」）は、IETF会議とワーキンググループの内部の仕組みを説明し、IETFに関連する組織について議論し、新しい参加者に作業プロセスを導入しました。TAOは決して正式なIETFプロセスドキュメントではなく、コミュニティが開発し、維持された情報概要でした。TAOが13年間RFCとして公開された後、[RFC6722]で説明されているプロセスに続いて10年以上にわたってWebページとして公開されました。しかし、TAOは、コミュニティと組織のプロセスの変化に追いつかず、それにより信頼できる情報源であることをやめました。私たちは、長年にわたってタオに貢献したすべての個人に感謝します。IETF参加の性質の変化、新しい参加者に情報を最も効果的に伝える方法をよりよく理解し、TAOをWebページとして公開する経験はすべて、新しい参加者が関与する必要がある情報を収集、更新、および伝達するための新しいアプローチを示唆しています。IETFの作業では、正常に。このドキュメントは、単一のスタンドアロン文書として「IETFのTAO」を正式に引退させ、廃止します。
In short, the breadth of topics covered in the Tao, the unpredictable and different schedule for updates to the topics, and the high overhead for revising and reviewing the content did not match the needs or preferences of the intended audience of the Tao.
要するに、TAOでカバーされているトピックの幅、トピックの更新の予測不可能で異なるスケジュール、およびコンテンツを修正およびレビューするための高いオーバーヘッドは、TAOの対象視聴者のニーズや好みと一致しませんでした。
The Tao was originally published as [RFC1391] in January 1993. In the following 17 years, four additional versions of the Tao were published as RFCs:
TAOはもともと1993年1月に[RFC1391]として公開されました。次の17年間で、TAOの4つの追加バージョンがRFCSとして公開されました。
* [RFC1539] in October 1993,
* [RFC1539] 1993年10月、
* [RFC1718] in November 1994,
* [RFC1718] 1994年11月、
* [RFC3160] in August 2001, and
* [RFC3160] 2001年8月、および
* [RFC4677] in September 2006.
* [RFC4677] 2006年9月。
In August 2012, [RFC6722] was published to document the process for publishing the Tao as a webpage so that it could "be updated more easily." However, in the subsequent 11 years, only four additional versions were published. The length of the Tao meant that review and approval of the entire document took considerable effort and time, leading to very infrequent updates.
2012年8月、[RFC6722]が公開され、TAOをWebページとして公開するプロセスを文書化して、「より簡単に更新する」ことができました。ただし、その後11年間で、追加のバージョンは4つの追加バージョンのみでした。TAOの長さは、ドキュメント全体のレビューと承認がかなりの努力と時間を費やし、非常にまれな更新につながることを意味しました。
The large, consolidated document format of the Tao made for a heavy investment by readers, in addition to the difficulty editors faced keeping pace with the changes required to keep it current. For example, the emergence of IETF Hackathon popularity with new participants prompted an update. However, that content was effectively buried in an already long document.
TAOの大規模で統合されたドキュメント形式は、読者による大規模な投資のために作成されました。これは、編集者が最新の状態に保つために必要な変更に対応する難易度に直面しました。たとえば、新しい参加者とのIETFハッカソンの人気の出現により、更新が促されました。ただし、そのコンテンツは、すでに長い文書に効果的に埋もれていました。
The original Tao aimed to welcome new participants to IETF meetings as attendance grew rapidly along with the growth of the Internet in the 1990s. As other avenues for initial participation in the IETF emerged over the ensuing decades, the main focus of the Tao remained on in-person meeting participation. For example, remote participation in IETF meetings has become a much more significant aspect in the past few years.
元のTAOは、1990年代のインターネットの成長とともに出席者が急速に成長したため、新しい参加者をIETF会議に歓迎することを目指しました。IETFへの最初の参加の他の手段がその後数十年にわたって現れたため、TAOの主な焦点は対面会議の参加にとどまりました。たとえば、IETF会議への遠隔参加は、過去数年間ではるかに重要な側面になりました。
The content of the Tao has already been integrated into the website of the IETF, which is the main channel of communication for IETF newcomers and a general audience. The content is continuously kept up to date with a variety of media to serve different audiences. The IETF seeks to ensure that the website continues to address the needs of our ever-evolving community and potential newcomers.
TAOのコンテンツは、IETFのWebサイトにすでに統合されています。これは、IETFの新人と一般聴衆のためのコミュニケーションの主なチャネルであるものです。コンテンツは、さまざまな視聴者にサービスを提供するために、さまざまなメディアで継続的に最新の状態に保たれています。IETFは、ウェブサイトが進化し続けるコミュニティと潜在的な新人のニーズに引き続き対応し続けることを保証しようとしています。
The IETF and its community continuously seek to improve its communication to newcomers and existing participants alike. Examples of possible ways of doing this:
IETFとそのコミュニティは、新規参入者と既存の参加者へのコミュニケーションを継続的に改善しようとしています。これを行う可能性のある方法の例：
* More focused guides, e.g., on IETF Hackathon participation, starting new work, etc.
* IETFハッカソンの参加、新しい仕事の開始など、より集中したガイド。
* Alternative formats, e.g., multiple shorter documents, on-demand video, podcasts, etc.
* 代替形式、たとえば、複数の短いドキュメント、オンデマンドビデオ、ポッドキャストなど。
* New channels for communications, e.g., blog posts, improved Datatracker, Slack, etc.
* 通信のための新しいチャネル、例：ブログ投稿、改善されたDataTracker、Slackなど。
The coverage of a wide range of topics, the unpredictable and different schedule for updates to the topics, and the high overhead for revising and reviewing the content mean that the Tao required a lot of effort to maintain, was commonly out-of-date, and thus did not serve its intended purpose of informing the community and newcomers. Therefore, this document is the end of the road for "Tao of the IETF." The document is now retired. For archival reasons, the last version of the Tao can be found in Appendix A.
幅広いトピックのカバレッジ、トピックの更新の予測不可能で異なるスケジュール、およびコンテンツを改訂およびレビューするための高いオーバーヘッドは、TAOが維持するために多くの努力を必要としたことを意味しますが、一般的には時代遅れであり、したがって、コミュニティと新人に通知するという意図された目的には役立ちませんでした。したがって、この文書は、「IETFのタオ」の道の終わりです。ドキュメントは廃止されました。アーカイブの理由から、タオの最後のバージョンは付録Aにあります。
This document has no security considerations.
このドキュメントにはセキュリティ上の考慮事項はありません。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[RFC1391] Malkin, G., "The Tao of the IETF: A Guide for New
Attendees of the Internet Engineering Task Force",
RFC 1391, DOI 10.17487/RFC1391, January 1993,
<https://www.rfc-editor.org/info/rfc1391>.
[RFC1539] Malkin, G., "The Tao of IETF - A Guide for New Attendees
of the Internet Engineering Task Force", RFC 1539,
DOI 10.17487/RFC1539, October 1993,
<https://www.rfc-editor.org/info/rfc1539>.
[RFC1718] IETF and G. Malkin, "The Tao of IETF - A Guide for New
Attendees of the Internet Engineering Task Force",
RFC 1718, DOI 10.17487/RFC1718, November 1994,
<https://www.rfc-editor.org/info/rfc1718>.
[RFC3160] Harris, S., "The Tao of IETF - A Novice's Guide to the
Internet Engineering Task Force", RFC 3160,
DOI 10.17487/RFC3160, August 2001,
<https://www.rfc-editor.org/info/rfc3160>.
[RFC4677] Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's
Guide to the Internet Engineering Task Force", RFC 4677,
DOI 10.17487/RFC4677, September 2006,
<https://www.rfc-editor.org/info/rfc4677>.
[RFC6722] Hoffman, P., Ed., "Publishing the "Tao of the IETF" as a
Web Page", RFC 6722, DOI 10.17487/RFC6722, August 2012,
<https://www.rfc-editor.org/info/rfc6722>.
For archival purposes, the last edition of the Tao as published under the process described in [RFC6722], is included below. Note that several links to resources external to the Tao do not work at the time of publication of this RFC. Additionally, minor errors in the following text have been corrected.
アーカイブのために、[RFC6722]で説明されているプロセスで公開されているTAOの最後の版を以下に示します。TAOの外部のリソースへのいくつかのリンクは、このRFCの公開時には機能しないことに注意してください。さらに、次のテキストの小さなエラーが修正されました。
This document introduces you to the "ways of the IETF": it will convey the might and magic of networking people and packets in the Internet's most prominent standards body. In this document we describe the inner workings of IETF meetings and Working Groups, discuss organizations related to the IETF, and introduce the standards process. This is not a formal IETF process document but an informal and informational overview.
このドキュメントでは、「IETFの方法」を紹介します。インターネットの最も顕著な基準体のネットワーキングの人々とパケットの力と魔法を伝えます。このドキュメントでは、IETF会議とワーキンググループの内部仕組みについて説明し、IETFに関連する組織について議論し、標準プロセスを導入します。これは、正式なIETFプロセスドキュメントではなく、非公式および情報の概要です。
The Internet Engineering Task Force (IETF) is the largest standard development organization (SDO) for the Internet. Since its early years, participation in the IETF has grown phenomenally. In-person attendance at face-to-face meetings now averages between 1000 and 1500 participants (https://datatracker.ietf.org/stats/meeting/ overview/). At any given meeting, around 200 attendees are _newcomers_ (defined by the IETF as someone who has attended five or fewer meetings), and many of those go on to become regular participants. When the IETF was smaller, it was relatively easy for a newcomer to adjust. Today, however, a newcomer meets many more new people -- some previously known only as the authors of documents or thought-provoking email messages.
インターネットエンジニアリングタスクフォース（IETF）は、インターネットにとって最大の標準開発組織（SDO）です。初期の頃から、IETFへの参加は驚異的に成長してきました。対面会議への対面の出席者は現在、平均1000〜1500人の参加者（https://datatracker.ietf.org/stats/meeting/ overview/）です。特定の会議では、約200人の参加者が_newcomers_（5回以下の会議に出席した人としてIETFによって定義されています）であり、それらの多くは定期的な参加者になります。IETFが小さい場合、新人が調整するのは比較的簡単でした。しかし、今日、新人はさらに多くの新しい人々に会います - 以前はドキュメントの著者としてのみ知られていたものや思考を刺激する電子メールメッセージです。
Of course, it's true that many IETF participants don't go to the face-to-face meetings at all -- especially since the COVID-19 pandemic when meetings were completely online for a while. There are also many participants who solely focus on the mailing lists 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. The IETF website also has a lot of newcomer information (https://www.ietf.org/about/participate/get-started/) in various formats. In this document we try to cover as much as possible in one place.
もちろん、多くのIETF参加者が対面の会議にまったく行われないことは事実です。また、さまざまなIETFワーキンググループのメーリングリストだけに焦点を当てている多くの参加者がいます。ワーキンググループの内部の仕組みは新人が理解するのが難しい可能性があるため、この文書は、積極的な参加者になるために新参者が必要とする普通の情報を提供します。IETF Webサイトには、さまざまな形式で多くの新規参照情報（https://www.ietf.org/about/particate/get-started/）もあります。このドキュメントでは、可能な限り1か所でカバーしようとします。
The IETF is always evolving. Although the principles in this document are expected to remain consistent 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 here. The IETF publishes its technical documentation as RFCs, still known by their historical term _Requests for Comments_. (Sometimes people joke that it stands for _Request for Compliance_.) STDs are RFCs identified as "standards", and BCPs are RFCs that represent thoughts on Best Current Practices in the Internet. Both STDs and BCPs are also RFCs. For example, BCP 9 (https://www.rfc-editor.org/info/bcp9) points to a collection of RFCs that describe the IETF's standardization processes. See RFCs and Internet-Drafts for more details.
多くのタイプのIETFドキュメントがここに記載されています。IETFは、その技術文書をRFCSとして公開していますが、歴史的な用語_ _ _requests for Contument_で知られています。（時々、人々はそれが_request for compliance _を表していると冗談を言っています。）STDは「標準」として識別されたRFCであり、BCPはインターネットでの最良の現在のプラクティスに関する考えを表すRFCです。STDとBCPの両方もRFCです。たとえば、BCP 9（https://www.rfc-editor.org/info/bcp9）は、IETFの標準化プロセスを説明するRFCのコレクションを指しています。詳細については、RFCとインターネットドラフトを参照してください。
Some of the acronyms and abbreviations from this document are listed below.
このドキュメントの頭字語と略語のいくつかを以下に示します。
+=======+=====================================================+
| Term | Meaning |
+=======+=====================================================+
| AD | Area Director |
+-------+-----------------------------------------------------+
| BCP | Best Current Practice (a type of RFC) |
+-------+-----------------------------------------------------+
| BOF | Birds of a Feather |
+-------+-----------------------------------------------------+
| IAB | Internet Architecture Board |
+-------+-----------------------------------------------------+
| IANA | Internet Assigned Numbers Authority |
+-------+-----------------------------------------------------+
| IASA | IETF Administrative Support Activity |
+-------+-----------------------------------------------------+
| ICANN | Internet Corporation for Assigned Names and Numbers |
+-------+-----------------------------------------------------+
| I-D | Internet-Draft |
+-------+-----------------------------------------------------+
| IESG | Internet Engineering Steering Group |
+-------+-----------------------------------------------------+
| IPR | Intellectual property rights |
+-------+-----------------------------------------------------+
| IRSG | Internet Research Steering Group |
+-------+-----------------------------------------------------+
| IRTF | Internet Research Task Force |
+-------+-----------------------------------------------------+
| ISOC | Internet Society |
+-------+-----------------------------------------------------+
| RFC | Request for Comments |
+-------+-----------------------------------------------------+
| STD | Standard (a type of RFC) |
+-------+-----------------------------------------------------+
| WG | Working Group |
+-------+-----------------------------------------------------+
Table 1
The IETF has no members and no dues; it 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 meetings (both in-person and virtual) and online activities (such as email and pull request discussions), in which individuals voluntarily participate.
IETFにはメンバーも会費もありません。これは、インターネットテクノロジーのエンジニアリングと進化に貢献する人々の大まかな自己組織化グループです。これは、新しいインターネット標準仕様の開発に従事している主要機関です。IETFは、個人が自発的に参加する会議（対面および仮想の両方）およびオンラインアクティビティ（電子メールやリクエストディスカッションなど）のコレクションとして存在するという点で珍しいです。
The IETF welcomes all interested individuals: IETF participants come from all over the world and from many different parts of the Internet industry. The IETF conducts its work solely in English. See Where do I fit in? for information about the ways that many people fit into the IETF.
IETFは、関心のあるすべての個人を歓迎します。IETF参加者は、世界中からインターネット業界のさまざまな地域から来ています。IETFは、英語のみで作業を行っています。どこに収まるのか見てみましょう。多くの人々がIETFに適合する方法についての情報。
Quoting from RFC 3935: A Mission Statement for the IETF (https://www.rfc-editor.org/info/rfc3935): "the overall goal of the IETF is to make the Internet work better. Its mission is to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better. These documents include protocol standards, best current practices, and informational documents of various kinds."
RFC 3935からの引用：IETFのミッションステートメント（https://www.rfc-editor.org/info/rfc3935）：「IETFの全体的な目標は、インターネットをより良くすることです。これらのドキュメントには、人々がインターネットの機能を改善するように、人々がインターネットを設計、使用、および管理する方法に影響を与える品質、関連する技術文書。
The ways to do that include the following:
それを行う方法には、次のものが含まれます。
* Identifying and proposing solutions to pressing operational and technical problems in the Internet.
* インターネットでの運用上および技術的な問題を差し引くための解決策を特定し、提案します。
* Specifying the development or usage of protocols and the near-term architecture to solve such technical problems for the Internet.
* インターネットのこのような技術的問題を解決するために、プロトコルと短期アーキテクチャの開発または使用を指定します。
* Making recommendations to the Internet Engineering Steering Group (IESG) regarding the standardization of protocols and protocol usage in the Internet.
* インターネットでのプロトコルの標準化とプロトコルの使用に関するインターネットエンジニアリングステアリンググループ（IESG）に推奨事項を作成します。
* Facilitating technology transfer from the Internet Research Task Force (IRTF) to the wider Internet community.
* インターネットリサーチタスクフォース（IRTF）からより広いインターネットコミュニティへの技術移転を促進します。
* Providing a forum for the exchange of information within the Internet community among vendors, users, researchers, agency contractors, operators, and network managers.
* ベンダー、ユーザー、研究者、代理店請負業者、オペレーター、ネットワークマネージャーの間で、インターネットコミュニティ内の情報交換のためのフォーラムを提供します。
RFC 3935 further states that the Internet isn't value-neutral, and neither is the IETF. The IETF wants the Internet to be useful for communities that share our commitment to openness and fairness. The IETF embraces technical concepts such as decentralized control, edge-user empowerment and sharing of resources, because those concepts resonate with the core values of the IETF community. These concepts have little to do with the technology that's possible, and much to do with the technology that the IETF chooses to create.
RFC 3935はさらに、インターネットは価値中立ではなく、IETFもそうではないと述べています。IETFは、オープン性と公平性へのコミットメントを共有するコミュニティにとって、インターネットが役立つことを望んでいます。IETFは、IETFコミュニティのコアバリューと共鳴するため、分散型制御、エッジユーザーエンパワーメント、リソースの共有などの技術的な概念を採用しています。これらの概念は、可能なテクノロジーとはほとんど関係がなく、IETFが作成することを選択したテクノロジーと関係があります。
In many ways, the IETF runs on the beliefs of its participants. 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つは、デビッド・クラークのIETFについての初期の引用で具体化されています。IETFに対する一般的に保持されている信念となった別の初期の引用は、ジョン・ポステルから来ています。
There is no membership in the IETF. Anyone may sign up to working group mailing lists, or register for a meeting and then attend. The closest thing there is to being an IETF member is being a participant on the IETF or Working Group mailing lists. This is where the best information about current IETF activities and focus can be found.
IETFにはメンバーシップはありません。誰でもワーキンググループメーリングリストにサインアップするか、会議に登録してから出席することができます。IETFメンバーであることに最も近いことは、IETFまたはワーキンググループのメーリングリストの参加者であることです。これは、現在の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 supporting organizations, as described in RFC 2028: The Organizations Involved in the IETF Standards Process (https://www.rfc-editor.org/info/rfc2028). Please note that RFC 2028 is outdated and being revised.
もちろん、IETFが何らかの構造を持たないほどIETFほど成功する組織はありません。IETFの場合、その構造は、RFC 2028：IETF標準プロセスに関与する組織（https://www.rfc-editor.org/info/RFC2028）に記載されている他のサポート組織によって提供されます。RFC 2028は時代遅れで修正されていることに注意してください。
The IETF web site (https://www.ietf.org) is the best source for information about upcoming IETF meetings and newcomer materials. The IETF Datatracker (https://datatracker.ietf.org/) is the best source for information about Internet-Drafts, RFCs, and Working Groups.
IETF Webサイト（https://www.ietf.org）は、今後のIETFミーティングと新人資料に関する情報の最良の情報源です。IETF DataTracker（https://datatracker.ietf.org/）は、インターネットドラフト、RFC、およびワーキンググループに関する情報の最良の情報源です。
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 voluntary standards that are often adopted by Internet users, network operators, and equipment vendors, and it thus helps shape the trajectory of the development of the Internet. But in no way does the IETF 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. A saying you will sometimes hear is, "we are not the protocol police."
新人にとって重要なもう1つのことは、一部の人々が誤って言うかもしれないことにもかかわらず、IETFは決して「インターネットを実行する」ことはありません。IETFは、インターネットユーザー、ネットワークオペレーター、および機器ベンダーによく採用される自発的な基準を作成します。したがって、インターネットの開発の軌跡を形作るのに役立ちます。しかし、IETFがインターネットを制御したり、パトロールを制御したりすることはありません。IETFへの関心が、あなたが監督の一員になりたいからであるなら、IETFにひどく失望するかもしれません。あなたが時々聞くと言うことは、「私たちはプロトコル警察ではない」ということです。
The first IETF meeting was held in January 1986 at Linkabit in San Diego, with 21 attendees. The 4th IETF, held at SRI in Menlo Park in October 1986, was the first that equipment 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会議で導入されました。
After the Internet Society (https://www.internetsociety.org) (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.
インターネット協会（https://www.internetsociety.org）（ISOC）が1992年1月に設立された後、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. The IETF first met in Oceania (in Adelaide, Australia) in 2000, the first meeting in Asia (in Yokohama, Japan) was in 2002, and the first meeting in Latin America (in Buenos Aires, Argentina) was in 2016. So far, the IETF has never met in Africa.
IETFは、1993年7月にオランダのアムステルダムで会合しました。これはヨーロッパで開催された最初のIETF会議であり、米国/非出席者の分割はほぼ50/50でした。IETFは、2000年にオセアニア（オーストラリア、オーストラリアのアデレード）で初めて会った、アジアでの最初の会議（日本、日本、日本）は2002年に行われ、ラテンアメリカでの最初の会議（アルゼンチン、ブエノスアイレス）は2016年でした。、IETFはアフリカで会ったことがありません。
The IETF currently has a "1-1-1" meeting policy where the goal is to distribute the meetings equally between North America, Europe, and Asia. This policy is mainly aimed at distributing the travel effort for the existing IETF participants who physically attend meetings and for distributing the timezone difficulty for those who participate remotely. The IETF has also met in Latin America and Oceania, but these continents are currently not part of the 1-1-1 rotation schedule. More information on picking the venue and the meeting policy can be found in RFC 8718: IETF Plenary Meeting Venue Selection Process (https://www.rfc-editor.org/info/rfc8718) and RFC 8719: High-Level Guidance for the Meeting Policy of the IETF (https://www.rfc-editor.org/info/rfc8719).
IETFには現在、北米、ヨーロッパ、アジアの間で会議を等しく配布することが目標がある「1-1-1」会議ポリシーがあります。このポリシーは、主に、会議に物理的に出席する既存のIETF参加者のために旅行努力を配布し、リモートに参加する人にタイムゾーンの難易度を配布することを目的としています。IETFはラテンアメリカとオセアニアでも会いましたが、これらの大陸は現在、1-1-1ローテーションスケジュールの一部ではありません。会場と会議ポリシーの選択に関する詳細については、RFC 8718：IETF全体会議会場の選択プロセス（https://www.rfc-editor.org/info/rfc8718）およびRFC 8719：IETFのポリシーを満たす（https://www.rfc-editor.org/info/rfc8719）。
Remote participation in IETF meetings has been growing significantly in the past few years, thanks in part to the ongoing effort to improve the tools and processes used to facilitate this mode of participation.
この参加モードを促進するために使用されるツールとプロセスを改善するための継続的な取り組みのおかげで、IETF会議への遠隔参加は過去数年で大幅に増加しています。
The Internet Society (ISOC) is an international, non-profit, membership organization that supports and promotes the development of the Internet as a global technical infrastructure. The mission of ISOC is "to promote the open development, evolution, and use of the Internet for the benefit of all people throughout the world." One of the ways that ISOC does this is through financial support of the IETF.
インターネット協会（ISOC）は、インターネットの開発をグローバルな技術インフラストラクチャとして支援および促進する国際的な非営利団体組織です。ISOCの使命は、「世界中のすべての人々の利益のためにインターネットのオープン開発、進化、および使用を促進すること」です。ISOCがこれを行う方法の1つは、IETFの財政的支援によるものです。
The IETF Administration LLC (https://www.ietf.org/about/ administration/) (IETF LLC) is a "disregarded entity" of ISOC, which means it is treated as a branch or division for tax purposes. The IETF LLC has no role in the oversight or steering of the standards process, the appeal chain, the confirming bodies for existing IETF and IAB appointments, the IRTF, or ISOC's memberships in other organizations. Rather, the IETF LLC, as overseen by its Board of Directors, is responsible for staffing and contracts with places like hotels to host IETF meetings. Most of the day-to-day activities are delegated to the IETF Executive Director.
IETF Administration LLC（https://www.ietf.org/about/ Administry/）（IETF LLC）はISOCの「無視されたエンティティ」です。つまり、税務目的の支店または部門として扱われます。IETF LLCは、標準プロセスの監視またはステアリング、控訴チェーン、既存のIETFおよびIABの任命の確認機関、IRTF、または他の組織のISOCのメンバーシップに役割を果たしていません。むしろ、取締役会が監督するIETF LLCは、IETFミーティングを開催するためにホテルのような場所との人員配置と契約を担当しています。日々の活動のほとんどは、IETFエグゼクティブディレクターに委任されます。
Responsibilities of the IETF LLC include:
IETF LLCの責任は次のとおりです。
* Supporting the ongoing operations of the IETF, including meetings and non-meeting activities.
* 会議や非ミーティング活動など、IETFの継続的な運用をサポートします。
* Managing the IETF's finances and budget.
* IETFの財政と予算の管理。
* Raising money on behalf of the IETF.
* IETFに代わって資金を集めます。
* Establishing and enforcing policies to ensure compliance with applicable laws, regulations, and rules.
* 適用される法律、規制、および規則への準拠を確保するためのポリシーの確立と実施。
The IETF and ISOC continue to be strongly aligned on key principles. ISOC initiatives related to the IETF continue to support participation in, and deployment of, the standards created by the IETF.
IETFとISOCは、主要な原則に強く整合し続けています。IETFに関連するISOCイニシアチブは、IETFによって作成された標準への参加と展開を引き続きサポートしています。
The IESG is responsible for technical management of IETF activities and the Internet standards process. However, the IESG doesn't exercise 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 gets WGs started and finished, ratifies or steers the output from the IETF's Working Groups (WGs), and makes sure that non-WG I-Ds that are about to become RFCs are correct.
IESGは、IETFアクティビティとインターネット標準プロセスの技術的管理を担当しています。ただし、IESGは、他の多くの標準組織にある種類など、それほど直接的なリーダーシップを発揮しません。その名前が示すように、その役割は注文を与えるのではなく、方向を設定することです。IESGは、WGSを開始および終了し、IETFのワーキンググループ（WGS）から出力を批准または操縦し、RFCになっているNon-WG I-DSが正しいことを確認します。
Check the IESG web pages (https://www.ietf.org/about/groups/iesg) to find up-to-date information about IESG statements, I-Ds processed, RFCs published, and documents in Last Call, as well as the monthly IETF status reports.
IESG Webページ（https://www.ietf.org/about/groups/iesg）をチェックして、IESGステートメント、I-DS処理、RFCSの公開、および最後の電話でドキュメントに関する最新情報を見つけてください。毎月のIETFステータスが報告するように。
The IESG consists of the Area Directors (ADs), who are selected by the Nominations Committee (NomCom) and are appointed for two years. The process for choosing the members of the IESG is detailed in BCP 10 (https://www.rfc-editor.org/info/bcp10).
IESGは、ノミネート委員会（NOMCOM）によって選択され、2年間任命されているエリアディレクター（ADS）で構成されています。IESGのメンバーを選択するプロセスは、BCP 10（https://www.rfc-editor.org/info/bcp10）に詳述されています。
The current Areas and abbreviations are shown below, and more details (https://www.ietf.org/topics/areas/) are on the IETF web site.
現在の領域と略語を以下に示し、詳細（https://www.ietf.org/topics/areas/）をIETF Webサイトに示します。
+======================+========================================+
| Area | Description |
+======================+========================================+
| Applications and | Protocols seen by user programs, such |
| Real-Time Area (art) | as email and the web and delay- |
| | sensitive interpersonal communications |
+----------------------+----------------------------------------+
| General (gen) | IETF process, and catch-all for WGs |
| | that don't fit in other Areas (which |
| | is very few) |
+----------------------+----------------------------------------+
| Internet (int) | Different ways of moving IP packets |
| | and DNS information |
+----------------------+----------------------------------------+
| Operations and | Network management, AAA, and various |
| Management (ops) | operational issues facing the Internet |
+----------------------+----------------------------------------+
| Routing (rtg) | Getting packets to their destinations |
+----------------------+----------------------------------------+
| Security (sec) | Privacy, integrity, authentication, |
| | non-repudiation, confidentiality, and |
| | access control |
+----------------------+----------------------------------------+
| Transport (tsv) | Transport for large volumes of traffic |
| | at potentially high bandwidths |
+----------------------+----------------------------------------+
Table 2
Because the IESG reviews all Internet-Drafts before they become RFCs, ADs have quite a bit of influence. The ADs for a particular Area are expected to know more about the combined work of the WGs in that Area than anyone else. This is because the ADs actively follow the working groups for which they are responsible and assist working groups and chairs with charter and milestone reviews. Some people, therefore, shy away from directly engaging with Area Directors. Don't -- they can be an important resource and help you find the person or the answer that you're looking for. They are, however, often very busy during meetings, and so an email to schedule a meeting can be useful, or just ask your questions.
IESGはすべてのインターネットドラフトをRFCになる前にレビューしているため、広告にはかなりの影響があります。特定の領域の広告は、他の誰よりもそのエリアでのWGSの組み合わせ作業についてもっと知ることが期待されています。これは、広告が責任を負い、憲章とマイルストーンのレビューでワーキンググループと椅子を支援するワーキンググループを積極的に追跡するためです。したがって、一部の人々は、地域のディレクターと直接関与することを避けます。しないでください - それらは重要なリソースであり、あなたが探している人や答えを見つけるのを助けます。しかし、彼らは多くの場合、会議中に非常に忙しいので、会議をスケジュールする電子メールは役立つか、質問することができます。
The entire IESG reviews each Internet-Draft (I-D or "draft") that is proposed to become an RFC and should be aware of general trends that can be gleaned from the collective work products of the IETF. For IETF produced RFCs, as part of the document reviews, ADs place ballots that may contain comments on documents. The AD enters a position that may be _YES_, _NO OBJECTION_, _DISCUSS_, _ABSTAIN_, or _RECUSE_ as the result of their review. Any AD may record a _DISCUSS_ ballot position against a draft if they have serious concerns and would like to discuss these concerns. It is common for documents to be approved with one or two _YES_ ballots, and the majority of the remaining IESG balloting _NO OBJECTION_. An IETF blog post (https://www.ietf.org/blog/handling-iesg-ballot-positions/) provides advice on how draft authors could handle the various ballot positions.
IESG全体では、RFCになることが提案されている各インターネットドラフト（I-Dまたは「ドラフト」）をレビューし、IETFの集合作業製品から収集できる一般的な傾向に注意する必要があります。IETFの場合、ドキュメントレビューの一部としてRFCSを作成した場合、ADSはドキュメントにコメントを含む可能性のある投票を行います。広告は、レビューの結果として、_yes_、_no deplyjection_、_discuss_、_ abstain_、または_recuse_である可能性のあるポジションに入ります。どんな広告も、深刻な懸念があり、これらの懸念について議論したい場合、ドラフトに対して_discuss_投票の位置を記録する場合があります。ドキュメントは、1つまたは2つの_YES_投票、および残りのIESG投票_NO異議_の大部分で承認されることが一般的です。IETFブログ投稿（https://www.ietf.org/blog/handling-iesg-ballot-positions/）は、ドラフト著者がさまざまな投票のポジションをどのように処理できるかについてのアドバイスを提供します。
Another 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 I-Ds coming out of Areas other than their own, and each Area has a _directorate_, a set of experienced volunteers who review I-Ds with a focus on potential issues for their area.
IESGのもう1つの重要な仕事は、すべてのWGSの出力を監視して、互いに対立しているIETFプロトコルを防ぐことです。これが、広告が独自のエリアから出てくるI-DSをレビューすることになっている理由であり、各エリアには_Directorate_があります。
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.
IETF標準の品質は、ワーキンググループで得られるレビューと、WGレビューが広告から得られる精査の両方から得られます。
The IAB (https://www.iab.org) 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.
IAB（https://www.iab.org）は、インターネットの「全体像」に注目する責任があり、IETFアクティビティのさまざまな分野の長期的な計画と調整に焦点を当てています。IABは、インターネットでの重要な長期的な問題について知らされたままであり、これらのトピックを彼らについて知っておくべきだと思う人々の注意を引き起こします。
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 (https://www.irtf.org) (IRTF) 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. The IAB keeps the community informed through blog posts and by publishing RFCs.
IABはまた、インターネットリサーチタスクフォース（https://www.irtf.org）（IRTF）を後援および組織し、特定のインターネットアーキテクチャの問題の詳細なレビューを提供する招待状のワークショップを開催します。通常、ワークショップレポートは、IETFコミュニティとIESGに推奨を行います。IABは、ブログの投稿やRFCを公開することにより、コミュニティに通知され続けています。
The IAB also:
IABも：
* Approves NomCom's IESG nominations
* NomcomのIESGノミネートを承認します
* Acts as the appeals board for appeals against IESG actions
* IESGアクションに対する控訴の控訴委員会として行動する
* Oversees the RFC series policy and procedures
* RFCシリーズのポリシーと手順を監督します
* Acts as an advisory body to ISOC
* ISOCのアドバイザリーボディとして機能します
* Oversees IETF liaisons with other standards bodies
* IETFリエゾンを他の標準団体で監督します
Like the IESG, the IAB members are selected for two-year positions by the NomCom and are approved by the ISOC Board of Trustees.
IESGと同様に、IABメンバーはNOMCOMによって2年間のポジションに選ばれ、ISOC理事会によって承認されます。
The core registrar for the IETF's activities is the IANA (https://www.iana.org). 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. IANA's work on behalf of the IETF is overseen by the IAB. There is a joint group (https://datatracker.ietf.org/group/ietfiana/about/) that advises IANA. IANA is funded by ICANN (https://www.icann.org).
IETFのアクティビティのコアレジストラはIANA（https://www.iana.org）です。多くのインターネットプロトコルでは、プロトコルが発表された後に追加されたプロトコルアイテムを誰かが追跡する必要があります。必要なレジストリの種類の典型的な例は、TCPポート番号とMIMEタイプです。IETFに代わってIANAの作業は、IABによって監督されています。IANAに助言する共同グループ（https://datatracker.ietf.org/group/ietfiana/about/）があります。IANAはICANN（https://www.icann.org）によって資金提供されています。
Even though being a registry 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.
レジストリであることは面白くないかもしれませんが、多くのIETF参加者は、IANAがインターネットにとってどれほど重要であるかについて証言します。慎重かつ保守的なオペレーターが実行する安定した長期リポジトリを持つことで、人々が物事をいじくり回すことを心配することなく実験しやすくなります。
The RPC edits, formats, and publishes RFC's. This used to be done by one person, which is why you will still see the term _RFC Editor_; IETFers are fond of their history. Also, if you are a document author, you will most commonly come in contact with people responsible for editing your draft. Another important role is to provide one definitive repository (https://www.rfc-editor.org) for all RFCs.
RPCは、RFCを編集、フォーマット、および公開します。これは以前は1人で行われていたため、_rfc editor_という用語がまだ表示されます。ietfersは彼らの歴史が好きです。また、あなたが文書著者である場合、あなたはあなたのドラフトの編集に責任がある人々と連絡を取るでしょう。もう1つの重要な役割は、すべてのRFCに1つの決定的なリポジトリ（https://www.rfc-editor.org）を提供することです。
A common misconception is that all RFCs are the work of the IETF. In fact, there are four sources of RFCs: the IETF, the IAB, the IRTF, and Independent streams. It is likely that there will soon be a fifth source, which will be for documents on the RFC series itself. Only documents coming directly from the IETF through Working Groups, or sponsored by ADs, can have IETF consensus and be described as IETF specifications or standards.
一般的な誤解は、すべてのRFCがIETFの仕事であるということです。実際、RFCには4つのソースがあります。IETF、IAB、IRTF、および独立ストリームです。すぐに5番目のソースが存在する可能性があります。これは、RFCシリーズ自体のドキュメント用です。ワーキンググループを通じてIETFから直接来るドキュメントのみ、またはADSがスポンサーになっているドキュメントは、IETFコンセンサスを持ち、IETFの仕様または標準として説明できます。
Once an RFC is published, it is never revised. If the specification it describes changes, the standard will be re-published in another RFC that "obsoletes" the first. If a technical or editorial error is found in an RFC, an errata may be filed for review. If accepted, the errata will be linked to the RFC and may be held for the next document update.
RFCが公開されると、修正されることはありません。仕様が変更を記述した場合、標準は別のRFCで最初に「廃止」するRFCで再発行されます。RFCで技術的または編集上のエラーが見つかった場合、レビューのためにErrataが提出される場合があります。受け入れられた場合、ERRATAはRFCにリンクされ、次のドキュメントアップデートのために保持される場合があります。
At the time of this writing, the model for the RFC Editor and the RPC is being revised under an IAB Program (https://datatracker.ietf.org/group/rfcefdp/about/). In this revision, there is a position hired by the IETF LLC known as the RFC Series Editor, who is advised by a couple of groups. As a newcomer, and potential author, the details shouldn't matter much to you right now.
この執筆時点で、RFCエディターとRPCのモデルはIABプログラム（https://datatracker.ietf.org/group/rfcefdp/about/）の下で改訂されています。この改訂では、RFCシリーズエディターとして知られるIETF LLCによって雇われたポジションがあり、いくつかのグループからアドバイスされています。新人であり、潜在的な著者として、詳細は今あなたにはそれほど重要ではないはずです。
The RPC is contracted by the IETF LLC.
RPCはIETF LLCによって契約されています。
There are a few people who are paid to support the IETF. The IETF Secretariat provides day-to-day logistical support, which mainly means coordinating face-to-face meetings and running the IETF presence on the web, including the IETF web site (https://www.ietf.org), mailing lists, the repository for Internet-Drafts, and so on. The Secretariat also provides administrative assistance to the IESG and others.
IETFをサポートするために支払われる人は数人います。IETF事務局は、日々のロジスティックサポートを提供します。これは、主にIETF Webサイト（https://www.ietf.org）、メーリングリストを含む、対面会議の調整とWebでのIETFの存在を実行することを意味します。、インターネットドラフトのリポジトリなど。事務局はまた、IESGなどに管理支援を提供します。
The Secretariat is contracted by the IETF LLC.
事務局はIETF LLCによって契約されています。
The IETF Trust (https://trustee.ietf.org) was set up to hold and license the intellectual property of the IETF, such as trademarks (the IETF logo, etc.) and copyrights. The trust is a stable, legally-identifiable entity. Most participants never interact with the IETF Trust, beyond seeing it mentioned in RFC boilerplate. This is a good sign, and indicates that they are quietly doing their job.
IETF Trust（https://trustee.ietf.org）は、商標（IETFロゴなど）や著作権など、IETFの知的財産を保持およびライセンスするために設定されました。信託は、安定した法的識別可能なエンティティです。ほとんどの参加者は、RFCボイラープレートで言及されていることを見る以外に、IETFトラストと相互作用することはありません。これは良い兆候であり、彼らが静かに仕事をしていることを示しています。
The IETF does most of its communication, and all of its official work, via email.
IETFは、電子メールを介して、そのコミュニケーションのほとんどと公式作業のすべてを行います。
Anyone who plans to participate in the IETF should join the IETF announcement mailing list (https://www.ietf.org/mailman/listinfo/ ietf-announce). This is where all of the meeting information, RFC announcements, and IESG Protocol Actions and Last Calls are posted. This list is strongly moderated, and only the Secretariat and a small number of IETF leaders can approve messages sent to the announcement list, although those messages can come from a variety of people.
IETFに参加する予定の人は誰でも、IETFアナウンスメーリングリスト（https://www.ietf.org/mailman/listinfo/ ietf-announce）に参加する必要があります。これは、すべての会議情報、RFCアナウンス、およびIESGプロトコルアクションと最後の呼び出しが投稿される場所です。このリストは強く緩和されており、事務局と少数のIETFリーダーのみがアナウンスリストに送信されたメッセージを承認できますが、これらのメッセージはさまざまな人々から来ることができます。
There is also a general discussion list (https://www.ietf.org/mailman/listinfo/ietf) that is unmoderated. This means that everyone can express their opinions about issues affecting the Internet. As an open discussion forum, it sometimes spins out of control and it helps to be quick on the _DELETE MESSAGE_ button while also being slow to take offense. The mailing list does have a charter (https://www.rfc-editor.org/info/bcp45), however, which points out that it is not a place for companies or individuals to solicit or advertise. As of this writing, the charter is being revised. It is lightly moderated by two people appointed by the IETF Chair; they used to be called the Sargent At Arms (SAA), and you might see that term sometimes. There is also a process for banning persistent offenders from the list, but fortunately this is extremely rare.
一般的なディスカッションリスト（https://www.ietf.org/mailman/listinfo/ietf）もあります。これは、誰もがインターネットに影響を与える問題について自分の意見を表明できることを意味します。オープンディスカッションフォーラムとして、それは時々制御不能になり、_Delete Message_ボタンを迅速に攻撃するのに迅速にするのに役立ちます。メーリングリストには憲章（https://www.rfc-editor.org/info/bcp45）がありますが、これは企業や個人が勧誘または宣伝する場所ではないことを指摘しています。この執筆時点で、憲章は改訂されています。IETF椅子によって任命された2人によって軽く緩和されています。彼らはかつてSargent at Arms（SAA）と呼ばれていましたが、あなたは時々その用語を見るかもしれません。永続的な犯罪者をリストから禁止するプロセスもありますが、幸いなことにこれは非常にまれです。
There are also subset lists. The i-d-announce (https://www.ietf.org/mailman/listinfo/i-d-announce) list only posts when a new Internet-Draft is submitted. It is moderated. The last-call (https://www.ietf.org/mailman/listinfo/last-call) list is not moderated, and is for discussion of IETF Last Calls (the stage when the IETF community is given one last chance to comment on a draft before it is published as an RFC).
サブセットリストもあります。i-d-Announce（https://www.ietf.org/mailman/listinfo/i-d-announce）は、新しいインターネットドラフトが送信された場合にのみ投稿をリストします。モデレートされています。最後のコール（https://www.ietf.org/mailman/listinfo/last-call）リストはモデレートされておらず、IETFの最後の呼び出し（IETFコミュニティがコメントする最後の機会が与えられた段階の段階の議論のためですRFCとして公開される前のドラフトで）。
Every Working Group has its own mailing list.
すべてのワーキンググループには独自のメーリングリストがあります。
Every IETF mailing list is archived. (Unfortunately, the archives for some lists from many years ago, when the IETF did not have its own servers, have been lost.)
すべてのIETFメーリングリストがアーカイブされています。（残念ながら、IETFが独自のサーバーを持っていなかった何年も前の一部のリストのアーカイブは失われています。）
Even though the IETF mailing lists "represent" the IETF participants at large, it is important to note that attending an IETF meeting does not mean you'll be automatically added to any list; you'll have to "opt in" directly.
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 not like these. The meetings, held three times a year, are week-long gatherings with the primary goals of helping Working Groups get their tasks done, and promoting a fair amount of mixing among the WGs and the Areas. IETF meetings are of little interest to sales and marketing folks, but of high interest to engineers and developers.
コンピューター業界には、会議、セミナー、博覧会、その他のあらゆる種類の会議があふれています。IETFの対面会議は、これらのようなものではありません。年に3回開催される会議は、ワーキンググループがタスクを完了するのを支援し、WGSとエリア間のかなりの量の混合を促進するという主要な目標を備えた1週間の集まりです。IETFの会議は、販売やマーケティングの人々にとってほとんど関心がありませんが、エンジニアと開発者にとって大きな関心です。
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 for many participants. The IETF believes that having a drink together (often beer in the hotel lobby, but drink whatever you want) is highly conducive to collaboration.
多くの人々にとって、IETF会議は、標準的なコンピューター業界の会議と比較すると、新鮮な空気の息吹です。博覧会ホール、チュートリアルはほとんどなく、有名な業界の専門家はありません。代わりに、多くの作業があり、多くの参加者にとって社交のためのかなりの時間があります。IETFは、一緒に飲み物を飲むこと（多くの場合、ホテルのロビーでビールを飲みますが、好きなものは何でも飲む）はコラボレーションを非常に助長すると考えています。
On the other hand, IETFers can sometimes be surprisingly direct, sometimes verging on rude. To build a climate in which people of many different backgrounds are treated with dignity, decency, and respect, the IETF has an anti-harassment policy (https://www.ietf.org/blog/ietf-anti-harassment-policy), a code of conduct (https://www.rfc-editor.org/info/bcp54), and an Ombudsteam (https://www.ietf.org/contact/ombudsteam) that you can reach out to.
一方、IETFERSは驚くほど直接的である場合があり、時には失礼なこともあります。多くの異なる背景を持つ人々が尊厳、品位、尊敬をもって扱われる気候を構築するために、IETFには反ハラスメントポリシーがあります（https://www.ietf.org/blog/ietf-anti-harassment-policy）、行動規範（https://www.rfc-editor.org/info/bcp54）、およびOmbudsteam（https://www.ietf.org/contact/ombudsteam）に手を差し伸べることができます。
The general flow of an IETF meeting is that it begins with an IETF Hackathon (https://www.ietf.org/how/runningcode/) on Saturday and Sunday, tutorials and an informal gathering on Sunday, and WG and BoF meetings Monday through Friday. WG meetings last for between one and 2.5 hours each, and some WGs meet more than once, depending on how much work they anticipate doing. The WG chairs set the agenda for their meeting time(s).
IETF会議の一般的な流れは、土曜日と日曜日のIETFハッカソン（https://www.ietf.org/how/runningcode/）から始まることです。金曜日まで。WGミーティングはそれぞれ1〜2.5時間続き、一部のWGは、予想している作業に応じて複数回会合します。WGチェアは、会議時間のアジェンダを設定します。
There is a plenary session during the week, sometimes two. Either the first part, or a separate Technical Plenary, will have one or more technical presentations on topics of interest to many Working Groups. This is organized by the IAB. The Administrative Plenary is organized by the IETF Chair, and will have greetings from the meeting sponsor, reports on meeting attendance and IETF finances, and progress reports from most groups mentioned in the "Hierarchy" section above. This ends with an "open mic" session, with the various groups on stage. This is a good time to share administrative concerns; praise is welcome, but more often concerns and gripes are raised.
週には全体のセッションがあり、時には2つのセッションがあります。最初の部分、または別の技術的な全体のいずれかで、多くのワーキンググループにとって関心のあるトピックに関する1つ以上の技術的なプレゼンテーションがあります。これはIABによって編成されています。管理上の全体は、IETF議長によって組織されており、会議スポンサーからの挨拶、会議の出席とIETFの財政に関する報告、および上記の「階層」セクションで言及されているほとんどのグループからの進捗報告があります。これは、さまざまなグループがステージ上にある「オープンマイク」セッションで終了します。これは、管理上の懸念を共有する良い時期です。賞賛は大歓迎ですが、より多くの場合、懸念や不満が提起されます。
There have been more than 110 IETF meetings so far. The list of future meetings is available online (https://www.ietf.org/how/meetings/upcoming/), and they are also announced on the _ietf-announce_ mailing list mentioned above.
これまでに110以上のIETF会議がありました。将来の会議のリストは、オンラインで（https://www.ietf.org/how/meetings/upcoming/）で入手できます。また、上記の_ietf-announce_メーリングリストでも発表されます。
Note that COVID-19 disrupted the in-person meetings. After several virtual or online meetings, the IETF tried its first hybrid meeting, in Vienna, in March 2022.
Covid-19が対面会議を混乱させたことに注意してください。いくつかの仮想またはオンライン会議の後、IETFは2022年3月にウィーンで最初のハイブリッド会議を試みました。
To attend an IETF meeting, either online or in person, you have to register and pay a registration fee. If you cannot afford the online registration fee, you can apply for a fee waiver during the registration process. The meeting site (if the meeting is not purely online) is generally announced at several 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 (https://www.ietf.org), that same day. Upcoming meeting locations are also mentioned at the plenary, and the host for the next meeting often gives a welcome.
オンラインまたは直接的にIETF会議に出席するには、登録料を登録して支払う必要があります。オンライン登録料を購入できない場合は、登録プロセス中に料金免除を申請できます。会議サイト（会議が純粋にオンラインではない場合）は、一般的に会議の数ヶ月前に発表されます - 可能であれば早めに。発表は_ietf-announce_メーリングリストにメールで送信され、情報はIETF Webサイト（https://www.ietf.org）に掲載されています。今後の会議の場所も本会議で言及されており、次の会議のホストはしばしば歓迎します。
You can register online at the IETF website, or in person throughout the week. There are different fee schedules for early-bird, latecomers, single-day, and so on. The general registration fee covers all of the week's meetings, the Sunday evening _Welcome Reception_, and afternoon beverage and snack breaks.
IETF Webサイトでオンラインで登録するか、1週間を通して直接登録できます。早期鳥、後半、一日などにはさまざまな料金スケジュールがあります。一般的な登録料は、週のすべての会議、日曜日の夕方_welcomeレセプション_、午後の飲み物とスナックの休憩をカバーしています。
The IETF and related organizations are committed to transparency and protecting the privacy of individuals. For information about the personal data that is collected, and how it is managed, please see the privacy statement (https://www.ietf.org/privacy-statement/).
IETFおよび関連組織は、個人のプライバシーを透明性と保護することに取り組んでいます。収集された個人データとその管理方法については、プライバシーステートメント（https://www.ietf.org/privacy-statement/）を参照してください。
You might also consider subscribing to the meeting-specific email list, which is presented as an option when you register to participate in the meeting either in-person or remotely. Discussions on the meetings list can be high volume and fairly wide-ranging about meeting-specific issues, but it is also a channel for sharing information that many find useful to understand what is going on during the meeting itself. Topics often include information about local mass transit, interesting sites to see, desire to buy or sell a social event ticket, and so on. Local experts, people who live in the area, often respond to questions and can be very helpful.
会議固有のメールリストに登録することも検討する場合があります。これは、会議に登録するときに登録するときにオプションとして提示されます。会議リストでの議論は、大量の大量であり、会議固有の問題についてかなり幅広い場合がありますが、多くの人が会議自体で何が起こっているのかを理解するのに役立つ情報を共有するためのチャネルでもあります。トピックには、地元の大量輸送に関する情報、見るべき興味深いサイト、ソーシャルイベントチケットを売買するという欲求などに関する情報が含まれます。地域に住んでいる地元の専門家は、しばしば質問に答え、非常に役立つ可能性があります。
Sunday is an excellent day to join the meeting, unless you already came on Saturday for the hackathon. Sunday is the day for the newcomer's tutorial, as well the Quick Connections session where newcomers get to meet with experienced IETF participants. After these sessions there is the welcome reception, a popular event where you can get a small bite to eat and socialize with other attendees.
あなたがすでにハッカソンのために土曜日に来ない限り、日曜日は会議に参加するのに最適な日です。日曜日は、新人のチュートリアルの日であり、新人が経験豊富なIETF参加者と会うことができるクイックコネクションセッションです。これらのセッションの後、ウェルカムレセプションがあります。これは、他の参加者と少し食事をしたり、交流したりできる人気のあるイベントです。
During registration, you will be asked to confirm that you agree to follow the _Note Well_. You can also read it, anytime, online (https://www.ietf.org/about/note-well/). This points out the rules for IETF intellectual property rights (IPR), anti-harassment, and other important guiding policies for the IETF. These slides will also be shown before every WG session; as it gets later in the week, the slide transitions tend to get faster and faster.
登録中、_note well_に従うことに同意することを確認するように求められます。いつでもオンラインで読むこともできます（https://www.ietf.org/about/note-well/）。これは、IETF知的財産権（IPR）、ハラスメント、およびIETFのその他の重要な指針に関する規則を指摘しています。これらのスライドは、すべてのWGセッションの前にも表示されます。週の後半になると、スライドの遷移はより速く速くなる傾向があります。
If you need to leave messages for other attendees, you can do so at the cork boards that are usually near the IETF registration desk. These cork boards will also have last-minute meeting changes and room changes. The agenda is available online, and changes can happen up to the last minute, such as cancelling a WG meeting.
他の参加者にメッセージを残す必要がある場合は、通常IETF登録デスクの近くにあるコルクボードでそうすることができます。これらのコルクボードには、最後の会議の変更と部屋の変更もあります。アジェンダはオンラインで利用可能であり、WG会議のキャンセルなど、変更が最後まで行われる可能性があります。
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," you should clarify if they mean the IETF registration desk, or the hotel registration desk: This has been a common cause of missed connections.
また、登録デスクに紛失したアイテムを提出することもできます。会議の終わりに、紛失したものから残されたものはすべてホテルに引き渡されるか、事務局のオフィスに持ち帰られます。ちなみに、IETF登録デスクは、多くの場合、人々に会うために手配するのに便利な場所です。誰かが「登録時に私に会ってください」と言ったら、IETF登録デスク、またはホテル登録デスクを意味するかどうかを明確にする必要があります。これは、接続を見逃したことの一般的な原因です。
IETF WG meetings are scheduled from Monday morning through Friday afternoon. Associated non-WG meetings often take place on the preceding or following weekends, and unofficial "side meetings" can also be scheduled during the week. It is best to plan to be present the whole week, to benefit from cross-fertilization between WGs and from hallway discussions (both offline as well as in online environments such as the _gather.town_ website). As noted below, the agenda is fluid, and there have been 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 WGミーティングは、月曜日の朝から金曜日の午後まで予定されています。関連する非WGミーティングは、前の週末に行われることが多いことが多く、非公式の「サイドミーティング」も週にスケジュールすることができます。WGS間の相互受精と廊下の議論（オフラインと_gather.town_ウェブサイトなどのオンライン環境の両方）の恩恵を受けるために、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. Almost every attendee has a laptop, and it is common to see many of them in the terminal room or in the lobbies and hallways working during meeting sessions. The IETF sets up a high-speed network throughout the hotel for the duration of the meeting, and there's no charge to use the "IETF wifi." This usually covers 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は、会議の期間中、ホテル全体に高速ネットワークを設定し、「IETF WiFi」を使用する料金はありません。これは通常、会議の会場の多くの場所（レストラン、コーヒーショップなど）をカバーするため、会議に参加していないときに電子メールに追いつくことは、IETFERSのかなり一般的なタスクです。
Note that many people use their laptops actively during meeting sessions for practical purposes such as consulting drafts. Power strips in all meeting rooms and hotel rooms will provide only the sockets permitted by local regulations, so ensure in advance that you have an appropriate travel adapter.
多くの人々は、ドラフトのコンサルティングなどの実用的な目的のために、会議セッション中にラップトップを積極的に使用していることに注意してください。すべての会議室とホテルの部屋のパワーストリップは、地元の規制で許可されているソケットのみを提供するため、適切な旅行アダプターがあることを事前に確認してください。
Newcomers should attend the Newcomer's Tutorial on Sunday, which is especially designed for them. The tutorial is organized and conducted by the IETF Education, Mentoring, and Outreach Directorate (_EMODIR_) team and is intended to provide useful introductory information. The session covers the structure of the IETF, how to get the most out of the meeting, and many other essential and enlightening topics for new IETFers. The IETF has a YouTube channel (https://www.youtube.com/user/ietf) which has the previous tutorials. This has recently been broken down into four 15-minute segments (https://www.youtube.com/watch?v=MW1cDLmr91c&list=PLC86T-6ZTP5imxIwnF0mYxWVp0sbqDR0J&pp=iAQB) which might be easier to view.
新人は日曜日に新人のチュートリアルに参加する必要があります。これは特に彼らのために設計されています。このチュートリアルは、IETF教育、メンタリング、およびアウトリーチ局（_Emodir_）チームによって編成および実施されており、有用な入門情報を提供することを目的としています。このセッションでは、IETFの構造、会議を最大限に活用する方法、および新しいIETFERのための他の多くの本質的で啓発的なトピックをカバーしています。IETFには、以前のチュートリアルがあるYouTubeチャンネル（https://www.youtube.com/user/ietf）があります。これは最近、4つの15分のセグメント（https://www.youtube.com/watch?v=mw1cdlmr91c&list=plc86t-6ztp5imxiwnf0myxwvp0sbqdr0j&pp=iaqb）に分割されました。
_Quick Connections_ is a session limited to newcomers and experienced IETF participants. It is a great chance to meet people, and establish contacts that can be useful during the rest of the week. Registration is required as space is limited. It is held right before the welcome reception.
_Quick Connections_は、新人と経験豊富なIETF参加者に限定されたセッションです。人々に会い、週の残りの期間に役立つ連絡先を確立する絶好のチャンスです。スペースが限られているため、登録が必要です。歓迎レセプションの直前に開催されます。
At meetings people generally dress informally, and newcomers could feel out of place if they show up Monday morning in suits. The general rule is "dress for casual comfort." Note that the hotel air conditioning might mean bringing a sweater or other covering as well.
会議では、一般的に非公式に服を着て、新人は月曜日の朝にスーツを着て現れた場合、新しい仲間が場違いに感じることができます。一般的なルールは「カジュアルな快適さのためのドレス」です。ホテルのエアコンは、セーターやその他のカバーも持ってくることを意味するかもしれないことに注意してください。
The heart of an IETF meeting is the WG meetings themselves. Different WGs chairs have very different styles, so it is impossible to generalize how a WG meeting will feel. All WGs have agendas, however, and most will follow the following approach.
IETF会議の中心は、WGミーティング自体です。さまざまなWGS椅子には非常に異なるスタイルがあるため、WGミーティングがどのように感じるかを一般化することは不可能です。ただし、すべてのWGにはアジェンダがあり、ほとんどは次のアプローチに従います。
At the beginning of the meeting, the chair will pass around the _blue sheets_, which are paper forms on which everyone writes their name and their affiliation. These are archived and used for planning capacity needs for the next time the WG meets. In very rare cases, they have been used to indicate exactly who showed up. When you are handed the sheet, sign your name and pass it along in the same direction. If you arrive after the start, at the end of the meeting you can go up front and sign it then. For virtual attendance using the _MeetEcho_ video conference system, attendance is handled by accessing the application.
会議の開始時に、椅子は_blue Sheets_を通過します。これらはアーカイブされ、WGが次に会うときの容量のニーズを計画するために使用されます。まれに、彼らは誰が現れたかを正確に示すために使用されてきました。シートに手渡されたら、名前に署名し、同じ方向に渡します。開始後に到着した場合、会議の終わりに、前に出て署名することができます。_Meetecho_ビデオ会議システムを使用した仮想出席者の場合、出席はアプリケーションにアクセスすることで処理されます。
After the blue sheets, there are calls for volunteers to take minutes. More than one person can do so, and they are often done on a Web page using a collaborative editing app. Taking minutes can be a good way to ensure you follow the discussions without distraction! The link to the web page will be part of the WG entry that is part of the online meeting agenda. There is also a chance to make any last-minute updates to the agenda. This is known as "agenda bashing." Finally, there will be a review of the Note Well. The order in which these things happen can vary, but they are all done before the meeting really "starts."
青いシートの後、ボランティアに数分かかるように呼びかけます。複数の人がそうすることができ、それらは多くの場合、共同編集アプリを使用してWebページで行われます。数分かかることは、気を散らすことなく議論に従うことを保証する良い方法です！Webページへのリンクは、オンライン会議アジェンダの一部であるWGエントリの一部になります。また、アジェンダの土壇場の更新を行うチャンスもあります。これは「アジェンダバッシング」として知られています。最後に、メモのレビューがよくあります。これらのことが起こる順序は異なる場合がありますが、会議が本当に「始まる」前にすべてが行われます。
To speak during a meeting, go to the microphone(s) located near the middle of the room. For controversial topics, there will be a line at the mic, but do not hesitate to be the first person at the line if you have a question or a contribution to the discussion. The WG chair or presenter will indicate when you can speak. Although it would be easier to just raise your hand from where you are sitting, the mics perform a very useful task: they let the people listening remotely and in the room hear your question or comment. When you first speak, say your name and affiliation for identification purposes. If you miss this, folks will often say "name!" to remind you. Don't be embarrassed if this happens, it's not uncommon.
会議中に話すには、部屋の真ん中近くにあるマイクに行きます。物議を醸すトピックについては、マイクにラインがありますが、質問や議論への貢献がある場合は、ラインで最初の人になることをheしないでください。WGの椅子またはプレゼンターは、あなたが話すことができるときを示します。あなたが座っている場所から手を挙げる方が簡単ですが、マイクは非常に便利なタスクを実行します。あなたが最初に話すとき、識別目的であなたの名前と所属を言ってください。あなたがこれを見逃した場合、人々はしばしば「名前！」と言うでしょうあなたを思い出させます。これが起こっても恥ずかしくないでください、それは珍しいことではありません。
Some attendees will have a little colored dot on their name tag, and a few people have more than one. These dots identify people who have volunteered to do extra work, such as being a WG chair, an IESG member, and so on. The colors have the meanings shown here.
一部の参加者は、名前タグに少し色の付いたドットを持っていますが、一部の人は複数の人を持っています。これらの点は、WG椅子、IESGメンバーなど、追加の仕事をすることに志願した人々を特定します。色にはここに示されている意味があります。
+========+=============================+
| Color | Meaning |
+========+=============================+
| Blue | Working Group/BOF Chair |
+--------+-----------------------------+
| Green | Meeting Host/Sponsor |
+--------+-----------------------------+
| Red | IAB member |
+--------+-----------------------------+
| Yellow | IESG member |
+--------+-----------------------------+
| Pink | IRSG member |
+--------+-----------------------------+
| Orange | Nominating Committee member |
+--------+-----------------------------+
| Black | IETF LLC Board |
+--------+-----------------------------+
Table 3
Members of the press wear orange-tinted badges with the word "press" on them.
プレスのメンバーは、「プレス」という言葉が付いたオレンジ色のバッジを着用します。
As newcomer, don't 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! Note, however, that IETF meetings are usually intense times for Area Directors. Talking to an AD during an IETF meeting will often result in them asking you to send email after the meeting ends. Also, when you start a hallway conversation with an Area Director (or even a WG chair, for that matter), it is often good to give them about 30 seconds of context for the discussion.
新人として、これらの点を身に着けている人々と会話をすることを恐れないでください。IABとIESGのメンバー、ワーキンググループとBOFの椅子が誰とも話したくなかった場合、そもそもドットを着ていません！ただし、IETFミーティングは通常、エリアディレクターにとって激しい時期であることに注意してください。IETF会議中に広告と話すと、会議が終了した後、メールを送信するように依頼することがよくあります。また、エリアディレクター（またはWGチェア）との廊下での会話を開始すると、議論のために約30秒のコンテキストを提供することがよくあります。
Near the registration area there are usually ribbons and markers so that people can label their specific interests, history, and so on. Many people use them to make (inside) jokes, which are sometimes amusing.
登録エリアの近くには、通常、リボンとマーカーがあり、人々が特定の興味、歴史などにラベルを付けることができます。多くの人がそれらを使用して（内部）ジョークを作成しますが、これは時々面白いです。
The IETF wifi is provided by volunteers who run the Network Operations Center (NOC). The terminal room is where you can get wired connectivity and limited access to a printer. The people and companies that donate their equipment, services, and time are to be heartily congratulated and thanked.
IETF WiFiは、ネットワークオペレーションセンター（NOC）を運営するボランティアによって提供されます。ターミナルルームは、有線接続とプリンターへのアクセスを制限できる場所です。機器、サービス、および時間を寄付する人々と企業は、心から祝福され、感謝することです。
You must be wearing your badge in order to get into the terminal room. The terminal room provides power strips, Ethernet ports, and wifi (for the people who don't need Ethernet but want power). What it doesn't provide are terminals; the name is historical. The help desk in the terminal room is also a good place to ask questions about network failures, although they might point you off to different networking staff.
ターミナルルームに入るためには、バッジを着用している必要があります。ターミナルルームには、パワーストリップ、イーサネットポート、およびWiFiが提供されます（イーサネットを必要としないが電力が必要な人向け）。それが提供していないのは端子です。名前は歴史的です。ターミナルルームのヘルプデスクは、ネットワークの障害について質問するのに適した場所でもありますが、さまざまなネットワーキングスタッフに向けられている可能性があります。
Although it is true that some people eat very well at the IETF, they find the food on their own since lunches and dinners are not included in the registration fee. In addition to socializing, dinner meetings can be a good way to get additional work done.
一部の人々はIETFで非常によく食事をしているのは事実ですが、昼食や夕食は登録料に含まれていないため、自分で食べ物を見つけます。社交に加えて、ディナーミーティングは追加の作業を完了する良い方法です。
If sponsorship for it is secured, the welcome reception provides drinks and appetizers but is not meant to be a full replacement for dinner. Sometimes a continental breakfast can be included with the hotel registration. There IETF meeting also includes a morning coffee and snack break, and a similar one in the afternoon.
それのスポンサーシップが確保されている場合、ウェルカムレセプションは飲み物と前菜を提供しますが、夕食の完全な代替品になることを意図したものではありません。時には、ホテルの登録に大陸の朝食を含めることができます。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, and the meeting-specific email list is also a useful source.
食事のためにホテルから出たい場合、地元のホストは通常、会議サイトの簡単な手の届く範囲内で食事をする場所のリストを提供します。また、会議固有のメールリストも有用なソースです。
Another of the most important things organized and managed by the host is the IETF social event. The social event is sometimes high-tech-related event, or it might be in an art museum or a reception hall. Note, however, that not all IETF meetings have social events.
ホストによって組織され管理されている最も重要なことのもう1つは、IETFソーシャルイベントです。ソーシャルイベントは、ハイテク関連のイベントである場合があります。または、美術館やレセプションホールにある場合があります。ただし、すべてのIETF会議には社交イベントがあるわけではないことに注意してください。
Newcomers to the IETF are encouraged to attend the social event. Wear your name tag and leave your laptop behind. The social event is designed to give people a chance to meet on a social, rather than technical, level. The social ticket costs extra, is reserved at registration time, and has limited capacity. People looking to buy or sell a social ticket often post to the email list, or on the corkboards mentioned above.
IETFの新参者は、社交イベントに参加することをお勧めします。名前タグを着用して、ラップトップを残してください。ソーシャルイベントは、技術的なレベルではなく、社会的なレベルで会う機会を人々に与えるように設計されています。ソーシャルチケットの費用は追加料金で、登録時に予約されており、容量が限られています。ソーシャルチケットの売買を検討している人は、しばしばメーリングリスト、または上記のコルクボードに投稿します。
The agenda for the IETF meetings is a very fluid thing. It is available on the web and through the IETF mobile apps starting a few weeks before the meeting. 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 last version posted before the meeting. The Secretariat will post agenda changes on the bulletin board near the IETF registration desk (reminder, 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 conflicts. The IETF is too dynamic for agendas to be tied down weeks in advance.
IETF会議のアジェンダは非常に流動的なものです。会議の数週間前に、WebおよびIETFモバイルアプリを通じて利用できます。もちろん、IETFの「最終」は、世界の他の場所と同じことを意味するものではありません。最終アジェンダは、会議の前に投稿された最後のバージョンです。事務局は、IETF登録デスクの近くの掲示板に議題の変更を投稿します（リマインダー、ホテル登録デスクではありません！）。これらの遅い変更は気まぐれではありません。セッションの椅子とスピーカーが予期せぬ紛争に気付くと、「ちょうど間に合う」ものになります。IETFは、アジェンダが数週間前に縛られるにはダイナミックすぎます。
A map showing the hotel layout and, specifically the meeting rooms, is also available with 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.
ホテルのレイアウト、特に会議室を示す地図もアジェンダで入手できます。アジェンダが変更されると、部屋の割り当てが変更される可能性があります。一部のワーキンググループは、会議中に複数回会合し、各セッションの同じ部屋でワーキンググループが会うようにすべての試みがなされています。
If, after you finish reading this document, certain aspects of the IETF still mystify you, you'll want to drop in on the on-site training offered by the Education, Mentoring, and Outreach (EMODIR) team. In addition to the Newcomer training mentioned above, EMODIR also hosts informal newcomer gatherings during the coffee break sessions. Details vary for each meeting, so watch the agenda and the newcomer-specific email list.
このドキュメントを読み終えた後、IETFの特定の側面がまだあなたを神秘化する場合、教育、メンタリング、アウトリーチ（Emodir）チームが提供するオンサイトトレーニングに立ち寄りたいと思うでしょう。上記の新人のトレーニングに加えて、Emodirはコーヒーブレイクセッション中に非公式の新人の集まりも開催しています。詳細は会議ごとに異なるため、アジェンダと新人固有のメーリングリストを視聴してください。
EMODIR also organized in-depth technical tutorials, useful for newcomers and experienced IETFers alike. These are also announced as part of the program, and are usually on Sundays.
Emodirは、新規参入者や経験豊富なIETFERにも役立つ詳細な技術チュートリアルを開催しました。これらはプログラムの一部としても発表されており、通常は日曜日に行われます。
Finally, EMODIR runs the _IETF Guides_ program, pairing newcomers with an experienced IETF person to help you become acclimated and effective quickly. This has not worked out very well during the all-virtual meetings, frankly. If you are interested, watch for the announcement. Ideally you have a call with your mentor before the meeting, a meeting during the beginning of the meeting, and check in some time during the meeting, so they can help you with any questions you might have.
最後に、Emodirは_ietf Guides_プログラムを実行し、新人と経験豊富なIETFの人をペアにして、順応して効果的になるようにします。これは、率直に言って、すべての自由な会議中にあまりうまくいっていません。興味がある場合は、発表に注意してください。理想的には、会議の前にメンターとの電話があり、会議の開始中の会議、会議中のしばらくの間チェックしてください。
Details on EMODIR membership and charter are available online (https://datatracker.ietf.org/group/emodir/about/).
Emodirメンバーシップとチャーターの詳細は、オンラインで入手できます（https://datatracker.ietf.org/group/emodir/about/）。
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, and you should not feel obligated to come to an IETF meeting just to get a feel for the IETF. If, however, you decide to come, this document and RFC 4144: How to Gain Prominence and Influence in Standards Organizations (https://www.rfc-editor.org/info/rfc4144) provides some pointers on how to make your meeting a success. The following guidelines (based on stereotypes of people in various industries) might help you decide whether you actually want to come and, if so, what might be the best use of your time at your first meeting.
IETFは、さまざまな人とは異なります。IETFの会議に一度も参加したことがないIETFに非常に活発な人がたくさんいます。IETFの感触を得るためだけにIETF会議に来る義務を感じるべきではありません。ただし、あなたが来ることにした場合、このドキュメントとRFC 4144：標準組織で目立つと影響力を得る方法（https://www.rfc-editor.org/info/rfc4144）は、会議の作成方法に関するいくつかのポインターを提供します成功。次のガイドライン（さまざまな業界の人々のステレオタイプに基づいて）は、実際に来たいかどうか、もしそうなら、最初の会議での時間の最良の使用方法を決定するのに役立つかもしれません。
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 IT 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 email 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会議に行くべきではないということではありません。ITマネージャーとして、IETFで開発中のテクノロジーを担当する特定の人々を送ることを検討することをお勧めします。これらの人々は、関連するワーキンググループリストの現在のインターネットドラフトと電子メールトラフィックを読んでいるため、彼らの存在があなたの会社やワーキンググループにとって価値があるかどうかの感覚を得るでしょう。
Knowledge of how networks are run is indispensable for the development of new (versions of) protocols. Especially if you work for the type of network that is always using the very latest hardware and software, and you are already following the relevant Working Groups, you could certainly find participating in the IETF valuable. Note that the IETF has several WGs focused on operations, that might be particularly relevant.
ネットワークの実行方法に関する知識は、新しい（バージョンの）プロトコルの開発に不可欠です。特に、常に最新のハードウェアとソフトウェアを使用しているネットワークのタイプで作業し、すでに関連するワーキンググループをフォローしている場合は、IETFへの参加が価値があることを確実に見つけることができます。IETFには、運用に焦点を当てたいくつかのWGSがあり、特に関連する可能性があることに注意してください。
Finally, note that the IETF is increasingly focused on encrypting network traffic, and that this has implications for operators. A fair amount of IETF work also covers many other parts of operations of ISPs and large enterprises, and the input of operators from each of these types of organizations 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 network researchers may have been true in the distant past, but the jobs of today's attendees are typically 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, or run a service available on the Internet, 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 or pre-sales, are 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, especially 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, but note that IETF participation is as an _individual_ not a formal representative of their employer.
これは、誰もが会議に行くことができるように、IETFの会議中に企業が店舗を閉鎖する必要があるということではありません。マーケティングの人々、技術的なマーケティングの人々や事前販売でさえ、会社の技術者の何人かが会議に出ている限り、IETFから離れるのに安全です。同様に、特にすべてがインターネットドラフトを読んでワーキンググループのメーリングリストをフォローしているわけではない場合、技術部門のすべての人が行く必要はありません。多くの企業には、完全で有用な旅行レポートを行う能力のために選ばれた指定された会議の出席者が数人しかいません。さらに、多くの企業には、内部調整努力と標準戦略があります。企業がビジネスの一部またはすべてについてインターネットに依存している場合、戦略はおそらくIETFをカバーする必要がありますが、IETFの参加は雇用主の正式な代表ではなく_Individual_であることに注意してください。
IETF meetings are often excellent places for all kinds of researchers to find out what is happening in the way of soon-to-be-deployed protocols, and networking architecture and infrastructure. 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活動に興味がある可能性が高い。
In addition, the IRTF and ACM co-host the annual Applied Networking Research Workshop (https://irtf.org/anrw/), normally scheduled during the July IETF meeting Registration is required, IETF attendees can attend for free. The IRTF also hosts the Applied Networking Research Prize (https://irtf.org/anrp/), which includes a cash prize, a travel grant to attend, and a chance to present. See the web page for requirements.
さらに、IRTFとACMは、通常7月のIETF会議の登録中にスケジュールされる年次Applied Networking Research Workshop（https://irtf.org/anrw/）を共同ホストすることが必要です。IETF参加者は無料で参加できます。IRTFは、賞金、出席への旅行助成金、提示の機会を含む、Applied Networking Research Prize（https://irtf.org/anrp/）も開催しています。要件については、Webページを参照してください。
If you're a member of the press and are considering attending IETF, please see the special section below.
あなたがマスコミのメンバーであり、IETFへの参加を検討している場合は、以下の特別なセクションをご覧ください。
IETF proceedings are compiled in the weeks and months after each meeting and are available online (https://www.ietf.org/how/meetings/ proceedings/). Be sure to look through a copy at least once; the proceedings are filled with information about IETF that you're not likely to find anywhere else. For example, you'll copies of every session's slides, links to the video recording, copies of the blue sheets (attendance), and so on.
IETFの議事録は、各会議の数週間と数ヶ月で編集され、オンラインで入手できます（https://www.ietf.org/how/meetings/ proceedings/）。少なくとも一度はコピーを調べてください。議事録には、他の場所では見つけることができないIETFに関する情報が記載されています。たとえば、すべてのセッションのスライドのコピー、ビデオ録画へのリンク、青いシートのコピー（出席）などがコピーされます。
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. If someone is presenting an update to their draft, feel free to step up to the mic and ask a clarifying question. Before you do, however, make sure to have read the draft first. Working Group meetings are not a time for general tutorials.
一般的に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 side meeting (historically but often inaccurately called a "bar BOF") is an unofficial get-together between WG meetings or in the late evening, during which a lot of work gets done. These side meetings spring up in many different places around an IETF meeting, such as restaurants, coffee shops, unused hall spaces and the like. You can read more about Birds-of-a Feather sessions (BOFs) in section 5.
サイドミーティング（歴史的には、しばしば「バーBOF」と呼ばれることが多い）は、WGミーティングまたは夜遅くに行われた非公式の集まりであり、その間に多くの作業が行われます。これらのサイドミーティングは、レストラン、コーヒーショップ、未使用のホールスペースなど、IETFミーティングの周りのさまざまな場所に登場します。セクション5で、Birds-of-of-of-o-feather Sessions（BOFS）の詳細を読むことができます。
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.
IETF会議、特に全体会議は、ベンダーが商品を販売しようとする場所ではありません。人々は確かに自分の会社とその製品についての質問に答えることができますが、IETFは展示会ではないことに留意してください。
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 they feel is not appropriate.
登録デスクの近くには常に「材料配布テーブル」があります。このデスクは、参加者が適切な情報を利用できるようにするために使用されます（たとえば、ワーキンググループセッションで議論された何かのコピー、オンラインIETF関連情報の説明）。机の上に材料を置く前に、事務局に確認してください。事務局は、彼らが適切ではないと思う資料を削除する権利を持っています。
People have joined IETF meetings remotely for a long time, but the tools for this have changed a lot over the years. Currently the IETF uses a browser- based tool known as _MeetEcho_. There is also a text-based discussion forum called _Jabber_. This is integrated into MeetEcho, but there are also stand-alone clients available. Planned for 2022, the _Zulip_ text will be available. Each WG will have its own stream.
人々は長い間IETF会議にリモートで参加してきましたが、このツールは長年にわたって大きく変わりました。現在、IETFは_meetecho_として知られるブラウザベースのツールを使用しています。_jabber_というテキストベースのディスカッションフォーラムもあります。これはMeeteChoに統合されていますが、スタンドアロンのクライアントも利用できます。2022年に計画されている_ZULIP_テキストが利用可能になります。各WGには独自のストリームがあります。
The links for the Meetecho rooms, the Jabber chats, and meeting materials, can always be found in the right-hand side of the agenda, under the different icons. All sessions are recorded and can be viewed after the meeting, along with chat logs and meeting minutes. This can be useful to refresh your memory while writing a trip report, or for catching up on what happened when you wanted to be in two WG meetings at once. It happens; scheduling conflicts are unavoidable.
MeeteChoの部屋、Jabberチャット、会議の資料のリンクは、常に異なるアイコンの下で、アジェンダの右側にある常に見つけることができます。すべてのセッションは記録されており、会議後にチャットログと会議の議事録とともに表示できます。これは、旅行レポートを書いているときにメモリをリフレッシュしたり、2回のWGミーティングになりたいときに何が起こったかに追いつくのに役立ちます。それは起こります。スケジューリングの競合は避けられません。
The vast majority of the IETF's work is done in its many Working Groups; at the time of this writing, there are well over one hundred different WGs. BCP 25 (https://www.rfc-editor.org/info/bcp25), "IETF Working Group Guidelines and Procedures," is an excellent resource for anyone participating in WG discussions. The full list of working groups can be found on the datatracker (https://datatracker.ietf.org/ wg/).
IETFの作業の大部分は、多くのワーキンググループで行われています。この執筆時点では、100を超えるWGがあります。BCP 25（https://www.rfc-editor.org/info/bcp25）、「IETFワーキンググループのガイドラインと手順」は、WGディスカッションに参加している人にとって優れたリソースです。ワーキンググループの完全なリストは、DataTracker（https://datatracker.ietf.org/ wg/）にあります。
A WG is really just a mailing list with a bit of supervision and facilitation. 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 non-subscribers have to have their postings approved first.
WGは、実際には監督と円滑化のあるメーリングリストです。メーリングリストを購読することにより、WGに「参加」します。すべてのメーリングリストは誰にでも開かれています。誰でもWGメーリングリストに投稿できますが、サブスクライダー以外は最初に投稿を承認する必要があります。
More importantly, each WG has a charter that the WG is supposed to follow. The charter states the scope of discussion for the Working Group and its goals. The WG's mailing list and face-to-face meetings are supposed to focus on only 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. Each WG has its own page on the datatracker.
さらに重要なことに、各WGにはWGが従うことになっているチャーターがあります。チャーターは、ワーキンググループの議論の範囲とその目標を述べています。WGのメーリングリストと対面会議は、チャーターにあるもののみに焦点を当てることになっており、他の「興味深い」トピックをさまようことはありません。もちろん、WGの範囲の外を少し見ることは時々有用ですが、議論の大部分はチャーターにリストされているトピックにあるべきです。実際、一部のWGチャーターは、特にチャーターの起草中に魅力的でありながら曖昧なトピックが育てられた場合、WGが何をしないかを実際に指定しています。すべてのWGチャーターのリストは、さまざまなワーキンググループが何をしているのかを知りたい人のために興味深い読書をします。各WGには、DataTrackerに独自のページがあります。
Each Working Group has one or two (or, rarely, three) chairs. The role of the WG chairs is described in both BCP 11 (https://www.rfc-editor.org/info/bcp11) and BCP 25 (https://www.rfc-editor.org/info/ bcp25).
各ワーキンググループには、1つまたは2つの（またはめったに3つの）椅子があります。WGチェアの役割は、BCP 11（https://www.rfc-editor.org/info/bcp11）とBCP 25（https://www.rfc-editor.org/info/ bcp25）の両方で説明されています。
Chairs have responsibility for the technical and non-technical quality of WG output. The chair must keep the WG productive, and making progress on its drafts. Sometimes there is a WG Secretary to help. Document editors, too, are usually incentivized to make progress on their drafts. 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. 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ドキュメントが公開に近づく場合、椅子は、非WG参加者またはIESGとの相互作用も管理することがあります。秘書、対人的、技術的な要求の組み合わせを考えると、想像できるように、一部のワーキンググループの椅子は、他の仕事よりもはるかに優れています。
One fact that confuses many newcomers 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. This is sometimes phrased as "at the last WG meeting, we decided XXX; if you disagree please speak up by the end of the week" and you'll therefore often hear the phrase "to be confirmed on the 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ミーティングで、XXXを決定しました。同意しない場合は、週の終わりまでに声を上げてください」と表現することがあります。したがって、「リストで確認される」というフレーズをよく聞くでしょう。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, and that those in the minority have had a chance to explain why. Generally consensus is determined by _humming_: if you agree with a proposal, you hum when prompted by the chair. Most hum questions come in three parts: you hum to the first part if you agree with the proposal, to the second part if you disagree, or to the third part if you do not have enough information to make up your mind. Newcomers find it quite peculiar, but it works. It is up to the chair to decide when the Working Group has reached rough consensus; sometimes the responsible AD will also do so.
多くの人々を混乱させるワーキンググループの別の側面は、正式な投票がないという事実です。争われたトピックに関する一般的なルールは、ワーキンググループが「大まかなコンセンサス」に到達しなければならないということです。つまり、気にする人の非常に大多数が同意しなければならないこと、そして少数派の人々がその理由を説明する機会があったことを意味します。一般的にコンセンサスは_humming_によって決定されます。提案に同意する場合は、椅子に促されたときにハミングします。ほとんどのハムの質問には3つの部分があります。最初の部分には、提案に同意する場合は、同意しない場合は第2の部分に、または心を補うのに十分な情報がない場合は3番目の部分にハムします。新人はそれが非常に独特であると感じていますが、それは機能します。ワーキンググループが大まかなコンセンサスに達した時期を決定するのは椅子次第です。責任ある広告もそうすることがあります。
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 invites all interested individuals to participate, and when it's impossible to count the participants?) A common definition and practice of humming can be found in RFC 7282: On Consensus and Humming in the IETF (https://www.rfc-editor.org/info/rfc7282).
正式な投票の欠如は、いくつかの提案にいくつかの非常に長い遅れを引き起こしましたが、rim慢な議論の後に大まかなコンセンサスを目撃したほとんどのIETF参加者は、遅延がしばしばより良いプロトコルにつながると感じています。（そして、あなたがそれについて考えるなら、どのようにしてすべての関心のある個人を参加させるグループに「投票」することができますか？：IETF（https://www.rfc-editor.org/info/rfc7282）のコンセンサスとハミングについて。
A related problem is that some people think that their topic should be discussed in the WG even when the WG chair believes it is outside the scope of the charter. If the WG agrees, they can work to _re-charter_ so that the topic is in scope. The individual can also bring their concerns to the responsible AD.
関連する問題は、WG議長がチャーターの範囲外であると信じている場合でも、WGで自分のトピックについて議論する必要があると考える人もいることです。WGが同意した場合、トピックが範囲になるように_RE-Charter_に作業できます。個人は責任ある広告に懸念をもたらすこともできます。
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.
WGが憲章を満たしたとき、それは運用を停止することになっています。（ほとんどのWGメーリングリストは、WGが閉じられた後も続きますが、ワーキンググループと同じトピックについて議論しています。）IETFでは、チャーターを満たしたためにWGが閉じることは成功のマークです。これは、他の標準団体で経験を持つ新参者が理解するのに苦労しているというIETFの側面の1つです。
There is an official distinction between WG I-Ds and individual I-Ds. A WG will have to review an individual draft before deciding if it should be adopted by the WG. The WG chairs appoint who will be the authors or editors of the I-Ds; often those who wrote the initial draft continue work on behalf of the WG. Procedures for Internet-Drafts are covered in much more detail later in this document.
WG I-DSと個々のI-DSの間には公式の区別があります。WGは、WGが採用する必要があるかどうかを決定する前に、個々のドラフトを確認する必要があります。WGチェアは、I-DSの著者または編集者になる人を任命します。多くの場合、最初のドラフトを書いた人は、WGに代わって作業を続けています。インターネットドラフトの手順については、このドキュメントの後半でさらに詳しく説明します。
For Working Group documents, the document editor serves at the pleasure of the WG Chair. There is often more than one editor for Working Group documents, particularly for complex documents. The document editor is responsible for ensuring that the contents of the document accurately reflects Working Group decisions; when a document editor does not follow the WG consensus, the WG Chairs will either be more forceful about getting changes that match the consensus or replace the document editor with someone more responsive to the WG. As a Working Group document is progressing, participants suggest changes on the Working Group's mail list (or online if the document is maintained somewhere accessible); the editors are expected to follow the discussion and make changes when there is consensus.
ワーキンググループのドキュメントについては、ドキュメントエディターがWGチェアの喜びでサービスを提供します。多くの場合、ワーキンググループドキュメント、特に複雑なドキュメント用に複数のエディターがあります。ドキュメントエディターは、ドキュメントの内容がワーキンググループの決定を正確に反映していることを確認する責任があります。ドキュメントエディターがWGのコンセンサスに従わない場合、WGチェアはコンセンサスに一致する変更を取得することについてより力強くなり、ドキュメントエディターをWGに応答する人に交換します。ワーキンググループのドキュメントが進行しているため、参加者はワーキンググループのメールリストの変更を提案します（または、ドキュメントがどこかにアクセス可能な場所に維持されている場合はオンライン）。編集者は、コンセンサスがあるときに議論に従い、変更を加えることが期待されています。
Sometimes a Working Group will consider several alternatives before selecting a particular Internet-Draft as a Working Group document. A Working Group will often take ideas from several of the alternatives to create a single Working Group document; in such a case, the chair determines who will be listed as authors on the title page and who will be acknowledged as contributors in the body of the document.
ワーキンググループは、特定のインターネットドラフトをワーキンググループドキュメントとして選択する前に、いくつかの代替案を検討する場合があります。ワーキンググループは、多くの場合、単一のワーキンググループドキュメントを作成するためのいくつかの選択肢からアイデアを取ります。そのような場合、議長は、誰がタイトルページの著者としてリストされ、誰が文書の本文の貢献者として認められるかを決定します。
When a WG document is ready to progress beyond the WG, the WG Chairs will assign a "shepherd" to take over the final process. The role of the document shepherd is described in RFC 4858: Document Shepherding from Working Group Last Call to Publication (https://www.rfc-editor.org/info/rfc4858). The chair, who knows the history of the draft within the WG, often does the shepherd write-up.
WGドキュメントがWGを超えて進行する準備ができた場合、WG椅子は「羊飼い」を割り当てて最終プロセスを引き継ぎます。ドキュメントシェパードの役割は、RFC 4858で説明されています：ワーキンググループからのドキュメントシェパーディングは、出版物への最後の呼び出し（https://www.rfc-editor.org/info/rfc4858）です。WG内のドラフトの歴史を知っている椅子は、しばしば羊飼いの記事を書いています。
The most important thing that *everyone* 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 and often the document is presented as a set of slides saying "here's what changed since last meeting." Even if you do not plan to say anything in the meeting, you should read, or at least skim, the group's documents before attending so you can understand what is being said.
対面会議に来る前に *誰もがすべきである最も重要なことは、インターネットドラフトとRFCを事前に読むことです。WGミーティングは明示的に教育用ではありません。グループのドキュメントを開発するためのものであり、多くの場合、文書は「前回の会議以来変化したものがここにある」というスライドのセットとして提示されます。会議で何も言うつもりがない場合でも、出席する前にグループの文書を読んだり、少なくともスキムを読んだりする必要があります。
It's up to the WG chairs 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 on the datatracker, and links to will be found on every full meeting agenda. Unfortunately, some WG chairs are lax (if not totally negligent) about turning them in.
通常、数週間前に会議のアジェンダを設定するのはWGチェア次第です。会議で何かが議論されたい場合は、必ず椅子にそれを知らせてください。すべてのWGミーティングのアジェンダは、DataTrackerで事前に入手でき、すべての完全な会議アジェンダにリンクが見つかります。残念ながら、一部のWG椅子は、それらを回転させることについて（完全に怠慢ではないにしても）緩いです。
The Secretariat only makes the full IETF meeting schedule 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 I-Ds and RFCs for those groups. Work in the IETF is often reciprocal, contribute positively to others work and you are more likely to receive comments and feedback on your work.
事務局は、数週間前に完全なIETF会議のスケジュールしか行いません。スケジュールは、初日の1週間前にわずかに変更されることがよくあります。WGミーティングのみに来る場合は、特にワーキンググループの会議がスケジュールを変更する場合は、そのような通知でフライトを予約するのに苦労するかもしれません。フライトやホテルをスケジュールできるように、現在のアジェンダを追跡してください。しかし、それが結局のところ、あなたはおそらく1回のWGミーティングのために来るべきではないでしょう。これらのグループのI-DSとRFCを読んだと仮定して、いくつかのWGSであなたの知識が価値がある可能性があります。IETFでの作業は、多くの場合、相互的なものであり、他の仕事に積極的に貢献し、あなたの仕事に関するコメントやフィードバックを受け取る可能性が高くなります。
If you are on the agenda at a face-to-face meeting, you should prepare a few slides and mail them to the chair before the meeting. Don't come with a tutorial; people are supposed to read the I-Ds in advance. Projectors for laptop-based presentations are available in all the meeting rooms.
対面の会議で議題にいる場合は、いくつかのスライドを準備して、会議の前に椅子に郵送する必要があります。チュートリアルが付属しないでください。人々は事前にI-DSを読むことになっています。ラップトップベースのプレゼンテーション用のプロジェクターは、すべての会議室で入手できます。
And here's a tip for your slides: 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.
そして、ここにスライドのヒントがあります：IETFの外での一般的な慣行であるにもかかわらず、あなたの会社のロゴをすべてに載せないでください。IETFは、この種の企業広告について眉をひそめています（プレナリープレゼンテーションでの会議スポンサーを除く）。ほとんどのプレゼンターは、オープニングスライドにロゴを置いていません。IETFは、会社のブースター主義ではなく、技術的なコンテンツに関するものです。スライドは、しばしば読みやすくするために白黒であり、色が実際に明確になる場合にのみ使用されます。繰り返しますが、コンテンツはスライドの最も重要な部分であり、提示方法ではありません。
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. Jabber is a free, streaming XML technology mainly used for instant messaging. You can find pointers to Jabber clients for many platforms at (https://xmpp.org/xmpp-software/clients). 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テクノロジーです。（https://xmpp.org/xmpp-software/clients）の多くのプラットフォームのJabberクライアントへのポインターを見つけることができます。Jabberチャットルームには、ワーキンググループの名前が続き、「@jabber.ietf.org」が続きます。実際、これらの部屋は、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 areas 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の椅子が「リストに取り込んでください」と言うために「リストに取り込んでみましょう」と言うことがよくあります。
Every WG has a dedicated page on the datatracker site, and the "About" tab will point to mailing list subscription and archives.
すべてのWGには、DataTrackerサイトに専用のページがあり、「ARTAR」タブはメーリングリストのサブスクリプションとアーカイブを指します。
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 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 the group needs to take attendance. Decisions tentatively made during an interim WG meeting must still be confirmed on the mailing list. Interim meetings are subject to the IETF Note Well. Most interim meetings are virtual these days and have the same reporting requirements as face-to-face virtual meetings.
ワーキンググループは、IETF間の暫定会議を開催することがあります。暫定会議はIETFミーティングの代わりではありませんが、グループは、3週間後にカンクン（またはどこか平凡な）で会うことができず、会うことができない場所で会議をスキップすることを決定することはできません。暫定会議は、少なくとも1か月前に発表する必要があります。場所とタイミングは、すべての参加者に公正なアクセスを可能にする必要があります。定期的なIETFミーティングのように、誰かがメモを取る必要があり、グループは出席する必要があります。暫定的なWG会議中に暫定的に行われた決定は、メーリングリストでまだ確認する必要があります。暫定会議は、IETFノートの対象となります。ほとんどの暫定会議は最近では仮想であり、対面の仮想会議と同じレポート要件を持っています。
The IESG has rules for advance notice on time and place of interim Working Group meetings, as well as reporting the results of the meetings. The purpose of these rules is to make interim meetings accessible to as many Working Group members as possible and to maintain the transparency of the Working Group process.
IESGには、暫定ワーキンググループ会議の時間と場所の事前通知の規則があり、会議の結果を報告しています。これらのルールの目的は、できるだけ多くのワーキンググループメンバーが暫定会議にアクセスできるようにし、ワーキンググループプロセスの透明性を維持することです。
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 without an initial meeting.
ワーキンググループを形成するには、チャーターと椅子になることができる人が必要です。これらのものを手に入れるには、人々がチャーターに集中するのを手伝って、プロジェクトが価値があることをエリアディレクターに納得させることができるようにする必要があります。これには対面の会議が役立ちます。実際、最初の会議なしに開始するWGSはほとんどありません。
A _Birds of a Feather_ (BOF) meeting has to be approved by the Area Director in the relevant area, in consultation with the IESG and the IAB, before it can be scheduled. If you think you need a new WG, approach an AD with your proposal and see what they think. You will have to write some informative background text, and they will work with you to get it scheduled. Of course, you can also gather interested people and work on a draft charter in the meantime.
feather_（BOF）会議の_バードは、IESGおよびIABと相談して、スケジュールする前に、関連するエリアのエリアディレクターによって承認されなければなりません。新しい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, that there are enough people willing to do the work needed in order to create standards, and that any standards would get adoption. Often a self-selected group of key people will get together after the BOF to refine the draft charter.
BOFミーティングは、WGミーティングとは非常に異なるトーンを持っています。BOFの目的は、優れたマイルストーンを備えた優れた憲章を作成し、基準を作成するために必要な作業を喜んで行う意思がある人がいること、および標準が採用されることを確認することです。多くの場合、主要な人々の自己選択グループがBOFの後に集まり、ドラフトチャーターを改良します。
Generally, there are only two BOF meetings allowed for the same topic. Sometimes it is obvious after one meeting that a WG should be created, and sometimes it is obvious a WG would not be successful.
一般的に、同じトピックに許可されているBOF会議は2回しかありません。会議の後、WGを作成する必要があることが明らかな場合があり、WGが成功しないことが明らかです。
If you have a draft already written, you can submit it to the relevant "dispatch" WG. Each area has one of these. Their job is to review submitted documents, and come to a decision about the next steps: possibilities include create a new WG, send to an existing WG, hold a BOF, and so on.
すでに書かれたドラフトがある場合は、関連する「ディスパッチ」WGにそれを送信できます。各エリアにはこれらのいずれかがあります。彼らの仕事は、提出されたドキュメントを確認し、次のステップに関する決定に至ることです。可能性には、新しいWGの作成、既存のWGへの送信、BOFの保持などが含まれます。
An advantage of using the dispatch WG compared to a BOF is that the discussion is more limited and focused. On the other hand, a draft might tend to limit what the other folks in the BOF want to do in the charter. 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と比較してディスパッチWGを使用する利点は、議論がより制限され、集中していることです。一方、ドラフトは、BOFの他の人々がチャーターでやりたいことを制限する傾向があります。特定のドキュメントのサポートを得るためではなく、最終的なワーキンググループのサポートを得るために、ほとんどのBOFが保持されていることを忘れないでください。
This section discusses Internet-Drafts and RFCs in the IETF stream, that is, it describes how documents are produced and advanced within the IETF. For a brief note on other RFC streams, see above.
このセクションでは、IETFストリーム内のインターネットドラフトとRFCについて説明します。つまり、IETF内でドキュメントがどのように生成および高度になっているかについて説明します。他のRFCストリームに関する簡単なメモについては、上記を参照してください。
If you're a new IETF participant and are looking for a particular RFC or Internet-Draft, you can use the IETF _Datatracker_. This website, https://datatracker.ietf.org/ (https://datatracker.ietf.org/), has a text search capability (including content, keywords, author, and so on), and the search results point to the document status, page count, and other useful information. A little-known hint is that _dt.ietf.org_ is an abbreviation (a DNS CNAME entry) for the longer "datatracker.ietf.org" hostname.
新しいIETF参加者であり、特定のRFCまたはインターネットドラフトを探している場合は、IETF _DATATRACKER_を使用できます。このウェブサイトhttps://datatracker.ietf.org/（https://datatracker.ietf.org/）には、テキスト検索機能（コンテンツ、キーワード、著者などを含む）があり、検索結果はドキュメントのステータス、ページ数、およびその他の有用な情報。あまり知られていないヒントは、_dt.ietf.org_は、長い「datatracker.ietf.org」ホスト名の略語（dns cnameエントリ）です。
Most RFCs in the IETF stream follow the same process, and the sections below discuss the process and some of the issues. Note that there are other ways to get an RFC published (https://www.ietf.org/about/participate/get-started/#officialdocuments), particularly if it is not intended for the standards track. For the sake of brevity, we will not mention those here. After all, this document is about "the Way of the IETF" and the main Way is "developing standards."
IETFストリームのほとんどのRFCは同じプロセスに従います。以下のセクションでは、プロセスといくつかの問題について説明します。特に標準トラック用に意図されていない場合は、RFCを公開する他の方法（https://www.ietf.org/about/particate/get-started/#officialdocuments）を取得する他の方法があることに注意してください。簡潔にするために、ここでそれらについては言及しません。結局のところ、このドキュメントは「IETFの道」に関するものであり、主な方法は「基準の開発」です。
If you are interested in learning more about how to author an Internet-Draft yourself, the I-D Authors website (https://authors.ietf.org) has a lot of information and resources, including pointers to online tools that can help.
インターネットドラフトを自分で作成する方法について詳しく知りたい場合は、I-D Authors Webサイト（https://authors.ietf.org）には、役立つオンラインツールへのポインターを含む多くの情報とリソースがあります。
The very first step is to have a draft document. Internet-Drafts should follow a specific format, and are required to have particular sections. This will be discussed more below.
最初のステップは、ドラフトドキュメントを持つことです。インターネットドラフトは特定の形式に従う必要があり、特定のセクションが必要です。これについては以下で詳しく説明します。
RFCs are generally written by a Working Group. If an appropriate WG doesn't seem to exist, then the BOF or Dispatch process mentioned above can be used to learn which one is appropriate, or start the process to create one.
RFCは通常、ワーキンググループによって書かれています。適切なWGが存在しないように見える場合、上記のBOFまたはディスパッチプロセスを使用して、どちらが適切かを学習するか、プロセスを作成するプロセスを開始できます。
Once a potential WG exists, the document must be _adopted_. To do this, you submit your individual draft to the datatracker. It should start with draft-YOURNAME-brief-subject where _YOURNAME_ is your name. Send a note to the WG mailing list, with an introduction to the draft, and why you think it is appropriate. After any discussion, the WG Chair will issue a _call for adoption_. If consensus is to adopt the draft, you will be asked to submit it with the name draft-ietf-WGNAME-brief-subject; you can probably guess what _WGNAME_ should be.
潜在的なWGが存在すると、ドキュメントは_Adopted_にする必要があります。これを行うには、個々のドラフトをDatAtrackerに送信します。_yourname_があなたの名前であるドラフトYourname-Brief-Subjectから始める必要があります。ドラフトの紹介とともに、WGメーリングリストにメモを送信します。議論の後、WG椅子は採用のために_callを発行します。コンセンサスがドラフトを採用することである場合、ドラフト-iTf-wgname-brief-subjectという名前でそれを提出するように求められます。おそらく_wgname_がどうあるべきか推測できます。
Note that as part of submitting an Internet Draft according to the rules, you grant the IETF certain rights. These rights give the IETF the ability to reliably build upon the work you have brought forward. These rights are held by the IETF Trust. BCP 78 (https://www.rfc-editor.org/rfc/rfc5378.html) explains the certain rights the IETF Trust takes on for submissions.
ルールに従ってインターネットドラフトを提出する一環として、IETFの特定の権利に付与することに注意してください。これらの権利は、IETFに、あなたが提起した仕事に確実に構築する能力を与えます。これらの権利は、IETFトラストによって保持されています。BCP 78（https://www.rfc-editor.org/rfc/rfc5378.html）は、IETFトラストが提出のために行う特定の権利について説明します。
Once a WG adopt a document, the WG as a whole has the right of "change control." This means the WG, can make any changes to the document, the one you initially wrote, that they want. If you are not comfortable with this, then the IETF is not the place for your document. There are a few more details on this below.
WGがドキュメントを採用すると、WGは全体として「Change Control」の権利を持ちます。これは、WGがドキュメントに変更を加えることができることを意味します。これに満足していない場合、IETFはドキュメントの場所ではありません。これには以下にさらにいくつかの詳細があります。
The WG now "works on" the document. This will be a combination of mailing list discussion, perhaps agenda time at a meeting, and publishing updated drafts. (Every draft ends with _-NN_ where the digits indicate the draft number.)
WGは今、ドキュメントを「取り組んでいます」。これは、メーリングリストのディスカッション、おそらく会議での議題の時間、および更新されたドラフトの公開の組み合わせです。（すべてのドラフトは_-nn_で終了し、数字はドラフト番号を示します。）
At some point, the document will seem finished. The WG Chair will put the document in _WG Last Call_ (WGLC) which gives the members of the WG a chance for last-minute changes. It can be frustrating to get a bunch of changes after you think you're done, but don't take it personally. Like many things, people are often deadline-driven.
ある時点で、ドキュメントは終了したように見えます。WG椅子は、ドキュメントを_WG Last Call_（WGLC）に配置し、WGのメンバーに土壇場の変更の機会を与えます。あなたが終わったと思った後、多くの変更を得るのはイライラするかもしれませんが、個人的にそれを取ってはいけません。多くのことと同様に、人々はしばしば締め切り駆動型です。
After WGLC, the responsible AD (the one who oversees the WG) does a review. They will probably have comments that must be resolved by you and the WG; it's quite likely you'll have to publish a new draft. Then the IESG and the overall IETF reviews the draft, as mentioned above. The purpose of IETF Last Call is to get community-wide discussion on documents before the IESG considers them. Note the word _discussion_ here. It is generally considered bad form to send IETF Last Call comments on documents that you have not read, or to send comments but not be prepared to discuss your views. The IETF Last Call is not a vote. Having said that, IETF Last Call comments that come from people who have just read the document for the first time can expose issues that IETF and WG regulars may have completely missed, which is why the discussion is open to everyone.
WGLCの後、責任ある広告（WGを監督する人）がレビューを行います。彼らはおそらくあなたとWGが解決しなければならないコメントを持っているでしょう。新しいドラフトを公開する必要がある可能性が非常に高いです。次に、上記のように、IESGとIETF全体がドラフトをレビューします。IETFの最後の呼び出しの目的は、IESGがそれらを検討する前に、ドキュメントに関するコミュニティ全体の議論を取得することです。_discussion_という言葉に注意してください。一般的に、読んでいないドキュメントにIETFの最後のコールコメントを送信したり、コメントを送信したり、意見を議論する準備をしていないことは、悪い形式と考えられています。IETFの最後の呼び出しは投票ではありません。そうは言っても、初めてドキュメントを読んだばかりの人からのIETFの最後のコールコメントは、IETFとWGの常連が完全に見逃した問題を公開することができます。
Finally, the draft is given to the RFC Production Center (RPC), and prepared for publication. There might be other changes required, including reviews by IANA for registrations and the like. The most common item you'll hear about this is _AUTH48_ state, which means the document is in the final stages of copy-editing by the RPC and you. The publication process can take weeks, but be patient, and you'll eventually see an email announcement saying that your brand-new RFC has been published. Congratulations!
最後に、ドラフトはRFC生産センター（RPC）に与えられ、出版の準備ができています。登録などのIANAによるレビューなど、他の変更が必要になる場合があります。これについて聞く最も一般的な項目は_auth48_状態です。つまり、ドキュメントはRPCおよびyouによるコピー編集の最終段階にあります。出版プロセスには数週間かかる場合がありますが、忍耐強くなり、最終的には最新のRFCが公開されているというメールの発表が表示されます。おめでとう！
A much more complete explanation of these steps is contained in BCP 9 (https://www.rfc-editor.org/info/bcp9). This set of documents 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.
これらの手順のより完全な説明は、BCP 9（https://www.rfc-editor.org/info/bcp9）に含まれています。このドキュメントのセットは、ベテランのIETF参加者であっても、非常に誤解されるトピックについて非常に詳細に説明します。さまざまなタイプのRFCが異なるプロセスを経て、ランキングが異なります。
There are two major issues that often come up while preparing I-Ds: copyright and patents.
I-DSの準備中にしばしば出てくる2つの主要な問題があります：著作権と特許。
We discussed copyright above, but expand on it here. When the IETF adopts an Internet-Draft, it is required that the _boilerplate_, the common text that appears in every draft, has a notice that says the IETF, _and the document authors_ own the copyright. This means that while the IETF can do what it wants with the document, within limitations so can you. You cannot, for example, claim this is an IETF standard, nor use the IETF trademarks.
上記の著作権について説明しましたが、ここで展開します。IETFがインターネットドラフトを採用する場合、すべてのドラフトに表示される一般的なテキストである_boilerPlate_は、IETFと書かれた通知を持つことが必要です。これは、IETFがドキュメントで望むことを行うことができる一方で、制限内でできることを意味します。たとえば、これはIETF標準であると主張したり、IETF商標を使用したりすることはできません。
Incidentally, the change control on Internet standards doesn't end when the RFC is published. Things can be changed later for a number of reasons, such as to solve a newly-discovered problem or address new use-cases. These later changes are also under the control of the IETF, not the editors of the standards document.
ちなみに、RFCが公開されたとき、インターネット標準の変更制御は終了しません。新たに発見された問題を解決したり、新しいユースケースに対処するなど、多くの理由で物事を変更することができます。これらの後の変更は、標準文書の編集者ではなく、IETFの管理下にあります。
The second issue is patents. The goal of the IETF is to have its standards widely used and validated by 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."
2番目の問題は特許です。IETFの目標は、その基準を市場で広く使用および検証することです。標準を使用する製品を作成するには、特許のライセンスを取得する必要がある場合、人々は標準を実装する可能性が低くなります。当然のことながら、一般的なルールは「可能な限り、優れた非特許技術を使用する」ことです。
Of course, this isn't always possible. Sometimes patents appear after a standard has been established and there is little the IETF can do about that. Sometimes there's a patent on something that is so valuable that there isn't a non-patented equivalent, and generally the IETF tries to avoid it.
もちろん、これは常に可能ではありません。標準が確立された後に特許が表示されることがあり、IETFがそれについてできることはほとんどありません。時には、非常に価値のあるものについて特許があるため、非特許と同等のものがなく、一般的にIETFはそれを避けようとします。
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. Ideally, and this is the common case when a patent-holder is active in a document, the patent holder will grant free use of the patent to implement the specification.
特許権者は寛大であり、標準のすべての実装者に特許のロイヤリティフリーライセンスを提供することを約束することがあり、それにより、特許が存在しなかった場合と同じくらい簡単に実装できます。理想的には、これは特許保有者が文書で活動している場合によくあるケースであり、特許権者は仕様を実装するために特許の無料使用を許可します。
The official rules for all intellectual property rights (IPR) in IETF documents, not just patents but also code samples and the like, are covered in BCP 78 (https://www.rfc-editor.org/info/bcp78) and BCP 79 (https://www.rfc-editor.org/info/bcp79).
IETF文書のすべての知的財産権（IPR）の公式規則は、特許だけでなく、コードサンプルなどもBCP 78（https://www.rfc-editor.org/info/bcp78）およびBCPでカバーされています。79（https://www.rfc-editor.org/info/bcp79）。
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 IPR disclosures (https://datatracker.ietf.org/ipr/about/) page. If you still have issues, consult with the WG Chair or the responsible AD. Intellectual property rights aren't mentioned in RFCs because RFCs never change after they are published, while knowledge of IPR can change at any time. Therefore, an IPR list in an RFC could be incomplete and mislead the reader. BCP 79 (https://www.rfc-editor.org/info/bcp79) provides specific text that should be added to RFCs where the author knows of IPR issues.
インターネットドラフトを書いており、書いているテクノロジーに適用される特許を知っている場合は、ドキュメントの特許をリストしないでください。代わりに、IPR開示（https://datatracker.ietf.org/ipr/about/）ページを参照してください。まだ問題がある場合は、WGチェアまたは責任ある広告に相談してください。RFCは公開された後は変わらないため、知的財産権はRFCSでは言及されていませんが、IPRの知識はいつでも変化する可能性があります。したがって、RFCのIPRリストは不完全であり、読者を誤解させる可能性があります。BCP 79（https://www.rfc-editor.org/info/bcp79）は、著者がIPRの問題を知っているRFCSに追加する必要がある特定のテキストを提供します。
Every RFC starts its life as an I-D. Internet-Drafts have the same format as an RFC, and are required to have all the content that should appear in the RFC. This includes a couple of sections detailed below. A draft may also have more information, such as an incremental list of changes from previous versions of the draft, or pointers to online locations for raising issues and suggesting changes.
すべてのRFCはI-Dとしての生活を始めます。インターネットドラフトはRFCと同じ形式であり、RFCに表示されるすべてのコンテンツを持つ必要があります。これには、以下に詳述されているいくつかのセクションが含まれます。ドラフトには、ドラフトの以前のバージョンからの変更の増分リストや、問題を提起し、変更を提案するためのオンライン場所へのポインターなど、より多くの情報がある場合があります。
For the past several years, the official canonical source of RFCs as RFC 7991: The "xml2rfc" Version 3 Vocabulary (https://www.rfc-editor.org/info/rfc7991). Some people enjoy writing in XML, and some don't. An alternative for the second group is to use a specific dialect of markdown, which is then converted to XML as needed (and especially during the publication process). A recent trend is the increasing use of markdown, and hosting I-Ds on GitHub to attract a wider audience of Internet-savvy users. Some information on this can be found at RFC 8874: Working Group GitHub Usage Guidance (https://www.rfc-editor.org/info/rfc8874).
過去数年間、RFC 7991としてのRFCの公式標準源：「XML2RFC」バージョン3の語彙（https://www.rfc-editor.org/info/rfc7991）。XMLで書くことを楽しんでいる人もいれば、そうでない人もいます。2番目のグループの代替案は、マークダウンの特定の方言を使用することです。これは、必要に応じて（特に公開プロセス中）XMLに変換されます。最近の傾向は、Markdownの使用の増加であり、GitHubでI-DSをホストして、インターネットに精通したユーザーのより多くの視聴者を引き付けることです。これに関するいくつかの情報は、RFC 8874：ワーキンググループGitHubの使用ガイダンス（https://www.rfc-editor.org/info/rfc8874）にあります。
The IETF is setting up a new site, https://authors.ietf.org (https://authors.ietf.org), to contain guides and online tools to help both new and experienced authors. As of this writing, it's still a draft but it does contain a great deal of useful content. You should feel free to use the site, and offer feedback.
IETFは、新しいサイトhttps://authors.ietf.org（https://authors.ietf.org）を設定しており、新しい作家と経験豊富な作家の両方を支援するガイドとオンラインツールを含んでいます。この執筆時点では、まだドラフトですが、非常に有用なコンテンツが含まれています。サイトを自由に使用し、フィードバックを提供する必要があります。
Outside of the formatting decision, the most important document you can read is Guidelines to Authors of Internet-Drafts (https://www.ietf.org/how/ids/guidelines). That document explains the naming conventions, formatting requirements, required content, and details of how to submit (also called _post_) your draft.
フォーマットの決定以外では、読むことができる最も重要なドキュメントは、インターネットドラフトの著者（https://www.ietf.org/how/ids/guidelines）のガイドラインです。このドキュメントでは、命名規則、要件の書式設定、必要なコンテンツ、およびドラフトを提出する方法の詳細について説明します。
It is common for Internet-Drafts that revise existing RFCs to have draft names with "bis" in them, meaning "again" or "twice." For example, a draft might be called "draft-ietf-uta-rfc6125bis" meaning that this is intended to be a revision of, and eventual replacement for, RFC6125.
既存のRFCを修正するインターネットドラフトが「BIS」が入ったドラフト名、「再び」または「2回」を意味するドラフト名を持つことが一般的です。たとえば、ドラフトは「ドラフト-ITA-UTA-RFC6125BIS」と呼ばれる場合があります。つまり、これはRFC6125の改訂および最終的な代替を目的としています。
Writing clear specifications can be a bit of an art, particularly for people who don't have English as their native language. 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. Over time, the IETF has realized that defining a few words with specific meanings helps a great deal. BCP 14 (https://www.rfc-editor.org/info/bcp14) defines about a dozen keywords that can be used to clarify what are requirements, as compared to what is purely informative. It defines the meaning of words like _MUST_ and points out that it has to appear in all uppercase to its special meaning.
開発者が相互運用可能な標準の実装を作成する可能性を高める1つの方法は、仕様で義務付けられているものを明確にすることです。時間が経つにつれて、IETFは、特定の意味を持ついくつかの単語を定義することは非常に役立つことに気付きました。BCP 14（https://www.rfc-editor.org/info/bcp14）は、純粋に有益なものと比較して、要件とは何かを明確にするために使用できる12個のキーワードを定義します。_must_のような単語の意味を定義し、すべての大文字で特別な意味に表示されなければならないことを指摘しています。
It is not uncommon for feedback on standards-track I-Ds to question the particular uses of what is called "2119 language." For example, "The document says MAY but doesn't explain why not; should it be a MUST?"
「2119言語」と呼ばれるものの特定の用途に疑問を投げかけることは、標準トラックI-DSに関するフィードバックが珍しいことではありません。たとえば、「ドキュメントはそうでないかもしれないが、なぜ説明しないかもしれない。それは必須であるべきだ」と言っています。」
One aspect of writing IETF standards that trips up many newcomers 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 not strictly needed to implement it.
多くの新規参入者をつかむIETF標準を作成する1つの側面は、_Normative References_を標準で_Normative References_または他のRFCに作成する方法についてのルールです。規範的な参照とは、標準を実装するために従わなければならないドキュメントへの参照です。非規範的な参照（_informative reference _と呼ばれることもあります）は、実装者に役立つが、それを実装するために厳密に必要ではないものです。
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 Internet Standard, all of the RFCs that appear as a normative reference must also be an Internet Standard. This rule gives implementors assurance that everything in an Internet standard is quite stable, even the things referenced outside the standard. This rule, and its exceptions, is described in BCP 97 (https://www.rfc-editor.org/info/bcp97).
IETF標準は、同じ標準レベル以上の他の標準トラックRFC、またはIETFの外側で開発された「オープン標準」を規範的に参照する場合があります。「同じレベル以上」ルールは、標準が提案されたものからインターネット標準に移動する前に、規範的参照として表示されるすべてのRFCもインターネット標準でなければならないことを意味します。このルールは、インターネット標準内のすべてが非常に安定しており、標準の外側で参照されているものでさえ、実装者に保証されます。この規則とその例外は、BCP 97（https://www.rfc-editor.org/info/bcp97）で説明されています。
There is no hard-and-fast rule about what is an "open standard", but generally this means a stable standard that was made by a generally-recognized SDO, and that anyone can get a copy of, although not necessarily for free. 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, ask the WG chair or AD if a particular external standard can be used in an IETF standard.
「オープン標準」とは何かについては厳しいルールはありませんが、一般に、一般的に認識されているSDOによって作成された安定した標準を意味し、必ずしも無料ではありませんが、誰でもコピーを入手できることを意味します。外部標準が変更された場合、標準の日付の指定と同様に、仕様にその標準の特定のインスタンス化を参照する必要があります。一部の外部標準団体は、古い標準を利用できません。これは、将来使用する必要があるIETF標準の問題です。疑わしい場合は、IETF標準で特定の外部標準を使用できるかどうかをWGチェアまたはADに尋ねます。
Every draft is required to have some content. Some of this is boilerplate text about copyright, "2119 keyword," and so on. The document formatting tools will generate this for you automatically if you use the right keyword. In addition, there are special sections that might be required for your draft, and you (and the WG) will have to write them.
すべてのドラフトには、コンテンツが必要です。これのいくつかは、著作権、「2119キーワード」などに関するボイラープレートテキストです。正しいキーワードを使用すると、ドキュメントのフォーマットツールが自動的にこれを生成します。さらに、ドラフトに必要な特別なセクションがあり、あなた（およびWG）がそれらを書く必要があります。
Many IETF standards have extension points, such as unassigned fields in a message header, or for something like email or HTTP, an actual message header. As mentioned above, IANA maintains online registries for these. 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) approves any registration requests, and so on.
多くのIETF標準には、メッセージヘッダー内の未割り当てフィールドや、実際のメッセージヘッダーである電子メールやHTTPなどの拡張ポイントがあります。上記のように、IANAはこれらのオンラインレジストリを維持しています。標準が必要とする大規模で多様なレジストリのため、IANAはパラメーターを登録する方法、登録しないもの、（誰かが）登録リクエストを承認する人などに関する特定の情報を持っている必要があります。
Anyone writing a draft that needs one or more registries, or adds values to existing registries must have an "IANA Considerations" section. Authors should read BCP 26 (https://www.rfc-editor.org/info/bcp26), "Guidelines for Writing an IANA Considerations Section in RFCs," which describes how to properly ask for IANA to make the changes requested in their draft. If there are no considerations, it is a good idea to have the section and explicitly say "This document has no IANA requests."
1つ以上のレジストリを必要とするドラフトを書いている人、または既存のレジストリに値を追加する人は、「IANAの考慮事項」セクションが必要です。著者は、BCP 26（https://www.rfc-editor.org/info/bcp26）を読む必要があります。下書き。考慮事項がない場合は、セクションを作成し、「このドキュメントにはIANAリクエストがない」と明示的に言うことをお勧めします。
Every draft must have a "Security Considerations" section. This describes possible threats or attacks, known vulnerabilities, information that could be exposed, and so on. It should also describe any strategies or mechanisms to mitigate them. When the security directorate (SECDIR) reviews your draft, this section will be one of their major focuses. Don't gloss over the section, or say things like "use TLS to get security" without explaining how the protocol uses TLS and what it provides. See BCP 72 (https://www.rfc-editor.org/info/bcp72), "Guidelines for Writing RFC Text on Security Considerations", for more information on writing good security considerations sections.
すべてのドラフトには、「セキュリティ上の考慮事項」セクションが必要です。これは、可能な脅威または攻撃、既知の脆弱性、さらされる可能性のある情報などを説明しています。また、それらを緩和する戦略やメカニズムを説明する必要があります。セキュリティ局（SECDIR）がドラフトをレビューすると、このセクションは主要な焦点の1つになります。プロトコルがTLSをどのように使用し、それが提供するものを使用するかを説明せずに、セクションを点灯したり、「TLSを使用してセキュリティを取得する」などのことを言ったりしないでください。BCP 72（https://www.rfc-editor.org/info/bcp72）、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」を参照してください。
Also, a draft might have a "Privacy Considerations" section. An Informational RFC, RFC 6973: Privacy Considerations for Internet Protocols (https://www.rfc-editor.org/info/rfc6973), written by the IAB, is intended to raise the general awareness of privacy on the Internet. It also provides advice for when a draft should have an explicit privacy section.
また、ドラフトには「プライバシーに関する考慮事項」セクションがある場合があります。情報RFC、RFC 6973：IABによって書かれたインターネットプロトコル（https://www.rfc-editor.org/info/rfc6973）のプライバシーに関する考慮事項は、インターネット上のプライバシーに関する一般的な意識を高めることを意図しています。また、ドラフトに明示的なプライバシーセクションが必要な時期についてもアドバイスを提供します。
Some drafts benefit from having an "Implementation Status" section, as explained by BCP 205: Improving Awareness of Running Code: The Implementation Status Section (https://www.rfc-editor.org/info/ rfc7942).
一部のドラフトは、BCP 205で説明されているように、「実装ステータス」セクションを持つことから恩恵を受けます：実行コードの認識の向上：実装ステータスセクション（https://www.rfc-editor.org/info/ rfc7942）。
More detail on the required content can be found online (https://authors.ietf.org/en/required-content).
必要なコンテンツの詳細については、オンラインで見つけることができます（https://authors.ietf.org/en/required-content）。
If the IESG approves the draft to become a standards-track RFC, they ask the RPC to publish it as a _Proposed Standard_.
IESGがドラフトを標準トラックRFCにするために承認した場合、RPCに_プロップ型標準_として公開するように依頼します。
Don't be surprised if a particular standard doesn't progress from Proposed Standard to Internet Standard. To become an Internet Standard, an RFC must have multiple interoperable implementations and the unused features in the Proposed Standard must be removed; there are additional requirements listed in BCP 9 (https://www.rfc-editor.org/info/bcp9). Most of the protocols 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 Internet Standard, 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.
特定の標準が提案された標準からインターネット標準まで進歩していなくても驚かないでください。インターネット標準になるには、RFCに複数の相互運用可能な実装が必要であり、提案された標準の未使用の機能を削除する必要があります。BCP 9（https://www.rfc-editor.org/info/bcp9）には追加の要件がリストされています。一般的な使用のプロトコルのほとんどは提案されている標準であり、決して前進しません。これは、誰もそれらをインターネット標準に到達させようとするのに時間がかからないか、標準の規範的な参照の一部がまだ提案されている標準であるか、誰もがより重要なことを見つけた可能性があるためかもしれません。
As mentioned earlier, not all RFCs are standards. In fact, many important RFCs are not on the standards track at all. At the time of writing, there are also categories for Informational, Experimental, Best Current Practice, and Historical for standards that are no longer recommended for use. The role of Informational RFCs can be confusing, and people sometimes refer to them as "standards," when they are not.
前述のように、すべてのRFCが標準であるわけではありません。実際、多くの重要なRFCは標準トラックにまったく載っていません。執筆時点では、情報、実験的、最高の現在の実践、および使用を推奨しなくなった標準の歴史のカテゴリもあります。情報提供のRFCの役割は混乱を招く可能性があり、人々は時々それらを「標準」と呼んでいない場合があります。
Experimental RFCs are for specifications that are interesting, but for which it is unclear if there will be widespread deployment, or if they will scale to work after such deployment. That is, a specification might solve a problem, but there might not be IETF consensus that the problem is worth solving or that the specification is complete enough to address the problem. 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は、興味深い仕様用ですが、展開が広く展開されるかどうか、またはそのような展開後に動作するようにスケーリングするかどうかは不明です。つまり、仕様は問題を解決する可能性がありますが、問題が解決する価値があるか、仕様が問題に対処するのに十分に完了しているというIETFコンセンサスはないかもしれません。また、実験的なRFCは、標準トラック素材のように見えるが、未回答の質問があるように見えるテクノロジーを人々に実験させるためにも使用されます。
The IESG has created guidelines (https://www.ietf.org/standards/process/informational-vs-experimental/) that can help choose between Informational and Experimental classification. This is a short informal read, and if are not sure where your document fits, it is worth reading.
IESGは、情報分類と実験分類を選択するのに役立つガイドライン（https://www.ietf.org/standards/process/informational-vs-experimental/）を作成しました。これは短い非公式の読み物であり、ドキュメントがどこに収まるかわからない場合は、読む価値があります。
Finally, there are two sub-series of RFCs: Best Current Practice (BCP) and Internet Standards (STD). BCP describes the application of various technologies in the Internet, and are also commonly used to document the many parts of the IETF process. The STD sub-series was created to identify RFCs that do in fact specify Internet standards.
最後に、RFCには2つのサブシリーズがあります。ベストカレントプラクティス（BCP）とインターネット標準（STD）です。BCPは、インターネットでのさまざまなテクノロジーの適用について説明しており、IETFプロセスの多くの部分を文書化するためにも一般的に使用されています。STDサブシリーズは、実際にインターネット標準を指定するRFCを特定するために作成されました。
These are an example of the aphorism that everything in computer science can be solved by a layer of indirection. For example, a single BCP can refer to one or more RFCs, and the specific RFCs can change such as when a new version of a protocol is published. Likewise, some STDs are actually sets of more than one RFC, and the "standard" designation applies to the whole set of documents.
これらは、コンピューターサイエンスのすべてが間接の層によって解決できるという格言の例です。たとえば、単一のBCPは1つ以上のRFCを参照でき、特定のRFCは、プロトコルの新しいバージョンが公開されたときなど、変更できます。同様に、一部のSTDは実際には複数の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. Remember the tenet, "rough consensus and running code," so you can help support the standards you want to become more widespread by creating more running code. You can help the development of protocols before they become standards by implementing I-Ds (but not doing wide-spread deployment) to ensure that the authors have done a good job. If you find errors or omissions, offer improvements based on your implementation experience. A great way to get involved in this is by participating in the Hackathons.
*実装：*現在のインターネット標準を使用するプログラムを作成します。インターネットユーザーが利用できない限り、標準はあまり価値がありません。より多くのソフトウェアに表示されるとマイナーになるようになるため、「マイナー」標準も実装します。標準で見つけた問題を適切なワーキンググループに報告して、後の改訂で標準を明確にできるようにします。テネット「ラフコンセンサスと実行中のコード」を覚えておいてください。そのため、より多くの実行中のコードを作成することで、より広く普及したい標準をサポートできます。プロトコルは、I-DSを実装することで標準になる前に（ただし、広範囲にわたる展開を行っていない）、著者が良い仕事をしていることを確認することができます。エラーや省略が見つかった場合は、実装エクスペリエンスに基づいて改善を提供します。これに参加する素晴らしい方法は、ハッカソンに参加することです。
*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 receive kinds of technical (and, sadly, sometimes personal) criticism. Take the technical comments with equanimity and use it to improve your draft in order to produce the best and most interoperable standard, and ignore the personal ones.
*書き込み：*専門分野のインターネットドラフトを編集または共著者。インターネットコミュニティの利益のためにこれを行い、ドキュメントであなたの名前（またはさらに悪いことに、あなたの会社の名前）を取得するためではありません。ドラフト著者は、種類の技術的な（そして悲しいことに、時には個人的な）批判を受けています。技術的なコメントを平等にして、それを使用してドラフトを改善して、最良かつ最も操作可能な基準を生み出し、個人的な基準を無視します。
*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 vendors that you are doing so.
*共有：*独自の基準を避けます。あなたが実装者である場合、IETF標準を強く好みます。IETF標準が独自の基準ほど良くない場合は、IETF標準を改善するために機能します。あなたが購入者である場合、IETFのオープン標準と競合する独自の基準を使用する製品を避け、あなたがそうしていることをベンダーに伝えてください。
*Open Up:* If your company owns a patent that is used in an IETF standard, convince the company to make the patent available at no cost to anyone who is implementing the standard. Patents have previously caused many serious problems for Internet standards because they prevent some companies from being able to freely implement them. 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しみなく提供しています。これらの企業は通常、他の特許保有者ほど貪欲でも近視眼的でもないという事実に対する前向きな宣伝で報われます。
*Support:* The IETF has sponsorship opportunities (https://ietf.org/about/donors/) and an endowment (https://www.ietf.org/endowment/donate-ietf-endowment/) which can also take individual-sized donations. Become a member of ISOC. Urge any company that has benefited from the Internet to contribute, since this has the greatest financial benefit for the group. It will, of course, also benefit the Internet as a whole.
*サポート：* IETFには、スポンサーシップの機会（https://ietf.org/about/donors/）と基本（https://www.ietf.org/endowment/donate-ietf-endowment/）があります。個人サイズの寄付。ISOCのメンバーになります。インターネットの恩恵を受けた企業に貢献を促します。これは、グループにとって最大の経済的利益をもたらすからです。もちろん、それはまた、インターネット全体に利益をもたらすでしょう。
While some IETF participants would like to think otherwise, the IETF does not exist in a standards vacuum. This section discusses two important groups.
一部のIETF参加者はそうでないと考えたいと思っていますが、IETFは標準の真空に存在しません。このセクションでは、2つの重要なグループについて説明します。
There are many other standards organizations whose decisions affect the Internet. Some of them ignored the Internet for a long time and now want to get a piece of the action. In general, the IETF tries to have cordial relationships with other SDOs. This isn't always easy, since they usually have different structures and processes 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, many SDOs make a great effort to interact well with the IETF despite the obvious cultural differences.
その決定がインターネットに影響を与える他の多くの標準組織があります。彼らの何人かは長い間インターネットを無視していたので、今ではアクションの一部を取得したいと考えています。一般に、IETFは他のSDOと心からの関係を築こうとします。通常、IETFとは異なる構造とプロセスを持っているため、これは必ずしも簡単ではありません。IETFは、他の団体の代表者と会うよりも標準を書くことを好むボランティアによってほとんど運営されています。それでも、多くのSDOは、明らかな文化的な違いにもかかわらず、IETFとうまく対話するために多大な努力をしています。
As stated in BCP 39 (https://www.rfc-editor.org/info/bcp39), the IAB Charter: "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 the WG level, with formal relationships and liaison documents in a backup role. The best place to check to see whether the IETF has any formal liaison at all is the list of IETF liaisons (https://www.ietf.org/about/liaisons).
BCP 39（https://www.rfc-editor.org/info/bcp39）で述べたように、IABチャーターは次のように述べています。実際には、IETFは、バックアップの役割で正式な関係とリエゾン文書を使用して、WGレベルで直接行われるリエゾンを好みます。IETFが正式なリエゾンを持っているかどうかを確認するのに最適な場所は、IETF Liaisons（https://www.ietf.org/about/liaisons）のリストです。
At the time of this writing, the IETF has around two dozen liaisons. Some of these liaison tasks fall to the IESG, whereas others fall to the IAB. Full details about the processes for dealing with other SDOs can be found in BCP 102 (https://www.rfc-editor.org/info/bcp102) and BCP 103 (https://www.rfc-editor.org/info/bcp103).
この執筆時点では、IETFには約20個のリエゾンがあります。これらの連絡タスクのいくつかはIESGに落ちますが、他の人はIABに落ちます。他のSDOを扱うためのプロセスの詳細については、BCP 102（https://www.rfc-editor.org/info/bcp102）およびbcp 103（https://www.rfc-editor.org/infoにあります。/BCP103）。
Given that the IETF is one of the best-known bodies that is helping move the Internet forward, it's natural for the media to cover its actions. But it can be hard to cover the IETF; a common mistake is reporting an individual's Internet-Draft as something the IETF is working on, or that the IETF has approved a new standard when it was an Informational or Individual RFC. Often, the press is not really to blame for the problem, as they might have been alerted to the story by a company trying to get publicity for a protocol, or they see the latest "controversy" on social media.
IETFがインターネットを前進させるのに役立つ最も有名な団体の1つであることを考えると、メディアがその行動をカバーするのは自然です。しかし、IETFをカバーするのは難しい場合があります。よくある間違いは、個人のインターネットドラフトをIETFが取り組んでいるものとして報告すること、またはIETFが情報または個々のRFCである場合、新しい基準を承認したことです。多くの場合、マスコミはプロトコルの宣伝をしようとしている会社によってストーリーに警告されたかもしれないし、ソーシャルメディアで最新の「論争」を見ているため、実際に問題を非難するものではありません。
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.
特定のトピックで「IETFがやっていること」について知りたい記者は、IETFのそのトピックについて活動している人と話をすることができ、おそらくWG椅子と話をするべきだと思います。いかなる場合でも。ドラフトを見たり、ドラフトの著者と話したりすることで、ドラフトで何が起こるかを判断することは不可能です。幸いなことに、すべてのWGSには、レポーターがドラフトの進捗状況が何であるかについての最近の兆候を調べることができるアーカイブがあります。残念ながら、この種の研究を行う時間や傾向がある記者はほとんどいません。
Reporters looking for information about the IETF, or pointers to IETF participants working on a particular topic relevant to the IETF, should send a message to media@ietf.org (mailto:media@ietf.org), and a full page of contacts for a variety of needs is available online (https://www.ietf.org/contact/). Replies are usually sent within a day. Even if a direct answer to a particular query is not available, pointers to resources or people who can provide more information about a topic are often provided.
IETFに関する情報、またはIETFに関連する特定のトピックに関連するIETF参加者へのポインターに関する情報を探している記者は、media@itef.org（mailto：media@ietf.org）にメッセージを送信する必要があります。さまざまなニーズがオンラインで利用できます（https://www.ietf.org/contact/）。通常、返信は1日以内に送信されます。特定のクエリへの直接的な回答が利用できない場合でも、トピックに関するより多くの情報を提供できるリソースまたは人へのポインターがしばしば提供されます。
The next phase of work to welcome new participants to the IETF builds on and gratefully acknowledges everyone who has contributed to the Tao, and other efforts to help newcomers to the IETF become engaged and productive participants.
IETFへの新しい参加者を歓迎する次の作業段階は、TAOに貢献したすべての人、およびIETFの新規参入者を支援する他の努力を魅了し、生産的な参加者になるための他の努力に感謝します。
We acknowledge all of the past "Tao of the IETF" editors:
私たちは、過去の「IETFのタオ」編集者のすべてを認めています。
* Gary Scott Malkin
* ゲイリー・スコット・マルキン
* Susan R. Harris
* スーザン・R・ハリス
* Paul Hoffman
* ポール・ホフマン
* Kathleen Moriarty
* キャスリーンモリアーティ
* Niels ten Oever
* ニールス10オーバー
We also acknowledge all the work of the translators that made the Tao accessible to many different audiences.
また、TAOに多くの異なる聴衆がアクセスできるようにした翻訳者のすべての作業を認めています。
Finally, we also want to acknowledge the work of countless contributors over the years.
最後に、長年にわたって無数の貢献者の仕事を認めたいと考えています。
Niels ten Oever
University of Amsterdam
Email: mail@nielstenoever.net
Greg Wood
IETF Administration LLC
Email: ghwood@staff.ietf.org