[要約] RFC 7241は、IEEE 802とIETFの関係についての要約です。その目的は、両組織の協力関係を強化し、標準化プロセスを改善することです。
Internet Architecture Board (IAB) S. Dawkins
Request for Comments: 7241 Huawei
Obsoletes: 4441 P. Thaler
Category: Informational Broadcom
ISSN: 2070-1721 D. Romascanu
AVAYA
B. Aboba, Ed.
Microsoft Corporation
July 2014
The IEEE 802/IETF Relationship
IEEE 802 / IETF関係
Abstract
概要
This document describes the standardization cooperation between Project 802 of the Institute of Electrical and Electronics Engineers (IEEE) and the Internet Engineering Task Force (IETF). This document obsoletes RFC 4441.
このドキュメントでは、米国電気電子学会（IEEE）のプロジェクト802とインターネット技術特別調査委員会（IETF）の間の標準化協力について説明します。このドキュメントはRFC 4441を廃止します。
Note: This document was collaboratively developed by authors from both the IEEE 802 and IETF leadership and was reviewed and approved by the IEEE 802 Executive Committee prior to publication.
注：このドキュメントは、IEEE 802とIETFの両方の指導者の共同作成者であり、発行前にIEEE 802実行委員会によってレビューおよび承認されました。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7241.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7241で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Why Cooperate? .............................................4
2. Organization, Participation, and Membership .....................4
2.1. IEEE 802 ...................................................5
2.2. IETF .......................................................7
2.3. Structural Differences .....................................8
2.4. Cultural Differences .......................................9
2.5. Mailing Lists .............................................11
3. Document Access and Cross-Referencing ..........................12
3.1. Access to IETF Documents ..................................12
3.2. Access to IEEE 802 Standards ..............................12
3.3. Access to IEEE 802 Working Group Drafts ...................12
3.4. Cross-Referencing .........................................15
4. Guidance on Cooperation ........................................16
4.1. Exchange of Information about Work Items ..................16
4.2. Document Review and Approval ..............................20
4.3. Solicited Review Processes ................................23
5. Liaison Managers and Liaison Statements ........................23
5.1. Liaison Managers ..........................................24
5.2. Liaison Statements ........................................24
6. Protocol Parameter Allocation ..................................24
6.1. IANA ......................................................24
6.2. IEEE Registration Authority ...............................25
6.3. IEEE 802 Registration at the Working Group Level ..........26
6.4. Joint-Use Registries ......................................26
7. Security Considerations ........................................26
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................26
9. Acknowledgments ................................................30
10. IAB Members at the Time of Approval ...........................31
11. IEEE 802 Executive Committee Members at the Time of Approval ..31
Appendix A. Current Examples of IEEE 802 and IETF Cooperation ....32
A.1. MIB Review .................................................32
A.2. AAA Review .................................................32
A.3 EAP Review .................................................33
Appendix B. Pointers to Additional Information ...................34
B.1. IEEE 802 Information .......................................34
B.2. IETF Information ...........................................34
This document contains a set of principles and guidelines that serve as the basis for coordination between Project 802 of the Institute of Electrical and Electronics Engineers (IEEE 802) and the Internet Engineering Task Force (IETF), a program under the Internet Society (ISOC) organizational umbrella [BCP101]. The objective is to encourage timely development of technical specifications that facilitate maximum interoperability with existing (fixed and mobile) Internet systems, devices, and protocols. Each organization will operate according to their own rules and procedures including rules governing IPR policy, specification elaboration, approval, and maintenance.
このドキュメントには、米国電気電子学会（IEEE 802）のプロジェクト802と、インターネットソサエティ（ISOC）のプログラムであるインターネットエンジニアリングタスクフォース（IETF）の間の調整の基礎となる一連の原則とガイドラインが含まれています。組織の傘[BCP101]。目的は、既存の（固定およびモバイル）インターネットシステム、デバイス、およびプロトコルとの最大の相互運用性を促進する技術仕様のタイムリーな開発を促進することです。各組織は、IPRポリシー、仕様の詳細、承認、および保守を管理するルールを含む独自のルールと手順に従って運用します。
While this document is intended to improve cooperation between the two organizations, it does not change any of the formal practices or procedures of either organization.
この文書は2つの組織間の協力関係を改善することを目的としていますが、どちらの組織の正式な慣行や手順も変更するものではありません。
IEEE 802 and the IETF are independent standards organizations that each use standards produced by the other organization and develop standards dependent on those produced by the other organization. This dependency may extend to carrying attributes in protocols that reflect technologies defined by the other organization.
IEEE 802とIETFは、それぞれが他の組織が作成した標準を使用し、他の組織が作成した標準に依存する標準を開発する独立した標準組織です。この依存関係は、他の組織によって定義されたテクノロジーを反映するプロトコルで属性を運ぶことにまで及ぶかもしれません。
The dependencies between IEEE 802 and IETF standards are a motivation for cooperation between the organizations. However, since the benefits of cooperation come at the cost of coordination overhead, the benefits of coordination must outweigh the cost.
IEEE 802とIETF標準間の依存関係は、組織間の協力の動機です。ただし、協力の利点は調整のオーバーヘッドを犠牲にするため、調整の利点はコストを上回る必要があります。
The IETF benefits from coordination by obtaining improved access to IEEE 802 expertise in the widely deployed and widely used IEEE 802 Local Area Network architecture [ARCH802].
IETFは、広く展開され、広く使用されているIEEE 802ローカルエリアネットワークアーキテクチャ[ARCH802]におけるIEEE 802の専門知識へのアクセスを改善することにより、調整からメリットを得ます。
IEEE 802 benefits from coordination by obtaining improved access to IETF expertise on IP datagram encapsulation, routing, transport, and security, as well as specific applications of interest to IEEE 802.
IEEE 802は、IPデータグラムのカプセル化、ルーティング、トランスポート、セキュリティ、およびIEEE 802に関連する特定のアプリケーションに関するIETFの専門知識へのアクセスを改善することにより、調整からメリットを得ます。
IEEE 802 and IETF are similar in some ways but different in others. When working on projects of interest to both organizations, it is important to understand the similarities and differences.
IEEE 802とIETFはいくつかの点で似ていますが、他の点では異なります。両方の組織にとって関心のあるプロジェクトに取り組む場合、類似点と相違点を理解することが重要です。
The IEEE Standards Association (IEEE-SA) is the standards-setting body of the IEEE. The IEEE-SA Standards Board oversees the IEEE standards development process.
IEEE Standards Association（IEEE-SA）は、IEEEの標準設定機関です。 IEEE-SA標準委員会は、IEEE標準の開発プロセスを監督します。
The IEEE-SA Standards Board supervises what IEEE calls "sponsors" -- IEEE entities that develop standards. The IEEE 802 LAN/MAN Standards Committee is a sponsor that develops and maintains networking standards and recommended practices for local, metropolitan, and other area networks, using an open and accredited process, while advocating for them on a global basis. Areas of standardization work include Ethernet, Bridging and Virtual Bridged LANs, Wireless LAN (Local Area Network), Wireless PAN (Personal Area Network), Wireless MAN (Metropolitan Area Network), Wireless Coexistence, Media Independent Handover Services, and Wireless RAN (Regional Access Network). Within IEEE 802, a Working Group provides the focus for each of these areas.
IEEE-SA規格委員会は、IEEEが「スポンサー」と呼ぶもの、つまり規格を開発するIEEEエンティティを監督します。 IEEE 802 LAN / MAN標準委員会は、オープンで認定されたプロセスを使用して、ローカル、メトロポリタン、およびその他のエリアネットワークのネットワーキング標準と推奨プラクティスを開発および維持し、グローバルベースで提唱するスポンサーです。標準化作業の領域には、イーサネット、ブリッジングおよび仮想ブリッジLAN、ワイヤレスLAN（ローカルエリアネットワーク）、ワイヤレスPAN（パーソナルエリアネットワーク）、ワイヤレスMAN（メトロポリタンエリアネットワーク）、ワイヤレス共存、メディア独立型ハンドオーバーサービス、およびワイヤレスRAN（地域アクセスネットワーク）。 IEEE 802内では、ワーキンググループがこれらの各領域に焦点を当てています。
In IEEE 802, work is done in Working Groups operating under an Executive Committee. Each Working Group is led by a Working Group Chair. Most Working Groups have one or more Task Groups. A Task Group is responsible for a project or group of projects.
IEEE 802では、作業は執行委員会の下で運営されているワーキンググループで行われます。各ワーキンググループは、ワーキンググループチェアが主導します。ほとんどのワーキンググループには1つ以上のタスクグループがあります。タスクグループは、プロジェクトまたはプロジェクトのグループを担当します。
The Executive Committee is comprised of the Executive Committee Chair, Executive Committee Officers (e.g., Vice-Chairs, Secretaries, Treasurer), and Working Group Chairs.
執行委員会は、執行委員会の議長、執行委員会の役員（副議長、秘書、会計など）、およびワーキンググループの議長で構成されます。
A good place to learn more is the IEEE 802 Home Page, at <http://www.ieee802.org/>. An IEEE 802 Orientation for new participants that gives an overview of IEEE 802 process is available from the home page.
詳細については、<http://www.ieee802.org/>にあるIEEE 802ホームページを参照してください。 IEEE 802プロセスの概要を説明する新規参加者向けのIEEE 802オリエンテーションは、ホームページから入手できます。
The IEEE 802 Executive Committee and all Working Groups meet three times per year at plenary sessions. Plenary sessions are held in March, July, and November. Most Working Groups hold interim meetings, usually in January, May, and September. The meeting schedule can be found at <http://www.ieee802.org/meeting/index.html>.
IEEE 802実行委員会とすべてのワーキンググループは、年次総会で3回開催されます。本会議は3月、7月、11月に開催されます。ほとんどのワーキンググループは、通常1月、5月、9月に中間会議を開催します。会議のスケジュールは、<http://www.ieee802.org/meeting/index.html>にあります。
A Study Group is a group formed to consider starting a new project and, if new work is found to be suitable, to develop an IEEE Project Authorization Request (PAR), similar in purpose to an IETF Working Group charter. A Study Group may operate under a Working Group or under the Executive Committee depending on whether the new work under consideration falls within the scope of an existing Working Group. Study Groups are expected to exist for a limited time, usually for one or two plenary cycles, and must be authorized to continue at each plenary if they have not completed their work.
研究グループは、新しいプロジェクトの開始を検討するために形成されたグループであり、新しい作業が適切であると判明した場合は、IETFワーキンググループの憲章と同様の目的で、IEEEプロジェクト承認リクエスト（PAR）を開発します。検討中の新しい作業が既存の作業部会の範囲に含まれるかどうかに応じて、研究会は作業部会または執行委員会の下で運営されます。研究会は、限られた期間、通常は1〜2回のプレナリーサイクルで存在することが期待されており、作業が完了していない場合は、各プレナリーで継続することを承認する必要があります。
Participation in IEEE 802 Working Groups is at the level of individuals -- participants are human beings and not companies. While participation is open, individuals are required to declare their affiliation (i.e., any individual or entity that financially or materially supports the individual's participation in IEEE 802).
IEEE 802ワーキンググループへの参加は個人レベルです。参加者は人間であり、企業ではありません。参加はオープンですが、個人は所属を宣言する必要があります（IEEE 802への個人の参加を経済的または実質的にサポートする個人またはエンティティ）。
Working Groups maintain membership rosters, with voting membership attained on the basis of in-person meeting attendance. Retention of voting membership generally requires continued attendance and responsiveness to letter ballots. Voting membership allows one to vote on motions and on Working Group Ballots of drafts. All drafts are also balloted by a Sponsor ballot pool before approval as standards. Joining a Sponsor ballot pool does not require participation in meetings. It is not necessary to be eligible to vote in order to comment on drafts, and the Working Group is required to consider and respond to all comments submitted during Working Group and Sponsor ballots.
ワーキンググループは、メンバー名簿を維持し、直接の会議出席に基づいて投票メンバーシップを取得します。投票権の保持には、通常、出席と手紙投票への対応が必要です。メンバーシップの投票により、草案の動議と作業部会の投票に投票することができます。すべてのドラフトは、標準として承認される前に、スポンサー投票プールによって投票されます。スポンサー投票プールに参加するには、会議に参加する必要はありません。草案にコメントするために投票する資格がある必要はありません、そして、ワーキンググループはワーキンググループとスポンサー投票中に提出されたすべてのコメントを考慮してそれに応答する必要があります。
To foster ongoing communication between IEEE 802 and IETF, it is important to identify and establish contact points within each organization. IEEE 802 contact points may include:
IEEE 802とIETFの間の継続的な通信を促進するには、各組織内の連絡先を特定して確立することが重要です。 IEEE 802の連絡先には次のものがあります。
IEEE 802 Working Group Chair: An IEEE 802 Working Group chair is an individual who is assigned to lead the work of IEEE 802 in a particular area. IEEE 802 Working Group chairs are elected by the Working Group and confirmed by the Executive Committee for a two-year term. The Working Group Chair provides a stable contact point for cooperation between the two organizations for a given topic.
IEEE 802ワーキンググループチェア：IEEE 802ワーキンググループチェアは、特定の分野でIEEE 802の作業を主導するよう割り当てられた個人です。 IEEE 802ワーキンググループの議長は、ワーキンググループによって選出され、2年間の執行委員会によって承認されます。ワーキンググループチェアは、特定のトピックに関する2つの組織間の協力のための安定した連絡窓口を提供します。
IEEE 802 Task Group (or Task Force) Chair: An IEEE 802 Task Group chair is an individual who is assigned to lead the work on a specific project or group of projects within a Working Group. The Task Group Chair often serves for the duration of a project. The Task Group Chair provides a stable contact point for cooperation between the two organizations on a particular project.
IEEE 802タスクグループ（またはタスクフォース）の議長：IEEE 802タスクグループの議長は、特定のプロジェクトまたはワーキンググループ内のプロジェクトグループでの作業を主導するために割り当てられた個人です。タスクグループの議長は、多くの場合、プロジェクトの期間中務めます。タスクグループの議長は、特定のプロジェクトに関する2つの組織間の協力のための安定した連絡窓口を提供します。
IEEE 802 Study Group Chair: An IEEE 802 Study Group Chair is an individual assigned to lead consideration of new work and development of an IEEE 802 Project Authorization Request (PAR). The Study Group chair provides a stable contact point for cooperation between the two organizations on a study group topic.
IEEE 802スタディグループチェア：IEEE 802スタディグループチェアは、IEEE 802プロジェクト承認リクエスト（PAR）の新しい作業と開発の検討を主導するために割り当てられた個人です。研究グループの議長は、研究グループのトピックに関する2つの組織間の協力のための安定した連絡窓口を提供します。
IEEE 802 Liaisons: It may be beneficial to establish liaisons as additional contact points for specific topics of mutual interest. These contact points should be established early in the work effort. The IEEE 802 and IETF projects may select the same individual as their contact point, but this is not required, so that two individuals each serve as contact points for one project participating in the liaison relationship.
IEEE 802リエゾン：相互に関心のある特定のトピックの追加の連絡先としてリエゾンを確立することは有益かもしれません。これらの窓口は、作業の早い段階で設定する必要があります。 IEEE 802およびIETFプロジェクトは、連絡先として同じ個人を選択する場合がありますが、これは必須ではないため、連絡関係に参加する1つのプロジェクトの連絡先として2人がそれぞれ機能します。
Informal Contact points: Other informal contacts can provide useful cooperation points. These include Project Editors who are responsible for editing the drafts and work with the Task Group Chairs to lead tracking and resolution of issues. Joint members who are active in both the IEEE 802 and IETF projects in an area can also aid in cooperation.
非公式の連絡先：他の非公式の連絡先は、有用な協力ポイントを提供できます。これらには、下書きの編集を担当し、タスクグループの議長と協力して問題の追跡と解決を主導するプロジェクト編集者が含まれます。ある地域のIEEE 802プロジェクトとIETFプロジェクトの両方で活動している合同メンバーも、協力を支援できます。
The IETF Standards Process is defined in [BCP9]. [BCP11] is a helpful description of organizations involved in the IETF standards process. It can still be useful as an overview, although details have changed since 1996.
IETF標準プロセスは[BCP9]で定義されています。 [BCP11]は、IETF標準プロセスに関与する組織についての役立つ説明です。詳細は1996年以降変更されていますが、それでも概要としては役立ちます。
In the IETF, work is done in Working Groups (WGs) and is mostly carried out through open, public mailing lists rather than face-to-face meetings. The IETF Working Group process is defined in [BCP25].
IETFでは、作業はワーキンググループ（WG）で行われ、ほとんどの場合、面談ではなく公開された公開メーリングリストを通じて行われます。 IETFワーキンググループプロセスは、[BCP25]で定義されています。
WGs are organized into areas, and each area is managed by one or more Area Directors. Collectively, the Area Directors constitute the Internet Engineering Steering Group (IESG) [RFC3710].
WGはエリアに編成され、各エリアは1人以上のエリアディレクターによって管理されます。総括して、エリアディレクターはインターネットエンジニアリングステアリンググループ（IESG）[RFC3710]を構成します。
To foster ongoing communication between IEEE 802 and IETF, it is important to identify and establish contact points within each organization. IETF contact points may include Area Directors, Working Group chairs, and other points of contact who can help communicate between IEEE 802 and IETF Working Groups.
IEEE 802とIETFの間の継続的な通信を促進するには、各組織内の連絡先を特定して確立することが重要です。 IETFの連絡先には、エリアディレクター、ワーキンググループの議長、およびIEEE 802とIETFワーキンググループ間の通信を支援できるその他の連絡先が含まれる場合があります。
The Internet Architecture Board (IAB) charter [BCP39] assigns the IAB several responsibilities relevant to this document:
インターネットアーキテクチャボード（IAB）憲章[BCP39]は、IABにこのドキュメントに関連するいくつかの責任を割り当てています。
1. IESG Appointment Confirmation [BCP10] 2. Architectural Oversight 3. Standards Process Oversight and Appeal 4. Appointment of the RFC Series Editor [RFC6635] and Independent Submission Editor [RFC6548] 5. Appointment of the Internet Assigned Number Authority (IANA) operator [RFC6220] 6. Oversight of External Liaisons for the IETF [BCP102]
1. IESGアポイントメントの確認[BCP10] 2.アーキテクチャの監視3.標準プロセスの監視とアピール4. RFCシリーズエディタ[RFC6635]と独立サブミッションエディタ[RFC6548]のアポイント5.インターネット割り当て番号認証局（IANA）オペレータ[RFC6220]のアポイント] 6. IETFの外部連絡の監視[BCP102]
IESG and IAB members are selected using the NomCom process defined in [BCP10]. Working Group chairs serve at the pleasure of their Area Directors, as described in [BCP25].
IESGおよびIABメンバーは、[BCP10]で定義されたNomComプロセスを使用して選択されます。ワーキンググループの議長は、[BCP25]で説明されているように、エリアディレクターが喜んで務めます。
The IETF is designed to be a "bottom-up" protocol engineering organization -- the leadership steers and manages but does not direct work in a top-down way. Technical agreements with "the IETF" are based on the consensus of Working Group participants, rather than negotiated with IETF leadership.
IETFは、「ボトムアップ」のプロトコルエンジニアリング組織になるように設計されています。リーダーシップは、トップダウン方式で作業を誘導および管理しますが、直接的な作業は行いません。 「IETF」との技術的合意は、IETFリーダーシップとの交渉ではなく、ワーキンググループ参加者のコンセンサスに基づいています。
IETF meets in plenary sessions three times per year. Some Working Groups schedule additional interim meetings, which may be either face-to-face or "virtual". Information about IETF meetings is available at <http://www.ietf.org/meeting/upcoming.html>. Information about IETF Working Group interim meetings is available on <http://www.ietf.org/meeting/interim-meetings.html>.
IETFは、年に3回、全体会議で会合します。一部のワーキンググループは、追加の中間会議をスケジュールします。これは、対面または「仮想」のいずれかです。 IETFミーティングに関する情報は、<http://www.ietf.org/meeting/upcoming.html>で入手できます。 IETFワーキンググループの中間会議に関する情報は、<http://www.ietf.org/meeting/interim-meetings.html>で入手できます。
The preferred way to develop specifications is to do work on mailing lists, reserving face-to-face sessions for topics that have not been resolved through previous mailing list discussion.
仕様を開発するための推奨される方法は、メーリングリストで作業を行い、以前のメーリングリストのディスカッションでは解決されなかったトピックの対面セッションを予約することです。
Participation in the IETF is open to anyone (technically, anyone with access to email sufficient to allow subscription to one or more IETF mailing lists). All IETF participants act as individuals. There is no concept of "IETF membership".
IETFへの参加は誰にでも開かれています（技術的には、1つ以上のIETFメーリングリストへのサブスクリプションを許可するのに十分な電子メールへのアクセス権を持つ誰でも）。すべてのIETF参加者は個人として行動します。 「IETF会員」という概念はありません。
A good place to learn more is the IETF Home Page, at <http://www.ietf.org/>, and especially the "About the IETF" page at <http://www.ietf.org/about>, selectable from the IETF Home Page.
詳細については、<http://www.ietf.org/>のIETFホームページ、特に<http://www.ietf.org/about>の「IETFについて」ページを参照してください。 IETFホームページから選択できます。
The "Tao of the IETF" is also very helpful, especially for IEEE 802 participants who will also be participating in IETF Working Groups and attending IETF meetings. It is available at <http://www.ietf.org/tao.html>.
「IETFのタオ」も非常に役立ちます。IETFワーキンググループにも参加し、IETFミーティングに参加するIEEE 802の参加者には特に役立ちます。 <http://www.ietf.org/tao.html>から入手できます。
The current list of IETF Area Directors and Working Group chairs can be found in the IETF Working Group charters, at <http://datatracker.ietf.org/wg/>.
IETFエリアディレクターおよびワーキンググループチェアの現在のリストは、IETFワーキンググループチャーター（<http://datatracker.ietf.org/wg/>）にあります。
IEEE 802 and IETF have similar structures, but the terms they use are different, and even conflicting. For example, both IEEE 802 and IETF use the term "Working Group", but this means very different things in the two organizations.
IEEE 802とIETFは類似した構造を持っていますが、それらが使用する用語は異なり、さらには矛盾します。たとえば、IEEE 802とIETFの両方で「ワーキンググループ」という用語を使用していますが、これは2つの組織で非常に異なることを意味します。
Thumbnail comparison between IETF and IEEE 802 entities
IETFとIEEE 802エンティティのサムネイル比較
IETF Area is similar to IEEE 802 Working Group IETF Working Group is similar to IEEE 802 Task Group IETF BOF is similar to IEEE 802 Study Group
IETFエリアはIEEE 802ワーキンググループに類似していますIETFワーキンググループはIEEE 802タスクグループに類似していますIETF BOFはIEEE 802スタディグループに類似しています
Both IEEE 802 Working Groups and IETF Areas are large, long-lived, and relatively broadly scoped, containing more narrowly chartered entities (IEEE 802 Task Groups and IETF Working Groups), which tend to be short-lived and narrowly chartered. IEEE 802 uses Study Groups to develop proposals for new work, and these are analogous to IETF Birds of a Feather ("BOF") sessions.
IEEE 802ワーキンググループとIETFエリアはどちらも大きく、存続期間が長く、範囲が比較的広く、チャーターされたエンティティ（IEEE 802タスクグループとIETFワーキンググループ）が含まれており、存続期間が短くチャーターされる傾向があります。 IEEE 802はスタディグループを使用して新しい作業の提案を作成します。これはIETF Birds of a Feather（ "BOF"）セッションに類似しています。
Several IETF Areas also have one or more directorates to support the work of the Area Directors. Area Directors often ask directorate members to review documents or provide input on technical questions. These directorates are often a source of expertise on specific topics. The list of Area Directorates is at <http://www.ietf.org/iesg/directorate.html>. IEEE 802 does not have a corresponding organizational entity.
いくつかのIETFエリアには、エリアディレクターの作業をサポートする1つ以上のディレクターもいます。エリアディレクターは多くの場合、ドキュメントを確認するか、技術的な質問についての情報を提供するようにディレクターメンバーに依頼します。多くの場合、これらの局は特定のトピックに関する専門知識の源です。エリア総局のリストは、<http://www.ietf.org/iesg/directorate.html>にあります。 IEEE 802には、対応する組織エンティティはありません。
IEEE 802 and IETF have cultures that are similar but not identical. Some of the differences include:
IEEE 802とIETFには、似ているが同一ではない文化があります。いくつかの違いは次のとおりです。
Consensus and Rough Consensus: Both organizations make decisions based on consensus, but in the IETF, "consensus" can mean "rough consensus, as determined by Working Group chairs". In practice, this means that a large part of the community being asked needs to agree. Not everyone has to agree, but if someone disagrees, they need to convince other people of their point of view. If they're not able to do that, they'll be "in the rough" when "rough consensus" is declared. Although IEEE Working Groups ultimately rely on voting for decision-making, they vary widely in their use of consensus versus voting in the course of a meeting and in their attention to Robert's Rules [RONR].
コンセンサスと大まかなコンセンサス：どちらの組織もコンセンサスに基づいて決定を下しますが、IETFでは、「コンセンサス」は「ワーキンググループの議長が決定した大まかなコンセンサス」を意味する場合があります。実際には、これは、質問されているコミュニティの大部分が同意する必要があることを意味します。誰もが同意する必要はありませんが、誰かが同意しない場合、彼らは他の人々に自分の視点を説得する必要があります。それができない場合は、「大まかなコンセンサス」が宣言されたときに「大まかに」なります。 IEEEワーキンググループは最終的には意思決定のための投票に依存していますが、コンセンサスの使用と会議の進行中の投票、およびロバートの規則[RONR]への注意は大きく異なります。
Running Code: David Clark coined the phrase "We reject kings, presidents and voting. We believe in rough consensus and running code" in 1992, to explain IETF culture. Although that's not always true today, the existence of "running code" as a proof of feasibility for a proposal often carries weight during technical discussions. IEEE 802 considers both technical and economic feasibility when deciding whether to approve new work, as noted in Section 4.1.7.
実行コード：David Clarkは、IETFの文化を説明するために、1992年に「王、大統領、投票を拒否します。大まかなコンセンサスと実行コードを信じています」という語句を作り出しました。今日は常にそうであるとは限りませんが、提案の実現可能性の証明としての「実行中のコード」の存在は、技術的な議論の中で重要な役割を果たすことがよくあります。セクション4.1.7に記載されているように、IEEE 802は、新しい作業を承認するかどうかを決定するときに、技術的および経済的実現可能性の両方を考慮します。
Decision-making: IEEE 802 Working Groups vary in their reliance upon voting versus consensus, and in the breadth of coverage of an individual motion, but ultimately, all rely upon a 75 percent vote to decide technical issues, and a 50 percent +1 vote to decide other issues. IETF Working Groups do not use voting. Working Group chairs may ask for a "show of hands" or "take a hum" to judge backing for a proposal and identify technical concerns and objections, but this is not considered "voting". IETF consensus and humming is discussed further in [RFC7282].
意思決定：IEEE 802ワーキンググループは、投票とコンセンサスへの依存度、および個々の申立ての対象範囲が異なりますが、最終的にはすべて、技術的な問題を決定するために75％の投票と50％+1の投票に依存しています他の問題を決定します。 IETFワーキンググループは投票を使用しません。ワーキンググループの議長は、提案の裏付けを判断し、技術的な懸念や異議を特定するために、「手を見せて」または「口論して」要求する場合がありますが、これは「投票」とは見なされません。 IETFのコンセンサスとハミングについては、[RFC7282]でさらに説明されています。
Balance between mailing lists and meetings: Both organizations make use of mailing lists. IETF Working Groups rely heavily on mailing lists, where work is done, in addition to formal meetings. The IETF requires all Working Group decisions to be made (or, often in practice, confirmed) on mailing lists -- final decisions aren't made in meetings. IEEE 802 Working Groups typically meet face-to-face about twice as often as IETF Working Groups (three IEEE 802 plenaries plus three IETF 802 interim meetings each year, compared to three IETF plenaries per year), and teleconferences are more common in IEEE 802 than in most IETF Working Groups. Most major decisions in IEEE 802 are made during plenary or interim meetings, except for procedural decisions. Attendance at meetings is critical to influencing decisions and to maintaining membership voting rights.
メーリングリストと会議のバランス：どちらの組織もメーリングリストを利用しています。 IETFワーキンググループは、正式な会議に加えて、作業が行われるメーリングリストに大きく依存しています。 IETFは、すべてのワーキンググループの決定をメーリングリストで行う（または、多くの場合、実際には確認する）必要があります。最終的な決定は会議では行われません。 IEEE 802ワーキンググループは通常、IETFワーキンググループの約2倍の頻度で面談します（IEEE 802プレナリー3つとIETF 802中間会議3つ、毎年IETFプレナリー3つと比較）。電話会議はIEEE 802でより一般的です。ほとんどのIETFワーキンググループよりも。 IEEE 802のほとんどの主要な決定は、手続き上の決定を除いて、本会議または中間会議中に行われます。会議への出席は、意思決定に影響を与え、メンバーの投票権を維持するために重要です。
Interim meetings: Both organizations use interim meetings (between plenary meetings). IETF Working Groups schedule interim meetings on an as-needed basis. IETF interim meetings may be face-to-face or virtual. Most IEEE 802 WGs hold regularly interim meetings three times a year in the middle of the interval between two plenary meetings. The schedules and locations of these meetings are typically known many months in advance. IEEE 802 interim meetings are face-to-face only. In addition to regularly scheduled IEEE 802 interim meetings, teleconference and ad hoc meetings are held on an as-needed basis.
中間会議：両方の組織が中間会議（本会議の間）を使用します。 IETFワーキンググループは、必要に応じて中間会議をスケジュールします。 IETFの中間会議は、対面または仮想の場合があります。ほとんどのIEEE 802 WGは、2回の本会議の合間に、年に3回定期的に中間会議を開催しています。これらの会議のスケジュールと場所は、通常、何ヶ月も前に知られています。 IEEE 802中間会議は対面のみです。定期的にスケジュールされたIEEE 802中間会議に加えて、電話会議やアドホック会議が必要に応じて開催されます。
Remote participation: Because the IETF doesn't make decisions at face-to-face meetings, attendance is not absolutely necessary, and some significant contributors do not attend most face-to-face IETF meetings. However, finding people interested in a proposal for new work, or soliciting backing for ideas, is often more easily accomplished face-to-face, such as in a hallway or bar. Significant contributors to IEEE 802 almost always attend face-to-face meetings; participation in IEEE 802 meetings is a condition for WG membership.
リモート参加：IETFは対面式の会議では決定を行わないため、出席する必要はなく、重要な貢献者の中にはほとんどの対面式のIETF会議に参加しない人もいます。ただし、新しい仕事の提案に興味がある人を見つけたり、アイデアの裏付けを求めることは、多くの場合、廊下やバーなどで対面して行う方が簡単です。 IEEE 802の重要な貢献者は、ほとんどの場合、対面式の会議に出席します。 IEEE 802会議への参加は、WGメンバーシップの条件です。
Lifetime of Standards: IEEE 802 periodically reviews existing standards. IETF Standards Track documents may be updated or obsoleted by newer Standards Track documents, but there is no formal periodic review for existing Standards Track documents. The status of specific IETF standards is available through the IETF "Datatracker" [DATATRACKER]. Because these status changes happen independently, standards from each organization may refer to documents that are no longer standards in the other organization.
規格の有効期間：IEEE 802は既存の規格を定期的に見直します。 IETF Standards Trackドキュメントは、新しいStandard Trackドキュメントによって更新または廃止される可能性がありますが、既存のStandards Trackドキュメントに対する正式な定期的なレビューはありません。特定のIETF標準のステータスは、IETFの「Datatracker」[DATATRACKER]から入手できます。これらのステータス変更は独立して発生するため、各組織の標準は、もう一方の組織の標準ではなくなったドキュメントを参照する場合があります。
Overlapping terminology: As two independent standards development organizations, IEEE 802 and IETF have developed vocabularies that overlap. For instance, IEEE 802 "ballots" at several levels of the organization during document approval, while IETF documents are only "balloted" during IESG review. The IESG uses "ballots" to indicate that all technical concerns have been addressed, not to indicate that the IESG agrees with a document. The intention is to "discuss" technical issues with a document, and "no" is not one of the choices on an IESG ballot.
重複する用語：2つの独立した規格開発組織として、IEEE 802とIETFは重複する語彙を開発しています。たとえば、IETF文書はIESGレビュー中にのみ「投票」されるのに対し、IEEE 802は文書の承認中に組織のいくつかのレベルで「投票」します。 IESGは「投票用紙」を使用して、すべての技術的な問題に対処したことを示します。これは、IESGが文書に同意したことを示すものではありません。意図は、ドキュメントで技術的な問題を「議論する」ことであり、「いいえ」はIESG投票の選択肢の1つではありません。
All IETF Working Groups and all IEEE 802 Working Groups have associated mailing lists. Most IEEE 802 Task Groups also have mailing lists, but in some cases (e.g., the IEEE 802.1 Working Group), the Working Group mailing list is used for any Task Group matters.
すべてのIETFワーキンググループとすべてのIEEE 802ワーキンググループには、関連するメーリングリストがあります。ほとんどのIEEE 802タスクグループにもメーリングリストがありますが、場合によっては（IEEE 802.1ワーキンググループなど）、ワーキンググループのメーリングリストがタスクグループの問題に使用されます。
In the IETF, the mailing list is the primary vehicle for discussion and decision-making. It is recommended that IEEE 802 experts interested in particular IETF Working Group topics subscribe to and participate in these lists. IETF WG mailing lists are open to all subscribers. The IETF Working Group mailing list subscription and archive information are noted in each Working Group's charter page.
IETFでは、メーリングリストが議論と意思決定の主要な手段です。特定のIETFワーキンググループのトピックに関心のあるIEEE 802の専門家がこれらのリストにサブスクライブして参加することをお勧めします。 IETF WGメーリングリストは、すべてのサブスクライバーに公開されています。 IETFワーキンググループメーリングリストのサブスクリプションとアーカイブ情報は、各ワーキンググループのチャーターページに記載されています。
In IEEE 802, mailing lists are typically used for meeting logistics, ballot announcements, reports, and some technical discussion. Most decision-making is at meetings, but in cases where a decision is needed between meetings, it may be done over the mailing list. Most technical discussion occurs at meetings and by generating comments on drafts that are compiled with responses in comment resolution documents.
IEEE 802では、メーリングリストは通常、会議のロジスティクス、投票の発表、レポート、およびいくつかの技術的な議論に使用されます。ほとんどの意思決定は会議で行われますが、会議の間に意思決定が必要な場合は、メーリングリストで行われることがあります。ほとんどの技術的なディスカッションは、会議で、およびコメント解決ドキュメントでの応答とともに編集されるドラフトにコメントを生成することによって行われます。
Most IEEE 802 mailing lists are open to all subscribers. For the few IEEE 802 mailing lists that are not open, please see the Working Group chair to arrange for access to the mailing list.
ほとんどのIEEE 802メーリングリストは、すべての加入者に公開されています。公開されていないいくつかのIEEE 802メーリングリストについては、ワーキンググループの議長に連絡して、メーリングリストへのアクセスを手配してください。
Some IEEE 802 participants refer to mailing lists as "reflectors".
一部のIEEE 802参加者は、メーリングリストを「リフレクタ」と呼んでいます。
During the course of IEEE 802 and IETF cooperation, it is important to share internal documents among the technical Working Groups. In addition, drafts of IEEE 802 standards, Internet-Drafts, and RFCs may also be distributed.
IEEE 802とIETFの協力の過程で、技術ワーキンググループ間で内部ドキュメントを共有することが重要です。さらに、IEEE 802標準のドラフト、インターネットドラフト、およびRFCも配布できます。
IETF Internet-Drafts may be located using the IETF Datatracker interface (see [DATATRACKER]) or via the IETF tools site at <http://tools.ietf.org>. RFCs may be found at either of the above sites, or via the RFC Editor web site at <http://www.rfc-editor.org>.
IETF Internet-Draftsは、IETF Datatrackerインターフェイス（[DATATRACKER]を参照）を使用して、またはIETFツールサイト（<http://tools.ietf.org>）から入手できます。 RFCは、上記のサイトのいずれか、または<http://www.rfc-editor.org>のRFC Editor Webサイトから入手できます。
IEEE 802 standards, once approved, are published and made available for sale. They can be purchased from the IEEE Standards Store, at <http://www.techstreet.com/IEEEgate.html>. They are also available from other outlets, including the IEEE Xplore digital library, at <http://ieeexplore.ieee.org>.
IEEE 802標準は、承認されると公開され、販売できるようになります。これらは<http://www.techstreet.com/IEEEgate.html>のIEEE標準ストアから購入できます。また、<http://ieeexplore.ieee.org>のIEEE Xploreデジタルライブラリを含む他の販売店からも入手できます。
The Get IEEE 802 program, at <http://standards.ieee.org/about/get>, grants public access to download individual IEEE 802 standards at no charge (although registration is required). IEEE 802 standards are added to the Get IEEE 802 program six months after publication. This program is approved year by year, but has been in place for several years.
<http://standards.ieee.org/about/get>にあるGet IEEE 802プログラムは、個々のIEEE 802標準を無料でダウンロードするためのパブリックアクセスを許可します（登録が必要です）。 IEEE 802標準は、発行から6か月後にGet IEEE 802プログラムに追加されます。このプログラムは毎年承認されていますが、数年間実施されています。
The IEEE owns the copyright to drafts of standards developed within IEEE 802 standardization projects. The IEEE-SA grants permission for an IEEE 802 draft to be distributed without charge to the participants for that IEEE 802 standards development project. Typically, access is provided over the Internet under password protection, with the password provided to members of the participating WG. Requests to the relevant WG Chair for access to a draft for purposes of participation in the project are typically granted.
IEEEは、IEEE 802標準化プロジェクト内で開発された規格の草案に対する著作権を所有しています。 IEEE-SAは、IEEE 802規格の開発プロジェクトの参加者に無料でIEEE 802ドラフトを配布することを許可します。通常、アクセスはパスワード保護の下でインターネット経由で提供され、パスワードは参加しているWGのメンバーに提供されます。プロジェクトへの参加を目的としたドラフトへのアクセスを求める関連WG議長へのリクエストは、通常、許可されます。
An alternative access mechanism which may more easily enable document access for IETF WGs cooperating with IEEE 802 was established by a liaison statement sent to the IETF in July 2004 by Paul Nikolich, Chair of IEEE 802 (available at <https://datatracker.ietf.org/ documents/LIAISON/file41.pdf>), describing the process by which IETF WGs can obtain access to IEEE 802 work in progress. IEEE 802 WG Chairs have the authority to grant membership in their WGs and can use this authority to grant membership to an IETF WG chair upon request. The IETF WG chair will be provided with access to the username/password for the IEEE 802 WG archives and is permitted to share that information with participants in the IETF WG. Since it is possible to participate in IETF without attending meetings, or even joining a mailing list, IETF WG chairs will provide the information to anyone who requests it. However, since IEEE 802 work in progress is copyrighted, copyright restrictions prohibit incorporating material into IETF documents or postings.
IEEE 802と協力するIETF WGのドキュメントアクセスをより簡単に有効にする代替アクセスメカニズムは、IEEE 802の議長であるPaul Nikolichが2004年7月にIETFに送信した連絡声明によって確立されました（<https：//datatracker.ietfで入手可能） .org / documents / LIAISON / file41.pdf>）、IETF WGが進行中のIEEE 802作業へのアクセスを取得できるプロセスを説明します。 IEEE 802 WG議長は、自分のWGにメンバーシップを付与する権限を持ち、この権限を使用して、要求に応じてIETF WGチェアにメンバーシップを付与できます。 IETF WG議長は、IEEE 802 WGアーカイブのユーザー名/パスワードへのアクセスが提供され、その情報をIETF WGの参加者と共有することが許可されます。ミーティングに参加したり、メーリングリストに参加したりせずにIETFに参加することは可能であるため、IETF WGの議長は情報を要求する人に情報を提供します。ただし、進行中のIEEE 802の著作物は著作権で保護されているため、著作権の制限により、IETF文書または投稿に素材を組み込むことは禁止されています。
In addition to allowing IETF participants to access documentation resources within IEEE 802, IEEE 802 can also make selected IEEE 802 documents at any stage of development available to the IETF by attaching them to a formal liaison statement. Although a communication can point to a URL where a non-ASCII document can be downloaded, sending attachments in proprietary formats to an IETF mailing list is discouraged.
IEEE 802は、IETF参加者がIEEE 802内のドキュメントリソースにアクセスできるようにするだけでなく、開発の任意の段階で選択したIEEE 802ドキュメントを正式な連絡声明に添付することにより、IETFが利用できるようにすることもできます。通信は非ASCIIドキュメントをダウンロードできるURLを指すことができますが、添付ファイルを独自の形式でIETFメーリングリストに送信することはお勧めしません。
Each IEEE 802 standardization project is assigned to a Working Group (WG) for development. In IEEE 802, the working methods of the WGs vary in their details. The documentation system is one area in which WG operations differ, based on varying needs and traditions. In some cases, the WGs assign the core development to a subgroup (typically known as a Task Group or Task Force), and the documentation procedures may vary among the subgroups as well. Prior to project authorization, or on topics not directly related to development of a standard, the WG may consider and develop documents itself or using other subgroups (standing committees, ad hocs, etc.).
各IEEE 802標準化プロジェクトは、開発のためのワーキンググループ（WG）に割り当てられています。 IEEE 802では、WGの動作方法は詳細が異なります。ドキュメンテーションシステムは、さまざまなニーズと伝統に基づいて、WGの運用が異なる領域の1つです。場合によっては、WGはコア開発をサブグループ（通常はタスクグループまたはタスクフォースとして知られている）に割り当て、ドキュメントの手順もサブグループ間で異なる場合があります。プロジェクトの承認前、または標準の開発に直接関連しないトピックについては、WGはドキュメント自体を検討または開発するか、他のサブグループ（常任委員会、アドホックなど）を使用する場合があります。
IEEE 802 also supports Technical Advisory Groups (TAGs) that conduct business and develop documents, although not standards. References here to WGs apply to TAGs as well.
IEEE 802は、標準ではありませんが、ビジネスを行い、ドキュメントを作成する技術諮問グループ（TAG）もサポートしています。ここでのWGへの参照は、TAGにも適用されます。
Generally, the archives of minutes and contributions to IEEE 802 groups are publicly and freely available.
一般に、議事録のアーカイブとIEEE 802グループへの貢献は、一般に無料で入手できます。
Many IEEE 802 groups use a documentation system provided by IEEE and known as "Mentor". The list of these groups is available at the IEEE 802 Mentor Home Page: <https://mentor.ieee.org/802>. Mentor provides the following features:
多くのIEEE 802グループは、IEEEによって提供され、「メンター」として知られるドキュメンテーションシステムを使用しています。これらのグループのリストは、IEEE 802 Mentor Home Page：<https://mentor.ieee.org/802>で入手できます。メンターは次の機能を提供します。
1. The documentation system is structured and ordered, with documentation tags and unique numbering and versioning.
1. ドキュメンテーションシステムは、ドキュメンテーションタグと一意の番号付けおよびバージョン管理を使用して、構造化および順序付けされています。
2. Online documentation is available.
2. オンラインドキュメントが利用可能です。
3. Limited search functionality is provided, and publicly available search engines index the data.
3. 限定された検索機能が提供されており、公開されている検索エンジンがデータにインデックスを付けます。
4. The ability to submit documents to Mentor is limited but is generally available to any interested party. An IEEE web account is required but can be easily and freely established using the IEEE Account Request page, at <http://www.ieee.org/go/create_web_account>. If submission is protected, the privilege can be requested via the Mentor system (using the "Join group" link on each WG Mentor page) and would typically be granted by the WG documentation manager in a manual approval.
4. メンターにドキュメントを送信する機能は制限されていますが、一般的には関係者であれば誰でも利用できます。 IEEE Webアカウントが必要ですが、<http://www.ieee.org/go/create_web_account>のIEEEアカウントリクエストページを使用して簡単かつ自由に設定できます。送信が保護されている場合、特権はメンターシステムを介して（各WGメンターページの[グループに参加]リンクを使用して）要求でき、通常、WGドキュメントマネージャーによって手動で承認されます。
5. Submitted documents are immediately available to the general public at the same instant they become available for consideration by the group.
5. 提出されたドキュメントは、グループによる検討の対象となると同時に、一般に公開されます。
IEEE 802.1 and IEEE 802.3 do not use Mentor.
IEEE 802.1およびIEEE 802.3はMentorを使用しません。
IEEE 802.1 documents are organized in folders by year at <http://www.ieee802.org/1/files/public/>. The file names indicate the relevant project, author, date, and version. The file-naming conventions and upload link are at <http://www.ieee802.org/1/filenaming.html>. Upload is moderated.
IEEE 802.1ドキュメントは、<http://www.ieee802.org/1/files/public/>のフォルダに年ごとにまとめられています。ファイル名は、関連するプロジェクト、作成者、日付、およびバージョンを示します。ファイルの命名規則とアップロードリンクは<http://www.ieee802.org/1/filenaming.html>にあります。アップロードは管理されています。
IEEE 802.3 documents are accessed from the home pages of the IEEE 802.3 subgroups (i.e., Task Force or Study Group) and are organized in folders by meeting date. These home pages are available from the IEEE 802.3 home page, at <http://www.ieee802.org/3/>. Files are uploaded by emailing to the subgroup chair.
IEEE 802.3ドキュメントは、IEEE 802.3サブグループ（つまり、タスクフォースまたはスタディグループ）のホームページからアクセスされ、会議の日付ごとにフォルダに整理されます。これらのホームページは、IEEE 802.3ホームページの<http://www.ieee802.org/3/>から入手できます。ファイルは、サブグループの議長にメールでアップロードされます。
In general, development of standards in IEEE 802 is contribution driven. In many cases, a WG or subgroup will issue a call for contributions with a specific technical solicitation, including deadlines and submission instructions. Some groups maintain specific submission procedures and specify a contribution cover sheet to clarify the status of the contribution.
一般に、IEEE 802での標準の開発は貢献主導です。多くの場合、WGまたはサブグループは、締め切りや提出指示を含む、特定の技術的な要請を伴う寄付を求めます。一部のグループは、特定の提出手順を維持し、寄付のステータスを明確にするために寄付のカバーシートを指定しています。
Content for drafts of standards is submitted to WGs by individual participants or groups of participants. Content toward other group documents (such as, for example, external communication statements or foundation documents underlying a draft of a standard) might also be contribution driven. At some point, the group assembles contributed material to develop group documents, and revision takes place within group meetings or by assignment to Editors. For the most part, the contributions toward discussion as well as the group documents (including minutes and other reports) are openly available to the public.
標準草案のコンテンツは、個々の参加者または参加者のグループによってWGに提出されます。他のグループ文書（例えば、外部通信ステートメントまたは標準のドラフトの基礎となる基礎文書など）に対するコンテンツも、コントリビューション主導型である可能性があります。ある時点で、グループは寄稿資料を集めてグループ文書を作成し、グループ会議内または編集者への割り当てによって改訂が行われます。ほとんどの場合、議論への貢献とグループ文書（議事録やその他のレポートを含む）は一般に公開されています。
IETF and IEEE 802 each recognize the standards defined by the other organization. Standards produced by each organization can be used as references in standards produced by the other organization.
IETFとIEEE 802はそれぞれ、他の組織によって定義された標準を認識します。各組織が作成した標準は、他の組織が作成した標準の参照として使用できます。
IETF specifications may reference IEEE 802 work in progress, but these references should be labeled "Work in Progress". If the references are normative, this will block publication of the referring specification until the reference is available in a stable form.
IETF仕様は、IEEE 802の進行中の作業を参照する場合がありますが、これらの参照には「作業中」というラベルを付ける必要があります。参照が規範的である場合、参照が安定した形で利用できるようになるまで、参照仕様の公開がブロックされます。
IEEE 802 standards may normatively reference non-expired Internet-Drafts, but IEEE 802 prefers that this be avoided if at all possible.
IEEE 802標準は、期限が切れていないインターネットドラフトを規範的に参照する場合がありますが、IEEE 802は、可能であればこれを回避することを推奨しています。
Informative references in IEEE 802 standards are placed in a bibliography, so they may point to either approved IETF standards or IETF Internet-Drafts, if necessary.
IEEE 802標準の参考資料は参考文献に記載されているため、必要に応じて、承認されたIETF標準またはIETFインターネットドラフトのいずれかを参照することができます。
When an IEEE 802 standard is revised, it normally retains the same number and the date is updated. Therefore, IEEE 802 standards are dated with the year of approval, e.g., IEEE Std 802.1Q(TM)-2011. There are two ways of referencing IEEE 802 standards: undated and dated references. IEEE 802 practice allows undated reference to be used when referencing a whole standard. An undated reference indicates that the most recent version of the standard should be used. A dated reference refers to a specific revision of an IEEE 802 standard. Since clauses, subclauses, tables, figures, etc., may be renumbered when a standard is revised, a dated reference should be used when citing specific items in a standard.
IEEE 802規格が改訂されると、通常は同じ番号が保持され、日付が更新されます。したがって、IEEE 802規格には承認年が付けられています（IEEE Std 802.1Q（TM）-2011など）。 IEEE 802標準を参照するには、日付のない参照と日付の付いた参照の2つの方法があります。 IEEE 802プラクティスでは、規格全体を参照するときに日付のない参照を使用できます。日付のない参照は、標準の最新バージョンを使用する必要があることを示しています。日付の付いた参照は、IEEE 802標準の特定のリビジョンを指します。条項、副次句、表、図などは、規格が改訂されるときに番号が付け直される可能性があるため、規格の特定の項目を引用する場合は日付の付いた参照を使用する必要があります。
IETF standards may be cited by RFC number, which would also be a dated reference. If an undated reference to an IETF Internet Standard is desired, a number is also assigned in the "STD" series [BCP9], and these references refer to the most recent version of an IETF Internet Standard.
IETF標準はRFC番号で引用されている場合があり、これも日付付きの参照です。 IETFインターネット標準への日付のない参照が必要な場合は、「STD」シリーズ[BCP9]でも番号が割り当てられ、これらの参照はIETFインターネット標準の最新バージョンを参照します。
This section describes how existing processes within the IETF and IEEE 802 may be used to enable cooperation between the organizations.
このセクションでは、IETFおよびIEEE 802内の既存のプロセスを使用して、組織間の連携を可能にする方法について説明します。
Historically, much of the work of coordination has fallen on individuals attending meetings of both organizations. However, as noted in "Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG" [RFC4663], downward pressure on travel budgets has made it increasingly difficult for participants to attend face-to-face meetings in both organizations. That pressure has continued in the intervening years. As a result, the coordination mechanisms described in this section typically do not require meeting attendance.
歴史的に、調整作業の多くは、両方の組織の会議に出席する個人に任されてきました。ただし、「MITF作業をIETFブリッジMIB WGからIEEE 802.1 WGに転送する」[RFC4663]で述べたように、旅行予算に対する下向きの圧力により、参加者が両方の組織で対面式の会議に出席することがますます困難になっています。その圧力はその後数年間続いた。その結果、このセクションで説明する調整メカニズムでは、通常、会議に出席する必要はありません。
The following sections outline a process that can be used to enable each organization to stay informed about the other's active and proposed work items.
以下のセクションでは、各組織が他の組織のアクティブで提案された作業項目について常に情報を入手できるようにするために使用できるプロセスの概要を説明します。
Early identification of topics of mutual interest allows the two organizations to cooperate in a productive way and helps each organization avoid developing specifications that overlap or conflict with specifications developed in the other organization. Where individuals notice a potential conflict or need for coordination, the issue should be brought to the attention of the relevant Working Group chairs and/or Area Directors.
相互に関心のあるトピックを早期に特定することで、2つの組織は生産的な方法で協力し、各組織が他の組織で開発された仕様と重複または競合する仕様の開発を回避できます。個人が潜在的な対立または調整の必要性に気付いた場合、その問題は関連するワーキンググループの議長および/またはエリアディレクターの注意を引く必要があります。
The responsibility is on IEEE 802 Working Groups to review current IETF Working Groups to determine if there are any topics of mutual interest. Working Group charters and active Internet-Drafts can be found in the IETF Datatracker [DATATRACKER]. If an IEEE 802 Working Group identifies a common area of work, the IEEE 802 Working Group leadership should contact both the IETF Working Group chair and the Area Director(s) responsible. This may be accompanied by a formal liaison statement (see Section 5.2).
IEEE 802ワーキンググループは、現在のIETFワーキンググループをレビューして、相互に関心のあるトピックがあるかどうかを判断する責任があります。ワーキンググループのチャーターとアクティブなインターネットドラフトは、IETF Datatracker [DATATRACKER]にあります。 IEEE 802ワーキンググループが共通の作業分野を特定する場合、IEEE 802ワーキンググループのリーダーシップは、IETFワーキンググループの議長と担当のエリアディレクターの両方に連絡する必要があります。これには、正式な連絡声明が伴う場合があります（セクション5.2を参照）。
It is the responsibility of IETF Working Groups to periodically review the IEEE 802 web site to determine if there is work in progress of mutual interest.
IEEE 802 Webサイトを定期的に確認して、相互に関心のある作業が進行中かどうかを判断するのは、IETFワーキンググループの責任です。
IEEE 802 Working Group status reports are published at the beginning and end of each plenary at <http://ieee802.org/minutes>. Each Working Group includes a list of their active projects and the status.
IEEE 802ワーキンググループのステータスレポートは、各プレナリーの最初と最後に<http://ieee802.org/minutes>で公開されています。各ワーキンググループには、アクティブなプロジェクトとステータスのリストが含まれています。
The charter of an IEEE 802 project is defined in an approved Project Authorization Request (PAR). PARs are accessible in IEEE Standards myProject, at <https://development.standards.ieee.org>. Access requires an IEEE web account, which is free and has no membership requirement.
IEEE 802プロジェクトの憲章は、承認されたプロジェクト許可要求（PAR）で定義されています。 PARは、IEEE標準myProjectの<https://development.standards.ieee.org>でアクセスできます。アクセスには、無料でメンバーシップ要件のないIEEE Webアカウントが必要です。
In myProject, a search on "View Active PARs" for 802 will bring up a list of all active IEEE 802 PARs.
myProjectでは、802の「View Active PARs」を検索すると、すべてのアクティブなIEEE 802 PARのリストが表示されます。
If an IETF working group identifies a common area of work or a need for cooperation, the Working Group leadership should contact the IEEE 802 Working Group Chair and Task Group Chair. This may be accompanied by a formal liaison statement (see Section 5.2).
IETFワーキンググループが作業の共通領域または協力の必要性を特定した場合、ワーキンググループのリーダーは、IEEE 802ワーキンググループの議長とタスクグループの議長に連絡する必要があります。これには、正式な連絡声明が伴う場合があります（セクション5.2を参照）。
These principles describe the notification process used by both organizations:
これらの原則は、両方の組織で使用される通知プロセスを説明しています。
1. For both organizations, the technical group making a proposal for new work that may conflict with, overlap with, or be dependent on the other organization is responsible for informing the top-level coordination body in the other organization that cooperation may be required.
1. どちらの組織でも、他の組織と競合する、重複する、または他の組織に依存する可能性がある新しい作業を提案する技術グループは、他の組織のトップレベルの調整機関に協力が必要になる可能性があることを通知する責任があります。
2. For both organizations, the top-level coordination body receiving that notification is responsible for determining whether cooperation is, in fact, required, and informing the specific groups within the organization who may be affected by the proposal for new work.
2. どちらの組織でも、その通知を受け取るトップレベルの調整機関は、協力が実際に必要かどうかを判断し、新しい作業の提案によって影響を受ける可能性のある組織内の特定のグループに通知する責任があります。
These direct notifications will be the most common way that each organization is informed about proposals for new work in the other organization. Several other ways of identifying proposed new work are described in the following sections. These additional ways act as "belt and suspenders" to reduce the chances that proposals for new work in one organization escape notice in the other organization when cooperation will be required.
これらの直接通知は、各組織が他の組織での新しい作業の提案について通知される最も一般的な方法になります。次のセクションでは、提案された新しい作業を特定する他のいくつかの方法について説明します。これらの追加の方法は、「ベルトとサスペンダー」として機能し、ある組織での新しい作業の提案が、協力が必要になったときに他の組織での通知を逃れる可能性を減らします。
Several standards development organizations (SDOs), including IETF and IEEE 802, have agreed to use a mailing list for the distribution of information about proposals for new work items among these SDOs.
IETFやIEEE 802を含むいくつかの標準開発機関（SDO）は、これらのSDO間の新しい作業項目の提案に関する情報の配布にメーリングリストを使用することに同意しています。
Rather than having individual IEEE 802 participants subscribe directly to New-Work, a single IEEE 802 mailing list is subscribed. Leadership of the IEEE 802 Working Groups may subscribe to this "second-level" IEEE 802 mailing list, which is maintained by the Executive Committee (EC).
個々のIEEE 802参加者がNew-Workに直接サブスクライブするのではなく、単一のIEEE 802メーリングリストがサブスクライブされます。 IEEE 802ワーキンググループのリーダーは、この「第2レベル」のIEEE 802メーリングリストを購読できます。これは、執行委員会（EC）によって管理されています。
This mailing list is limited to representatives of SDOs proposing new work that may require cooperation with the IETF. Subscription requests may be sent to the IAB Executive Director.
このメーリングリストは、IETFとの協力を必要とする可能性のある新しい作業を提案するSDOの代表者に限定されています。サブスクリプションのリクエストは、IAB Executive Directorに送信される場合があります。
Many proposals for new IETF work items can be identified in proposed Birds of a Feather (BOF) sessions, as well as draft charters for Working Groups. The IETF forwards all such draft charters for new and revised Working Groups and BOF session announcements to the IETF New-Work mailing list.
新しいIETF作業項目の多くの提案は、提案されたBirds of a Feather（BOF）セッション、およびワーキンググループのチャータードラフト案で確認できます。 IETFは、新規および改訂されたワーキンググループおよびBOFセッションのアナウンスのドラフトチャーターすべてをIETF New-Workメーリングリストに転送します。
Each IEEE 802 Working Group Chair, or designated representative, may provide comments on these charters by responding to the IESG mailing list at iesg@ietf.org clearly indicating their IEEE 802 position and the nature of their concern.
各IEEE 802ワーキンググループチェア、または指定された代表は、iesg @ ietf.orgのIESGメーリングリストに返信して、IEEE 802の立場と懸念の性質を明確に示すことにより、これらの憲章にコメントを提供できます。
It should be noted that the IETF turnaround time for new Working Group charters can be as short as two weeks, although the call-for-comment period on work items that may require cooperation with IEEE 802 can be extended to allow more time for discussion within IEEE 802. This places a burden on both organizations to proactively communicate and avoid "late surprises" to either organization.
新しいワーキンググループチャーターのIETFターンアラウンドタイムは最短2週間ですが、IEEE 802との協力を必要とする可能性のある作業項目のコメント募集期間を延長して、 IEEE802。これは、どちらの組織にも積極的に通信し、「遅いサプライズ」を回避するという両方の組織に負担をかけます。
Although an IEEE 802 Working Group may not be able to develop a formal consensus response unless the notification arrives during that Working Group's meeting, the IEEE 802 Working Group chair can informally let the IETF know that IEEE 802 may have concerns about a proposed work item. The IETF will consider any informal comments received without waiting for a formal liaison statement.
IEEE 802ワーキンググループは、そのワーキンググループの会議中に通知が届かない限り、正式なコンセンサス応答を作成できない場合がありますが、IEEE 802ワーキンググループの議長は、IETF 802に提案されたワークアイテムについて懸念がある可能性があることを非公式に知らせます。 IETFは、正式な連絡声明を待たずに、受け取った非公式コメントを検討します。
An IEEE 802 project is initiated by approval of a Project Authorization Request (PAR), which includes a description of the scope of the work. Any IEEE 802 PARs that introduce new functionality are required to be available for review no less than 30 days prior to the Monday of the IEEE 802 plenary session where they will be considered.
IEEE 802プロジェクトは、作業の範囲の説明を含むプロジェクト承認要求（PAR）の承認によって開始されます。新しい機能を導入するIEEE 802 PARは、検討されるIEEE 802プレナリーセッションの月曜日の30日前までにレビューに利用できる必要があります。
IEEE 802 considers "Five Criteria" when deciding whether to approve new work: Broad Market Potential, Compatibility, Distinct Identity, Technical Feasibility, and Economic Feasibility. The criteria are defined in the IEEE 802 LAN/MAN Standards Committee (LMSC) Operations Manual. The PARs are accompanied by responses on the "Five Criteria".
IEEE 802は、新しい作業を承認するかどうかを決定するときに「5つの基準」を考慮します。それは、幅広い市場の可能性、互換性、明確なアイデンティティ、技術的実現可能性、および経済的実現可能性です。基準は、IEEE 802 LAN / MAN標準委員会（LMSC）運用マニュアルで定義されています。 PARには、「5つの基準」に関する回答が付いています。
IEEE 802 posts proposed PARs to the New-Work mailing list, prior to the IEEE 802 meetings where the PARs will be discussed. The IETF coordination body will notify technical groups about PARs of interest.
IEEE 802は、PARについて議論されるIEEE 802会議の前に、提案されたPARをNew-Workメーリングリストに投稿します。 IETF調整機関は、関心のあるPARについて技術グループに通知します。
Any comments on proposed PARs should be submitted to the Working Group Chair and copied to the Executive Committee chair by email not later than 5:00 PM Tuesday of the plenary session (in the time zone where the plenary is located).
提案されたPARに関するコメントは、ワーキンググループの議長に提出し、本会議の火曜日午後5時（プレナリーが設置されているタイムゾーン）までに電子メールで執行委員会委員長にコピーする必要があります。
From time to time, IEEE 802 and IETF may agree to use additional mechanisms for coordination between the two groups. The details of these mechanisms may vary over time, but the overarching goal is to communicate effectively as needed.
IEEE 802およびIETFは、2つのグループ間の調整に追加のメカニズムを使用することに同意する場合があります。これらのメカニズムの詳細は時間とともに変化する可能性がありますが、最も重要な目標は、必要に応じて効果的に通信することです。
As examples of such mechanisms, at the time this document was written, the two organizations are holding periodic conference calls between representatives of the IETF and IEEE 802 leadership teams, and are maintaining a "living list" of shared interests between the two organizations, along with the status of these interests and any related action items. At the time this document was written, the "living list" included about 20 topics being actively discussed, with more expected. These conference calls help the two organizations coordinate more effectively by allowing higher-bandwidth discussions than formal liaison statements would allow and by permitting more timely interactions than waiting for face-to-face meetings.
そのようなメカニズムの例として、このドキュメントが作成された時点で、2つの組織はIETFとIEEE 802のリーダーシップチームの代表者間で定期的な電話会議を開催しており、2つの組織間で共有される利益の「生きたリスト」を維持しています。これらの関心のステータスと関連するすべてのアクションアイテム。このドキュメントが作成された時点では、 "リビングリスト"には約20のトピックが含まれており、活発に議論されています。これらの電話会議は、正式な連絡声明よりも高帯域幅のディスカッションを許可し、対面式の会議を待つよりもタイムリーな対話を許可することにより、2つの組織がより効果的に調整するのに役立ちます。
Minutes for these conference calls, and the "living lists" discussed on each call, are available at <http://www.iab.org/activities/ joint-activities/iab-ieee-coordination/>.
これらの電話会議の議事録、および各会議で議論される「リビングリスト」は、<http://www.iab.org/activities/ joint-activities / iab-ieee-coordination />で入手できます。
During the course of IEEE 802 and IETF cooperation, it is important for technical experts to review documents of mutual interest and, when appropriate, to provide review comments to the approving body as the document moves through the approval process.
IEEE 802とIETFの協力の過程で、技術専門家が相互に関心のある文書をレビューし、必要に応じて、文書が承認プロセスを進むときに承認機関にレビューコメントを提供することが重要です。
IEEE 802 drafts are reviewed and balloted at multiple stages of the draft. Any ballot comments received from non-voters before the close of the ballot are required to be considered in the comment resolution process. The Editors, Task Group Chairs, or Working Group Chairs responsible for the project will facilitate the entering of comments from non-voters.
IEEE 802ドラフトは、ドラフトの複数の段階で見直され、投票されます。投票が終了する前に投票者以外から受け取った投票コメントは、コメント解決プロセスで検討する必要があります。プロジェクトの責任者である編集者、タスクグループチェア、またはワーキンググループチェアは、非投票者からのコメントの入力を容易にします。
IEEE 802 draft reviews and ballots sometimes produce a large volume of comments. In order to handle them efficiently, spreadsheets or a comment database tool are used. It is highly recommended that balloters and others submitting comments do so with a file that can be imported into these tools. A file with the correct format is normally referenced in the ballot announcement or can be obtained from the Editor, Task Group Chair, or Working Group Chair responsible for the project. Comments on a draft should be copied to the Editor, Task Group Chair, and Working Group Chair.
IEEE 802ドラフトのレビューと投票では、大量のコメントが作成されることがあります。それらを効率的に処理するために、スプレッドシートまたはコメントデータベースツールが使用されます。投票者やコメントを提出する人は、これらのツールにインポートできるファイルを使用してそうすることを強くお勧めします。正しい形式のファイルは、通常、投票の発表で参照されるか、プロジェクトの責任者である編集者、タスクグループの議長、またはワーキンググループの議長から入手できます。草案に関するコメントは、編集者、タスクグループチェア、ワーキンググループチェアにコピーする必要があります。
During draft development, informal task group reviews (task group ballots) are conducted. Though these are called "ballots" by some Working Groups, the focus is on collecting and resolving comments on the draft rather than on trying to achieve a specific voting result.
草案の作成中、非公式のタスクグループレビュー（タスクグループ投票）が行われます。これらは一部のワーキンググループでは「投票用紙」と呼ばれていますが、焦点は特定の投票結果を達成しようとすることではなく、草案に関するコメントを収集して解決することです。
Once the draft is substantially complete, Working Group ballots are conducted. Working Group voting members are entitled and required to vote in Working Group ballots. Any "disapprove" votes are required to be accompanied by comments that indicate what the objection is and a proposed resolution. "Approve" votes may also be accompanied by comments. The comments submitted with a "disapprove" vote may be marked to indicate which comments need to "be satisfied" to change the vote.
草案が実質的に完成すると、作業部会の投票が行われます。ワーキンググループの投票メンバーは、ワーキンググループの投票用紙に投票する資格があり、必要です。 「不承認」の投票には、異議の内容と提案された解決策を示すコメントを添付する必要があります。 「承認」の投票にはコメントが添付される場合もあります。 「不承認」の投票で送信されたコメントは、投票を変更するために「満足」する必要があるコメントを示すためにマークされる場合があります。
Initial Working Group ballots are at least 30 days. Recirculation ballots to review draft changes and comment resolutions are open at least 10 days.
最初のワーキンググループ投票は少なくとも30日間です。ドラフトの変更とコメントの解決をレビューするための再循環投票は、少なくとも10日間有効です。
In order to submit a WG ballot, contact the WG Chair for the submission tool currently in use, as the tools may change over time.
WG投票を送信するには、現在使用されている送信ツールについてWG議長に連絡してください。ツールは時間とともに変更される可能性があります。
When a draft has successfully completed Working Group ballot, it proceeds to Sponsor ballot. One may participate in IEEE 802 Sponsor ballots with an individual membership in the IEEE Standards Association (IEEE-SA) or by paying a per-ballot fee. Participants are also required to state their affiliation and the category of their relationship to the scope of the standards activity (e.g., producer, user, general interest).
草案が作業部会の投票を無事に完了すると、スポンサー投票に進みます。 IEEE Standards Association（IEEE-SA）に個人会員として参加するか、投票ごとの料金を支払うことにより、IEEE 802スポンサー投票に参加できます。参加者はまた、彼らの所属と標準活動の範囲との関係のカテゴリー（例えば、生産者、ユーザー、一般的な関心）を述べる必要があります。
Information about IEEE-SA membership can be found at <http://standards.ieee.org/membership/>.
IEEE-SAメンバーシップに関する情報は、<http://standards.ieee.org/membership/>にあります。
Sponsor ballot is a public review. An invitation is sent to any parties known to be interested in the subject matter of the ballot. One can indicate interest in IEEE myProject (<https://development.standards.ieee.org>). An IEEE web account is freely available and is required for login. To select interest areas, go to the Projects tab and select "Manage Activity Profile" and check any areas of interest. IEEE 802 projects are under Computer Society; LAN/MAN Standards Committee.
スポンサー投票は公開レビューです。投票の主題に関心があることがわかっている関係者に招待状が送信されます。 IEEE myProject（<https://development.standards.ieee.org>）への関心を示すことができます。 IEEE Webアカウントは自由に利用でき、ログインに必要です。関心領域を選択するには、[プロジェクト]タブに移動し、[アクティビティプロファイルの管理]を選択して、関心領域を確認します。 IEEE 802プロジェクトはComputer Societyの下にあります。 LAN / MAN標準委員会。
The Sponsor ballot pool is formed from those that accept the invitation during the invitation period.
スポンサー投票プールは、招待期間中に招待を受け入れるものから形成されます。
As with other ballot levels, the IETF participants who want to comment on Sponsor ballots need not be members in the Sponsor ballot pool. The Editors, Task Group Chairs, or Working Group Chairs responsible for the project will facilitate the entering of comments from IETF participants who are not members in the Sponsor ballot pool.
他の投票レベルと同様に、スポンサー投票についてコメントしたいIETF参加者は、スポンサー投票プールのメンバーである必要はありません。プロジェクトの責任者である編集者、タスクグループチェア、またはワーキンググループチェアは、スポンサー投票プールのメンバーではないIETF参加者からのコメントの入力を容易にします。
Any "disapprove" votes are required to be accompanied by comments that indicate what the objection is, along with a proposed resolution. "Approve" votes may also be accompanied by comments. The comments submitted with a "disapprove" vote may be marked to indicate which comments need to "be satisfied" for the commenter to change the vote from "disapprove".
「不承認」の投票には、提案された解決策とともに、異議の内容を示すコメントを添付する必要があります。 「承認」の投票にはコメントが添付される場合もあります。 「不承認」の投票で送信されたコメントは、コメントを「不承認」から変更するために「満足」する必要があるコメントを示すためにマークされる場合があります。
Initial Sponsor ballots are open for at least 30 days. Recirculation ballots to review draft changes and proposed comment resolutions are open at least 10 days.
最初のスポンサー投票は少なくとも30日間有効です。ドラフトの変更と提案されたコメントの解決策をレビューするための再循環投票は、少なくとも10日間有効です。
At each level, the relevant group (Task Group for TG ballots, Working Group for WG and Sponsor ballots) examines the ballot comments and determines their disposition. The Editor (or editorial team) may prepare proposed dispositions. Task Group procedures vary, but at the Working Group level, the Working Group must vote 75 percent to approve the final ballot disposition in order to advance the document.
各レベルで、関連グループ（TG投票のタスクグループ、WGおよびワーキンググループのワーキンググループ）が投票のコメントを調べて、その処分を決定します。編集者（または編集チーム）は、提案された処置を準備できます。タスクグループの手順はさまざまですが、ワーキンググループレベルでは、ワーキンググループは75％の票を投じて、ドキュメントを進めるために最終的な投票処理を承認する必要があります。
The IETF Working Group Process is defined in [BCP25]. The overall IETF standards process is defined in [BCP9].
IETFワーキンググループプロセスは、[BCP25]で定義されています。 IETF標準プロセス全体は、[BCP9]で定義されています。
As noted in Section 2.4, IETF Working Groups do not "ballot" to determine Working Group consensus to forward documents to the IESG for approval.
セクション2.4で述べたように、IETFワーキンググループは、承認のためにドキュメントをIESGに転送するためのワーキンググループの合意を決定するために「投票」しません。
Technical contributions are welcome at any point in the IETF document review and approval process, but there are some points where contribution is more likely to be effective.
技術的な貢献は、IETF文書のレビューおよび承認プロセスのどの時点でも歓迎されますが、貢献が効果的である可能性が高いいくつかの点があります。
1. When a Working Group is considering adoption of an individual draft. Adoption is often announced on the Working Group's mailing list.
1. ワーキンググループが個別のドラフトの採用を検討しているとき。採択はワーキンググループのメーリングリストでしばしば発表されます。
2. When Working Group chairs issue a "Working Group Last Call" ("WGLC") for a draft, to confirm that the Working Group has consensus to request publication. Although this is not a mandatory step in the document review and approval process for Internet-Drafts, most IETF Working Groups do issue WGLCs for most Working Group documents. WGLC would be announced on the Working Group's mailing list.
2. ワーキンググループの議長がドラフトの「ワーキンググループの最後のコール」（「WGLC」）を発行するとき、ワーキンググループが公開を要求することに合意したことを確認します。これは、インターネットドラフトのドキュメントレビューおよび承認プロセスにおける必須の手順ではありませんが、ほとんどのIETFワーキンググループは、ほとんどのワーキンググループドキュメントに対してWGLCを発行します。 WGLCはワーキンググループのメーリングリストで発表されます。
3. When the Internet Engineering Steering Group issues an "IETF Last Call" ("Last Call") for a draft. IETF Last Call is a formal and required part of the review and approval process, is addressed to the larger IETF community, and is often the first time the entire community has looked at the document. IETF Last Call is signaled on the IETF-Announce Mailing List, and comments and feedback are ordinarily directed to the IETF Discussion Mailing List.
3. インターネットエンジニアリングステアリンググループがドラフトの「IETFラストコール」（「ラストコール」）を発行したとき。 IETFラストコールは、レビューおよび承認プロセスの正式で必須の部分であり、より大きなIETFコミュニティに向けられ、多くの場合、コミュニティ全体がこのドキュメントを初めて見ます。 IETF Last CallはIETF-Announceメーリングリストで通知され、コメントとフィードバックは通常IETFディスカッションメーリングリストに送られます。
In practice, earlier input is more likely to be effective input. IEEE 802 participants who are interested in work within the IETF should be monitoring that work and providing input long before Working Group Last Calls and IETF Last Calls, for best results.
実際には、以前の入力が効果的な入力である可能性が高くなります。最良の結果を得るには、IETF内での作業に関心のあるIEEE 802参加者は、その作業を監視し、ワーキンググループの最終呼び出しとIETFの最終呼び出しのかなり前に入力を提供する必要があります。
Some IETF Working Group charters direct the Working Group to communicate with relevant IEEE 802 Task Groups.
一部のIETFワーキンググループチャーターは、関連するIEEE 802タスクグループと通信するようワーキンググループに指示します。
With the number of areas of cooperation between IEEE 802 and IETF increasing, the document review process has extended beyond the traditional subjects of SMI (Structure of Management Information) MIB modules and AAA (Authentication, Authorization, and Accounting) described in [RFC4441]. IESG members routinely solicit directorate reviews as a means to request the opinion of specialized experts on specific aspects of documents in IESG review (examples include security, "MIB Doctors", or congestion management reviews). Area Directors may also require solicited reviews from IEEE 802 or IEEE 802 Working Groups when it becomes clear that the Internet-Draft has implications that impact some area of IEEE 802's responsibility and expertise.
IEEE 802とIETFの間の協力分野の数が増えるにつれて、ドキュメントレビュープロセスは、[RFC4441]で説明されているSMI（管理情報の構造）MIBモジュールとAAA（認証、承認、およびアカウンティング）の従来の主題を超えて広がりました。 IESGメンバーは、IESGレビューのドキュメントの特定の側面（例として、セキュリティ、「MIB Doctors」、または輻輳管理レビューなど）に関する専門家の意見を要求する手段として、定期的に監督レビューを求めます。エリアディレクターは、インターネットドラフトがIEEE 802の責任と専門知識の一部の領域に影響を与えることが明らかになったら、IEEE 802またはIEEE 802ワーキンググループからの要請されたレビューを要求することもあります。
IEEE 802 leadership can also solicit similar reviews, but these reviews are not included as part of the formal IEEE 802 process.
IEEE 802リーダーシップも同様のレビューを要請できますが、これらのレビューは正式なIEEE 802プロセスの一部として含まれていません。
Both IEEE 802 and IETF work best when people participate directly in work of mutual interest, but that is not always possible, and individuals speaking as individuals may not provide effective communication between the two SDOs. From time to time, it may be appropriate for a technical body in one SDO to communicate as a body with a technical body in the other SDO. This section describes the mechanisms used to provide formal communication between the two organizations, should that become necessary.
IEEE 802とIETFはどちらも、人々が相互に関心のある仕事に直接参加する場合に最適に機能しますが、常に可能であるとは限らず、個人として話す個人は2つのSDO間の効果的な通信を提供できない場合があります。場合によっては、1つのSDOの技術団体が他のSDOの技術団体と1つの団体として通信することが適切な場合があります。このセクションでは、必要になった場合に2つの組織間で正式なコミュニケーションを提供するために使用されるメカニズムについて説明します。
The Internet Architecture Board (IAB) is responsible for liaison relationship oversight for the IETF. In IEEE 802, liaison relationship oversight is distributed, and each organization appointing liaison managers is responsible for oversight of its own liaison relationships.
インターネットアーキテクチャボード（IAB）は、IETFのリエゾン関係の監視を担当します。 IEEE 802では、リエゾン関係の監視が分散されており、リエゾンマネージャーを任命する各組織は、自身のリエゾン関係の監視を担当しています。
The reader should note that the role of a liaison manager in both IEEE 802 and IETF is not to "speak for" the appointing organization. A liaison manager is most helpful in ensuring that neither organization is surprised by what's happening in the other organization, helping to identify the right people to be talking to in each organization, and making sure that formal liaison statements don't "get lost" between the two organizations. The IAB's guidance to liaison managers is available in [RFC4691]. IEEE 802 organizations appointing each liaison manager also provide guidance to those liaison managers. There is no global guidance for all IEEE 802 liaison managers.
読者は、IEEE 802とIETFの両方における連絡管理者の役割が、指名した組織を「代弁」することではないことに注意する必要があります。リエゾンマネージャーは、どちらの組織も他の組織で何が起こっているかに驚かないようにし、各組織で話し合う適切な人物を特定し、正式なリエゾンステートメントが「紛失」しないようにするのに最も役立ちます。 2つの組織。リエゾンマネージャーに対するIABのガイダンスは、[RFC4691]で入手できます。各リエゾンマネージャーを任命するIEEE 802組織も、これらのリエゾンマネージャーにガイダンスを提供します。すべてのIEEE 802リエゾンマネージャーに対するグローバルなガイダンスはありません。
The IAB appoints IETF liaison managers using the process described in [BCP102]. The current list of the IETF's liaison relationships and the liaison managers responsible for each of these relationships is available at <http://www.ietf.org/liaison/managers.html>.
IABは、[BCP102]で説明されているプロセスを使用してIETFリエゾンマネージャーを任命します。 IETFのリエゾン関係と、これらの各関係に責任があるリエゾンマネージャーの現在のリストは、<http://www.ietf.org/liaison/managers.html>で入手できます。
IEEE liaison managers are selected by the organizations they represent, either in an election or by Working Group or Task Group Chair appointment. The current list of IEEE 802's liaison relationships and the liaison managers responsible for each of these relationships is available at <http://www.ieee802.org/liaisons.shtml>.
IEEEリエゾンマネージャーは、選挙で、またはワーキンググループまたはタスクグループの議長の指名によって、彼らが代表する組織によって選択されます。 IEEE 802のリエゾン関係の現在のリスト、およびこれらの各関係に責任があるリエゾンマネージャーは、<http://www.ieee802.org/liaisons.shtml>で入手できます。
The IEEE 802 procedure for sending and receiving liaison statements is defined by the Procedure for Coordination with Other Standards Bodies in the IEEE 802 LMSC Operations Manual (<http://ieee802.org/devdocs.shtml>).
リエゾンステートメントを送受信するためのIEEE 802の手順は、IEEE 802 LMSC運用マニュアル（<http://ieee802.org/devdocs.shtml>）の他の標準化団体との調整手順で定義されています。
The IETF process for sending and receiving liaison statements is defined in [BCP103].
リエゾンステートメントを送受信するためのIETFプロセスは、[BCP103]で定義されています。
Both IEEE 802 and IETF maintain registries of assigned protocol parameters, and some protocol parameters assigned in one organization are of interest to the other organization. This section describes the way each organization registers protocol parameters.
IEEE 802とIETFはどちらも、割り当てられたプロトコルパラメータのレジストリを維持しており、ある組織で割り当てられた一部のプロトコルパラメータは、他の組織にとって重要です。このセクションでは、各組織がプロトコルパラメータを登録する方法について説明します。
The IETF uses the Internet Assigned Numbers Authority (IANA) as a central authority that administers registries for most protocol parameter allocations. The overarching document describing this is [BCP26]. [BCP141] discusses use of IEEE 802-specific IANA parameters in IETF protocols and specifies IANA considerations for allocation of code points under the IANA OUI (Organizationally Unique Identifier).
IETFは、Internet Assigned Numbers Authority（IANA）を、ほとんどのプロトコルパラメータ割り当てのレジストリを管理する中央機関として使用します。これを説明する包括的なドキュメントは[BCP26]です。 [BCP141]は、IETFプロトコルでのIEEE 802固有のIANAパラメータの使用について説明し、IANA OUI（Organizationally Unique Identifier）でのコードポイントの割り当てに関するIANAの考慮事項を指定します。
Requests for protocol parameter allocations from IANA are subject to assignment policies, and these policies vary from registry to registry. A variety of well-known policies are described in [BCP26], but registries are not limited to one of the well-known choices.
IANAからのプロトコルパラメータ割り当てのリクエストは割り当てポリシーの対象であり、これらのポリシーはレジストリごとに異なります。よく知られているさまざまなポリシーが[BCP26]で説明されていますが、レジストリはよく知られた選択肢の1つに限定されません。
The purpose of these allocations is to manage a namespace appropriately, so unless a registry has a policy that allows something like first come, first served ("FCFS") for a namespace that is effectively unbounded, requests for protocol parameter allocation will require some level of review. "Standards Action" is at the other extreme (an approved Standards Track RFC is required in order to obtain an allocation). Some registries require that a request for allocation pass "Expert Review" -- review by someone knowledgeable in the technology domain, appointed by the IESG and given specific criteria to use when reviewing requests.
これらの割り当ての目的は名前空間を適切に管理することです。したがって、レジストリに、事実上無制限の名前空間に対して先着順（ "FCFS"）などのポリシーを許可しない限り、プロトコルパラメータ割り当てのリクエストにはある程度のレベルが必要になります。レビューの。 「標準アクション」はもう一方の極端です（割り当てを取得するには、承認された標準トラックRFCが必要です）。一部のレジストリは、割り当ての要求が「エキスパートレビュー」に合格することを要求します-技術ドメインに精通し、IESGによって任命され、要求をレビューするときに使用する特定の基準を与えられた人によるレビュー。
The IEEE Standards Association uses the IEEE Registration Authority as a central authority administering registries. The IEEE Registration Authority Committee (IEEE RAC) provides technical oversight for the IEEE Registration Authority.
IEEE Standards Associationは、IEEE Registration Authorityをレジストリを管理する中心的な機関として使用しています。 IEEE Registration Authority Committee（IEEE RAC）は、IEEE Registration Authorityの技術監視を提供します。
The list of Registries administered by the IEEE Registration Authority can be found on the IEEE RAC web site, at <http://standards.ieee.org/develop/regauth/general.html>.
IEEE Registration Authorityが管理するレジストリのリストは、IEEE RAC Webサイトの<http://standards.ieee.org/develop/regauth/general.html>にあります。
Regarding Ethertype allocation: Some IETF protocol specifications make use of Ethertypes. Ethertypes are a fairly scarce resource so allocation has the following requirements. All Ethertype requests are subject to review by a consultant to the IEEE RA, followed by IEEE RAC confirmation.
Ethertype割り当てについて：一部のIETFプロトコル仕様では、Ethertypeを使用しています。 Ethertypeはかなり希少なリソースであるため、割り当てには次の要件があります。すべてのEthertype要求は、IEEE RAのコンサルタントによるレビューの後に、IEEE RACによる確認を受けます。
The IEEE RAC will not assign a new Ethertype to a new IETF protocol specification until the IESG has approved the protocol specification for publication as an RFC. In exceptional cases, the IEEE RA will consider "early allocation" of an Ethertype for an IETF protocol that is still under development when the request comes from, and has been vetted by, the IESG.
IESGがプロトコル仕様をRFCとして公開することを承認するまで、IEEE RACは新しいEthertypeを新しいIETFプロトコル仕様に割り当てません。例外的なケースでは、IEEE RAは、要求がIESGから送信され、精査されたときに、まだ開発中のIETFプロトコルのEthertypeの「早期割り当て」を検討します。
Note that "playpen" Ethertypes have been assigned in IEEE 802 [ARCH802] for use during protocol development and experimentation.
「playpen」Ethertypeは、プロトコルの開発および実験中に使用するためにIEEE 802 [ARCH802]で割り当てられていることに注意してください。
While a fee is normally charged by the IEEE Registration Authority Committee (RAC) for the allocation of an Ethertype, the IEEE RAC will consider waiving the fee for allocations relating to an IETF Standards Track document, based on a request from the IESG.
イーサタイプの割り当てには通常、IEEE登録局委員会（RAC）が料金を請求しますが、IEEE RACは、IESGからの要求に基づいて、IETF標準トラックドキュメントに関連する割り当ての料金を免除することを検討します。
Each IEEE 802 Working Group has a registry of identifier values and a mechanism to allocate identifier values in its standards and approved amendments. This includes items such as Object Identifiers for managed objects and assignment for protocols defined by that Working Group, such as OpCodes. Contact the IEEE 802 Working Group Chair for the details of a given Working Group registry.
各IEEE 802ワーキンググループには、識別子の値のレジストリと、その標準および承認された修正で識別子の値を割り当てるメカニズムがあります。これには、管理対象オブジェクトのオブジェクト識別子や、OpCodeなど、そのワーキンググループによって定義されたプロトコルの割り当てなどの項目が含まれます。特定のワーキンググループレジストリの詳細については、IEEE 802ワーキンググループチェアに問い合わせてください。
Because some registries are "joint-use" between IEEE 802 and IETF, it is necessary for each organization to review usage of registries maintained by the other organization as part of the review and approval process for standards.
一部のレジストリはIEEE 802とIETFの間で「共同使用」されるため、各組織は、標準のレビューおよび承認プロセスの一環として、他の組織によって維持されているレジストリの使用をレビューする必要があります。
If an IEEE 802 document refers to IANA registries, those references should be checked prior to Sponsor balloting. If an IETF document refers to IEEE 802 registries, those references should be checked as part of IANA Review during IETF Last Call.
IEEE 802文書がIANAレジストリを参照している場合、スポンサー投票の前にそれらの参照を確認する必要があります。 IETF文書がIEEE 802レジストリを参照している場合、それらの参照はIETFの最終呼び出し中にIANAレビューの一部としてチェックする必要があります。
This document describes cooperation procedures and has no direct Internet security implications.
このドキュメントは協力手順を説明したものであり、インターネットのセキュリティに直接影響するものではありません。
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[BCP26] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[BCP141] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, October 2013.
[BCP141] Eastlake 3rd、D。およびJ. Abley、「IANAの考慮事項とIEEE 802パラメータのIETFプロトコルおよびドキュメントの使用法」、BCP 141、RFC 7042、2013年10月
[RFC4691] Andersson, L., Ed., "Guidelines for Acting as an IETF Liaison to Another Organization", RFC 4691, October 2006.
[RFC4691] Andersson、L.、Ed。、「別の組織へのIETFリエゾンとして行動するためのガイドライン」、RFC 4691、2006年10月。
[ARCH802] IEEE 802, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", IEEE 802 Std 802(TM)-2014, 2014.
[ARCH802] IEEE 802、「IEEE Standard for Local and Metropolitan Area Networks：Overview and Architecture」、IEEE 802 Std 802（TM）-2014、2014。
[BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[BCP9] Bradner、S.、「インターネット標準プロセス-リビジョン3」、BCP 9、RFC 2026、1996年10月。
Dusseault, L. and R. Sparks, "Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard", BCP 9, RFC 5657, September 2009.
Dusseault、L.およびR. Sparks、「相互運用に関するガイダンスおよびドラフト標準への移行に関する実装レポート」、BCP 9、RFC 5657、2009年9月。
Housley, R., Crocker, D., and E. Burger, "Reducing the Standards Track to Two Maturity Levels", BCP 9, RFC 6410, October 2011.
Housley、R.、Crocker、D。、およびE. Burger、「Reducing the Standards Track to Two Maturity Levels」、BCP 9、RFC 6410、2011年10月。
Resnick, P., "Retirement of the "Internet Official Protocol Standards" Summary Document", BCP 9, RFC 7100, December 2013.
Resnick、P。、「「インターネット公式プロトコル標準」要約文書の廃止」、BCP 9、RFC 7100、2013年12月。
Kolkman, O., Bradner, S., and S. Turner, "Characterization of Proposed Standards", BCP 9, RFC 7127, January 2014.
Kolkman、O.、Bradner、S。、およびS. Turner、「Characterization of Proposed Standards」、BCP 9、RFC 7127、2014年1月。
[BCP10] Galvin, J., Ed., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 3777, June 2004.
[BCP10] Galvin、J。、編、「IABおよびIESGの選択、確認、およびリコールプロセス：指名委員会およびリコール委員会の運営」、BCP 10、RFC 3777、2004年6月。
Dawkins, S., Ed., "Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers", BCP 10, RFC 5633, August 2009.
Dawkins、S.、Ed。、 "指名委員会のプロセス：募集職種の早期発表とボランティアの勧誘"、BCP 10、RFC 5633、2009年8月。
Dawkins, S., Ed., "The Nominating Committee Process: Open Disclosure of Willing Nominees", BCP 10, RFC 5680, October 2009.
Dawkins、S.、Ed。、「指名委員会のプロセス：有望な候補者のオープンな開示」、BCP 10、RFC 5680、2009年10月。
Leiba, B., "Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership", BCP 10, RFC 6859, January 2013.
Leiba、B。、「IETFリーダーシップの指名委員会の資格を明確にするためのRFC 3777の更新」、BCP 10、RFC 6859、2013年1月。
[BCP11] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.
[BCP11] Hovey、R。およびS. Bradner、「IETF標準プロセスに関与する組織」、BCP 11、RFC 2028、1996年10月。
[BCP25] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.
[BCP25] Bradner、S。、「IETF Working Group Guidelines and Procedures」、BCP 25、RFC 2418、1998年9月。
Wasserman, M., "Updates to RFC 2418 Regarding the Management of IETF Mailing Lists", BCP 25, RFC 3934, October 2004.
Wasserman、M。、「IETFメーリングリストの管理に関するRFC 2418の更新」、BCP 25、RFC 3934、2004年10月。
[BCP39] Internet Architecture Board and B. Carpenter, Ed., "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000.
[BCP39]インターネットアーキテクチャボードおよびB.カーペンター編、「インターネットアーキテクチャボード（IAB）のチャーター」、BCP 39、RFC 2850、2000年5月。
[BCP101] Austein, R., Ed., and B. Wijnen, Ed., "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, April 2005.
[BCP101] Austein、R.、Ed。およびB. Wijnen、Ed。、「Structure of the IETF Administrative Support Activity（IASA）」、BCP 101、RFC 4071、2005年4月。
Carpenter, B., Ed., and L. Lynch, Ed., "BCP 101 Update for IPR Trust", BCP 101, RFC 4371, January 2006.
Carpenter、B。、編、およびL. Lynch、編、「BCP 101 Update for IPR Trust」、BCP 101、RFC 4371、2006年1月。
[BCP102] Daigle, L., Ed., and Internet Architecture Board, "IAB Processes for Management of IETF Liaison Relationships", BCP 102, RFC 4052, April 2005.
[BCP102] Daigle、L.、Ed。、およびInternet Architecture Board、「IAB Processes for Management for IETF Liaison Relationships」、BCP 102、RFC 4052、2005年4月。
[BCP103] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for Handling Liaison Statements to and from the IETF", BCP 103, RFC 4053, April 2005.
[BCP103] Trowbridge、S.、Bradner、S。、およびF. Baker、「IETFとの間の連絡ステートメントを処理するための手順」、BCP 103、RFC 4053、2005年4月。
[BCP111] Heard, C., Ed., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005.
[BCP111]ハード、C。、編、「MIBドキュメントの作成者とレビュー担当者のためのガイドライン」、BCP 111、RFC 4181、2005年9月。
Heard, C., Ed., "RFC 4181 Update to Recognize the IETF Trust", BCP 111, RFC 4841, March 2007.
ハード、C。、編、「IETFトラストを認識するためのRFC 4181アップデート」、BCP 111、RFC 4841、2007年3月。
[BCP132] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[BCP132] Housley、R。およびB. Aboba、「認証、承認、およびアカウンティング（AAA）キー管理のガイダンス」、BCP 132、RFC 4962、2007年7月。
[BCP158] DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, March 2011.
[BCP158] DeKok、A.、Ed。、およびG. Weber、「RADIUS Design Guidelines」、BCP 158、RFC 6158、2011年3月。
[DADG] Morand, L., Ed., Fajardo, V. and H. Tschofenig, "Diameter Applications Design Guidelines", Work in Progress, June 2014.
[DADG] Morand、L.、Ed。、Fajardo、V.およびH. Tschofenig、「Diameter Applications Design Guidelines」、Work in Progress、2014年6月。
[DATATRACKER] Internet Engineering Task Force, "IETF Datatracker", <https://datatracker.ietf.org>.
[DATATRACKER]インターネット技術特別調査委員会、「IETF Datatracker」、<https://datatracker.ietf.org>。
[IEEE80211F] IEEE, "IEEE Trial-Use Recommended Practice for Multi-Vendor Access Point Interoperability Via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation", IEEE 802 Std 802.11F(TM)-2003, 2003.
[IEEE80211F] IEEE、「IEEE 802.11オペレーションをサポートする配信システム間でのアクセスポイントプロトコルを介したマルチベンダーアクセスポイントの相互運用性のためのIEEEトライアル使用推奨プラクティス」、IEEE 802 Std 802.11F（TM）-2003、2003。
[IEEE-802.16-Liaison1] Liaison letter from IEEE 802.16 to Bernard Aboba, March 17, 2005, <http://ieee802.org/16/liaison/docs/L80216-05_025.pdf>.
[IEEE-802.16-Liaison1] 2005年3月17日、IEEE 802.16からBernard Abobaへの連絡レター<http://ieee802.org/16/liaison/docs/L80216-05_025.pdf>。
[IEEE-802.16-Liaison2] Liaison letter from IEEE 802.16 to Bernard Aboba, May 5, 2005, <http://ieee802.org/16/liaison/docs/L80216-05_039.pdf>.
[IEEE-802.16-Liaison2] IEEE 802.16からBernard Abobaへの連絡レター、2005年5月5日、<http://ieee802.org/16/liaison/docs/L80216-05_039.pdf>。
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003.
[RFC3575] Aboba、B。、「RADIUS（リモート認証ダイヤルインユーザーサービス）に関するIANAの考慮事項」、RFC 3575、2003年7月。
[RFC3710] Alvestrand, H., "An IESG charter", RFC 3710, February 2004.
[RFC3710] Alvestrand、H。、「An IESG Charter」、RFC 3710、2004年2月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、編、「Extensible Authentication Protocol（EAP）」、RFC 3748、2004年6月。
[RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, "State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator", RFC 4137, August 2005.
[RFC4137] Vollbrecht、J.、Eronen、P.、Petroni、N。、およびY. Ohba、「State Machines for Extensible Authentication Protocol（EAP）Peer and Authenticator」、RFC 4137、2005年8月。
[RFC4441] Aboba, B., Ed., "The IEEE 802/IETF Relationship", RFC 4441, March 2006.
[RFC4441] Aboba、B。、編、「The IEEE 802 / IETF Relationship」、RFC 4441、2006年3月。
[RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG", RFC 4663, September 2006.
[RFC4663]ハリントン、D。、「IETFブリッジMIB WGからIEEE 802.1 WGへのMIB作業の転送」、RFC 4663、2006年9月。
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
[RFC5247] Aboba、B.、Simon、D。、およびP. Eronen、「Extensible Authentication Protocol（EAP）Key Management Framework」、RFC 5247、2008年8月。
[RFC6220] McPherson, D., Ed., Kolkman, O., Ed., Klensin, J., Ed., Huston, G., Ed., and Internet Architecture Board, "Defining the Role and Function of IETF Protocol Parameter Registry Operators", RFC 6220, April 2011.
[RFC6220] McPherson、D.、Ed。、Kolkman、O.、Ed。、Klensin、J.、Ed。、Huston、G.、Ed。、and Internet Architecture Board、 "Defining the Role and Function of IETF Protocol Parameterレジストリオペレーター」、RFC 6220、2011年4月。
[RFC6548] Brownlee, N., Ed., and IAB, "Independent Submission Editor Model", RFC 6548, June 2012.
[RFC6548] Brownlee、N.、Ed。、およびIAB、「Independent Submission Editor Model」、RFC 6548、2012年6月。
[RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor Model (Version 2)", RFC 6635, June 2012.
[RFC6635] Kolkman、O。、編、Halpern、J。、編、およびIAB、「RFC Editor Model（Version 2）」、RFC 6635、2012年6月。
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, October 2012.
[RFC6733] Fajardo、V.、Ed。、Arkko、J.、Loughney、J.、and G. Zorn、Ed。、 "Diameter Base Protocol"、RFC 6733、October 2012。
[RFC6756] Trowbridge, S., Ed., Lear, E., Ed., Fishman, G., Ed., and S. Bradner, Ed., "Internet Engineering Task Force and International Telecommunication Union - Telecommunication Standardization Sector Collaboration Guidelines", RFC 6756, September 2012.
[RFC6756]トローブリッジ、S。、編、リア、E。、編、フィッシュマン、G。、編、S。ブラドナー、編、「インターネット技術特別調査委員会および国際電気通信連合-電気通信標準化部門のコラボレーションガイドライン"、RFC 6756、2012年9月。
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, April 2013.
[RFC6929] DeKok、A。およびA. Lior、「Remote Authentication Dial In User Service（RADIUS）Protocol Extensions」、RFC 6929、2013年4月。
[RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC 7282, June 2014.
[RFC7282] Resnick、P。、「On Consensus and Humming in the IETF」、RFC 7282、2014年6月。
[RONR] Robert, H., et al., "Robert's Rules of Order Newly Revised", 11th ed., Da Capo Press, 2011, <http://www.robertsrules.com/>.
[RONR] Robert、H.、et al。、 "Robert's Rules of Order Newly Revised"、11 ed。、Da Capo Press、2011、<http://www.robertsrules.com/>。
This document borrows a significant amount of text, and much of its structure, from [RFC6756]. Additional text was borrowed from [RFC4441]. We are grateful to the authors and editors of both these predecessor documents.
この文書は、[RFC6756]からかなりの量のテキストとその構造の多くを借用しています。追加のテキストは[RFC4441]から借用されました。私たちは、これら両方の先行ドキュメントの作成者と編集者に感謝しています。
The initial draft of this document was assembled by a team of participants from both IEEE 802 and IETF. Team members included Dan Romascanu, Dorothy Stanley, Eric Gray, Patricia Thaler, Roger Marks, Ross Callon, Spencer Dawkins, and Subir Das.
このドキュメントの最初のドラフトは、IEEE 802とIETFの両方の参加者のチームによって組み立てられました。チームメンバーには、ダンロマスカヌ、ドロシースタンリー、エリックグレイ、パトリシアターラー、ロジャーマークス、ロスキャロン、スペンサードーキンス、スーバーダスが含まれていました。
We also thank Abdussalam Baryun, Adrian Farrel, Dave Thaler, Jari Arkko, Russ Housley, Jouni Korhonen, Max Riegel, Norm Finn, Pete Resnick, Peter Yee, S. Moonesamy, and Stephen Farrell for providing review comments.
また、レビューコメントを提供してくれたAbdussalam Baryun、Adrian Farrel、Dave Thaler、Jari Arkko、Russ Housley、Jouni Korhonen、Max Riegel、Norm Finn、Pete Resnick、Peter Yee、S。Moonesamy、Stephen Farrellにも感謝します。
Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Alissa Cooper Joel Halpern Russ Housley Eliot Lear Xing Li Erik Nordmark Andrew Sullivan Dave Thaler Hannes Tschofenig
バーナードアボバジャリアルコマルクブランシェロスカロンアリッサクーパージョエルハルパーンラスハウズリーエリオットリアシンリーエリックノードマークアンドリューサリバンデイブターラーハネスチョーフェニグ
Radhakrishna Canchi Clint Chaplin John D'Ambrosia Subir Das James Gilb Bob Heile Tony Jeffree Bruce Kraemer David Law John Lemon Mike Lynch Roger Marks Apurva Mody Paul Nikolich Max Riegel Jon Rosdahl Steve Shellhammer Pat Thaler Geoff Thompson
ラダクリシュナカンチクリントチャップリンジョンダンブロージアスバーダスジェームズギルブボイルハイルトニージェフフリーブルースクレーマーデビッドロウジョンレモンマイクリンチロジャーマークスアプルバモディポールニコリックスマックスリーゲルジョンロスダールスティーブシェルハンマーパットタラージェフトンプソン
Historically, the MIB modules for IEEE 802.1 and IEEE 802.3 were developed in the IETF Bridge MIB and Hub MIB Working Groups, respectively. With travel budgets under pressure, it has become increasingly difficult for companies to fund employees to attend both IEEE 802 and IETF meetings.
歴史的に、IEEE 802.1およびIEEE 802.3のMIBモジュールは、それぞれIETFブリッジMIBおよびハブMIBワーキンググループで開発されました。旅行予算に圧力がかかっているため、企業が従業員にIEEE 802とIETFの両方の会議に出席するための資金を調達することはますます難しくなっています。
As a result, an alternative was found to past arrangements that involved chartering MIB work items within an IETF WG. Instead, the work was transferred to IEEE 802 with expert support for MIB review from the IETF. The process of transfer of the MIB work from the IETF Bridge MIB WG to IEEE 802.1 WG is documented in [RFC4663].
その結果、IETF WG内でMIBワークアイテムをチャーターすることを含む過去の取り決めに代わるものが見つかりました。代わりに、IETFからのMIBレビューの専門家のサポートにより、作業はIEEE 802に移されました。 IETFブリッジMIB WGからIEEE 802.1 WGへのMIB作業の転送プロセスは、[RFC4663]で文書化されています。
By standardizing IEEE 802 MIBs only within IEEE 802 while utilizing the IETF SNMP quality control process, the IETF and IEEE 802 seek to ensure quality while decreasing overhead. In order to encourage wider review of MIBs developed by IEEE 802 WGs, it is recommended that MIB modules developed in IEEE 802 follow the MIB guidelines [BCP111]. An IEEE 802 group may request assignment of a "MIB Doctor" to assist in a MIB review by contacting the IETF Operations and Management Area Director.
IETF SNMP品質管理プロセスを利用しながら、IEEE 802内でのみIEEE 802 MIBを標準化することにより、IETFとIEEE 802はオーバーヘッドを削減しながら品質を確保しようとします。 IEEE 802 WGによって開発されたMIBの幅広いレビューを促進するために、IEEE 802で開発されたMIBモジュールがMIBガイドライン[BCP111]に従うことをお勧めします。 IEEE 802グループは、IETF Operations and Management Area Directorに連絡して、MIBレビューを支援するために「MIB Doctor」の割り当てを要求する場合があります。
IEEE 802 WGs requiring new AAA applications should send a liaison request to the IETF. Where new attribute definitions are sufficient, rather than defining new authentication, authorization, and accounting logic and procedures, an Internet-Draft can be submitted and review can be requested from AAA-related WGs such as the RADEXT or DIME WGs.
新しいAAAアプリケーションを必要とするIEEE 802 WGは、IETFに連絡要求を送信する必要があります。新しい認証、承認、およびアカウンティングロジックと手順を定義するのではなく、新しい属性定義で十分な場合は、インターネットドラフトを送信し、RADEXTやDIME WGなどのAAA関連WGにレビューを要求できます。
In addition to the RADEXT and DIME WGs, a "AAA doctors" team (directorate) is currently active in the OPS Area and can be consulted for more general advice on AAA issues that cross the limits of one or the other of the RADIUS or Diameter protocols, or are more generic in nature.
RADEXTとDIMEのWGに加えて、「AAA医師」チーム（ディレクター）は現在OPSエリアで活動しており、RADIUSまたはDiameterのいずれかの限界を超えるAAAの問題に関するより一般的なアドバイスを求めることができます。プロトコル、またはより一般的な性質のものです。
For attributes of general utility, particularly those useful in multiple potential applications, allocation from the IETF standard attribute space is preferred to creation of IEEE 802 Vendor-Specific Attributes (VSAs). As noted in [RFC3575]: "RADIUS defines a mechanism for Vendor-Specific extensions (Attribute 26) for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful. For functions specific only to one vendor's implementation of RADIUS, the use of that should be encouraged instead of the allocation of global attribute types."
一般的なユーティリティの属性、特に複数の潜在的なアプリケーションで役立つ属性の場合、IETF 802ベンダー固有属性（VSA）の作成よりもIETF標準属性スペースからの割り当てが推奨されます。 [RFC3575]で述べられているように、「RADIUSは、ベンダー固有の拡張機能（属性26）のメカニズムを、1つのベンダーのRADIUS実装にのみ固有の機能に対して定義します。相互運用性は有用ではないと見なされます。RADIUSの1つのベンダーの実装にのみ固有の機能については、グローバル属性タイプの割り当ての代わりに、それを使用することが推奨されます。」
Where allocation of VSAs are required, it is recommended that IEEE 802 create a uniform format for all of IEEE 802, rather than having each IEEE 802 Working Group create their own VSA format. The VSA format defined in [IEEE80211F] is inappropriate for this, since the Type field is only a single octet, allowing for only 255 attributes. It is recommended that IEEE 802 Working Groups read and follow the recommendations in "RADIUS Design Guidelines" [BCP158] and "Protocol Extensions" [RFC6929] when designing and reviewing new extensions and attributes.
VSAの割り当てが必要な場合は、IEEE 802ワーキンググループごとに独自のVSAフォーマットを作成するのではなく、IEEE 802がすべてのIEEE 802に共通のフォーマットを作成することをお勧めします。 [IEEE80211F]で定義されているVSA形式は、Typeフィールドが単一のオクテットであり、255の属性しか許可しないため、これには不適切です。 IEEE 802ワーキンググループは、「RADIUS設計ガイドライン」[BCP158]および「プロトコル拡張機能」[RFC6929]の推奨事項を読み、それに従って新しい拡張機能と属性を設計および確認することをお勧めします。
"Diameter Applications Design Guidelines" [DADG] explains and clarifies the rules to extend the Diameter base protocol [RFC6733]. Extending Diameter can mean either the definition of a completely new Diameter application or the reuse of commands, Attribute-Value Pairs (AVPs), and AVP values in any combination for the purpose of inheriting the features of an existing Diameter application. The recommendation for reusing existing applications as much as possible is meaningful as most of the requirements defined for a new application are likely already fulfilled by existing applications. It is recommended that IEEE 802 Working Groups read and follow the recommendations in [DADG] when defining and reviewing new extensions and attributes.
「Diameterアプリケーション設計ガイドライン」[DADG]は、Diameter基本プロトコル[RFC6733]を拡張するためのルールを説明および明確化しています。 Diameterの拡張とは、まったく新しいDiameterアプリケーションの定義、または既存のDiameterアプリケーションの機能を継承するためのコマンド、属性値ペア（AVP）、およびAVP値の任意の組み合わせの再利用を意味します。新しいアプリケーションに対して定義された要件のほとんどは既存のアプリケーションによってすでに満たされている可能性が高いため、既存のアプリケーションを可能な限り再利用するための推奨事項は意味があります。 IEEE 802ワーキンググループは、新しい拡張機能と属性を定義およびレビューするときに、[DADG]の推奨事項を読んでそれに従うことをお勧めします。
The Extensible Authentication Protocol (EAP), defined in [RFC3748], provides a framework within which authentication mechanisms, known as methods, can be defined. In addition to supporting authentication, EAP also provides for key derivation as described in [RFC5247]. State machines for EAP are described in [RFC4137].
[RFC3748]で定義されている拡張認証プロトコル（EAP）は、メソッドと呼ばれる認証メカニズムを定義できるフレームワークを提供します。認証のサポートに加えて、EAPは[RFC5247]で説明されているようにキーの派生も提供します。 EAPのステートマシンは、[RFC4137]で説明されています。
As noted in [BCP132] and [RFC5247], security issues can arise in integration of EAP within lower layers. Therefore, it is recommended that IEEE 802 WGs looking to incorporate support for EAP send a liaison request to the IETF, requesting assistance in carrying out a security review. As an example, a security review of IEEE 802.16 was carried out by the EAP WG, at the request of IEEE 802.16 [IEEE-802.16-Liaison1] [IEEE-802.16-Liaison2]. Where development of new EAP authentication methods is sufficient, an Internet-Draft can be submitted and review can be requested from WGs such as the EAP Method Update (EMU) WG.
[BCP132]と[RFC5247]で述べたように、下位層内のEAPの統合でセキュリティの問題が発生する可能性があります。したがって、EAPのサポートを組み込むことを検討しているIEEE 802 WGは、IETFに連絡要求を送信し、セキュリティレビューの実施の支援を要求することが推奨されます。例として、IEEE 802.16のセキュリティレビューは、IEEE 802.16 [IEEE-802.16-Liaison1] [IEEE-802.16-Liaison2]の要請により、EAP WGによって実施されました。新しいEAP認証方法の開発で十分な場合は、インターネットドラフトを送信し、EAPメソッド更新（EMU）WGなどのWGからレビューを要求できます。
This section provides pointers to additional useful information for participants in IEEE 802 and IETF.
このセクションでは、IEEE 802およびIETFの参加者に役立つ追加情報へのポインタを提供します。
IEEE 802 Home Page: <http://ieee802.org/>
IEEE 802 policies and procedures:
<http://ieee802.org/devdocs.shtml>
The IEEE 802 WG and TAG main page URLs follow this convention: They have the one- or two-digit numerical designation for the WG or TAG appended after <http://ieee802.org/>. For example the IEEE 802.1 main web page is at <http://ieee802.org/1>, while the IEEE 802.11 main web page is at <http://ieee802.org/11>.
IEEE 802 WGとTAGのメインページのURLは、この規則に従います。<http://ieee802.org/>の後に、WGまたはTAGの1桁または2桁の数値指定が追加されています。たとえば、IEEE 802.1メインWebページは<http://ieee802.org/1>にあり、IEEE 802.11メインWebページは<http://ieee802.org/11>にあります。
Information on IETF procedures may be found in the documents in the informative references and at the URLs below.
IETFの手順に関する情報は、参考情報のドキュメントおよび以下のURLにあります。
Note: RFCs do not change after they are published. Rather, they are either obsoleted or updated by other RFCs. Such updates are tracked in the rfc-index.txt file.
注：RFCは公開後も変更されません。むしろ、他のRFCによって廃止または更新されています。このような更新は、rfc-index.txtファイルで追跡されます。
Current list and status of all RFCs:
<http://www.rfc-editor.org/rfc-index.html>
Current list and description of all IETF Internet-Drafts:
<ftp://ftp.ietf.org/internet-drafts/1id-abstracts.txt>
Current list of IETF Working Groups and their Charters: <http://datatracker.ietf.org/wg/> (includes Area Directors and chair contacts, mailing list information, etc.)
IETFワーキンググループとその憲章の現在のリスト：<http://datatracker.ietf.org/wg/>（エリアディレクターと議長の連絡先、メーリングリスト情報などが含まれます）
Current list of requested BOFs:
<http://trac.tools.ietf.org/bof/trac/>
RFC Editor pages about publishing RFCs: <http://www.rfc-editor.org> (including available tools and guidance) <http://www.rfc-editor.org/pubprocess.html> is particularly helpful.
RFCの公開に関するRFCエディターのページ：<http://www.rfc-editor.org>（利用可能なツールとガイダンスを含む）<http://www.rfc-editor.org/pubprocess.html>は特に役立ちます。
Current list of liaison statements:
<https://datatracker.ietf.org/liaison/>
IETF Intellectual Property Rights Policy and Notices:
<http://www.ietf.org/ipr/>
The Tao of the IETF: <http://www.ietf.org/tao.html> (A Novice's Guide
to the Internet Engineering Task Force)
Authors' Addresses
著者のアドレス
Spencer Dawkins Huawei Technologies 1547 Rivercrest Blvd. Allen, TX 75002 USA
Spencer Dawkins Huawei Technologies 1547 Rivercrest Blvd.アレン、テキサス州75002米国
EMail: spencerdawkins.ietf@gmail.com
Patricia Thaler Broadcom Corporation 5025 Keane Drive Carmichael, CA 95608 USA
Patricia Thaler Broadcom Corporation 5025 Keane Drive Carmichael、CA 95608 USA
EMail: pthaler@broadcom.com
Dan Romascanu AVAYA Park Atidim, Bldg. #3 Tel Aviv 61581 Israel
ダンローマスカヌアヴァヤパークアティディム、ビル。 ＃3テルアビブ61581イスラエル
EMail: dromasca@avaya.com
Bernard Aboba (editor) Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
べｒなｒｄ あぼば （えぢとｒ） みｃろそｆｔ こｒぽらちおん おね みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２ うさ
EMail: bernard_aboba@hotmail.com