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