RFC3160 日本語訳
3160 The Tao of IETF - A Novice's Guide to the Internet EngineeringTask Force. S. Harris. August 2001. (Format: TXT=98411 bytes) (Obsoletes RFC1718) (Obsoleted by RFC4677) (Also FYI0017) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Harris Request for Comments: 3160 Merit Network FYI: 17 August 2001 Obsoletes: 1718 Category: Informational
コメントを求めるワーキンググループS.ハリス要求をネットワークでつないでください: 3160はネットワークFYIに値します: 2001年8月17日は以下を時代遅れにします。 1718年のカテゴリ: 情報
The Tao of IETF - A Novice's Guide to the Internet Engineering
Task Force
IETFのタオ--インターネット・エンジニアリング・タスク・フォースへの初心者のガイド
Status of this Memo
この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 (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process.
このドキュメントは、IETFミーティングとWorking Groupsの内側の作業について説明して、IETFに関連する組織について議論して、標準化過程を導入します。
Table of Contents
目次
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . 3
1. What Is the IETF? . . . . . . . . . . . . . . . . . . . . . 4
1.1 Humble Beginnings. . . . . . . . . . . . . . . . . . . . 5
1.2 The Hierarchy . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 ISOC . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 IESG . . . . . . . . . . . . . . . . . . . . . . 6
1.2.3 IAB. . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.4 IANA . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.5 RFC Editor . . . . . . . . . . . . . . . . . . . . 8
1.2.6 IETF Secretariat . . . . . . . . . . . . . . . . . 9
1.3 IETF Mailing Lists. . . . . . . . . . . . . . . . . . . 9
2. IETF Meetings . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Registration . . . . . . . . . . . . . . . . . . . . . 11
2.2 Newcomers' Orientation. . . . . . . . . . . . . . . . . 12
2.3 Dress Code. . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Seeing Spots Before Your Eyes . . . . . . . . . . . . . 13
2.5 Terminal Room . . . . . . . . . . . . . . . . . . . . . 13
2.6 Meals and Other Delights. . . . . . . . . . . . . . . . 14
2.7 Social Event. . . . . . . . . . . . . . . . . . . . . . 14
序論. . . . . . . . . . . . . . . . . . . . . . . . . 3承認。 . . . . . . . . . . . . . . . . . . . . . . . 3 1. IETFは何ですか? . . . . . . . . . . . . . . . . . . . . . 4 1.1謙虚な始め。 . . . . . . . . . . . . . . . . . . . 5 1.2 階層構造. . . . . . . . . . . . . . . . . . . . . 5 1.2.1ISOC. . . . . . . . . . . . . . . . . . . . . . . 5 1.2.2IESG. . . . . . . . . . . . . . . . . . . . . . 6 1.2.3IAB。 . . . . . . . . . . . . . . . . . . . . . . . 7 1.2 .4 IANA. . . . . . . . . . . . . . . . . . . . . . . 8 1.2.5RFCエディタ.81.2.6IETF事務局. . . . . . . . . . . . . . . . . 9 1.3IETFメーリングリスト。 . . . . . . . . . . . . . . . . . . 9 2. IETFミーティング. . . . . . . . . . . . . . . . . . . . . . 10 2.1登録. . . . . . . . . . . . . . . . . . . . . 11 2.2新来者のオリエンテーション。 . . . . . . . . . . . . . . . . 12 2.3服装規定。 . . . . . . . . . . . . . . . . . . . . . . 12 2.4 見るのは目の当りに.132.5の余地の.132.6の端末の食と他の喜びを見つけます。 . . . . . . . . . . . . . . . 14 2.7 社会的事件。 . . . . . . . . . . . . . . . . . . . . . 14
Harris Informational [Page 1] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[1ページ]のRFC3160タオ
2.8 Agenda. . . . . . . . . . . . . . . . . . . . . . . . . 14
2.9 Where Do I Fit In?. . . . . . . . . . . . . . . . . . . 15
2.9.1 IS Managers. . . . . . . . . . . . . . . . . . . 15
2.9.2 Network Operators and ISPs . . . . . . . . . . . 15
2.9.3 Networking Hardware and Software Vendors . . . . 15
2.9.4 Academics . . . . . . . . . . . . . . . . . . . 16
2.9.5 Computer Trade Press . . . . . . . . . . . . . . 16
2.10 Proceedings. . . . . . . . . . . . . . . . . . . . . . 16
2.11 Other General Things . . . . . . . . . . . . . . . . . 17
3. Working Groups. . . . . . . . . . . . . . . . . . . . . . . 18
3.1 Working Group Chairs . . . . . . . . . . . . . . . . . .18
3.2 Getting Things Done in a Working Group. . . . . . . . . 19
3.3 Preparing for Working Group Meetings . . . . . . . . 19
3.4 Working Group Mailing Lists . . . . . . . . . . . . . 20
3.5 Interim Working Group Meetings . . . . . . . . . . . . 21
4. BOFs. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5. New to the IETF? STOP HERE! (Temporarily). . . . . . . . . 22
6. RFCs and Internet Drafts . . . . . . . . . . . . . . . . . 22
6.1 Getting a Standard Published . . . . . . . . . . . . . 22
6.2 Letting Go Gracefully . . . . . . . . . . . . . . . . . 24
6.3 Internet Drafts . . . . . . . . . . . . . . . . . . . . 24
6.3.1 Recommended Reading for Writers . . . . . . . . . 25
6.3.2 Filenames and Other Matters . . . . . . . . . . . 26
6.4 Standards-Track RFCs . . . . . . . . . . . . . . . . . 26
6.4.1 Telling It Like It Is -- Using MUST and
SHOULD and MAY. . . . . . . . . . . . . . . . . . 27
6.4.2 Normative References in Standards . . . . . . . . 28
6.4.3 IANA Considerations . . . . . . . . . . . . . . . 29
6.4.4 Security Considerations . . . . . . . . . . . . . 29
6.4.5 Patents in IETF Standards . . . . . . . . . . . . 30
6.5 Informational and Experimental RFCs . . . . . . . . . . 31
7. How to Contribute to the IETF -- What You Can Do . . . . . . 31
7.1 What Your Company Can Do . . . . . . . . . . . . . . . 32
8. IETF and the Outside World . . . . . . . . . . . . . . . . . 33
8.1 IETF and Other Standards Groups . . . . . . . . . . . . 33
8.2 Press Coverage of the IETF. . . . . . . . . . . . . . . 33
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1 Tao . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.2 Useful E-mail Addresses . . . . . . . . . . . . . . . . 35
9.3 Useful Documents and Files. . . . . . . . . . . . . . . 35
9.4 Acronyms and Abbreviations Used in the Tao . . . . . . 36
9.5 Documents Cited in the Tao . . . . . . . . . . . . . . 36
Security Considerations . . . . . . . . . . . . . . . . . . . . 37
Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 37
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 38
2.8議題。 . . . . . . . . . . . . . . . . . . . . . . . . どこで、私は適合しますか?14 2.9 .152.9に、.1はマネージャです。 . . . . . . . . . . . . . . . . . . 15 2.9 .2人のネットワーク・オペレータとISP. . . . . . . . . . . 15 2.9.3のネットワークハードウェアとソフトウェア業者. . . . 15 2.9.4人のアカデミー会員. . . . . . . . . . . . . . . . . . . 16 2.9.5コンピュータ貿易は.16 2.10の議事を押します。 . . . . . . . . . . . . . . . . . . . . . 16 2.11 他の一般もの. . . . . . . . . . . . . . . . . 17 3。 ワーキンググループ。 . . . . . . . . . . . . . . . . . . . . . . 18 3.1 作業部会は作業部会で物事を成し遂げる.183.2をまとめます。 . . . . . . . . 19 3.3 ワーキンググループミーティング. . . . . . . . 19 3.4ワーキンググループメーリングリスト. . . . . . . . . . . . . 20 3.5の当座のワーキンググループミーティング. . . . . . . . . . . . 21 4の用意をします。 転炉。 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5. IETFに、新しいですか? ここに止まってください! (一時。) . . . . . . . . 22 6. そして、必須を使用して、.1が作家. . . . . . . . . 25 6.3.2のファイル名と他の件. . . . . . . . . . . 26 6.4の標準化過程RFCsのために.1がそれが好きであるとそれに言う.266.4を読むことを勧めた.246.3のインターネット草稿. . . . . . . . . . . . . . . . . . . . 24 6.3を優雅に行かせながら.226.2に規格を発行するRFCsとインターネット草稿. . . . . . . . . . . . . . . . . 22 6.1がそうである、そして、5月であるべきです。 . . . . . . . . . . . . . . . . . 27 6.4 IETF規格. . . . . . . . . . . . 30 6.5の情報的、そして、実験的なRFCs. . . . . . . . . . 31 7の規格. . . . . . . . 28 6.4.3のIANA問題. . . . . . . . . . . . . . . 29 6.4.4のセキュリティ問題. . . . . . . . . . . . . 29 6.4.5の特許における.2の引用規格。 どうIETFに貢献するか--あなたが.317.1に、あなたの会社が.328ができることができること。 IETFのIETFと外の世界. . . . . . . . . . . . . . . . . 33 8.1IETFの、そして、他の規格グループ. . . . . . . . . . . . 33 8.2マスコミ報道であること。 . . . . . . . . . . . . . . 33 9. 参照. . . . . . . . . . . . . . . . . . . . . . . . . 35 9.1タオ. . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.2の役に立つEメールアドレス. . . . . . . . . . . . . . . . 35 9.3の役に立つドキュメントとファイル。 . . . . . . . . . . . . . . 35 9.4の頭文字語と略語がタオでタオの.36のセキュリティ問題. . . . . . . . . . . . . . . . . . . . 37エディタのアドレスの.37の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 38で引用された.369.5通のドキュメントを使用しました。
Harris Informational [Page 2] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[2ページ]のRFC3160タオ
Introduction
序論
Over the last several 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 e-mail 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 FYI provides the mundane bits of information that newcomers will need in order to become active participants.
もちろん、多くのIETF関係者が全くさしの会談に行かないのは、本当です。 代わりに、彼らは様々なIETF Working Groupsに関するメーリングリストでアクティブです。 新来者にとって、Working Groupsの内側の作業は理解しているのが困難である場合があるので、このFYIは新来者が積極的な参加者になるように必要とする世俗的なビットの情報を提供します。
Many types of IETF documentation are mentioned in the Tao, from BCPs to RFCs and FYIs. (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;" and FYIs provide topical and technical overviews that are introductory or appeal to a broad audience. See Section 6 for more information.)
IETFドキュメンテーションの多くのタイプがタオでBCPsからRFCsとFYIsまで言及されます。 (BCPsはインターネットでBest Current Practicesのための推薦状をします。 RFCsは「コメントを求める要求」として礼儀正しく知られているIETFの主な技術的なドキュメンテーションシリーズです。 そして、FYIsは紹介している時事問題的、そして、技術的な概観を提供するか、または広い聴衆の好みに合います。 詳しい情報に関してセクション6を見てください。)
The acronyms and abbreviations used in this document are usually expanded in place, and are explained fully in Section 9.
本書では使用される頭文字語と略語は、通常、適所に広げられて、セクション9で完全に説明されます。
Acknowledgements
承認
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 draft are also much appreciated. Paul Hoffman wrote significant portions of this revision and provided encouragement, expertise, and much-needed guidance. Other contributors include Scott Bradner, Michael Patton, Donald E. Eastlake III, the IETF Secretariat, and members of the User Services Working Group.
1994年に発表されたこのドキュメントのオリジナルバージョンはゲーリー・マルキンによって書かれました。 IETF、洞察、および優れた文体に関する彼の知識はこの後の改正の規格を設定します、そして、また、現在の草稿への彼の貢献に非常に感謝します。 ポール・ホフマンは、この改正の重要な部分を書いて、奨励、専門的技術を提供して、指導を非常に必要としました。 他の貢献者はスコット・ブラドナー、マイケル・パットン、ドナルド・E.イーストレークIII IETF事務局、およびUser Services作業部会のメンバーを入れます。
Harris Informational [Page 3] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[3ページ]のRFC3160タオ
1. What Is the IETF?
1. 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.
インターネット・エンジニアリング・タスク・フォースはインターネット技術の工学と発展に貢献する人々の緩く自己に組織化されたグループです。 それは新しいインターネット標準仕様の開発に従事している本体です。 IETFは出来事の収集として存在しているので珍しいのですが、会社でなく、また理事会がなく、メンバーがなく、および支払われるべきものを全く持っていません。
Its mission includes:
任務は:
- Identifying, and proposing solutions to, pressing operational and
technical problems in the Internet;
- インターネットで操作上的、そして、技術的な問題を押して、解決策を特定して、提案します。
- Specifying the development or usage of protocols and the near-term
architecture to solve such technical problems for the Internet;
- インターネットへのそのような技術的問題を解決するためにプロトコルの開発か用法と短期間構造を指定します。
- Making recommendations to the Internet Engineering Steering Group
(IESG) regarding the standardization of protocols and protocol
usage in the Internet;
- インターネットのプロトコルとプロトコル用法の標準化に関するインターネットEngineering Steering Group(IESG)への作成推薦。
- Facilitating technology transfer from the Internet Research Task
Force (IRTF) to the wider Internet community; and
- インターネットResearch Task Force(IRTF)から、より広いインターネットコミュニティまで技術移転を容易にします。 そして
- Providing a forum for the exchange of information within the
Internet community between vendors, users, researchers, agency
contractors, and network managers.
- 業者と、ユーザと、研究者と、政府機関の契約者と、ネットワークマネージャの間のインターネットコミュニティの中の情報交換にフォーラムを提供します。
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回満たされます。
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 1.3). This is where the best information about current IETF activities and focus can be found.
会員資格が全くIETFにありません。 だれでも、どんなミーティングにも登録して、出席するかもしれません。 IETFメンバーであることへの最も近いことはIETFか作業部会メーリングリストにあることです(セクション1.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 BCP 11, "The Organizations Involved in the IETF Standards Process." If you participate in the IETF and only read one BCP, this is the one you should read.
もちろん、どんな組織もIETFがある種の構造を持っていなくてあるのと同じくらいうまくいっているはずがありません。 IETFの場合では、その構造は他の組織で、BCP11で説明されるように「IETF規格にかかわる組織は処理するかどうか」ということです。 あなたがIETFに参加して、1BCPしか読まないなら、これはあなたが読むべきであるものです。
Harris Informational [Page 4] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[4ページ]のRFC3160タオ
1.1 Humble Beginnings
1.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 over 100 attendees.
最初のIETF会合が1986年1月に21人の出席者と共にサンディエゴでLinkabitで行われました。 1986年10月のメンローパークのSRIで持たれていた第4IETFは非政府業者が出席した1番目でした。 Working Groupsの概念は1987年2月にカリフォルニアの米航空宇宙局エイムズ研究所の5番目のIETFミーティングで紹介されました。 第7 1987年7月のマクリーン(ヴァージニア)にMITREに保持されたIETFは100人以上の出席者との最初のミーティングでした。
The 14th IETF meeting was held at Stanford University in July 1989. It marked a major change in the structure of the IETF universe. The IAB (then Internet Activities Board, now Internet Architecture Board), which until that time oversaw many "task forces," changed its structure to leave only two: the IETF and the IRTF. The IRTF is tasked to consider long-term research problems in the Internet. The IETF also changed at that time.
14番目のIETF会合が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. One in five 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 US.
IETFはアムステルダム(オランダ)、1993年7月に会いました。 これはヨーロッパで行われる最初のIETF会合でした、そして、非米国/米国出席者分裂はおよそ50/50でした。 5つのIETFミーティングにおける1は現在ヨーロッパかアジアで主張されます、そして、非米国の出席者の数は米国で行われる会合でさえずっと高いです。
1.2 The Hierarchy
1.2 階層構造
1.2.1 ISOC (Internet Society)
1.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's oversight of the IETF is remarkably hands-off, so many IETF participants don't even know about it. 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-funded) heroes of the Internet.
インターネット協会はインターネットの拡大を伸ばす国際的で、非営利の会員組織です。 ISOCがこれをする方法の1つがここで説明されたもう片方の「私」グループの財政的で法的なサポートであります、特にIETF。 ISOCのIETFの見落としが手の著しく取り止めになっているので、多くのIETF関係者はそれに関して知ってさえいません。 ISOCはIETFの過程で人々の多くに損害補償の範囲を提供して、「私」グループのひとりが何かを言いたがっているという回のために広報チャンネルとしてプレスに務めます。 ISOCはインターネットの少佐歌われていなくて(下の資金を供給される)の英雄のひとりです。
Harris Informational [Page 5] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[5ページ]のRFC3160タオ
1.2.2 IESG (Internet Engineering Steering Group)
1.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. The IESG ratifies or corrects the output from the IETF's Working Groups, 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を始動されて、終えるように得て、RFCsになろうとしている非WG草稿が確実に正しくなるようにします。
The IESG consists of the Area Directors ("ADs"), who are selected by
the Nominations Committee (which is usually called "Nomcom") and are
appointed for two years. The process for choosing the members of the
IESG is detailed in BCP 10, "IAB and IESG Selection, Confirmation,
and Recall Process: Operation of the Nominating and Recall
Committees."
IESGをAreaディレクター(「広告」)から成らせます。(そのディレクターは、Nominations Committee(通常、"Nomcom"と呼ばれる)によって選ばれて、2年間任命されます)。 IESGのメンバーを選ぶための過程はBCP10、「IAB、IESG選択、確認、およびリコールは以下を処理するところ」で詳細です。 「指名とリコール委員会の操作。」
The current areas and abbreviations are:
現在の領域と略語は以下の通りです。
- Applications (APP) Protocols seen by user programs, such as
e-mail and the Web
- General (GEN) Catch-all for WGs that don't fit in other
areas (which is very few)
- Internet (INT) Different ways of moving IP packets and DNS
information
- Operations and Operational aspects, network monitoring,
Management (OPS) and configuration
- Routing (RTG) Getting packets to their destinations
- Security (SEC) Authentication and privacy
- Transport (TSV) Special services for special packets
- User Services (USV) Support for end users and user support
organizations
- メールやウェブなどのユーザ・プログラムで見られたアプリケーション(APP)プロトコル--他の領域をうまくはめ込まないWGs(ほんのわずかである)--動くIPパケットとDNS情報のインターネット(INT)の異なった道--操作とOperational局面のための一般(GEN)キャッチすべて、; ネットワーク監視、Management(OPS)、構成--それらの目的地にパケットを届けるルート設定(RTG)--セキュリティ(SEC)認証、およびプライバシー--特別なパケットのための輸送(TSV)特殊業務--ユーザServices(USV)はエンドユーザとユーザ・サポートのために組織を支持します。
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 an Area Director 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 discusses each Internet Draft that is proposed to become an RFC. At least two IESG members must express concerns before a draft can be blocked from moving forward. These checks help
特定の領域へのADsが他の誰よりその領域でのWGsの結合した仕事に関しても知ると予想されます。 他方では、全体のIESGはRFCになるように提案されるそれぞれのインターネットDraftについて議論します。 前方へ動くのを草稿を妨げることができる前に少なくとも2人のIESGメンバーが関心を述べなければなりません。 これらのチェックは助けます。
Harris Informational [Page 6] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[6ページ]のRFC3160タオ
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.
ADの「長年暖めてきた計画」がIETFプロトコルの残りのときにマイナスの影響があるならそれを標準化過程にしないのを確実にしてください。
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 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 review that the WG review gets from the ADs.
これは、IESGが決して勢力を振るわないと言わないためのものです。 IESGが、作業部会を特許から変わらせているのを見るか、またはWGが、WGのひどく設計されたプロトコルを規格にするようにIESGに頼むとき、IESGは行動するでしょう。 事実上、高いワークロードのために、通常、IESGは反応ファッションに入って来ます。 それは、インターネットDraftsがRFCsになるというほとんどのWG要求を承認して、何かが非常に間違うようになったときだけ、通常、中へ入ります。 これについて考える別の方法はADsが過程をただ走らせるのではなく、思うのが選択されるということです。 IETF規格の品質はそれらがWorking Groupsで得るレビューとWGレビューがADsから得るレビューから来ます。
The IETF is run by rough consensus, and it is the IESG that decides if a WG has come up with a result that has a real 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です。 これのために、IESGがWGで生産された何かを妨げるかもしれない主な理由の1つは結果が本当に全体でIETFでコンセンサスを獲得しなかったということです、すなわち、すべての領域のWorking Groupsのすべて中で。 例えば、1WGの結果は異なった作業部会で開発される技術に衝突するかもしれません。 IESGの重要な仕事は互いと仲たがいしてあるIETFプロトコルを防ぐのを助けるためにすべてのWGsの出力を監視することです。 これはADsがそれら自身のを除いた領域から出て来る草稿を見直すべきである理由です。
1.2.3 IAB (Internet Architecture Board)
1.2.3 IAB(インターネット・アーキテクチャ委員会)
The IAB is responsible for keeping an eye on the "big picture" of the Internet, and 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 brings these topics to the attention of people they think should know about them.
IABはインターネットの「大きい絵」を見守るのに責任があって、IETF活動の様々な領域の中で長期計画とコーディネートに焦点を合わせます。 IABはインターネットに重要な長期の問題に関して知識があったままでいて、彼らが彼らに関して知るべきであると思う人々の注意にこれらの話題をもたらします。
IAB members pay special attention to emerging activities in the IETF. When a new IETF working group is proposed, the IAB reviews its charter for architectural consistency and integrity. Even before the group is chartered, the IAB members are more than willing to discuss new ideas with the people proposing them.
IABメンバーは活動としてIETFに現れることに関する特別な注意を向けます。 新しいIETFワーキンググループが提案されるとき、IABは建築一貫性と保全のための特許を見直します。 グループが貸し切りになる前にさえ、IABメンバーは、彼らを提案する人々と新しいアイデアについて議論しても構わないと十二分に思っています。
The IAB also sponsors and organizes the Internet Research Task Force, 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に通常、します。
Harris Informational [Page 7] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[7ページ]のRFC3160タオ
The IAB also:
IABも:
- Approves Nomcom's IESG nominations - Acts as the appeals board for appeals against IESG actions - Appoints and oversees the RFC Editor - Approves the appointment of the IANA - Acts as an advisory body to the ISOC - Oversees IETF liaisons with other standards bodies
- 承認、NomcomのIESG指名(IESG動作に対する上告のための上告板としての条例)は、RFC Editorを任命して、監督します--IANA(ISOCへの諮問機関としての条例)のアポイントメントを承認する、他の標準化団体とのIETF連絡を監督します。
Like the IESG, the IAB members are selected for multi-year positions by the Nomcom, and are approved by the Board of Trustees of the ISOC.
IESGのように、IABメンバーはNomcomによってマルチ年の位置に選択されて、BoardによってISOCのTrusteesを承認されます。
1.2.4 IANA (Internet Assigned Numbers Authority)
1.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(アイキャン)によって財政上支持されます。
Five years ago, no one would have expected to ever 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 which 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.
5年前に、だれも、今までに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の創設者(ジョン・ポステル)は、ものを整理するために大いに当てにされました。
1.2.5 RFC Editor
1.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で再刊されるでしょう。
Harris Informational [Page 8] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[8ページ]のRFC3160タオ
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 ISOC and can be contacted by e- mail at rfc-ed@rfc-editor.org.
IETF共同体で最もポピュラーな誤解の1つはRFC Editorの役割がIANAによって実行されるということです。 事実上、RFC Editorは別々の仕事です、RFC EditorとIANAの両方が何年間も同じ人々にかかわりましたが。 IABはRFC Editorとして機能する組織とRFC Editorの全般的執行方針を承認します。 RFC EditorにISOCが資金を供給して、電子メールは rfc-ed@rfc-editor.org へ連絡できます。
1.2.6 IETF Secretariat
1.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 for helping the IESG do its work. The IETF Secretariat is financially supported by the fees of the face-to-face meetings.
事実上、IETFを維持するのに支払われる数人の人々がいます。 IETF事務局はその日その日の後方支援を提供します。(それは、さしの会談を調整して、IETF特有のメーリングリスト(WGメーリングリストでない)を走らせることを主に意味します)。 また、IETFウェブサイトを維持して、公式のインターネットDraftsディレクトリを最新で規則的に保管して、IESGが仕事するのを助けるのに事務局も責任があります。 IETF事務局はさしの会談の料金によって財政上支持されます。
1.3 IETF Mailing Lists
1.3 IETFメーリングリスト
Anyone who plans to attend an IETF meeting should join the IETF announcement mailing list, "ietf-announce@ietf.org". This is where all of the meeting information, Internet Draft and RFC announcements, and IESG Protocol Actions and Last Calls are posted. People who would like to "get technical" may also join the IETF 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).
IETFミーティングに出席するのを計画しているだれでもIETF発表メーリングリスト、" ietf-announce@ietf.org "に加わるべきです。 これはIESGプロトコルのミーティング情報、インターネットDraft、RFC発表、Actions、およびLast Callsのすべてが掲示されるところです。 また、「技術的になりたがっている」人々はIETF議論リスト、" ietf@ietf.org "に加わるかもしれません。 これは宇宙意味の議論が行われる(働くGroupsには、彼らの仕事に関連する議論のためのそれら自身のメーリングリストがあります)ところです。
Subscriptions to these and other IETF mailing lists are handled by a program called Majordomo. Majordomo tends to be somewhat finicky about the format of subscription messages, and interacts poorly with email programs that make all email messages into HTML files. Majordomo will treat you well, however, if you format your messages just the way it likes. To join the IETF announcement list, for example, send email to:
これらの購読と他のIETFメーリングリストはMajordomoと呼ばれるプログラムで扱われます。 家令は、購読メッセージの形式に関していくらか気むずかしい傾向があって、すべてのメールメッセージをHTMLファイルに作りかえるメールプログラムと不十分に対話します。 しかしながら、あなたがまさしくそれが好きである方法でメッセージをフォーマットすると、家令はあなたをよく扱うでしょう。 IETF発表に参加するために、記載してください、そして、例えば、以下のことのためにメールを送ってください。
ietf-announce-request@ietf.org
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:
単語('申し込む'(引用文なしで))をメッセージのSubject線とメッセージ本体に入力してください。 IETF議論リストを接合するために、メールを以下に送ってください。
ietf-request@ietf.org
ietf-request@ietf.org
Harris Informational [Page 9] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[9ページ]のRFC3160タオ
and enter the word 'subscribe' as explained above. If you decide to withdraw from either list, use the word 'unsubscribe.' Your messages to Majordomo should have nothing other than the commands 'subscribe' or 'unsubscribe' in them.
そして、上で説明されるように単語('申し込む')を入力してください。 どちらのリストからも引き下がると決めるなら、単語('外す')を使用してください。MajordomoへのYourメッセージは、コマンド以外の何も'申し込む'か、またはそれらで'外さないこと'をさせるべきです。
Both lists are archived on the IETF web site:
両方のリストはIETFウェブサイトに格納されます:
http://www.ietf.org/maillist.html
http://www.ietf.org/maillist.html
Do not, ever, under any circumstances, for any reason, send a request to join a list to the list itself! The thousands of people on the list don't need, or want, to know when a new person joins. Similarly, when changing e-mail 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 anyone 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 "IETF Discussion List Charter," RFC 3005. It is a good idea to read the whole RFC (it's short!) before posting to the IETF discussion list.
IETF議論リストは非加減されます。 これは、だれでもインターネットに影響する問題に関して意見を言うことができることを意味します。 しかしながら、それは請求するか、または広告を出す会社か個人のための場所ではありません、「IETFディスカッション・リスト憲章」で注意されるように、RFC3005。 任命の前に全体のRFC(それは短いです!)をIETF議論リストに読み込むのは、名案です。
Only the Secretariat can send messages to the announcement list.
事務局だけが発表リストにメッセージを送ることができます。
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ミーティングに出席するのが、あなたが自動的にどちらのメーリングリストにも追加されることを意味しないことに注意するのは重要です。
2. IETF Meetings
2. 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 dweebfests 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, although ISOC kicks in additional funds for things like the multicast simulcast of some Working Group sessions.
コンピュータ産業は、会議、セミナーでおびただしくて、博覧会と、すべて、他の種類のミーティングの方法です。 IETF表面全く、表面へのミーティングはこれらに似ていません。 1年に3回行われる会合は第一の目標が彼らのタスクを完了させるためにWGsを生き返らせることであり、WGsと領域の間の公正な量の混合を促進する二次目標がことである1週間のdweebfestsです。 ミーティングの費用は人々出席と各ミーティングのための法人のホストによって支払われます、ISOCはいくつかの作業部会のセッションのマルチキャスト同時放送のようなもののために追加基金をけり入れますが。
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ミーティングは、営業人々へのわずかの関心がありますが、技術者と開発者への高利についてあります。
Harris Informational [Page 10] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[10ページ]のRFC3160タオ
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 or two. The past few meetings have had about 2,500 attendees. There have been over 50 IETF meetings so far, and a list of upcoming meetings is available on the IETF web pages, http://www.ietf.org/meetings/0mtg-sites.txt.
それが関係者の大部分がそうであるところであるので、ほとんどのIETF会合が北アメリカで行われます。 しかしながら、会合が毎年におよそ一度他の大陸か2つの大陸で行われます。 過去のわずかなミーティングには、およそ2,500人の出席者がいました。 今までのところ、50以上の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 half the people in a WG meeting reading e-mail or perusing the web during presentations they find uninteresting.
IETFさしの会談への新来者はしばしば少しのショックのそうです。 彼らは、それらが他の標準化団体に似ていると予想するか、またはコンピュータ会議が好きです。 幸い、ショックは1日か2日時以降次第になくなります、そして、彼らにはどのくらいの楽しみがあるかに関して多くの新しい出席者がかなり活気づけられます。 最近のIETFミーティングの1つの特に耳障りな特徴は集会場中の無線のインターネット接続の使用です。 彼らが見つけるプレゼンテーションの間に電子メールを読むか、またはウェブを熟読するWGミーティングにおける人々の半分がおもしろくないのがわかるのは一般的です。
2.1 Registration
2.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 e-mail 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 breaks.
仮登録に、あなたはウェブで登録を提出しなければなりません。 前納してください、仮登録。そして、あなたがそうすることができる、仮登録、そして、サイトでミーティングの現場のクレジットカード、仮登録、および賃金で支払うか、登録して、または支払うのが、より遅いウェブサイトへのリターン。 下側の入会手続料を得るために、あなたは登録の(ミーティングのおよそ1週間前)締め切り前半で支払わなければなりません。 入会手続料はコーヒー休憩の1週間のミーティング、日曜日の晩のレセプション(現金棒)、毎日のコンチネンタル・ブレックファースト、および午後のすべてを覆っています。
Credit card payments on the web are encrypted and secure, or, if you prefer, you can use PGP to send your payment information to the Registrar (ietf-registrar@ietf.org).
ウェブにおけるクレジットカードによる支払が、コード化されていて安全であるか、またはよければ、あなたは、Registrar( 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, beginning at noon on Sunday and continuing throughout the 5:00 Sunday evening reception. The reception is a popular event where you can get a bite to eat and socialize with other early arrivals.
登録はミーティングの週の間中開いています。 しかしながら、事務局は、出席者が早めの登録のために到着することを強く勧めます、日曜日の正午に始まって、レセプションを平等にする日曜日の5:00の間中続いて。 レセプションはあなたが軽食を手に入れて、他の早めの到着で社交的にすることができるところのポピュラーな出来事です。
Harris Informational [Page 11] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[11ページ]のRFC3160タオ
Registered attendees (and there aren't any other kind) receive a registration packet. It contains much useful information, including a general orientation sheet, the most recent agenda, and a name tag. Attendees who pre-paid will also find their receipt in their packet. It's worth noting that neither attendee names and addresses or IETF mailing lists are ever offered for sale.
登録された出席者(いかなる他の種類もありません)は登録パケットを受けます。 それは一般的なオリエンテーションシート、最新の議題、および名札を含む多くの役に立つ情報を含んでいます。 また、あらかじめ支払った出席者が彼らのパケットで彼らの領収書を見つけるでしょう。 出席者名とアドレスもIETFメーリングリストもかつて販売のために提供されないことに注意する価値があります。
2.2 Newcomers' Orientation
2.2人の新来者のオリエンテーション
Newcomers are encouraged to attend the Newcomers' Orientation, which is especially designed for first-time attendees. The orientation is organized and conducted by the IETF Secretariat, and is intended to provide useful introductory information. The orientation is typically about 30 minutes long and 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.
新来者がNewcomersのOrientationに出席するよう奨励されます。(Orientationは初めての出席者のために特に設計されています)。 オリエンテーションは、IETF事務局によって組織化されて、行われて、役に立つ紹介している情報を提供することを意図します。 オリエンテーションは、通常長さおよそ30分であり、出席者パケット、名札の上のすべてのドットが意味することには何があるか、そして、IETFの構造、および他の新しいIETFersにおける多くの不可欠の、そして、啓蒙的な話題を含んでいます。
Immediately following the Newcomers' Orientation 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. The Standards Process Orientation also lasts about 30 minutes.
すぐにNewcomersのOrientationに続くのは、IETF Standards Process Orientationです。 ドキュメントが規格になることへの途中にどんなステージを通り抜けなければならないか、そして、次の舞台に達するために何をしなければならないかを説明することによって、このセッションは標準化過程の多くを啓蒙します。 また、Standards Process Orientationはおよそ30分続きます。
There is ample time at the end for questions. The Secretariat also provides handouts that include an overview of the IETF, a list of important files available online, and 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 "Additional Information".
質問のための終わりに、十分な時間があります。 また、事務局はオンラインでIETFの概観、利用可能な重要なファイルのリストを含んでいる施し物、および「IETF構造とインターネット標準化過程」プレゼンテーションのスライドのハードコピーを提供します。 また、これらの非常に役に立つスライドもwww.ietf.orgで「追加情報」の下でオンラインであることで利用可能です。
The orientation is held on Sunday afternoon before the 5:00 p.m. reception (check the agenda for exact time and location). Be advised that attending the orientation does NOT mean you can go to the reception early!
オリエンテーションは午後5時のレセプションの前の午後に日曜日に保持されます(正確な時間と位置がないかどうか議題をチェックしてください)。 オリエンテーションに出席するのが、あなたが早くレセプションに行くことができることを意味しないのをお知らせします!
2.3 Dress Code
2.3 服装規定
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
出席者が彼らの名札を身につけなければならないので、また、それらはシャツかブラウスを着なければなりません。 また、ズボンかスカートも非常にお勧めです。 もっとも、真剣に、彼らが月曜日の朝他の人皆がtシャツ、ジーンズ(天気が可能にするなら、ショートする)、およびサンダルをはいていると発見するためにスーツで現れるとき、多くの新来者がしばしば当惑しています。 それらがスーツ以外の何でも着るのを拒否するIETFにいます。 幸い、よく知られているので(他の理由で)、それらはあります。
Harris Informational [Page 12] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[12ページ]のRFC3160タオ
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!).
この特定の特異性を許します。 一般的な規則は「天気のためのドレス」(あなたが、あなたが戸外へ出ないほど一生懸命働くのを計画していないなら、その場合、「安らぎのためのドレス」は規則です!)です。
2.4 Seeing Spots Before Your Eyes
2.4 目の当りにスポットを見ること。
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 following meanings:
IETFの何人かの人々が彼らの名札の上に小さい有色のドットを持つでしょう。 数人の人々には、1つ以上があります。 これらのドットは多くの時間外労働をするのを買って出ることができるくらい愚かな人々を特定します。 色には、以下の意味があります:
blue - Working Group/BOF chair
green - Host group
red - IAB member
yellow - IESG member
orange - Nominating Committee member
青--作業部会/BOFいす緑色--ホストグループ赤--IABメンバー黄色--IESGメンバーオレンジ--メンバーに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いすがだれとも話したいと思わないなら、彼らは第一に、ドットを着ないでしょうに。
2.5 Terminal Room
2.5 端末の余地
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 who donate their equipment, services and time are to be heartily congratulated and thanked.
ホストがする中で最も重要な(あなたの観点による)ことの1つはミーティング出席者のためのインターネット・アクセスを提供することです。 一般に、ワイヤードで無線の接続性は素晴らしいです。 これは完全なローカル・ホストのオリンピックの努力、および請って、借りて、盗む彼らの能力のためです。 人々、それらの設備を寄贈する会社、サービス、および時間は、心から祝われて、感謝されることです。
While 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. The terminal room provides workstations, one or two printers, and ports for laptops.
ミーティングのずっと前の準備が奨励されている間、いくつかの避けられない「土壇場」のときに、端末の部屋で達成できるものがあるかもしれません。 また、それもいろいろなことが彼らの心でまだ新鮮である間、旅行レポートか現状報告を作る必要がある人々の役に立つかもしれません。 端末の部屋は1か2つのワークステーション、プリンタ、およびポートをラップトップに提供します。
Harris Informational [Page 13] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[13ページ]のRFC3160タオ
2.6 Meals and Other Delights
2.6 食事と他の喜び
Marshall Rose once remarked that the IETF was a place to go for "many fine lunches and dinners." While it is true that some people eat very well at the IETF, they find the food on their own; lunches and dinners are not included in the registration fee. The Secretariat does provide appetizers at the Sunday evening reception (not meant to be a replacement for dinner), continental breakfast every morning, and (best of all) cookies, brownies and other yummies during afternoon breaks.
マーシャル・ローズは、一度IETFが「多くのすばらしい昼食と夕食」に行く場所であると述べました。 何人かの人々がIETFで非常に上手に食事するのが、本当である間、彼らは一人で食物を見つけます。 昼食と夕食は入会手続料に含まれていません。 事務局は午後の休みの間、(最もよく)の日曜日の晩のレセプション(夕食との交換であることを意味しない)、毎朝のコンチネンタル・ブレックファースト、クッキー、ブラウニー、および他のyummiesでアペタイザーを提供します。
If you prefer to get out of the hotel for meals, the local host usually provides a list of places to eat within easy reach of the meeting site.
あなたが、食事のためにホテルを出るのを好むなら、通常、ローカル・ホストはミーティングサイトの簡単に届くの中で食事する場所のリストを提供します。
2.7 Social Event
2.7 社会的事件
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 the 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.
ホストによって組織化されて、管理された中で最も重要なものの別のものはIETF社会的事件です。 時々、社会的事件は、コンピュータかハイテク関連する出来事です。 ボストンIETFでは、例えば、社会的なことはコンピュータ博物館の夕食でした。 他の回であり、画廊へのディナークルーズか社会的なことは旅行であるかもしれません。
Newcomers to the IETF are encouraged to attend the social event. Everyone is 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で技術的であって、平らであるというよりむしろ社会的に会う機会を人々に与えるように設計されています。
2.8 Agenda
2.8 議題
The agenda for the IETF meetings is a very fluid thing. It is sent, updated, to the IETF announcement list three times prior to the meeting, and is also available on the web. The agenda for the 50th IETF, for example, is at http://www.ietf.org/meetings/agenda_50.html. 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).
IETFミーティングのための議題は非常に流動的なものです。 それも、送られて、ミーティングの前にIETF発表リストに3回をアップデートして、また、ウェブで利用可能です。 例えば、第50IETFのための議題が http://www.ietf.org/meetings/agenda_50.html にあります。 最終的な議題は登録パケットに含まれています。 もちろん、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がミーティングの間の複数の回に会います、そして、それぞれのセッションの同じ部屋に作業部会大会を持っているように最善の努力をします。
Harris Informational [Page 14] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[14ページ]のRFC3160タオ
2.9 Where Do I Fit In?
2.9 どこで、私は適合しますか?
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ミーティングに来るのが義務付けられると感じるべきではありません。 以下のガイドライン(様々な産業で人々のステレオタイプに基づいている)は、あなたがあなたが実際に来たがっているかどうかと、そうだとすれば、何があなたの時間があなたの最初のミーティングの最善の利用であるかもしれないかを決めるのを助けるかもしれません。
2.9.1 IS Managers
2.9.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 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において、それらの存在価値があるだろうかどうかに関する感覚を得るでしょう。
2.9.2 Network Operators and ISPs
2.9.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 might find attending the IETF meeting valuable. The closer you are to the bleeding edge of networking, particularly in the areas of routing and switching, the more likely it is that you will be able to learn and contribute at an IETF meeting.
新しいプロトコルかあなたが既に取扱っているプロトコルの新しいバージョンと格闘する必要はなくて、ネットワークを経営しているのは十分困難です。 あなたがいつもまさしくその最新のハードウェアとソフトウェアを使用しているネットワークのタイプのために働いて、あなたの豊富な空き時間で関連Working Groupsの後をつけているなら、あなたは、IETFミーティングに出席するのが貴重であることがわかるかもしれません。 IETFミーティングでは、あなたは、学んで、近ければ近くほど、ネットワークの最前線と、特にルーティングと切り換えの領域では、より貢献できそうでしょう。
2.9.3 Networking Hardware and Software Vendors
2.9.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
ほとんど象牙の塔のアカデミー会員であるIETFのイメージは過去に本当であったかもしれませんが、現在、産業には典型的な出席者の仕事があります。 IETFのほとんどの領域では、業者の従業員がプロトコルを書いて、Working Groupsを導くものであるので、業者が出席するのが、完全に適切です。 どんな他のもののためにもそうしないで、あなたがインターネットハードウェアかソフトウェアを作成して、あなたの会社からのだれも今までにIETFミーティングに出席したことがないなら、それは、ミーティングに来るためにあなたに当然です。
Harris Informational [Page 15] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[15ページ]のRFC3160タオ
reason than to tell the others how relevant the meeting was or was not to your business.
ミーティングがどれくらい関連していたかを他のものに言うことになっていなかったか、ビジネスが推論することになっていなかったより推論してください。
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.
これは、皆がミーティングに行くことができるように会社がIETFミーティング数週間店を閉ざすべきであると言わないためのものです。 通常、マーケティング人々(技術マーケティング人々さえ)は会社からの何人かの技術人々がミーティングにいる限り、IETFから離れるのにおいて安全です。 同様に、それは、必要でなく、またおそらく役に立ちません、行く技術部からの皆のために、特に、彼らが皆、インターネットDraftsを読んで、作業部会メーリングリストに従っていないなら。 多くの会社が完成する彼らの能力と役に立つ旅行レポートに選ばれているミーティング出席者にまさしくいくつかを指定させます。
2.9.4 Academics
2.9.4 アカデミー会員
IETF meetings are often excellent places for computer science folk 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.
IETFミーティングはコンピュータサイエンス人々が何がもうすぐ配備されたプロトコルの方法で起こっているかを見つけるしばしば素晴らしい場所です。 ネットワークかコミュニケーションでする研究である教授と大学院生(時々大学生を予想以上にやり遂げて)は、彼らの興味がある特定の分野でWorking Groupsに続くことによって、豊富な情報を得ることができます。 異なった作業部会のミーティングまでさまようのはあなたの部にシンポジウムとセミナーに行くのと同じ効果を持つことができます。
2.9.5 Computer Trade Press
2.9.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 8.2.
あなたが、プレスのメンバーであり、IETFに出席すると考えているなら、私たちはタオの特別なセクションを準備しました--セクション8.2を見てください。
2.10 Proceedings
2.10 議事
IETF proceedings are compiled in the two months following each meeting, and are available on the web, on CD, and in print. 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 usually start with an informative (and highly entertaining) message from Steve Coya, the Executive Director of the IETF. Each volume of 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.
通常、議事はスティーブCoya、IETFの事務局長からの有益で(非常に愉快)のメッセージから始まります。 各ボリューム、最終的な(後知恵)議題、IETF概観、領域、および作業部会のレポートを含んでいて、プロトコルと技術的なプレゼンテーションから滑ります。 作業部会のレポートとプレゼンテーションは時々不完全です、材料が公表に間に合うように事務局に渡されていないなら。
Harris Informational [Page 16] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[16ページ]のRFC3160タオ
An attendee list is also included, and contains names, affiliations, work and fax phone numbers, and e-mail addresses 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.
出席者リストは、また、含まれていて、登録用紙の上で提供するように名前、提携、仕事、ファックス電話番号、およびEメールアドレスを含んでいます。 議事のコピーを入手することの情報に関しては、ウェブが http://www.ietf.org/proceedings/directory.html に記載しているのを見てください。
2.11 Other General Things
2.11 他の一般もの
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が命令に従うと予想しないでください。
The IETF, 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, etc.). Please check with the Secretariat before placing materials on the desk; the Secretariat has the right to remove material that they feel is not appropriate.
「材料分配テーブル」がフロント・デスクの近くにいつもあります。 この机は、適切な情報を出席者(例えば、作業部会のセッションのときに議論した、何かのコピー、オンラインIETF関連の情報の記述など)にとって利用可能にするのに使用されます。 材料を机に置く前に、事務局に問い合わせてください。 事務局には、彼らが適切でないと感じる材料を取り除く権利があります。
Harris Informational [Page 17] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[17ページ]のRFC3160タオ
3.0 Working Groups
3.0 ワーキンググループ
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 a very good reason.) BCP 25, "IETF Working Group Guidelines and Procedures," is an excellent resource for anyone participating in WG discussions.
多くの「ワーキンググループ」でかなりの大多数の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. Some IETF WG mailing lists only let subscribers to the mailing list post to the mailing list, while others let anyone post. Each Working Group has one or two chairs.
WGは本当にただ少しの大人の監視があるメーリングリストです。 あなたはメーリングリストに加入することによって、WGを「接合します」。 だれにとっても、すべてのメーリングリストが開いています。 いくつかのIETF WGメーリングリストが加入者をメーリングリストへのメーリングリストポストにさせるだけです、他のものはだれでもさせますが。ポスト。 各作業部会には、1か2脚のいすがあります。
More importantly, each WG has a charter that the WG is supposed to follow. The charter states the scope of discussion for the Working Group, as well as its goals. The WG's mailing list and face-to-face meetings are supposed to focus on just what is in the charter, and not to wander off on other "interesting" topics. Of course, looking a bit outside the scope of the WG is occasionally useful, but the large majority of the discussion should be on the topics listed in the charter. In fact, some WG charters actually specify what the WG will not do, particularly if there were some attractive but nebulous topics brought up during the drafting of the charter. The list of all WG charters makes interesting reading for folks who want to know what the different Working Groups are supposed to be doing.
より重要に、各WGには、WGが続くべきである特許があります。 特許は作業部会、およびその目標に議論の範囲を述べます。 ちょうど特許中であることのものに焦点を合わせます、そして、WGのメーリングリストとさしの会談は下に他の「おもしろい」話題に関してさまようべきではありません。 もちろん、WGの範囲の外で少し見るのは時折役に立ちますが、特許で記載された話題に関して議論の大多数はあるべきです。 事実上、いくつかのWG特許が、WGが何をしないかを実際に指定します、特に特許の草稿の間に持って来られたいくつかの魅力的な、しかし、不明瞭な話題があったなら。 すべてのWG特許のリストは異なったWorking Groupsが何をするべきであるかを知りたがっている人々にとって、おもしろい読書を作ります。
3.1 Working Group Chairs
3.1 ワーキンググループいす
The role of the WG chairs is described in both BCP 11 and BCP 25. Basically, their job is to keep the discussion moving forward towards the milestones in the WG charter -- usually publication of one or more RFCs. They are not meant to be taskmasters, but are responsible for assuring positive forward motion and preventing random wandering.
WGいすの役割はBCP11とBCP25の両方で説明されます。 基本的に、彼らの仕事は議論をWG特許における重大事件に向かって早めさせ続けることです--通常1RFCsの公表。 彼らは、仕事割当係であることは意味されませんが、積極的な前進運動を保証して、無作為の歩き回ることを防ぐのに原因となります。
As you can imagine, some Working Group chairs are much better at their jobs than others. 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
ご想像のとおり、何人かの作業部会いすは他のものよりはるかに彼らの仕事が上手です。 WGが特許を実現させたとき、それは操作をやめるべきです。 (WGメーリングリストがWGの後に続く大部分は閉じられます、作業部会が議論したようにまだ同じ話題について議論していて。) IETFでは、特許を実現させたので、それはWGが閉ざす成功のマークです。 これはIETFの局面の1つです。他の標準化団体の経験を持っている新来者は、分かるのに苦労します。 しかしながら、彼らのWGを終わらせるか、または何人かのWGいすが何とか新しいタスクを特許に加え決して続けないので、作業部会は何年間も長引きます。 これらの老朽化しているWGsの出力は決してしばしば同じくらい役に立ちません。
Harris Informational [Page 18] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[18ページ]のRFC3160タオ
earlier products, and the messy results are sometimes called "degenerative Working Group syndrome."
より早く、時々製品、および乱雑な結果はそうです。「退化的な作業部会シンドローム」と呼ばれます。
One important role of the chair is to decide which Internet Drafts get published as "official" Working Group drafts, and which don't. In practice, there is actually not much procedural difference between WG drafts and independent drafts; 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.
いすの1つの重要な役割はどのインターネットDraftsが「公式」の作業部会ドラフトとして発行されるか、そして、どれが発行されないかを決めることです。 実際には、WG草稿と独立している草稿の間には、実際にそれほど多くない手続き上の違いがあります。 例えば、また、多くのWGメーリングリストが独立している草稿(WGいすの裁量における)について議論します。 インターネットDraftsのための手順は後で多くのその他の詳細で本書ではカバーされています。
WG chairs are strongly advised to go to the new chairs' training lunch the first day of the IETF meeting. If you're interested in what they hear there, take a look at the slides at http://www.ietf.org/wgchair/index.htm.
WGいすが初日新しいいすのトレーニング昼食にIETFミーティングを行かせるように強くアドバイスされます。 彼らがそこで聞くことに関心があるなら、 http://www.ietf.org/wgchair/index.htm でスライドを見てください。
3.2 Getting Things Done in a Working Group
3.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.
多くの初心者を混乱させる1つの事実は面と向かっているWGミーティングがそれらよりIETFで他のほとんどの組織であまり重要でないということです。 また、さしの会談でされたどんな決定もWGメーリングリストに関するコンセンサスを獲得しなければなりません。 後でメーリングリストでひっくり返されるWGミーティングでされた重要な決定の多数の例があります、ミーティングに出席できなかっただれかが、論理の重大な欠陥が以前はよく結論に達していたとしばしば指摘したので。
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. The lack of 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?)
多くの人々を困惑させるWorking Groupsのもう一つの側面は正式な票ないという事実です。 議論された話題の一般的な規則は作業部会が「コンセンサスは粗であり」に来なければならないということです、気にかける人の非常に大きい大部分が同意しなければならないことを意味して。 作業部会によって荒いコンセンサスを決定する正確な方法は異なります。 いくつかの提案のための非常に長い遅れをいくつかに引き起こしましたが、票の不足は辛らつな討論が、遅れがしばしばより良いプロトコルをもたらすと感じた後に荒いコンセンサスを目撃したIETF関係者を大部分に引き起こしました。 (そして、それについて考えるなら、あなたはだれかが加わることができて、関係者を数えるのが不可能であるグループでどのように「票」を持っているかもしれませんか?)
3.3 Preparing for Working Group Meetings
3.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 beforehand. 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ミーティングは教育のために明らかにそうしていません: それらは、グループのドキュメントを開発するものです。 ミーティングにおける何も言うのを計画していなくても、あなたはあなたが、何が言われているかを理解できるように出席する前に、グループのドキュメントを読むべきです。
Harris Informational [Page 19] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[19ページ]のRFC3160タオ
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'がミーティング番号です。
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're giving a presentation at a face-to-face meeting, you should probably come with a few slides prepared. Projectors for laptop- based presentations are available in all the meeting rooms. And here's a tip for your slides: don't put your company's logo on every one, even though it's common practice outside the IETF. The IETF frowns on this kind of corporate advertising, and most presenters don't even put their logo on their opening slide. The IETF is about technical content, not company boosterism.
さしの会談で報告しているなら、いくつかのスライドが準備されている状態で、あなたはたぶん来るべきです。 ラップトップがプレゼンテーションを基礎づけたので、プロジェクターはすべてのミーティング部屋で利用可能です。そして、ここに、あなたのスライドのためのチップがあります: それはIETFの外の一般的な習慣ですが、会社のロゴを皆に置かないでください。 IETFはこの種類の企業広告を反対します、そして、ほとんどの贈呈者は彼らの初めのスライドに彼らのロゴを置いてさえいません。 IETFは会社の自己推奨宣伝ではなく、技術的な内容に関するものです。
3.4 Working Group Mailing Lists
3.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 everybody follow the discussions on the mailing lists of the Working Groups that they 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.
メーリングリストがまた、続きたがっている人にフォーラムを提供するか、または貢献する、IETFミーティングに出席できないのを除いたWorking Groupsの努力。
Harris Informational [Page 20] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[20ページ]のRFC3160タオ
Most IETF discussion lists use Majordomo and have a "-request" address which handles the administrative details of joining and leaving the list. (See Section 1.3 for more information on Majordomo.) It is generally frowned upon when such administrivia appears on the discussion mailing list.
ほとんどのIETF議論リストが、Majordomoを使用して、リストを接合して、出る管理詳細を扱う「要求」アドレスを持っています。 (Majordomoの詳しい情報に関してセクション1.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 FTP access. Many such archives are listed online at ftp://ftp.ietf.org/ietf-mail-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!).
ほとんどのIETF議論リストが格納されます。 すなわち、リストに送られたメッセージのすべてが公開FTPアクセサリーのためにホストに自動的に格納されます。 そのような多くのアーカイブが ftp://ftp.ietf.org/ietf-mail-archive/ にオンラインでリストアップされています。あなたが探しているリストを見つけないなら、リストの「要求」アドレス(リスト自体でないことへの!)にメッセージを送ってください。
3.5 Interim Working Group Meetings
3.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 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 minutes@ietf.org, and the group needs to take attendance.
ワーキンググループは時々IETFsの間の当座の会合を開きます。 当座のミーティングがIETFミーティングの代用品でない、しかしながら、グループは彼らは好きでない位置でミーティングをサボって、3週間後、例えば、カンクンで会うと決めることができません。 当座のミーティングは、AD許可を必要として、少なくとも1カ月早く発表される必要があります。 位置とタイミングは、すべての関係者のための公正なアクセスを許す必要があります。 定期的なIETFミーティングのように、だれかが、メモを取って、それらを minutes@ietf.org に送る必要があります、そして、グループは出席をとる必要があります。
4. BOFs
4. 転炉
In order to form a Working Group, you need a charter and someone who is able to be chair. In order to get those things, you need to get people interested so that they can help focus the charter and convince an Area Director that the project is worthwhile. A face- to-face meeting is useful for this. In fact, very few WGs get started by an Area Director; most start after a face-to-face BOF because attendees have expressed interest in the topic.
作業部会を形成するために、あなたはいすであることを特許とだれかできる人を必要とします。 それらのものを手に入れるために、あなたは、彼らが、特許の焦点を合わせるのを助けることができるくらい人々を興味を持たせるのが必要であり、プロジェクト価値があるとAreaディレクターに納得させます。 表面への表面ミーティングはこれの役に立ちます。 事実上、ほんのわずかなWGsはAreaディレクターで開始します。 出席者が話題への関心を示したので、大部分は面と向かっているBOFの後に始まります。
A 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 they think. The next step is to request a meeting slot at the next face- to-face meeting. Of course, you don't need to wait for that meeting to get some work done, such as setting up a mailing list and starting to discuss a charter.
それを予定できる前にBOFミーティングは関連領域のAreaディレクターによって承認されなければなりません。 本当に新しいWGを必要とすると思うなら、提案でADに非公式に近づいてください、そして、彼らが考えるものを見てください。 次のステップは表面への次の表面ミーティングでミーティングスロットを要求することです。 もちろん、あなたはいくらかの仕事を完了させるそのミーティングを待つ必要はありません、メーリングリストをセットアップして、特許について議論し始めるのなどように。
BOF meetings have a very different tone than 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, while others start from scratch.
BOFミーティングには、非常にWGミーティングと異なったトーンがあります。 BOFの目的は良い重大事件を伴う良い特許を作成できて、規格を作成するのに必要である仕事をしても構わないと思っている人々が十分いるのを確実にすることです。 いくつかのBOFsにはインターネットDraftsが既に過程にありますが、他のものは最初から、始めます。
Harris Informational [Page 21] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[21ページ]のRFC3160タオ
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が形成しなければならない、さもなければ、話題は落とされるべきです。
5. ** New to the IETF? STOP HERE! (Temporarily) **
-----------------------------------------
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.
5. ** IETFに、新しいですか? ここに止まってください! (一時) ** ----------------------------------------- IETFに新しく、これがあなたがミーティングに来る前に読むのを計画している唯一の参照であるなら、ここに少なくとも一時止まってください。 そして、飛行の家の上でタオの残りを読んでください。 その時までには、あなたは活発にミーティングであなたに興味を持たせたWorking Groupsにかかわる準備ができているでしょう、そして、タオは途中であなたを開始させるでしょう。
6. RFCs and Internet Drafts
6. 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 です。(そこでは、あなたがタイトルとキーワードで探すことができます)。
6.1 Getting a Standard Published
6.1 規格を発行させること。
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規格になるドキュメントを書こうとすると決めるなら、総合的な過程が困難であるかもしれないと警告されてください、独特のステップがかなり簡単であっても。 もっとも、多くの人々が過程で無事になります、そして、彼らの自我が多少完全な状態で作者が現れるのを助ける多くの書かれた指導があります。
Harris Informational [Page 22] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[22ページ]のRFC3160タオ
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:
あらゆるIETF規格がRFCとして発行されます、そして、(「コメントを求める要求」、皆だけがそれらをただRFCsと呼びます)あらゆるRFCがインターネットDraft(しばしば"I-D"と呼ばれる)として始めます。 IETFとして発行された何かが標準になるための基本的なステップは以下の通りです。
1. Publish the document as an Internet Draft
2. Receive comments on the draft
3. Edit your draft based on the comments
4. Repeat steps 1 through 3 a few times
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.
6. Make any changes deemed necessary by the IESG (this might
include giving up on becoming a standard)
7. Wait for the document to be published by the RFC Editor
1. インターネットDraft2としてドキュメントを発表してください。 草稿3のコメントを受けてください。 コメント4に基づく草稿を編集してください。 数回5ステップ1〜3を繰り返してください。 草稿をIESGに連れて行くようにAreaディレクターに頼んでください(それが個々の服従であるなら)。 草稿が公式の作業部会製品であるなら、WGいすは分かるADをIESGに招きます。 6. IESGで必要な(これは、規格になるのに見切りをつけるのを含むかもしれない)7であるとあらゆる変化を考えさせてください。 ドキュメントがRFC Editorによって発表されるのを待ってください。
A much more complete explanation of these steps is contained in BCP 9, "The Internet Standards Process." Anyone who writes a draft that they hope will become an IETF standard must read BCP 9 so that they can follow the path of their document through the process. BCP 9 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規格になることを望んでいる草稿を書くだれでも、過程でそれらのドキュメントの経路に続くことができるように、BCP9を読まなければなりません。 BCP9は頻繁に慣れたIETF関係者によってさえ誤解される話題に関して詳細に述べます: RFCsの異なったタイプは、異なった過程に直面していて、異なったランキングを持っています。 6種類のRFCsがあります:
- Proposed standards
- Draft standards
- Internet standards (sometimes called "full standards")
- Experimental protocols
- Informational documents
- Historic standards
- 提案された標準--草稿規格--インターネット標準(時々「完全な規格」と呼ばれる)--実験プロトコル--情報のドキュメント--歴史的な規格
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 RFC 1796, "Not All RFCs are Standards."
最初の唯一の3(提案されて、草稿の、そして、完全な)はIETFの中の規格です。 適切に題をつけられたRFC1796、「どんなAll RFCsもStandardsでないところ」でこの良い概要を見つけることができます。
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 which are introductory or appeal to a broad audience. Frequently, FYIs are created by groups within the IETF User Services Area. 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サブシリーズは紹介しているか、または広い聴衆の好みに合うドキュメント概観と話題に作成されました。 頻繁に、FYIsはIETF User Services Areaの中のグループによって作成されます。 最も良いCurrent Practiceドキュメントはインターネットでの様々な技術の適用について説明します。 STD RFCサブシリーズは、事実上、インターネット標準を指定するRFCsを特定するために作成されました。 いくつかのSTDsが実際に1RFCのセットです、そして、「標準」の名称はドキュメントの全体集合に適用されます。
Harris Informational [Page 23] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[23ページ]のRFC3160タオ
6.2 Letting Go Gracefully
6.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が過程であることが好みにわかるかもしれません。
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が標準化過程の上を進むのに必要です)、第一にそれを標準化過程に置くのは、たぶん誤りでした。
6.3 Internet Drafts
6.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 BCP 9 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はいつでも、どんな正式な状態も持たないで、変化か取り外しを被りやすいです。 どんな紙、レポート、または提案のためのRequestもインターネットDraftに決して、参照をつけるはずがありません、または、インターネットDraftへの業者クレームコンプライアンスはそうするべきです。
Harris Informational [Page 24] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[24ページ]のRFC3160タオ
You can always tell a person who doesn't understand the IETF (or is intentionally trying to fool people) when they brag about having published an Internet Draft; it takes no significant effort.
あなたは、いつも彼らがいつインターネットDraftを発行したことに関してほらをふくかをIETF(故意にだまそうとするのは、人々である)を理解していない人に言うことができます。 それはどんな重要な努力も取りません。
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. RFC 2223, "Instructions to RFC Authors," describes the nroff formatting used by the RFC Editor.
I-Dには、RFCとほとんど同じ形式があるはずです。 多くの人々の信念とは逆に、I-DはちょうどRFCに似る必要はありませんが、あなたがあなたがI-Dsを作成するとRFC Editorによって用いられた同じ形式手順を用いることができると、あなたの草稿がRFCとして発表されるとき、それはRFC Editorの仕事を簡素化するでしょう。 「RFC作者への指示」というRFC2223はRFC Editorによって使用されたnroff形式について説明します。
An Internet Draft can be either a Working Group draft or an individual submission. Working Group drafts are usually reviewed by the chair before being accepted as a WG item.
インターネットDraftは作業部会ドラフトか個々の服従のどちらかであるかもしれません。 WGの品目として認められる前に通常、作業部会ドラフトはいすによって見直されます。
6.3.1 Recommended Reading for Writers
6.3.1 作家にとってのお勧めの読書
Before you create the first draft of your Internet Draft, you should read four documents:
あなたのインターネットDraftの最初の草稿を作成する前に、あなたは4通のドキュメントを読むべきです:
- More important than just explaining formatting, RFC 2223 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.
- ただ形式について説明するより重要です、また、RFC2223は何が、RFCになることができる前にインターネットDraftにある必要であるかを説明します。 このドキュメントがあなたのドキュメントにある必要があるすべてのセクションと通知について説明して、そこに始めからそれらを持っているのが良いので、あなたが後のバージョンに彼らを入れる場合、読者は驚いていません。
- BCP 22, "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.
- 「インターネット規格作家のためのガイド」というBCP22はあなたが相互運用性につながる規格を書くのを助けるチップを提供します。 例えば、それで、仕様の外への振舞いと、どう州のダイヤグラムを見せているかをどう反応させるかというプロトコルオプションの正しい数を選ぶ方法がわかります。
- The online "Guidelines to Authors of Internet Drafts,"
http://www.ietf.org/ietf/1id-guidelines.txt, has up-to-date
information about the process for turning in Internet Drafts, as
well as the most current boilerplate information that has to be
included in each Internet Draft.
- オンライン「インターネット草稿の作者へのガイドライン」( http://www.ietf.org/ietf/1id-guidelines.txt )には、インターネットDraftsを渡すための過程に関する最新情報があります、それぞれのインターネットDraftに含まれなければならない中で最も現在の決まり文句の情報と同様に。
- 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 "Considerations for Internet Drafts,"
http://www.ietf.org/ID-nits.html, a list of common "nits" that
have been known to stop documents in the IESG. In fact, you
should probably read that document well before you are finished,
so that you don't have to make a bunch of last-minute changes.
- あなたが草稿の過程を終えていると思って、草稿がRFCになるよう要求する準備ができているとき、あなたは確実に「インターネット草稿のための問題」を読むべきです、 http://www.ietf.org/ID-nits.html 、IESGのドキュメントを止めるのが知られている一般的な「夜」のリスト。 事実上、終わる前にあなたはたぶん上手にそのドキュメントを読むべきです、あなたが多くの土壇場での変更を作る必要はないように。
Harris Informational [Page 25] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[25ページ]のRFC3160タオ
6.3.2 Filenames and Other Matters
6.3.2 ファイル名と他の件
When you're ready to turn in your Internet Draft, send it to the Internet Drafts editor at internet-drafts@ietf.org. There is a real person at the other end of this mail address -- their 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, the draft editor supplies the 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を渡す準備ができているとき、 internet-drafts@ietf.org のインターネットDraftsエディタにそれを送ってください。 実在の人物がこの郵便の宛先のもう一方の端にいます--彼らの仕事はあなたがインターネット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, the author sometimes follows 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 editor (and, if it is an official WG draft, the WG chair) to come up with the filename.
例えば、キーを作成する周りのS/MIME WGの草稿は「00.txtを合わせる草稿ietf-smime」と命名されるかもしれません。 それが作業部会の製品でないなら、名前は描写的である単語があとに続いた作者のひとりか"00.txt"によって続かれたふたりの「草稿」と姓から始まるでしょう。 例えば、だれかが命名した草稿は「00.txtを合わせる草稿鍛冶屋」と命名されるかもしれませんスミスが、書いた。 草稿が個々の服従ですが、特定のワーキンググループに関連するなら、作者は時々ワーキンググループの名前のそれらの名前に従います、「00.txtを合わせる草稿鍛冶屋smime」などのように。 名前を示すのにおいてあなたを歓迎します。 しかしながら、ファイル名を思いつくのは、インターネットDraftsエディタ(それが公式のWG草稿であることのWGいす)次第です。
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 the first version, such as when a personal effort is pulled into a Working Group.
草稿の初版の後に、ファイル名の数は増加されています。 例えば、上で指定されたS/MIME草稿の第2版は「01.txtを合わせる草稿ietf-smime」でしょう。 ケースがファイル名が個人的な努力が作業部会に引かれる時などの最初のバージョンの後に変化するところにあることに注意してください。
6.4 Standards-Track RFCs
6.4 標準化過程RFCs
The procedure for creating and advancing a standard is described in BCP 9. 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 it 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 can sometimes cause further changes to the draft. It is also a time when people in the WG who
IESGにそれを提出した後に、IESGは最後のIETF全体の呼び出しを発表します。 これは、草稿の進歩の後をつけていなくて、時々草稿への一層の変化を引き起こす場合がある人々の注意を得るのを助けます。 また、いつがWGにだれをもう住ませるべきであるか時間です。
Harris Informational [Page 26] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[26ページ]のRFC3160タオ
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.
それらが聞かれて、彼らのコメントを皆に作ることができるということでなかったと感じてください。 最終が呼ぶ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がインターネットStandardになるように草稿を承認するなら、彼らは、Proposed Standardとしてそれを発行するようにRFC Editorに頼みます。 少なくとも6カ月Proposed Standardになっている後に、RFCの作者(または、適切なWGいす)は、Draft Standardになるように自ら災難を招くことができます。 しかしながら、それが起こる前に、だれかが、少なくとも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 while another implementor thought they meant something else. Another common occurrence is that none of the implementations actually tried to implement a few of the features of the standard; these features get removed not just because no one tested them, but also because they weren't needed.
いくつかのことがここに通常起こります。 まず最初に、規格における仕様のいくつかが、1人の作成者が、別の作成者が、彼らが他の何かを意味したと考えましたが、彼らが1つのものを意味したと考えたので言い換えられる必要であるのがわかるのは一般的です。 別の一般的な発生は実現のどれかが実際に規格の特徴のいくつかを実行しようとしなかったということです。 だれでもそれらをテストしたので取り除くだけではなく、それらはまた必要でもなかったので、これらの特徴を取り除きます。
Don't be surprised if a particular standard doesn't progress from Proposed to Draft. In fact, most of the standards in common use are Proposed Standards and never move forward. This may be because no one took the time to try to get them to Draft, or some of the normative references in the standard are still at Proposed Standard, or it may be that everyone found more important things to do.
特定の規格がProposedからDraftまで進歩をしないなら、驚かないでください。 事実上、共用の規格の大部分は、Proposed Standardsと決して移動フォワードではありません。 これはだれもわざわざそれらをDraftに得ようとしなかったか、規格における引用規格のいくつかがまだProposed Standardにあったか、または皆が多分するより重要なことを見つけたからです。
A few years after a document has been a Draft Standard, it can become an Internet Standard, also known as "full standard." This doesn't happen often, and 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 before making a Draft Standard an Internet Standard.
ドキュメントがDraft Standardになった数年後に、それはまた、「完全な規格」として知られているインターネットStandardになることができます。 これは、しばしば起こるというわけではなくて、通常、インターネットが機能するのに絶対に必要であるプロトコルのために予約されます。 Draft StandardをインターネットStandardにする入念に吟味しながら前に、IESGはドキュメントを調べます。
6.4.1 Telling It Like It Is -- Using MUST and SHOULD and MAY
そして、6.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.
芸術についてあなたが欲しい道を実行される仕様に書くのは、しばらくです。 あなたはまさしく要件のリストで非常に短く仕様を守ることができますが、それは、作成者があまりに多くの余裕を取ることを引き起こす傾向があります。 あなたが代わりに仕様を多くの提案に非常にくどくするなら、作成者は、要件を逃す傾向があります(とにかく提案としばしば意見を異にしてください)。 最適の仕様がどこかで中間であります。
Harris Informational [Page 27] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[27ページ]のRFC3160タオ
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の規格作家は、彼らの言葉遣いをいくつかの特定の意味があるいくつかの特定の単語に制限するのに同意しました。
RFC 1123, "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 BCP 14, "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 lists a few synonyms for the words defined.
RFC1123、「インターネットホストのための要件--、アプリケーションとサポート、」 1989年にずっと返事を書かれて、すなわち、役に立つように見えた単語の短いリスト、“must"、“should"、および“may"を持っていました。 これらの定義をアップデートして、BCP14、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」でさらに洗練しました。(それは、現在のインターネット標準で広く参照をつけられます)。 また、BCP14は明確に単語のためのいくつかの同義語が定義した“must not"、“should not"、およびリストを定義します。
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 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が相互運用性に必要です。 これは規格における指定過ぎて指定している要件の問題の要所に行きます。
6.4.2 Normative References in Standards
6.4.2 規格における引用規格
One aspect of writing IETF standards that trips up many novices (and quite a few long-time IETF folk) 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 is one that is helpful to an implementor but is not needed. As we noted above, a "MUST" specification would certainly be normative, so any reference needed to implement the "MUST" would be normative. A "SHOULD" or "MAY" specification is not necessarily
多くの初心者(そして、かなり多くの長年のIETF人々)を間違えさせるIETFに規格を書く1つの局面がどう非IETFの「引用規格」をドキュメントにするか、または、規格における他のRFCsへの規則です。 引用規格は規格を実行するために従わなければならないドキュメントの参照です。 非引用規格は作成者にとって役立っていますが、必要でないものです。 私たちが上で注意したように、確かに、“MUST"仕様は規範的でしょう、したがって、“MUST"を実行するのに必要であるどんな参照も規範的でしょう。 “SHOULD"か「5月」仕様は必ずそうであるというわけではありません。
Harris Informational [Page 28] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[28ページ]のRFC3160タオ
normative, but it could be normative based on what is being required. There is definitely room for debate here!
規範的であることで、それだけが必要であることに基づいて規範的であるかもしれません。 確実に討論の余地がここにあります!
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の外で開発されたどんな「オープンスタンダード」の引用規格もするかもしれません。 「同程度か、より高い」規則は、また、引用規格があるRFCsのすべてがDraftかインターネットStandardの規格がProposedからDraftまで動くことができる前であるに違いないことを意味します。 この規則はDraft StandardかインターネットStandardのすべてがかなり安定しているという作成者保証を与えます、規格の外で参照をつけられるものさえ。 また、もう片方のドキュメントキャッチが上昇している間、これは何カ月(時々何年もさえ)もDraftかインターネットStandardの公表を遅らせることができます。
There is no hard and fast rule about what is an "open standard," but generally this means a stable standard that anyone can get a copy of (although they might have to pay for it) and that was made by a generally recognized standards group. If the external standard changes, you have to reference the particular instantiation of that standard in your specification, as with a designation of the date of the standard. Some external standards bodies don't make old standards available, which is a problem for IETF standards that need to be used in the future. When in doubt, a draft author should ask the WG chair or appropriate Area Director if a particular external standard can be used in an IETF standard.
一般にこれはだれでもコピーを手に入れることができる安定した規格を意味します、そして、(彼らがそれの代価を払わなければならないかもしれませんが)「オープンスタンダード」であることに関する鉄則が全くありませんでしたが、それは一般に、認識された規格グループによって作られました。 外部の規格が変化するなら、あなたは仕様にその規格の特定の具体化を参照に持っています、規格の日付の名称のように。 いくつかの外部の標準化団体で、古い規格は利用可能になりません(将来使用される必要があるIETF規格のための問題です)。 草稿作者が、IETF規格に特定の外部の規格を使用できるかどうかWGいすか適切なAreaディレクターに疑問で尋ねるべきであるとき。
6.4.3 IANA Considerations
6.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 1.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規格がプロトコルにおけるオプションと命名されるように様々なプロトコルパラメタの登録を必要とします。 私たちが、セクション1.2.4、メインですべてのIETF規格のための登録が長い間IANAであることに注意したので。 規格が必要とする大きくてさまざまの種類の登録のために、IANAはどうパラメタを示すかに関する特殊情報、登録する何やかや、だれが登録されていることになっているべきことについて決めるだろうか、そして、(だれであるならも)などを必要とします。
Anyone writing an Internet standard that may need an IANA registry needs to read BCP 26, "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登録を必要とするかもしれないインターネット標準に書いているだれでも、BCP26、RFC作者が、IANAが始まるか、または登録を占領するようにどう適切に頼むべきであるかを説明する「RFCsにIANA問題部に書くためのガイドライン」を読む必要があります。 また、IANAはBCP26が生産されたずっと前に始められた登録を維持します。
6.4.4 Security Considerations
6.4.4 セキュリティ問題
One thing that's required in every RFC is a "Security Considerations" section. This section should describe any known vulnerabilities of the protocol, possible threats, and mechanisms or strategies to
あらゆるRFCで必要である1つのものが「セキュリティ問題」セクションです。 このセクションはプロトコルか、可能な脅威と、メカニズムか戦略のどんな知られている脆弱性についても説明するべきです。
Harris Informational [Page 29] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[29ページ]のRFC3160タオ
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.
それらを記述してください。 このセクションを言い繕わないでください--特に、「あなたがセキュリティが欲しいなら私たちのプロトコルがここにあって、まさしく使用はIPSECです。」と言わないでください。 これは全くそうしないでしょう、IPSECがどうあなたのプロトコルと対話するかに関する質問に答えないので、逆もまた同様に。 確実に草稿でどのようにこのセクションを扱わないかなら、作業部会いすに必ず問い合わせてください。
6.4.5 Patents in IETF Standards
6.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の目標は規格を広く使用されて、市場で有効にするように持つことです。 それが使用する製品を作成するなら、規格は、特許のために認可を得るのを必要として、人々は規格をより実行しそうにはありません。 そして、当然ながら、一般的な規則は「可能であるところで良い非特許で保護された技術を使用する」ことです。
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. You can read about the official rules in BCP 9, but you should assume that the application of those rules is flexible and depends on the type of patent, the patent holder, and the availability of alternate technologies that are not encumbered by patents.
規格における特許に対処するためのIETFの方法は多くの討論の対象です。 BCP9の公認規則に関して読むことができますが、あなたはそれらの規則の適用をフレキシブルであり、特許のタイプ、特許所有権者、および特許によって妨げられない交互の技術の有用性に頼ると仮定するべきです。
Patent holders who freely allow their patents to be used by people implementing IETF standards often get a great deal of good will 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, send a note to the IETF Secretariat (ietf-secretariat@ietf.org) about the patent or other intellectual property rights. The note will be published on the IETF IPR web page (http://www.ietf.org/ipr.html). Intellectual property rights aren't
インターネットDraftに書いていて、周囲に書いているのを技術に申請される特許を知っているなら、ドキュメントの特許を記載しないでください。 代わりに、特許か他の知的所有権に関してIETF事務局( ietf-secretariat@ietf.org )に手紙を書いてください。 注意はIETF IPRウェブページ( http://www.ietf.org/ipr.html )で発表されるでしょう。 知的所有権はそうではありません。
Harris Informational [Page 30] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[30ページ]のRFC3160タオ
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 a RFC could be incomplete and mislead the reader. BCP 9 provides specific text that should be added to RFCs where the author knows of IPR issues.
RFCsでは、彼らが発行された後にRFCsが決して変化しませんが、IPRに関する知識がいつでも変化できるので、言及されます。 したがって、RFCのIPRリストは、不完全であり、読者をミスリードするかもしれません。 BCP9は作者がIPR問題を知っているRFCsに加えられるべきである特定のテキストを提供します。
6.5 Informational and Experimental RFCs
6.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, Historical, 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つの名称があります: タオのように情報的であって、実験的です。 (Historical、3番目の名称が実際にありますが、それが標準化過程の上にあって、現在の使用の不足のため取り外されたドキュメントのために予約されるか、またはそのより最近の考えは、技術が実際にインターネットに有害であることを示します。)
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. That is, a specification might solve a problem, but if it is not clear 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, 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はそれが標準化過程の材料であるかもしれないように使用されます。(答えられていない質問がそれなしでまだあります)。
7. How to Contribute to the IETF -- What You Can Do
7. どうIETFに貢献するか--あなたができることが
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.
読んでください--専門的技術の領域、およびWorking Groupsの彼らのコメントでインターネットDraftsを見直してください。 好意的で、役立っているやり方で可能な最も良いインターネット標準である目標で議論に参加してください。 話すよりはるかに聴いてください。
Harris Informational [Page 31] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[31ページ]のRFC3160タオ
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つが「走行コードは得られます」であるので、あなたは、より多くの走行コードを作成することによって、より広範囲になるようにあなたが欲しい規格を支持するのを助けることができます。
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について編集するか、または共同執筆してください。 ドキュメントの上に名前(さらにひどくあなたの会社の商号)を得ないようにインターネットコミュニティの利益のためのこれをしてください。 草稿作者はすべての種類の技術的で(時々個人的)の批評を受けることがあります。 平静でそれを受けてください、そして、それを使用して、最も良くて最も共同利用できる規格を生産するために草稿を改良してください。
7.1 What Your Company Can Do
7.1 あなたの会社ができることが
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 them 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規格が栄えるのを助けて、多くの会社が特定の特許のために気前よく無制限なライセンスを提供しました。 通常、これらの会社はそれらが他の特許所有権者ほど貪欲でもなくて、また近視でもないという事実のための積極的な宣伝で報酬を与えられます。
Harris Informational [Page 32] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[32ページ]のRFC3160タオ
Join -- Become a member of ISOC. More importantly, 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の法人会員になるようインターネットの利益を得たあらゆる会社に促してください、これにはグループのための最もすばらしい財政的な利益があるので。 また、それはもちろん全体でインターネットのためになるでしょう。
8. IETF and the Outside World
8. IETFと外の世界
8.1 IETF and Other Standards Groups
8.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 who 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, and the IETF is mostly run by volunteers who would probably prefer to write standards rather than meet with representatives from other bodies. Even so, some other standards bodies make a great effort to interact well with the IETF despite the obvious cultural differences.
一般に、IETFには、他の重要な標準化団体との親密な間柄があろうとします。 これはいつも簡単であるというわけではありません、他の多くのボディーには非常にIETFと異なった構造があって、たぶん他のボディーから代表に会うよりむしろ規格を書くのを好むボランティアがIETFをほとんど走らせるので。 たとえそうだとしても、ある他の標準化団体は明白な文化の相違にもかかわらず、IETFとよく対話するためのかなりの努力をします。
At the time of this writing, the IESG has some liaisons with large standards bodies, including the ITU (International Telecommunication Union), the W3C, the Unicode Consortium, the ATM Forum, and ISO- IEC/JTC1 (The Joint Technical Committee of the International Organization for Standardization and International Electrotechnical Commission). The list of IETF liaisons, www.ietf.org/ietf/1iesg- liaisons.txt, shows that there are many different liaisons to ISO- IEC/JTC1 subcommittees.
この書くこと時点で、IESGには、大きい標準化団体との数人の連絡がいます、ITU(国際電気通信連合)、W3C、ユニコードConsortium、ATM Forum、およびISO IEC/JTC1(国際標準化機構と国際電気標準化会議のJoint Technical Committee)を含んでいて。 IETF連絡のリスト(www.ietf.org/ietf/1iesg liaisons.txt)は、ISO IEC/JTC1小委員会への多くの異なった連絡がいるのを示します。
8.2 Press Coverage of the IETF
8.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仕事までの引用文などがあります。
Harris Informational [Page 33] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[33ページ]のRFC3160タオ
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 reporter would probably get them in contact with someone who could straighten them out, such as a WG chair or an Area Director. The official press contact for the IETF is the IETF Secretariat.
主要なプレス誤りは2つのカテゴリになります: IETFが、作業部会にまさしくインターネットDraftが事実上あるとき、何かを考えて、起こったすべてがInformational RFCが発行されたということであったときに、IETFが何かを承認したと言っていると言います。 どちらの場合も、問題には、プレスは完全に悪いというわけではありません、それらが通常彼らが開発するか、または少なくともサポートするプロトコルのための宣伝を得ようとする会社による話に警告されるので。 もちろん、レポーターによる少しの研究がたぶんそれらをまっすぐにすることができただれかに連絡してそれらを得るでしょう、WGいすやAreaディレクターのように。 IETFに関する公式のプレス接触はIETF事務局です。
The fact that those reporters who've gotten it wrong once 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!). Further, 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
特定の話題に関して「IETFがしていること」を見つけたがっているレポーターは、1人以上のIETFのその話題に関して活発な人と話すために慎重であるだろう、たぶんどのような場合でもWGいすと話そうとするべきです。 何が草稿で草稿を見るか、または草稿の作者と話すことによって起こるかを決定するのは不可能です。 幸い、すべてのWGsには、レポーターが最近の指摘に関して草稿の進歩が何であるかに関して目を通すことができるアーカイブがあります。 残念ながら、わずかなレポーターにはしか、時間かこの種類の研究をする傾向がありません。 IETF
Harris Informational [Page 34] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[34ページ]のRFC3160タオ
doesn't have a press liaison, a magazine or newspaper that runs 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から聞かないその成績を上げないで、したがって、それらが悪く何をしたかをしばしば知るというわけではないので、それらは後で再び容易にそれをするかもしれません。
9. References
9. 参照
9.1 Tao
9.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.
「ダウ船」、タオであると断言されているのは、老子、中国人のマスターに関する教えの後ろの基本原理です。 身近なシンボルは白黒の殷-陽の円です。 道教は単一の有機体としての宇宙、および宇宙全体の互いに依存している部品としての人間を発想します。 タオによる時々翻訳されて、単語で「道」、道教信奉者の哲学に従ったしかし、単語の本当の意味を言い表すことができないということです。
9.2 Useful E-mail Addresses
9.2 役に立つEメールアドレス
agenda@ietf.org Requests for agenda slots at IETF
meetings
ietf-info@ietf.org General questions about the IETF
ietf-registrar@ietf.org Questions about registration, meeting
locations, and fees
ietf-request@ietf.org Requests to join/leave IETF lists
ietf-secretariat@ietf.org Questions for the Secretariat
ietf-web@ietf.org Web questions/comments
internet-drafts@ietf.org Internet Draft submissions and queries
minutes@ietf.org Where to send Working Group minutes
proceedings@ietf.org IETF Proceedings Coordinator
iana@iana.org Internet Assigned Numbers Authority
rfc-ed@rfc-editor.org RFC Editor
agenda@ietf.org は、議題のために事務局 ietf-web@ietf のためにIETFリストを ietf-secretariat@ietf.org Questionsに接合するか、または出るようIETFミーティングのIETF ietf-registrar@ietf.org Questionsに関する ietf-info@ietf.org の一般質問、登録に関してミーティング位置、および料金 ietf-request@ietf.org Requestsのスロットに要求します; orgウェブは、 internet-drafts@ietf.org インターネットDraft差出について質問するか、または論評して、作業部会数分 proceedings@ietf.org IETF Proceedings Coordinator iana@iana.org インターネットAssigned民数記Authority rfc-ed@rfc-editor.org RFC Editorを送るために minutes@ietf.org Whereについて質問します。
9.3 Useful Documents and Files
9.3 役に立つドキュメントとファイル
The IETF web site, http://www.ietf.org, is the best source for information about meetings, Working Groups, Internet Drafts, RFCs, IETF e-mail 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:
IETFウェブサイト( http://www.ietf.org )はミーティング、Working Groups、インターネットDrafts、RFCs、IETF Eメールアドレス、およびはるかに多くの情報のための最も良いソースです。 「追加情報」をクリックして、さまざまな役立っているリンクを見つけてください。 また、インターネットDraftsと他のドキュメントも世界中の公開FTPサイトの"ietf"ディレクトリで利用可能です。 これらのサイトのリストに関しては、見てください:
http://www.ietf.org/shadow.html
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現状報告と同様に。
Harris Informational [Page 35] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[35ページ]のRFC3160タオ
9.4 Acronyms and Abbreviations Used in the Tao
9.4 タオで使用される頭文字語と略語
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
IANA Internet Assigned Numbers Authority
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/
IRTF Internet Research Task Force, http://www.irtf.org/
ISO International Organization for Standardization,
http://www.iso.ch/
ISO-IEC/JTC1
Joint Technical Committee of the International
Organization for Standardization and International
Electrotechnical Commission, http://www.jtc1.org/
ISOC Internet Society, http://www.isoc.org
ITU International Telecommunication Union, http://www.itu.int
RFC Request For Comments
STD Standard (RFC)
W3C World Wide Web Consortium, http://www.w3.org/
WG Working Group
ADの最も良い現在の習慣転炉同じ羽毛の鳥領域ディレクターBCP FAQは頻繁にあなたの情報(RFC)IABインターネット・アーキテクチャ委員会IANAインターネット規定番号権威ICANNアイキャンを質問FYIに求めました、 http://www.icann.org/ I-Dインターネット草稿IESGインターネット工学運営グループ、 http://www.ietf.org/iesg.html IETFインターネット・エンジニアリング・タスク・フォース、 http://www.ietf.org/ INETインターネット協会コンファレンス、 http://www.isoc 国際標準化機構と国際電気標準化会議のorg/isoc/会議/inet/IRTFインターネットResearch Task Force、 http://www.irtf.org/ ISO国際標準化機構 http://www.iso.ch/ ISO-IEC/JTC1 Joint Technical Committee( http://www ); jtc1.org/ ISOCインターネット協会、 http://www.isoc.org ITU国際電気通信連合、 http://www.itu.int RFC Request For Comments STD Standard(RFC)W3Cワールドワイドウェブコンソーシアム、 http://www.w3.org/ WG作業部会
9.5 Documents Cited in the Tao
9.5 タオで引用されたドキュメント
BCP 9 "The Internet Standards Process"
BCP 10 "IAB and IESG Selection, Confirmation, and Recall Process:
Operation of the Nominating and Recall Committees"
BCP 11 "The Organizations Involved in the IETF Standards Process"
BCP 14 "Key words for use in RFCs to Indicate Requirement Levels"
BCP 22 "Guide for Internet Standards Writers"
BCP 25 "IETF Working Group Guidelines and Procedures"
BCP 26 "Guidelines for Writing an IANA Considerations Section
in RFCs"
RFC 1123 "Requirements for Internet Hosts -- Application and
Support"
RFC 1796 "Not All RFCs are Standards"
RFC 2223 "Instructions to RFC Authors"
インターネット規格は」 BCP10を処理します。BCP9、「「IAB、IESG選択、確認、およびリコールは以下を処理します」。 「NominatingとRecall Committeesの操作」BCP11「IETF標準化過程にかかわる組織」BCP14「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」BCP22がBCP25「IETFワーキンググループガイドラインと手順」BCP26「RFCsにIANA問題部に書くためのガイドライン」RFC1123を「インターネット規格作家のために、誘導する」、「「RFCへの指示は書く」RFC1796「どんなAll RFCsもStandardsではありません」RFCアプリケーションとサポート」2223インターネットホストのための要件--
Harris Informational [Page 36] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[36ページ]のRFC3160タオ
"Considerations for Internet Drafts,"
http://www.ietf.org/ID-nits.html
「インターネット草稿のための問題」、 http://www.ietf.org/ID-nits.html
"Guidelines to Authors of Internet-Drafts,"
ftp://ftp.ietf.org/ietf/1id-guidelines.txt
「インターネット草稿の作者へのガイドライン」、 ftp://ftp.ietf.org/ietf/1id-guidelines.txt
Security Considerations
セキュリティ問題
Section 6.4.5 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.
セクション6.4 .5 各RFCがなぜSecurity Considerations部を持つのが必要であり、それが何は含んでいて、含むべきでないかに関する何らかの考えを与えるかを説明します。 その情報以外に、このドキュメントはインターネットセキュリティに触れません。
Editor's Address
エディタのアドレス
Susan Harris Merit Network, Inc. 4251 Plymouth Road, Suite 2000 Ann Arbor, MI 48105
スーザンハリス長所ネットワークInc.4251プリマス道路、アナーバー、スイート2000MI 48105
EMail: srh@merit.edu
メール: srh@merit.edu
Harris Informational [Page 37] RFC 3160 The Tao of IETF August 2001
IETF2001年8月のハリス・情報[37ページ]のRFC3160タオ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Harris Informational [Page 38]
ハリスInformationalです。[38ページ]
一覧
スポンサーリンク
