RFC4441 日本語訳
4441 The IEEE 802/IETF Relationship. B. Aboba, Ed.. March 2006. (Format: TXT=49624 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Aboba, Ed. Request for Comments: 4441 Internet Architecture Board Category: Informational March 2006
ワーキンググループB.Aboba、エドをネットワークでつないでください。コメントのために以下を要求してください。 4441年のインターネット・アーキテクチャ委員会カテゴリ: 情報の2006年3月
The IEEE 802/IETF Relationship
IEEE802/IETF関係
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
Since the late 1980s, IEEE 802 and IETF have cooperated in the development of Simple Network Management Protocol (SNMP) MIBs and Authentication, Authorization, and Accounting (AAA) applications. This document describes the policies and procedures that have developed in order to coordinate between the two organizations, as well as some of the relationship history.
以来、1980年代、後半とIEEE802とIETFはSimple Network Managementプロトコル(SNMP)MIBsとAuthentication、Authorization、およびAccounting(AAA)アプリケーションの開発に協力しています。 このドキュメントは2つの組織の間で調整するために展開した方針と手順について説明します、関係歴史のいくつかと同様に。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Liaison Communications .....................................2
1.2. Access to IEEE 802 Archives ................................3
1.3. New Work Review ............................................3
1.4. MIB Review .................................................4
1.5. EAP Review .................................................4
1.6. AAA Review .................................................5
1.7. Document Review ............................................5
1.8. EtherType Allocation .......................................6
2. Security Considerations .........................................6
3. Informative References ..........................................7
4. Acknowledgements ...............................................12
Appendix A. Relationship History .................................13
A.1. MIB Development ..........................................13
A.2. AAA/EAP ..................................................16
Appendix B. IAB Members at the Time of This Writing ..............21
1. 序論…2 1.1. 連絡コミュニケーション…2 1.2. 802のアーカイブにIEEEにアクセスしてください…3 1.3. 新しい仕事レビュー…3 1.4. MIBは論評します…4 1.5. EAPは論評します…4 1.6. AAAレビュー…5 1.7. レビューを記録してください…5 1.8. EtherType配分…6 2. セキュリティ問題…6 3. 有益な参照…7 4. 承認…12 付録A.関係歴史…13 A.1。 MIB開発…13 A.2。 AAA/EAP…16 この書くこと時点の付録B.IABメンバー…21
IAB Informational [Page 1] RFC 4441 IEEE 802/IETF Relationship March 2006
2006年の[1ページ]RFC4441IEEE802/IETF関係行進の情報のIAB
1. Introduction
1. 序論
Since the late 1980s, participants in IEEE 802 and the IETF have cooperated in the development of Management Information Bases (MIBs) and Authentication, Authorization, and Accounting (AAA) applications relating to IEEE standards. This has included the Bridge MIB [RFC1493] [RFC4188], the multicast filtering and VLAN extension MIB [RFC2674] [RFC4363], the Hub MIB [RFC2108], the Ethernet-like Interfaces MIB [RFC3635], the MAU MIB [RFC3636], the WAN Interfaces Sublayer MIB [RFC3637], the Power Ethernet MIB [RFC3621], IEEE 802.1X RADIUS usage guidelines [RFC3580], the revised Extensible Authentication Protocol (EAP) specification [RFC3748], RADIUS/EAP [RFC3579], and the EAP State Machine specification [RFC4137]. This document describes the policies and procedures that have been put in place to encourage cooperation between the IETF and IEEE 802. Details of the relationship history are included in Appendix A.
1980年代後半以来、IEEE802とIETFの関係者はIEEE規格に関係するManagement Information基地(MIBs)とAuthentication、Authorization、およびAccounting(AAA)アプリケーションの開発に協力しています。 これはBridge MIB[RFC1493][RFC4188]、マルチキャストフィルタリング、VLAN拡張子MIB[RFC2674][RFC4363]、Hub MIB[RFC2108]、イーサネットのようなInterfaces MIB[RFC3635]、MAU MIB[RFC3636]、WAN Interfaces Sublayer MIB[RFC3637]、PowerイーサネットMIB[RFC3621]、IEEE 802.1X RADIUS用法ガイドライン[RFC3580]、改訂された拡張認証プロトコル(EAP)仕様[RFC3748]、RADIUS/EAP[RFC3579]、およびEAP州Machine仕様[RFC4137]を含んでいました。 このドキュメントはIETFとIEEE802との協力を奨励するために適所に置かれた方針と手順について説明します。 関係歴史の詳細はAppendix Aに含まれています。
In order to improve communications between the IETF and IEEE 802, members of the Internet Engineering Steering Group (IESG) and Internet Architecture Board (IAB) (including Bert Wijnen, James Kempf, and Bernard Aboba) met with the IEEE 802 Executive Committee in Vancouver, Canada, in January 2004. At that meeting, a number of issues were discussed and new procedures were put in place.
IETFとIEEE802とのコミュニケーションを改良するために、インターネットEngineering Steering Group(IESG)とインターネット・アーキテクチャ委員会(IAB)(バートWijnen、ジェームス・ケンフ、およびバーナードAbobaを含んでいる)のメンバーはIEEEと共にバンクーバー(カナダ)の802執行委員会と会合しました、2004年1月に。 そのミーティングでは、多くの問題について議論しました、そして、新しい手順は適所に置かれました。
1.1. Liaison Communications
1.1. 連絡コミュニケーション
IETF Working Groups are organized into areas, which have one or more Area Directors. The Area Directors, plus the IETF Chair, comprise the Internet Engineering Steering Group (IESG). IEEE 802 Working Groups have one or more Task Groups. The IEEE 802 Working Group Chairs, plus the IEEE 802 Chair, comprise the IEEE 802 Executive Committee (ExComm).
IETF Working Groupsは領域に組織化されます。(そこには、1人以上のAreaディレクターがいます)。 Areaディレクター、およびIETF議長はインターネットEngineering Steering Group(IESG)を包括します。 IEEE802Working Groupsには、1Task Groupsがあります。 IEEE802作業部会Chairs、およびIEEE、802、議長、IEEE802執行委員会(ExComm)を包括してください。
Participants in the IETF are appointed as liaisons to other organizations by the IAB or IESG as appropriate. This includes a liaison to IEEE 802 as well as liaisons to specific IEEE 802 Working Groups. The IETF liaison web page includes a list of IETF liaisons, as well as a pointer to the archive of liaison statements received by the IETF [Liaison-Page]. IETF processes for management of liaison relationships are described in [BCP102]; procedures for handling of incoming liaison statements are described in [BCP103]. In order to ensure that liaison statements from IEEE 802 to the IETF are archived and responded to, IEEE 802 liaisons to IETF should utilize the IETF liaison management tool to submit liaison communications. A username and password suitable for use with the tool can be obtained by sending mail to iesg-secretary@ietf.org. If a liaison management account is not available, liaison communications can be sent to the IETF liaison(s) to IEEE 802 and copied to statements@ietf.org.
IETFの関係者はIABかIESGによって適宜他の組織への連絡に任命されます。 これは特定のIEEE802Working Groupsへの連絡と同様にIEEE802に連絡係を含めます。 IETF連絡ウェブページはIETF連絡のリストを含んでいます、IETF[連絡ページ]によって受け取られた連絡声明のアーカイブへの指針と同様に。 連絡関係の管理のためのIETFプロセスは[BCP102]で説明されます。 入って来る連絡声明の取り扱いのための手順は[BCP103]で説明されます。 IEEE802からIETFへの声明が格納されて、反応するその連絡を確実にして、IETFへのIEEE802連絡は、連絡コミュニケーションを提出するのにIETF連絡管理ツールを利用するべきです。 メールを iesg-secretary@ietf.org に送ることによって、ツールによって使用に適したユーザ名とパスワードを得ることができます。 連絡管理アカウントが利用可能でないなら、連絡コミュニケーションをIEEE802へのIETF連絡に送って、 statements@ietf.org にコピーできます。
IAB Informational [Page 2] RFC 4441 IEEE 802/IETF Relationship March 2006
2006年の[2ページ]RFC4441IEEE802/IETF関係行進の情報のIAB
However, in this case substantially greater processing delays will occur due to the need for manual handling by the IETF Secretariat staff.
しかしながら、この場合、実質的によりすばらしい処理遅れはIETF事務局のスタッフによる手動の取り扱いの必要性のため起こるでしょう。
Liaison requests from the IETF to IEEE 802 should be sent to the Chair(s) of the IEEE 802 WG to which the request pertains, with a copy sent to the IEEE 802 Chair and the IEEE 802 liaison(s) to IETF. IEEE 802 procedures for communicating with other standards bodies are described in Section 14.1 of [Policy]. Liaison communications to IEEE 802 WGs are archived by the individual WGs.
要求が関係するIEEE802WGの議長にIETFからIEEE802までの連絡要求を送るべきです、コピーをIEEEに送って802、議長、そして、IETFへのIEEE802連絡。 他の標準化団体とコミュニケートするためのIEEE802手順は[方針]のセクション14.1で説明されます。 IEEE802WGsへの連絡コミュニケーションは個々のWGsによって格納されます。
1.2. Access to IEEE 802 Archives
1.2. IEEE802アーカイブへのアクセス
Access to IEEE 802 standards more than six months old is provided free of charge on the IEEE 802 website via the Get IEEE 802 Program [GetIEEE-802]. Access to IEEE 802 work-in-progress has frequently arisen as an issue in cooperation between IETF and IEEE 802. While in the past IETF Working Groups (WGs) have successfully negotiated access to IEEE 802 work-in-progress, each instance has been handled separately and took significant time and effort to complete. In order to more easily enable document access for IETF WGs collaborating with IEEE 802, a liaison statement was sent to the IETF in July 2004 by Paul Nikolich, Chair of IEEE 802 [IEEE-802Liaison], 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, incorporating material into IETF documents or posting the username/password on mailing lists or websites is not permitted.
Get IEEE802Program[GetIEEE-802]を通してIEEE802ウェブサイトで無料で6カ月以上目のIEEE802規格へのアクセスを提供します。 IEEE802処理中の作業へのアクセスはIETFとIEEE802との協力における問題として頻繁に起こりました。 (WGs)が過去のIETF Working Groupsで首尾よくIEEE802処理中の作業へのアクセスを交渉している間、各インスタンスは、別々に扱われて、重要な時間と完成する取り組みがかかりました。 IEEE802と協力するIETF WGsのために、より容易にドキュメントアクセスを可能にするために、連絡声明は2004年7月にポールNikolichによってIETFに送られました、IEEE802[IEEE-802Liaison]の議長、IETF WGsがIEEE802処理中の作業へのアクセスを得ることができるプロセスについて説明して。 IEEE802WG Chairsは彼らのWGsに会員資格を与える権威を持って、要求のときにIETF WGいすに会員資格を与えるこの権威を使用できます。 IETF WGいすを802WGが格納するIEEEのためにユーザ名/パスワードへのアクセスを提供して、IETF WGの関係者とその情報を共有することを許可します。 ミーティングに出席するか、またはメーリングリストを接合さえしないでIETFに参加するのが可能であるので、IETF WGいすはそれを要求するだれにも情報を提供するでしょう。 しかしながら、IEEE802処理中の作業は著作権があるので、IETFドキュメントに材料を組み入れるか、またはメーリングリストかウェブサイトに関するユーザ名/パスワードを掲示するのが受入れられません。
1.3. New Work Review
1.3. 新しい仕事レビュー
In order to enable IEEE 802 review of proposed IETF WG charters, as well as to enable IETF review of proposed IEEE 802 Project Authorization Requests (PARs), the New Work mailing list is used. The IEEE 802 Executive Committee is subscribed to the list, so that it can receive proposed IETF WG Charters. Proposed IEEE 802 PARs are posted to the New Work list as well. Where a New Work announcement is of particular interest, it is also (manually) forwarded to the relevant IETF and IEEE 802 mailing lists.
提案されたIETF WG特許のIEEE802レビューを可能にして、提案されたIEEE802Project Authorization Requests(PARs)のIETFレビューを可能にするために、New Workメーリングリストは使用されています。 IEEE802執行委員会は、提案されたIETF WG憲章を受け取ることができるように、リストに申し込まれます。 提案されたIEEE802PARsはまた、New Workリストに掲示されます。 New Work発表が特別におもしろいところでは、それは802のまた、関連IETFとIEEEに転送された(手動)メーリングリストです。
IAB Informational [Page 3] RFC 4441 IEEE 802/IETF Relationship March 2006
2006年の[3ページ]RFC4441IEEE802/IETF関係行進の情報のIAB
However, by the time an IETF WG Charter or IEEE 802 PAR appears on New Work, a IETF BOF or IEEE 802 "Call for Interest" has already occurred, interest has been demonstrated and considerable work has gone into development of the Charter or PAR. If problems are found at that point, it is often too late in the process to make major changes. Therefore, where a potential work item is likely to be controversial, discussions between IETF and IEEE 802 are encouraged to occur earlier in the process.
しかしながら、802PARがNew Work、IETF BOFに現れるか、またはIEEE802が「関心のために呼ぶ」IETF WG憲章かIEEEが既に起こる時までには、関心は示されました、そして、かなりの仕事が憲章かPARの開発に入りました。 問題がその時見つけられるなら、大きな変化を作るのはしばしばプロセスに遅過ぎます。 したがって、潜在的仕事項目が論議を呼ぶ傾向があるところでは、IETFとIEEE802との議論が、より早くプロセスに起こるよう奨励されます。
1.4. MIB Review
1.4. MIBレビュー
With travel budgets under pressure, it has become increasingly
difficult for companies to fund employees to attend both IEEE 802 and
IETF meetings. As a result, an alternative is needed to past
arrangements that involved chartering MIB work items within an IETF
WG. In order to encourage wider review of MIBs developed by IEEE 802
WGs, it is recommended that Simple Network Management Protocol (SNMP)
MIBs developed in IEEE 802 follow the MIB guidelines [RFC4181] and be
reviewed as part of the IETF SNMP quality control process ('MIB
Doctors'). 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.
圧力の下における旅行予算で、会社がIEEE802とIETFミーティングの両方に出席するために従業員に資金を供給するのはますます難しくなりました。 その結果、代替手段がIETF WGの中でMIB仕事の品目をチャーターすることを伴った過去のアレンジメントに必要です。 IEEE802WGsによって開発されたMIBsの、より広いレビューを奨励するために、IEEE802で開発されたSimple Network Managementプロトコル(SNMP)MIBsがMIBガイドライン[RFC4181]に従って、IETF SNMP品質管理プロセス('MIB医師')の一部として見直されるのは、お勧めです。 IEEE802グループは、IETF OperationsとManagement Areaディレクターに連絡することによってMIBレビューを助けるよう'MIB医師'の課題に要求するかもしれません。
By standardizing IEEE 802 MIBs only within IEEE 802 while utilizing the SNMP quality control process, the IETF and IEEE 802 seek to ensure quality while decreasing overhead. A trial run of this process has taken place in IEEE 802.1 where a MIB Doctor (David Harrington) has agreed to review IEEE 802.1 MIBs. Currently, discussion is under way on how change control of selected IEEE 802.1 MIB documents published as RFCs can be transferred to IEEE 802.1 [MIB-TRANSFER].
IEEEを標準化することによって、IEEE802だけの中の802MIBsがオーバーヘッドを下げている間、品質を確実にしようとしますSNMP品質管理プロセス、IETF、およびIEEE802を利用している間。 このプロセスの試運転はMIB医師(デヴィッド・ハリントン)が802.1MIBsにレビューIEEEに同意したIEEE802.1で行われました。 現在、議論は選択されたIEEE802.1MIBドキュメントの変化コントロールがIEEE802.1[MIB-TRANSFER]にRFCsを移すことができるのでどう発行されたかに関する道を下回っています。
1.5. EAP Review
1.5. EAPレビュー
Several IEEE 802 standards, including [IEEE-802.1X-2004], [IEEE-802.11i], and [IEEE-802.16e], depend on EAP [RFC3748] and EAP key management, described in [KEYFRAME]. Rather than developing their own EAP methods, or extensions for EAP key management, IEEE 802 working groups should send a liaison letter to the IETF, outlining the required functionality or requesting a review of draft text. Most recently, a security review of IEEE 802.16e D8 [EAPREVIEW] has been carried out by the EAP WG, at the request of the IEEE 802.16 Chair, Roger Marks [IEEE-802.16-Liaison1] [IEEE-802.16-Liaison2].
[IEEE-802.1X-2004]、[IEEE-802.11i]、および[IEEE-802.16e]を含むいくつかのIEEE802規格が[KEYFRAME]で説明されたEAP[RFC3748]とEAPかぎ管理に依存します。 EAPかぎ管理のためにそれら自身のEAPメソッド、または拡大を発生するよりむしろ、IEEE802ワーキンググループは連絡手紙をIETFに送るべきです、必要な機能性について概説するか、または草案文面のレビューを要求して。 ごく最近、IEEE 802.16e D8[EAPREVIEW]の安全レビューがEAP WGによって行われました、IEEEの依頼で802.16、議長、ロジャー・マーク[IEEE-802.16-Liaison1][IEEE-802.16-Liaison2]。
IAB Informational [Page 4] RFC 4441 IEEE 802/IETF Relationship March 2006
2006年の[4ページ]RFC4441IEEE802/IETF関係行進の情報のIAB
1.6. AAA Review
1.6. AAAレビュー
IEEE 802 WGs requiring new AAA applications should send a liaison request to the IETF. Where new attributes are required rather than a new application, an Internet-Draft can be submitted and review can be requested from AAA-related WGs such as the AAA or RADEXT WGs. For attributes of general utility, and 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]:
新しいAAAアプリケーションを必要とするIEEE802WGsは連絡要求をIETFに送るはずです。 新しい属性が新しいアプリケーションよりむしろ必要であるところでは、インターネット草稿を提出できます、そして、AAAかRADEXT WGsなどのAAA関連のWGsからレビューを要求できます。 一般的なユーティリティの属性、および特に複数の潜在的アプリケーションにおける役に立つそれらに関しては、IETFの標準の属性スペースからの配分はIEEE802のVendor特有のAttributes(VSAs)の作成より好まれます。 [RFC3575]に述べられるように:
RADIUS defines a mechanism for Vendor-Specific extensions (Attribute 26) and the use of that should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful.
RADIUSはVendor特有の拡大(属性26)のためにメカニズムを定義します、そして、それの使用はグローバルな属性タイプの配分の代わりに奨励されるべきです、1つのベンダーの相互運用性が全く役に立つのは考えられないRADIUSの実装だけに特定の機能のために。
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 group create their own VSA format. The VSA format defined in [IEEE-802.11F] is inappropriate for this, since the Type field is only a single octet, allowing for only 255 attributes. Recently, the AAA Doctors list has been created within the IETF Operations and Management Area Directorate, serving a similar function to the MIB Doctors. While the AAA Doctors have not yet been called upon to assist with and review AAA work outside of the IETF, this group could potentially be of assistance to IEEE 802 working groups requiring help with AAA.
VSAsの配分が必要であるところでは、IEEE802がそれぞれのIEEE802グループにそれら自身のVSA形式を作成させるよりむしろIEEE802のすべてのための一定の形式を作成するのは、お勧めです。 これに、[IEEE-802.11F]で定義されたVSA書式は不適当です、Type分野がただ一つの八重奏にすぎないので、255の属性だけを考慮して。 最近、IETF OperationsとManagement Area Directorateの中でAAA医師リストを作成してあります、MIB医師に同様の機能を果たして。 IETFの外でAAA仕事を助けて、AAAの医師が見直すのがまだ要求されていない間、このグループには、IEEE802ワーキンググループに対する支援がAAAとの助けを必要とするのが潜在的にあるかもしれません。
1.7. Document Review
1.7. ドキュメントレビュー
With the areas of cooperation between IEEE 802 and IETF increasing, the document review process has extended beyond the traditional subjects of SNMP MIBs and AAA. For example, as part of the IETF CAPWAP WG charter, IEEE 802.11 was asked to review the CAPWAP Taxonomy Document [RFC4118]; Dorothy Stanley organized an ad hoc group for this purpose. IEEE 802.11 has also reviewed [IDSEL] and [IABLINK]. Within IETF, IEEE 802 comments are resolved using normal WG and IETF processes.
IEEE802とIETFとの協力の領域が増加していて、ドキュメント吟味の過程はSNMP MIBsとAAAの伝統的な対象を超えて広がりました。 例えば、IETF CAPWAP WG特許の一部として、IEEE802.11がCAPWAP Taxonomy Document[RFC4118]を見直すように頼まれました。 ドロシー・スタンリーはこのために専門家班をまとめました。 また、IEEE802.11は[IDSEL]と[IABLINK]を見直しました。 IETFの中では、IEEE802コメントは、正常なWGとIETFプロセスを使用することで決議されています。
IETF participants can comment as part of the IEEE 802 ballot process, regardless of their voting status within IEEE 802. Comments must be composed in the format specified for the ballot, and submitted by the ballot deadline.
彼らがIEEE802の中で状態について投票することにかかわらずIETF関係者はIEEE802投票プロセスの一部としてコメントできます。 投票に指定されて、投票の締め切りで提出された形式でコメントを構成しなければなりません。
IAB Informational [Page 5] RFC 4441 IEEE 802/IETF Relationship March 2006
2006年の[5ページ]RFC4441IEEE802/IETF関係行進の情報のIAB
1.8. EtherType Allocation
1.8. EtherType配分
The EtherType field is very limited, so that allocations are made solely on an "as needed" basis. For related uses, a single EtherType should be requested, with additional fields serving as sub-protocol identifiers, rather than applying for multiple EtherTypes. EtherType allocation policy is described in [TYPE-TUT].
EtherType分野が非常に限られているので、唯一「必要」ベースで配分をします。 関連する用途において、独身のEtherTypeは要求されているべきです、追加分野が複数のEtherTypesに申し込むよりサブプロトコル識別子としてむしろ機能して。 EtherType配分方針は[TYPE-TUT]で説明されます。
While a fee is normally charged by IEEE 802 for the allocation of an EtherType, IEEE 802 will consider waiving the fee for allocations relating to an IETF standards track document, based on a request from the IESG.
通常、料金がIEEE802によってEtherTypeの配分に課される間、IEEE802は、IETF標準化過程ドキュメントに関連する配分のために料金を放棄すると考えるでしょう、IESGからの要求に基づいて。
2. Security Considerations
2. セキュリティ問題
As IEEE 802 becomes increasingly involved in the specification of standards for link-layer security, experience has shown that it is helpful to obtain outside review of work-in-progress prior to publication. This has proven somewhat challenging since access to IEEE 802 work-in-progress documents is often tightly controlled. For example, special permission had to be obtained for IEEE 802.11i to be able to circulate a version of its security standard-in-progress for review. A liaison between an IEEE 802 group and an IETF WG can help in obtaining the necessary level of review.
IEEE802がますますリンクレイヤセキュリティの規格の仕様にかかわるようになるとき、経験は、それに公表の前に処理中の作業のレビューの外で得るために役立っているのを示しました。 IEEE802処理中の作業ドキュメントへのアクセスがしばしばしっかり制御されるので、これはいくらかやりがいがあると判明しました。 例えば、IEEE 802.11iがレビューにおける、標準に進行中のセキュリティのバージョンを循環させることができるように、特許を得なければなりませんでした。 IEEE802グループとIETF WGとの連絡係は、必要なレベルのレビューを得るのを手伝うことができます。
Experience has also shown that IETF standards may not be written to the level of clarity required by the IEEE 802 standards process. In the case of EAP [RFC3748], the process of developing the EAP state machine specification [RFC4137] proved useful in uncovering aspects requiring clarification, and the joint review process exposed IEEE 802 and IETF documents-in-progress to wider review than might otherwise have been possible.
また、経験は、IETF規格がIEEE802標準化過程によって必要とされた明快のレベルに書かれていないかもしれないのを示しました。 IEEE802とIETFが進行中のドキュメントであるとEAP[RFC3748]の場合では、EAP州の機械仕様書[RFC4137]を開発するプロセスは明確化を必要とする局面の覆いを取る際に有用であることが分かって、共同吟味の過程は、そうでなければ、可能であったかもしれないより広いレビューに暴露しました。
Similarly, the development of [IEEE-802.11i], [RFC3748], [KEYFRAME], and [RFC4017] led to a deeper understanding of the limitations and security vulnerabilities of the EAP/AAA system. As described in [Housley], it is not advisable to develop new AAA key management applications without completing a security analysis, such as the analysis provided in [KEYFRAME].
同様に、[IEEE-802.11i]、[RFC3748]、[KEYFRAME]、および[RFC4017]の開発は制限の、より深い理解とEAP/AAAシステムのセキュリティの脆弱性につながりました。 [Housley]で説明されるように、証券分析を終了しないで新しいAAAかぎ管理アプリケーションを開発するのは賢明ではありません、[KEYFRAME]に提供された分析などのように。
Due to weaknesses in the RADIUS specification [RFC2865], it is relatively easy for protocol extensions to introduce serious security vulnerabilities. As a result, IETF review of IEEE 802 RADIUS extensions is advisable, and the RADIUS IANA Considerations [RFC3575] have been revised so as to require such a review in most cases.
RADIUS仕様[RFC2865]による弱点のために、プロトコル拡大が重大なセキュリティの脆弱性を導入するのは、比較的簡単です。 その結果、IEEE802RADIUS拡張子のIETFレビューは賢明です、そして、RADIUS IANA Considerations[RFC3575]は、多くの場合、そのようなレビューを必要とするように改訂されました。
IAB Informational [Page 6] RFC 4441 IEEE 802/IETF Relationship March 2006
2006年の[6ページ]RFC4441IEEE802/IETF関係行進の情報のIAB
3. Informative References
3. 有益な参照
[BCP102] Daigle, L. and Internet Architecture Board, "IAB
Processes for Management of IETF Liaison
Relationships", BCP 102, RFC 4052, April 2005.
[BCP102] Daigle、L.、およびインターネット・アーキテクチャ委員会、「IABはIETF連絡関係の管理のために処理します」、BCP102、RFC4052、2005年4月。
[BCP103] Trowbridge, S., Bradner, S., and F. Baker,
"Procedures for Handling Liaison Statements to and
from the IETF", BCP 103, RFC 4053, April 2005.
[BCP103] トローブリッジ、S.、ブラドナー、S.、およびF.ベイカー、「IETFとIETFからの取り扱い連絡声明のための手順」、BCP103、RFC4053(2005年4月)。
[EAPREVIEW] EAP WG letter to Roger Marks, June 2005,
http://www.drizzle.com/~aboba/EAP/review.txt.
ロジャー・マーク、2005年6月、 http://www.drizzle.com/~aboba/EAP/review.txt への[EAPREVIEW]EAP WG手紙。
[GetIEEE-802] IEEE Standards Association Get IEEE 802 (R) Program,
http://standards.ieee.org/getieee802/portfolio.html.
[GetIEEE-802]IEEE規格協会はIEEE802(R)プログラム、 http://standards.ieee.org/getieee802/portfolio.html を手に入れます。
[IDSEL] Adrangi, F., Lortz, V., Bari, F., and P. Eronen,
"Identity Selection Hints for the Extensible
Authentication Protocol (EAP)", RFC 4284, January
2006.
[IDSEL] Adrangi、F.、ロルツ、V.、バリ、F.、およびP.Eronen、「アイデンティティ選択は拡張認証プロトコル(EAP)のために暗示します」、RFC4284、2006年1月。
[Housley] Housley, R. and B. Aboba, "AAA Key Management", Work
in Progress, November 2005.
[Housley] 「AAA Key Management」というHousley、R.、およびB.Abobaは進歩、2005年11月に働いています。
[IABLINK] Aboba, B., "Architectural Implications of Link
Indications", Work in Progress, August 2005.
B.、「リンク指摘の建築含意」という[IABLINK]Abobaは進歩、2005年8月に働いています。
[IEEE-80211Liaison1]
IEEE 802.11 liaison letter to Harald Alvestrand,
February 2002,
https://www.ietf.org/IESG/LIAISON/ieee802.11.txt.
ハラルドAlvestrand、2002年2月、 https://www.ietf.org/IESG/LIAISON/ieee802.11.txt への[IEEE-80211Liaison1]IEEE802.11連絡手紙。
[IEEE-80211Liaison2]
Input To IETF EAP Working Group on Methods and Key
Strength, March 2003,
http://www.ietf.org/IESG/LIAISON/LS-ieee-80211.txt.
[IEEE-80211Liaison2]はメソッドと主要な強さ、2003年3月、 http://www.ietf.org/IESG/LIAISON/LS-ieee-80211.txt で作業部会をIETF EAPに入力しました。
[IEEE-802.11F] Institute of Electrical and Electronics Engineers,
"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.11F, June 2003 (now
deprecated).
[IEEE-802.11F]の米国電気電子技術者学会、「Inter-アクセスPointプロトコルAcross Distribution Systems Supporting IEEE802.11Operationを通したMulti-ベンダーAccess Point InteroperabilityのためのRecommended PracticeをIEEE Trial使用してください」、IEEE802.11F、2003(現在推奨しない)年6月。
[IEEE-802Liaison]
IEEE 802 Liaison letter to Bert Wijnen and Bernard
Aboba, July 26, 2004,
http://www.ietf.org/IESG/LIAISON/file41.pdf.
バートWijnenとバーナードAboba、2004年7月26日、 http://www.ietf.org/IESG/LIAISON/file41.pdf への[IEEE-802Liaison]IEEE802Liaison手紙。
IAB Informational [Page 7] RFC 4441 IEEE 802/IETF Relationship March 2006
2006年の[7ページ]RFC4441IEEE802/IETF関係行進の情報のIAB
[IEEE-802.1X-MIB]
Norseth, K., "Definitions for Port Access Control
(IEEE 802.1X) MIB", Work in Progress, November 2003.
K.、「ポートアクセス制御(IEEE 802.1X)MIBのための定義」という[IEEE-802.1X-MIB]Norsethは進歩、2003年11月に働いています。
[IEEE-802.1X] IEEE Standards for Local and Metropolitan Area
Networks: Port based Network Access Control, IEEE
P802.1X-2001, June 2001.
地方とメトロポリタンエリアネットワークの[IEEE-802.1X]IEEE規格: ポートは2001年6月にNetwork Access Control、IEEE P802.1X-2001を基礎づけました。
[IEEE-802.1X-2004]
IEEE Standards for Local and Metropolitan Area
Networks: Port based Network Access Control, IEEE
P802.1X-2004, December 2004.
地方とメトロポリタンエリアネットワークの[IEEE-802.1X-2004]IEEE規格: ポートは2004年12月にNetwork Access Control、IEEE P802.1X-2004を基礎づけました。
[IEEE-802.1D] ISO/IEC 15802-3 Information technology -
Telecommunications and information exchange between
systems - Local and metropolitan area networks -
Common specifications - Part 3: Media access Control
(MAC) Bridges, (also ANSI/IEEE Std 802.1D-1998),
1998.
[IEEE-802.1D]ISO/IEC15802-3情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク--一般的な仕様--パート3: メディアはControl(MAC)ブリッジ、(ANSI/IEEE Std 802.1D-1998も)、1998にアクセスします。
[IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area
Networks: Draft Standard for Virtual Bridged Local
Area Networks, P802.1Q, January 1998.
地方とメトロポリタンエリアネットワークの[IEEE-802.1Q]IEEE規格: 1998年1月に仮想のブリッジしているローカル・エリア・ネットワーク、P802.1Qの規格を作成してください。
[IEEE-802.3] ISO/IEC 8802-3 Information technology -
Telecommunications and information exchange between
systems - Local and metropolitan area networks -
Common specifications - Part 3: Carrier Sense
Multiple Access with Collision Detection (CSMA/CD)
Access Method and Physical Layer Specifications,
(also ANSI/IEEE Std 802.3- 1996), 1996.
[IEEE-802.3]ISO/IEC8802-3情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク--一般的な仕様--パート3: 衝突検出型搬送波検知多重アクセス(CSMA/CD)はメソッドと物理的な層の仕様、(ANSI/IEEE Std802.3- 1996も)、1996にアクセスします。
[IEEE-802.11] Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Specific Requirements
Part 11: Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) Specifications, IEEE
P802.11-2003, 2003.
[IEEE-802.11]情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク--特定のRequirements Part11: ワイヤレスのLAN媒体アクセス制御(MAC)と物理的な層(PHY)の仕様、IEEE P802.11-2003、2003。
[IEEE-802.11i] IEEE Supplement to Standard for Telecommunications
and Information Exchange Between Systems - LAN/MAN
Specific Requirements - Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY)
Specifications: Specification for Enhanced Security,
IEEE P802.11i, July 2004.
[IEEE-802.11i]IEEEはシステムの間のテレコミュニケーションと情報交換--LAN/男性決められた一定の要求--パート11の規格に補います: ワイヤレスのLAN媒体アクセス制御(MAC)と物理的な層(PHY)の仕様: 警備の強化、IEEE P802.11iのための2004年7月の仕様。
IAB Informational [Page 8] RFC 4441 IEEE 802/IETF Relationship March 2006
2006年の[8ページ]RFC4441IEEE802/IETF関係行進の情報のIAB
[IEEE-802.16e] IEEE Standard for Local and Metropolitan Area
Networks - Part 16: Air Interface for Fixed and
Mobile Broadband Wireless Access Systems, Amendment
for Physical and Medium Access Control Layers for
Combined Fixed and Mobile Operation in Licensed
Bands, IEEE P802.16e, September 2005.
地方とメトロポリタンエリアネットワークの[IEEE-802.16e]IEEE規格--パート16: 修理されてモバイルの広帯域のワイヤレス・アクセスシステムのための空気インタフェース、物理的で中型のアクセスコントロールのための修正は結合した修理されてモバイルの操作のために認可されたバンドで層にされます、IEEE P802.16e、2005年9月。
[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]連絡IEEE802.16からバーナードAboba、2005年3月17日、 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]連絡IEEE802.16からバーナードAboba、2005年5月5日、 http://ieee802.org/16/liaison/docs/L80216-05_039.pdf への手紙。
[KEYFRAME] Aboba, B., Simon, D., Arkko, J., Eronen, P., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)
Key Management Framework", Work in Progress, October
2005.
B.、サイモン、D.、Arkko、J.、Eronen、P.、およびH.Levkowetz、「拡張認証プロトコル(EAP)Key Managementフレームワーク」という[KEYFRAME]Abobaは進行中(2005年10月)で働いています。
[Liaison-Page] IETF Liaison Activities,
http://www.ietf.org/liaisonActivities.html.
[連絡ページ] IETF連絡活動、 http://www.ietf.org/liaisonActivities.html 。
[MIB-TRANSFER] Harrington, D., "Transferring MIB Work from IETF
Bridge WG to IEEE 802.1 WG", Work in Progress,
October 2005.
[MIB-転送] 「IETFブリッジWGからIEEE802.1WGまでのMIB仕事を移し」て、ハリントン、D.は進歩、2005年10月に働いています。
[Mishra] Mishra, A. and W. Arbaugh, "An Initial Security
Analysis of the IEEE 802.1X Standard", Department of
Computer Science, University of Maryland College
Park, CS-TR-4328, February 2002.
[Mishra] MishraとA.とW.Arbaugh、「IEEE 802.1X規格の初期の証券分析」、コンピュータサイエンス学部、メリーランド大学カレッジパーク、Cs-TR-4328(2002年2月)。
[Policy] IEEE Project 802 LAN MAN Standards Committee (LMSC)
Policies and Procedures, September 14, 2005,
http://www.ieee802.org/policies-and-procedures.pdf.
[方針]IEEEプロジェクト802LAN男性規格委員会(LMSC)の方針と手順、2005年9月14日、 http://www.ieee802.org/policies-and-procedures.pdf 。
[RFC1493] Decker, E., Langille, P., Rijsinghani, A., and K.
McCloghrie, "Definitions of Managed Objects for
Bridges", RFC 1493, July 1993.
1993年7月の[RFC1493]デッカーとE.とLangilleとP.とRijsinghani、A.とK.McCloghrie、「ブリッジのための管理オブジェクトの定義」RFC1493。
[RFC2108] de Graaf, K., Romascanu, D., McMaster, D., and K.
McCloghrie, "Definitions of Managed Objects for IEEE
802.3 Repeater Devices using SMIv2", RFC 2108,
February 1997.
[RFC2108] deグラーフ、K.、Romascanu、D.、マクマスター、D.、およびK.McCloghrie、「1997年2月にSMIv2"、RFC2108を使用するIEEE802.3リピータデバイスのための管理オブジェクトの定義。」
IAB Informational [Page 9] RFC 4441 IEEE 802/IETF Relationship March 2006
2006年の[9ページ]RFC4441IEEE802/IETF関係行進の情報のIAB
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible
Authentication Protocol (EAP)", RFC 2284, March 1998.
1998年の[RFC2284]BlunkとL.とJ.Vollbrecht、「ppp拡張認証プロトコル(EAP)」、RFC2284行進。
[RFC2390] Bradley, T., Brown, C., and A. Malis, "Inverse
Address Resolution Protocol", RFC 2390, September
1998.
[RFC2390] ブラッドリーとT.とブラウン、C.とA.Malis、「逆さのアドレス解決プロトコル」、RFC2390、1998年9月。
[RFC2674] Bell, E., Smith, A., Langille, P., Rijhsinghani, A.,
and K. McCloghrie, "Definitions of Managed Objects
for Bridges with Traffic Classes, Multicast Filtering
and Virtual LAN Extensions", RFC 2674, August 1999.
[RFC2674] ベル、E.、スミス、A.、Langille、P.、Rijhsinghani、A.、およびK.McCloghrie、「トラフィックのクラス、マルチキャストフィルタリング、およびバーチャルLAN拡大とのブリッジのための管理オブジェクトの定義」、RFC2674(1999年8月)。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service
(RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C.、「半径会計」、RFC2866、2000年6月。
[RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS
Accounting Modifications for Tunnel Protocol
Support", RFC 2867, June 2000.
[RFC2867] ゾルン、G.、Aboba、B.、およびD.ミットン、「トンネルプロトコルサポートのための半径会計変更」、RFC2867、2000年6月。
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
Holdrege, M., and I. Goyret, "RADIUS Attributes for
Tunnel Protocol Support", RFC 2868, June 2000.
[RFC2868]ゾルンとG.とライファーとD.とルーベンとA.とシュライバーとJ.とHoldrege、M.とI.Goyret、「トンネルプロトコルサポートのための半径属性」RFC2868(2000年6月)。
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS
Extensions", RFC 2869, June 2000.
[RFC2869] RigneyとC.とWillats、W.とP.カルフーン、「半径拡大」、RFC2869、2000年6月。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and
IPv6", RFC 3162, August 2001.
[RFC3162] AbobaとB.とゾルン、G.とD.ミットンと「半径とIPv6"、RFC3162、2001年8月。」
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575, July
2003.
[RFC3575] Aboba、B.、「半径(ユーザサービスにおけるリモート認証ダイヤル)のためのIANA問題」、RFC3575、2003年7月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote
Authentication Dial In User Service) Support For
Extensible Authentication Protocol (EAP)", RFC 3579,
September 2003.
[RFC3579]Aboba、B.とP.カルフーン、「拡張認証プロトコル(EAP)の半径(ユーザサービスにおけるリモート認証ダイヤル)サポート」RFC3579(2003年9月)。
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J.
Roese, "IEEE 802.1X Remote Authentication Dial In
User Service (RADIUS) Usage Guidelines", RFC 3580,
September 2003.
[RFC3580] コングドン、P.、Aboba、B.、スミス、A.、ゾルン、G.、およびJ.Roese、「ユーザサービス(半径)用法ガイドラインのIEEE 802.1Xのリモート認証ダイヤル」、RFC3580(2003年9月)。
[RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB",
RFC 3621, December 2003.
[RFC3621]バーガーとA.とD.Romascanu、「パワーイーサネットMIB」、RFC3621 2003年12月。
IAB Informational [Page 10] RFC 4441 IEEE 802/IETF Relationship March 2006
2006年の[10ページ]RFC4441IEEE802/IETF関係行進の情報のIAB
[RFC3635] Flick, J., "Definitions of Managed Objects for the
Ethernet-like Interface Types", RFC 3635, September
2003.
[RFC3635] 軽打、J.、「イーサネットのようなインターフェース型のための管理オブジェクトの定義」、RFC3635、2003年9月。
[RFC3636] Flick, J., "Definitions of Managed Objects for IEEE
802.3 Medium Attachment Units (MAUs)", RFC 3636,
September 2003.
[RFC3636] 軽打、J.、「IEEE802.3媒体付属ユニット(MAUs)管理オブジェクトの定義」、RFC3636、2003年9月。
[RFC3637] Heard, C.M., Ed., "Definitions of Managed Objects for
the Ethernet WAN Interface Sublayer", RFC 3637,
September 2003.
聞かれた[RFC3637]、C.M.、エド、「イーサネットWANインタフェース副層のための管理オブジェクトの定義」、RFC3637、9月2003日
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J.,
and H. Levkowetz, "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[RFC3748]Aboba、B.、Blunk、L.、Vollbrecht、J.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、2004年6月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.
[RFC4017] スタンリー、D.、ウォーカー、J.、およびB.Aboba、「無線のLANのための拡張認証プロトコル(EAP)方法要件」、RFC4017(2005年3月)。
[RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture
Taxonomy for Control and Provisioning of Wireless
Access Points (CAPWAP)", RFC 4118, June 2005.
[RFC4118]の陽、L.、Zerfos、P.、およびE.Sadot、「ワイヤレス・アクセスのコントロールと食糧を供給する構造分類学は(CAPWAP)を指します」、RFC4118、2005年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.、ペトローニ、N.、およびY.オオバ)は「拡張認証プロトコル(EAP)同輩と固有識別文字のためにマシンを述べます」、RFC4137、2005年8月。
[RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers
of MIB Documents", BCP 111, RFC 4181, September 2005.
聞かれた[RFC4181]、C.、エド、「MIBドキュメントの作者と評論家へのガイドライン」、BCP111、RFC4181、9月2005日
[RFC4188] Norseth, K. and E. Bell, "Definitions of Managed
Objects for Bridges", RFC 4188, September 2005.
[RFC4188] NorsethとK.とE.ベル、「橋への管理オブジェクトの定義」、RFC4188、2005年9月。
[RFC4363] Levi, D. and D. Harrington, "Definitions of Managed
Objects for Bridges with Traffic Classes, Multicast
Filtering, and Virtual LAN Extensions", RFC 4363,
January 2006.
[RFC4363]レビ、D.とD.ハリントン、「交通のクラス、マルチキャストフィルタリング、およびバーチャルLAN拡大との橋への管理オブジェクトの定義」RFC4363(2006年1月)。
[TYPE-TUT] IEEE Standards Association, "Use of the IEEE Assigned
EtherType Field with IEEE Std 802.3, 1998 Edition
Local and Metropolitan Area Networks",
http://standards.ieee.org/regauth/ethertype/
type-tut.html.
[TYPE-ツタンカーメン]IEEE規格協会、「IEEEの使用はIEEE Std802.3、1998版がローカルであることでのEtherType分野とメトロポリタンエリアネットワークを割り当てました」、 http://standards.ieee.org/regauth/ethertype/ タイプ-tut.html。
IAB Informational [Page 11] RFC 4441 IEEE 802/IETF Relationship March 2006
2006年の[11ページ]RFC4441IEEE802/IETF関係行進の情報のIAB
4. Acknowledgements
4. 承認
The authors would like to acknowledge Les Bell, Dan Romascanu, Dave Harrington, Tony Jeffree, Fred Baker, Paul Congdon, Paul Langille, and C. M. Heard for contributions to this document.
作者はこのドキュメントへの貢献のためにレス・ベル、ダンRomascanu、デーヴ・ハリントン、トニーJeffree、フレッド・ベイカー、ポール・コングドン、ポールLangille、およびC.M.Heardを承認したがっています。
IAB Informational [Page 12] RFC 4441 IEEE 802/IETF Relationship March 2006
2006年の[12ページ]RFC4441IEEE802/IETF関係行進の情報のIAB
Appendix A. Relationship History
付録A.関係歴史
A.1. MIB Development
A.1。 MIB開発
A.1.1. Bridge MIB
A.1.1。 橋のMIB
The relationship between IETF and IEEE 802 began in the late 1980s with SNMP MIBs developed for the original IEEE 802.1D standard. Because the IEEE specification [IEEE-802.1D] contained only a functional definition of the counters and operations, the IETF's Bridge MIB WG took on the role of defining the Bridge MIB [RFC1493], which was published as an RFC. Fred Baker and later Keith McCloghrie served as chairs of the Bridge WG.
SNMP MIBsが元のIEEE 802.1D規格のために開発されている状態で、IETFとIEEE802との関係は1980年代後半に始まりました。 IEEE仕様[IEEE-802.1D]がカウンタと操作の機能定義だけを含んだので、IETFのBridge MIB WGはRFCとして発行されたBridge MIB[RFC1493]を定義する役割を引き受けました。 フレッド・ベイカーと後のキースMcCloghrieはBridge WGのいすとして勤めました。
The Bridge MIB combined the work of Keith McCloghrie, Eric Decker, and Paul Langille, with spanning tree expertise provided by Anil Rijsinghani. Mick Seaman (author of 802.1D) and Floyd Backes (who had written the code for Digital Equipment's spanning tree implementation) were the main contacts within IEEE 802.1. Since Mick, Floyd, Anil, and Paul all worked for Digital Equipment Corporation at the time, much of the coordination between IEEE 802.1 and the Bridge MIB WG took place in the hallways at Digital, rather than within official channels.
Bridge MIBはキースMcCloghrie、エリックDecker、およびポールLangilleの仕事を結合しました、スパニングツリー専門的技術がAnil Rijsinghaniによって提供されている状態で。 ミックSeaman(802.1Dの作者)とフロイドBackes(デジタル・イクイップメントのスパニングツリー実現のためにコードを書いた)はIEEE802.1の中の主な接触でした。 ミック、フロイド、Anil、およびポールが当時DECですべて働いていたので、IEEE802.1とBridge MIB WGの間のコーディネートの多くが公式のルートの中でというよりむしろDigitalで廊下で行われました。
A.1.2. MAU and Hub MIBs
A.1.2。 MAUとハブMIBs
In the early 1990s when IEEE 802.3 was completing the first Ethernet standards, SNMP was not yet the dominant network management protocol. As a result, a 'protocol independent' MIB is included in Clause 30 of the IEEE 802.3 standard [IEEE-802.3], which is updated each time the Ethernet standard is enhanced to support higher speeds. In parallel, IEEE 802 participants interested in network management were active in the formation of the IETF HUBMIB WG, which took on the task of transforming IEEE 802 definitions into SNMP MIBs documented as Standards Track RFCs. This included Dan Romascanu, Chair of the IETF HUBMIB WG since 1996.
1990年代に、IEEE802.3が最初のイーサネット規格を完成していた前半しかし、SNMPは優位なネットワーク管理プロトコルではありませんでした。 その結果、'プロトコル独立者'MIBはIEEE802.3規格[IEEE-802.3]のClause30に含まれています。(イーサネット規格が、より高い速度を支持するために高められるたびに規格はアップデートされます)。 平行では、ネットワークマネージメントに興味を持っているIEEE802関係者はIETF HUBMIB WGの構成で活発でした。(IETF HUBMIB WGはIEEEを変えるタスクでStandards Track RFCsとして記録されたSNMP MIBsに802の定義を取りました)。 1996年以来これはダンRomascanu、IETF HUBMIB WGの議長を含んでいました。
The Charter of the HUBMIB WG explicitly mentions that the IEEE 802.3 standard is the starting point for the Ethernet MIB, but at the same time reserves the right to deviate from the IEEE model -- either to cover only part of the capabilities offered by the standard or to add MIB objects that are not directly derived from the IEEE model (mostly implemented in software). If management needs lead to requirements for hardware support, the IETF HUBMIB WG is to provide this input to IEEE 802.3 in a timely manner.
HUBMIB WGの憲章は、IEEE802.3規格がイーサネットMIBのための出発点であると明らかに言及しますが、同時に、IEEEモデルからどちらか能力の一部だけが規格で提供したカバーに逸れるか、またはIEEEモデル(ソフトウェアでほとんど実行される)から直接得られないMIB物を加える権利を保有します。 管理の必要性がハードウェアサポートのための要件につながるなら、IETF HUBMIB WGは直ちにこの入力をIEEE802.3に供給することになっています。
IAB Informational [Page 13] RFC 4441 IEEE 802/IETF Relationship March 2006
2006年の[13ページ]RFC4441IEEE802/IETF関係行進の情報のIAB
Cooperation between the IETF HUBMIB WG and IEEE 802.3 has continued for more than a decade until today, mostly based on the work of a few editors supported by their companies, who are taking the IEEE standards and mapping them into a management data model and MIBs. Work items include:
IETF HUBMIB WGとIEEE802.3との協力は10年間以上の間、彼らの会社によって支持されたIEEE規格とそれらを写像するのを管理データモデルに連れていって、MIBsである数人のエディタの仕事に今日、ほとんど基づくまで続いています。 仕事項目は:
- The Hub MIB [RFC2108], which has gone through three iterations,
and is probably ending its evolution, as repeaters are less used
in Ethernets.
- The MAU MIB, which has been updated each time a new Ethernet speed
is developed, with [RFC3636] accommodating 10-Gbps Ethernet.
- The Ethernet-like Interfaces MIB was not originally a work item
of the HUBMIB WG, but the WG took responsibility for a revision,
published as [RFC3635].
- The WAN Interface Sublayer MIB [RFC3637] and the Power Ethernet MIB
[RFC3621] were developed in IEEE 802.3 and the IETF HUBMIB WG.
- Hub MIB[RFC2108](そうした)は、3つの繰り返しに直面して、たぶん発展を終わらせています、リピータがEthernetsでそれほど使用されないとき。 - MAU MIBであり、[RFC3636]が10-Gbpsイーサネットを収容する状態で、その都度新しいイーサネット速度にどれをアップデートしたかは開発されます。 - 元々、イーサネットのようなInterfaces MIBはHUBMIB WGの仕事項目ではありませんでしたが、WGは[RFC3635]として発行された改正への責任を取りました。 - WAN Interface Sublayer MIB[RFC3637]とPowerイーサネットMIB[RFC3621]はIEEE802.3とIETF HUBMIB WGで開発されました。
In 2000, an official liaison was established between IEEE 802.3 and the IETF HUBMIB WG, and Dan Romascanu was appointed IETF liaison. The conditions of the liaison agreement allows editors and other participants in the IETF HUBMIB WG access to work-in-progress drafts in IEEE 802.3 on a personal basis, for the purpose of working on MIBs before the release of the standard. However, the username and password for IEEE 802.3 document access are not for publication on any IETF website or mailing list.
2000年に、公式の連絡係はIEEE802.3とIETF HUBMIB WGの間で確立されました、そして、ダンRomascanuはIETF連絡に任命されました。 連絡協定の状態は個人ベースではIEEE802.3の処理中の作業草稿へのIETF HUBMIB WGアクセスのエディタと他の関係者を許容します、規格のリリースの前にMIBsに働く目的のために。 しかしながら、IEEE802.3ドキュメントアクセスのためのユーザ名とパスワードはどんなIETFウェブサイトやメーリングリストに関する公表のためのものではありません。
A.1.3. 802.1p/Q MIB
A.1.3。 802.1 p/Q MIB
In 1996 as the 802.1p and 802.1Q [IEEE-802.1Q] standards were being completed, a need was perceived for development of an SNMP MIB, based on the management clauses of those standards. IEEE 802 management clauses are written in a manner that was independent of any protocol that may be used to implement them.
802.1pと802.1Q[IEEE-802.1Q]規格が完成していたとき、必要性はSNMP MIBの開発のために知覚されました、1996年にそれらの規格の管理節に基づいて。 IEEE802管理節はそれらを実行するのに使用されるどんなプロトコルからも独立している方法で書かれています。
At that time, there were a number of proprietary VLAN management MIBs that were both inadequate and difficult to understand. As a result, there was a need for a more comprehensive, simpler model for VLAN management, along with the priority and multicast filtering management also defined by these standards.
その時、不十分で、かつ理解しているのが難しかった独占VLAN管理MIBsの数がありました。 その結果、VLAN管理の、より包括的で、より簡単なモデルの必要がありました、また、これらの規格によって定義された管理をフィルターにかける優先権とマルチキャストと共に。
A small group of participants from the 802.1 WG began working on the problem independently, then combined their work. The original authors of the Bridge MIB, on which some of the work was based, reviewed the initial work.
802.1WGからの関係者の小さいグループは、独自に問題に働いてい始めて、次に、彼らの仕事を結合しました。 Bridge MIBの原作者は初期の仕事を見直しました。(いくらかの仕事がBridge MIBに基づきました)。
IAB Informational [Page 14] RFC 4441 IEEE 802/IETF Relationship March 2006
2006年の[14ページ]RFC4441IEEE802/IETF関係行進の情報のIAB
By the end of 1997, the work was ready for review by a larger audience. Andrew Smith worked with Keith McCloghrie, chair of the Bridge MIB WG (dormant at the time), to obtain a meeting slot at the March 1998 IETF meeting. After this, review and development of the MIB continued on the IETF standards track.
1997年の終わりまでには、仕事は、より大きい聴衆によるレビューの準備ができていました。 アンドリュー・スミスは、1998年3月のIETFミーティングでミーティングスロットを得るためにキースMcCloghrie、Bridge MIB WGのいす(当時、眠っている)で働いていました。 この後、MIBのレビューと開発はIETF標準化過程の上で続きました。
During the development of [RFC2674], there was no official inter- working between the IETF Bridge MIB and IEEE 802.1 groups. Development of this MIB was successful, because the main developers (Andrew Smith and Les Bell) were involved in both the IEEE 802.1 and the IETF Bridge MIB WGs.
[RFC2674]の開発の間、IETF Bridge MIBとIEEE802.1グループの間には、公式の相互の働きがありませんでした。 このMIBの開発はうまくいきました、主な開発者(アンドリュー・スミスとレス・ベル)がIEEE802.1とIETF Bridge MIB WGsの両方にかかわったので。
A.1.4. 802.3ad and 802.1X MIBs
A.1.4。 802.3 広告と802.1X MIBs
As part of the IEEE 802.3ad and IEEE 802.1X standards work, it was decided that it would be better to develop a MIB as part of the standards, rather than wait until an IETF WG was formed, and develop the MIBs separately, so as to avoid a significant time lag in their development.
IEEE 802.3adとIEEE 802.1X標準化作業の一部として、IETF WGが形成されるまで待っていて、別々にMIBsを開発するより規格の一部としてむしろMIBを開発しているほうがよいと決められました、彼らの開発における重要なタイムラグを避けるために。
As Les Bell was the participant in IEEE 802.3ad and IEEE 802.1 most familiar with SNMP MIB development, he put together the initial MIBs based on the management framework the groups had come up with. Additional assistance was then received for both MIBs from within the IEEE 802.3ad and IEEE 802.1X groups. Tony Jeffree, editor of both standards, acted as editor of the MIBs as well.
レス・ベルがSNMP MIB開発に最もなじみ深いIEEE 802.3adとIEEE802.1の関係者であったので、彼はグループが思いついた管理枠組みに基づく初期のMIBsを組み立てました。 そして、IEEE 802.3adからのMIBsとIEEE 802.1Xグループの両方のために追加援助を受けました。 トニーJeffree(両方の規格のエディタ)はまた、MIBsのエディタとして務めました。
The problem with IEEE 802 developing these MIBs without IETF involvement was the lack of review. IEEE 802 members are generally not familiar with MIBs, and very few comments were received as part of the balloting process for either MIB.
IETFかかわり合いなしでこれらのMIBsを開発するIEEE802に関する問題はレビューの不足でした。 一般に、IEEE802人のメンバーはMIBsに詳しくはありません、そして、MIBのために投票の過程の一部としてほんのわずかなコメントを受けました。
In the case of the IEEE 802.3ad MIB, this meant that basic errors were not discovered until just before publication. Unfortunately, by then it was too late, and the corrections submitted to the IEEE 802.3ad chair and document editor did not get applied to the published version.
IEEE 802.3ad MIBの場合では、これは、基本的な誤りが公表のすぐ前まで発見されなかったことを意味しました。 残念ながら、その時までには、遅過ぎました、そして、IEEE 802.3adいすとドキュメントエディタに提出された修正は発行されたバージョンに適用されませんでした。
Subsequent to the publication of [IEEE-802.1X], the IEEE 802.1X MIB was reviewed within the Bridge WG, and several syntax errors were found. These have been corrected in the version of the MIB module that was developed as part of [IEEE-802.1X-2004]. However, while [IEEE-802.1X-MIB] was originally published as a work in progress within the Bridge WG, there was not sufficient interest to complete its publication as an RFC. As a result, the draft has now expired.
[IEEE-802.1X]の公表にその後です、IEEE 802.1X MIBはBridge WGの中で見直されました、そして、いくつかの構文エラーが見つけられました。 [IEEE-802.1X-2004]の一部として開発されたMIBモジュールのバージョンでこれらを修正してあります。 しかしながら、[IEEE-802.1X-MIB]は元々処理中の作業としてBridge WGの中で発行されましたが、RFCとして公表を完成できるくらいの関心がありませんでした。 その結果、草稿は現在、期限が切れました。
IAB Informational [Page 15] RFC 4441 IEEE 802/IETF Relationship March 2006
2006年の[15ページ]RFC4441IEEE802/IETF関係行進の情報のIAB
A.1.5. 802.1t, 802.1u, 802.1v, and 802.1w MIBs
A.1.5。 802.1 t、802.1u、802.1v、および802.1w MIBs
802.1t and 802.1u were minor amendments to the 802.1D and 802.1Q standards, requiring some additions to the MIB published in [RFC2674]. 802.1v was a new feature extending the VLAN classification schemes of 802.1Q, also requiring extensions to [RFC2674]. 802.1w was a new version of Spanning Tree, requiring rewriting of part of [RFC1493].
802.1 [RFC2674]で発行されたMIBへのいくつかの追加を必要として、tと802.1uは802.1Dと802.1Q規格の小さい方の修正でした。 802.1 vはまた、[RFC2674]に拡大を必要として、802.1QのVLAN分類計画を広げる新機能でした。 802.1 [RFC1493]の一部について書き直すのが必要であることで、wはSpanning Treeの新しいバージョンでした。
When Les Bell took on the role of Chair of the IETF Bridge MIB WG in 2001, these issues were raised as new work items and two volunteers were found to become editors of the Internet-Drafts. A work item was also included to publish the IEEE 802.1X MIB as an Informational RFC.
レス・ベルが2001年にIETF Bridge MIB WGの議長の役割を引き受けたとき、新しい仕事項目と2人のボランティアがインターネット草稿のエディタになるのがわかったとき、これらの問題は提起されました。 また、仕事項目は、Informational RFCとしてIEEE 802.1X MIBを発行するために含まれていました。
This approach worked well for a while, but it then became difficult for the participants, including the editors and the Chair, to sustain a level of interest sufficient to overcome the difficulties introduced by budget cutbacks. As a result, the drafts have now expired, although there are no significant technical issues outstanding.
このアプローチはしばらくうまくいきましたが、次に、関係者にとって難しくなりました、興味があるレベルを予算削減で導入された困難は克服できるくらい支えるためにエディタと議長を含んでいて。 その結果、未払いのどんな重要な専門的な問題もありませんが、草稿は現在、期限が切れました。
A.2. AAA/EAP
A.2。 AAA/EAP
Since the late 1990s, IEEE 802.1 has been involved in work relating to authentication and authorization [IEEE-802.1X], which led to discovery of issues in several IETF specifications, including [RFC2284] and [RFC2869]. Similarly, IETF participants have uncovered issues in early versions of the RADIUS usage specifications such as [RFC3580], as well as the IEEE 802.1X state machine [Mishra].
1990年代後半以来IEEE802.1はいくつかのIETF仕様に基づく、問題の発見につながった認証と認可[IEEE-802.1X]に関連する仕事にかかわっています、[RFC2284]と[RFC2869]を含んでいて。 同様に、IETF関係者はRADIUS用法仕様の早めのバージョンの[RFC3580]などの問題を発見しました、IEEE 802.1X州のマシン[Mishra]と同様に。
In order to address these issues and ensure synchronization between IEEE 802.1 and the IETF EAP and AAA WGs, a liaison arrangement was utilized during the development of [IEEE-802.1X] and [IEEE-802.1X-2004].
IEEE802.1と、IETF EAPとAAA WGsの間でこれらの問題を記述して、同期を確実にするために、連絡アレンジメントは[IEEE-802.1X]と[IEEE-802.1X-2004]の開発の間、利用されました。
IEEE 802.11 groups such as IEEE 802.11i and IEEE 802.11F have also become dependent on EAP and AAA work. This relationship was more challenging since IEEE 802.11 required development of EAP methods and the EAP Key Management Framework, which represented substantial new IETF work, as opposed to the clarifications and updates required by IEEE 802.1.
IEEE802.11はIEEE 802.11iなどのように分類します、そして、また、IEEE802.11FはEAPとAAA仕事に依存するようになりました。 IEEE802.11が開発を必要としたので、この関係はEAP方法とEAP Key Management Frameworkをよりやりがいがありました、IEEE802.1によって必要とされた明確化とアップデートと対照的に。(Frameworkはかなりの新しいIETF仕事を表しました)。
A.2.1. IEEE 802.1X
A.2.1。 IEEE 802.1X
IEEE 802.1X-2001 [IEEE-802.1X] defined the encapsulation of EAP [RFC2284] over IEEE 802, as well as a state machine for the joint operation of IEEE 802.1X and EAP.
IEEE 802.1X-2001[IEEE-802.1X]はIEEE 802.1XとEAPの共同経営のためにIEEE802、および州のマシンの上でEAP[RFC2284]のカプセル化を定義しました。
IAB Informational [Page 16] RFC 4441 IEEE 802/IETF Relationship March 2006
2006年の[16ページ]RFC4441IEEE802/IETF関係行進の情報のIAB
During the development of IEEE 802.1X-2001, several problems were discovered in the specification for RADIUS/EAP [RFC2869], and as a result, work was begun on a revision [RFC3579]. In addition, clarifications were required on how RADIUS attributes defined in [RFC2865], [RFC2866], [RFC2867], [RFC2868], [RFC2869], and [RFC3162] would be interpreted by IEEE 802.1X implementations. To address this, a non-normative RADIUS usage appendix was added to [IEEE-802.1X], and published as [RFC3580].
IEEE 802.1X-2001の開発の間、いくつかの問題がRADIUS/EAP[RFC2869]のための仕様で発見されました、そして、その結果、仕事は改正[RFC3579]のときに始められました。 さらに、[RFC2865]、[RFC2866]、[RFC2867]、[RFC2868]、[RFC2869]、および[RFC3162]で定義されたRADIUS属性がIEEE 802.1X実現でどう解釈されるだろうかに関して明確化が必要でした。 非標準のRADIUS用法付録は、これを記述するために、[IEEE-802.1X]に加えられて、[RFC3580]として発行されました。
Subsequent to the publication of [IEEE-802.1X], a formal analysis of the IEEE 802.1X state machine by the University of Maryland disclosed several security issues [Mishra]. Discussion within IEEE 802.1 pointed to lack of clarity in [RFC2284], which resulted from the absence of a specification for the EAP state machine specification.
[IEEE-802.1X]の公表にその後です、メリーランド大学によるIEEE 802.1X州のマシンの形式的分析はいくつかの安全保障問題[Mishra]を明らかにしました。 IEEE802.1の中の議論は[RFC2284]の明快の不足を示しました。(]はEAP州の機械仕様書のための仕様の欠如から生じました)。
At that time, EAP was handled within the IETF PPPEXT WG, which was largely inactive. In order to undertake work on a revised EAP specification as well as the specification of the EAP state machine, the IETF EAP WG was formed in July 2002. Bernard Aboba, a participant in IEEE 802.1 as well as PPPEXT, was named co-chair.
その時、EAPはIETF PPPEXT WGの中で扱われました。IETF PPPEXT WGは主に不活発でした。 EAP州のマシンの仕様と同様に改訂されたEAP仕様に対する仕事を引き受けるために、IETF EAP WGは2002年7月に形成されました。 バーナードAboba(PPPEXTと同様にIEEE802.1の関係者)は共同議長に任命されました。
Work on the EAP state machine [RFC4137] and revised EAP specification [RFC3748] proceeded in parallel within the EAP WG, with issues or changes in one document requiring changes to the other document, as well as revisions to [IEEE-802.1X-2004]. The revised RADIUS/EAP specification [RFC3579] was also reviewed within the EAP WG, since at that time the RADEXT WG had not yet been formed.
EAP州のマシン[RFC4137]と改訂されたEAP仕様[RFC3748]への作業はEAP WGの中で平行で続きました、1通のドキュメントにおける問題か変化がもう片方のドキュメントに釣り銭がいて、[IEEE-802.1X-2004]への改正と同様に。 また、改訂されたRADIUS/EAP仕様[RFC3579]はEAP WGの中で再検討されました、RADEXT WGがその時まだ形成されていなかったので。
The revision to IEEE 802.1X [IEEE-802.1X-2004] included the following:
IEEE 802.1X[IEEE-802.1X-2004]への改正は以下を含んでいました:
- a revised RADIUS usage appendix based on [RFC3580]
- clarifications based on [RFC3579]
- a revised IEEE 802.1X state machine, based on [RFC3748] and
[RFC4137]
- そして改訂されたRADIUS用法付録は改訂されたIEEE 802.1X州のマシンを[RFC3580]([RFC3579]に基づく明確化)に基礎づけました、[RFC3748]に基づいて。[RFC4137]
Due to the deep dependencies between [IEEE-802.1X-2004], [RFC3748], and [RFC4137], a liaison was established between IEEE 802.1X-REV and the IETF EAP WG in August 2002. This enabled participants in the IETF EAP WG to obtain access to the IEEE 802.1X revision in progress.
[IEEE-802.1X-2004]と、[RFC3748]と、[RFC4137]の間の深い依存のため、連絡係は2002年8月にIEEE 802.1X-REVとIETF EAP WGの間で確立されました。 これは、IETF EAP WGの関係者が進行中のIEEE 802.1X改正へのアクセスを得るのを可能にしました。
IEEE 802 groups are duty bound to consider all comments received, regardless of their origin. This allows IETF participants to comment as part of the IEEE 802 ballot process, regardless of their voting status within IEEE 802. Where there is active cooperation, IETF WGs may be made aware that IEEE 802 ballots are occurring and that their
IEEE802グループはそれらの起源にかかわらず受けられたすべてのコメントを考えるのにおいて義務があります。 これで、IETF関係者はIEEE802投票の過程の一部としてコメントできます、彼らがIEEE802の中で状態について投票することにかかわらず。 積極的な協力があるところでIETF WGsをIEEE802投票が発生とそれであることを意識するようにするかもしれない、それら
IAB Informational [Page 17] RFC 4441 IEEE 802/IETF Relationship March 2006
2006年の[17ページ]RFC4441IEEE802/IETF関係行進の情報のIAB
comments are welcome. IEEE 802.1X-REV and IEEE 802.11i ballots were announced on the EAP WG mailing list, as are IEEE 802 interim meeting arrangements.
コメントを歓迎します。 IEEE 802.1X-REVとIEEE 802.11i投票はEAP WGメーリングリストで発表されました、IEEE802の当座のミーティングのセッティングのように。
Similarly, during the IEEE 802.1X-REV ballot process, comments were received relating to [RFC3748], [RFC4137], and [RFC3579]. These comments were tracked on the EAP WG Issues List, and were subsequently addressed in the documents.
同様に、IEEE 802.1X-REV投票の過程の間、[RFC3748]、[RFC4137]、および[RFC3579]に関連しながら、コメントを受けました。 これらのコメントは、EAP WG Issues Listで追跡されて、次に、ドキュメントに記述されました。
In April 2003, [RFC3580] was approved by the IESG for publication as an RFC, and in May 2003, [RFC3579] was approved for publication as an RFC. The review process for both drafts involved bringing the documents to IETF last call, and then reposting the IETF last-call announcement on the IEEE 802.1 mailing list. While ballot comments on IEEE 802.1X-REV were also reflected in changes to both documents, it was necessary for both documents to be approved for publication as RFCs well in advance of Sponsor Ballot, in order to ensure that RFC numbers would be assigned in time, so as to avoid delaying publication.
2003年4月に、[RFC3580]は公表のためにRFCとしてIESGによって承認されました、そして、2003年5月に、[RFC3579]は公表のためにRFCとして承認されました。 両方の草稿のための吟味の過程は、IEEE802.1メーリングリストで最後の呼び出しをIETFへのドキュメントにもたらして、IETF最後の呼び出し発表を当時の再び投函にもたらすことを伴いました。 また、IEEE 802.1X-REVの投票コメントは両方のドキュメントへの変化に反映されましたが、両方のドキュメントが公表のためにRFCsとしてSponsor Ballotのよく前で承認されるのが必要でした、RFC番号が時間内に割り当てられるのを確実にするために、出版を遅らせるのを避けるために。
Overall, despite the complex inter-dependencies between [IEEE-802.1X-2004], [RFC3748], and [RFC4137], the documents were produced without undue delay. This was largely due to the work of joint participants in IEEE 802.1 and IETF EAP WG.
全体的に見て、[IEEE-802.1X-2004]と、[RFC3748]と、[RFC4137]の間の複雑な相互依存性にもかかわらず、ドキュメントは不当な遅延なしで製作されました。 これは主にIEEE802.1とIETF EAP WGでの共同関係者の仕事のためでした。
A.2.2. IEEE 802.11i
A.2.2。 IEEE 802.11i
IEEE 802.11i was chartered to specify security enhancements to [IEEE-802.11]. Since [IEEE-802.11i] utilized IEEE 802.1X, it depended on [IEEE-802.1X-2004]. As a result, IEEE 802.11i and IEEE 802.1 held joint meetings at IEEE 802 plenaries and established a liaison arrangement that permitted members of either group (as well as EAP WG participants) access to IEEE 802.11i work-in-progress.
IEEE 802.11iは、[IEEE-802.11]にセキュリティ増進を指定するためにチャーターされました。 [IEEE-802.11i]がIEEE 802.1Xを利用したので、それは[IEEE-802.1X-2004]によりました。 その結果、IEEE 802.11iとIEEE802.1はIEEE802plenariesで合同会議を開催して、IEEE 802.11i処理中の作業へのグループ(EAP WGと同様に関係者)アクセスのメンバーを可能にした連絡アレンジメントを確立しました。
Since [IEEE-802.11i] depended on [IEEE-802.1X-2004], it inherited the dependencies of [IEEE-802.1X-2004], including work on EAP, EAP methods, and AAA support for EAP. In addition, since IEEE 802.11i utilized EAP for key management whereas [IEEE-802.1X] does not, additional security requirements arose with respect to EAP methods.
[IEEE-802.11i]が[IEEE-802.1X-2004]によったので、[IEEE-802.1X-2004]の依存を引き継ぎました、EAPのEAPへの作業、EAP方法、およびAAAサポートを含んでいて。 さらに、[IEEE-802.1X]は起こりませんでしたが、IEEE 802.11iがかぎ管理にEAPを利用したので、追加担保要件はEAP方法に関して起こりました。
In February 2002, IEEE 802.11 sent a liaison letter to the IESG [IEEE-80211Liaison1] requesting additional work on EAP, EAP methods, and EAP key management. This letter was presented at the second EAP BOF at IETF 53, and was used as input to the EAP WG charter. In March 2003, another liaison letter was presented, providing further clarifications on requirements for EAP method work [IEEE-80211Liaison2]. This included a request from IEEE 802.11i for
2002年2月に、IEEE802.11はEAPへの追加作業、EAP方法、およびEAPかぎ管理を要求するIESG[IEEE-80211Liaison1]に連絡手紙を送りました。 この手紙は、IETF53の第2EAP BOFに提示されて、EAP WG特許に入力されるように使用されました。 2003年3月に、EAP方法仕事[IEEE-80211Liaison2]のための要件でさらなる明確化を提供して、別の連絡手紙は提示されました。 これはIEEE 802.11iからのa要求を含んでいました。
IAB Informational [Page 18] RFC 4441 IEEE 802/IETF Relationship March 2006
2006年の[18ページ]RFC4441IEEE802/IETF関係行進の情報のIAB
the EAP WG to consider changing the mandatory-to-implement EAP method within [RFC3748], so as to provide a method meeting the security requirements of IEEE 802.11i.
IEEE 802.11iのセキュリティ要件を方法ミーティングに提供するために[RFC3748]の中で実行するために義務的なEAP方法を変えると考えるEAP WG。
During IETF 56, the request for changing the mandatory-to-implement method was considered by the EAP WG. A recommendation was made by the Internet Area Director Erik Nordmark that the IEEE 802.11i requirements be documented in an RFC and that the EAP WG consider the security requirements for EAP methods in various situations. It was recommended not to change the mandatory-to-implement method, since the EAP WG was not chartered to do work on methods. However, it was decided to produce a document describing the EAP method requirements for WLAN usage. This document was subsequently published as [RFC4017].
IETF56の間、実行するために義務的な方法を変えるのを求める要求はEAP WGによって考えられました。 推薦はIEEE 802.11i要件があるインターネットAreaディレクターエリックNordmarkによって作られていて、RFCとそれに記録されて、EAP WGが様々な状況においてEAP方法のためのセキュリティ要件を考えるということでした。 実行するために義務的な方法を変えないのはお勧めでした、EAP WGが方法に取り組むためにチャーターされなかったので。 しかしながら、それは、WLAN用法のためのEAP方法要件について説明するドキュメントを製作するために決められました。 このドキュメントは次に、[RFC4017]として発表されました。
Most recently, IEEE 802.11r has been involved in discussions relating to fast handoff, which may potentially require AAA extensions as well as changes to the EAP key hierarchy. However, the direction of this work has not yet been determined so that no liaison request has been formulated yet.
ごく最近、IEEE 802.11rは速い移管に関連する議論にかかわりました。潜在的に、移管はEAPの主要な階層構造への変化と同様にAAA拡大を必要とするかもしれません。 しかしながら、この仕事の指示がまだ決定していないので、連絡要求は全くまだ定式化されていません。
In April 2003, Dorothy Stanley was appointed liaison from IEEE 802.11 to the IETF, in order to help coordinate between IEEE 802.11 and IETF WGs, including AAA, BMWG, CAPWAP, and EAP.
2003年4月に、ドロシー・スタンリーはIEEE802.11からIETFまでの連絡に任命されました、IEEE802.11とIETF WGsの間で調整するのを助けるために、AAA、BMWG、CAPWAP、およびEAPを含んでいて。
A.2.3. IEEE 802.11F
A.2.3。 IEEE802.11F
IEEE 802.11F was chartered with development of a recommended practice for Inter-Access Point Communications. As part of development of an Inter-Access Point Protocol (IAPP), it was necessary to secure communications between the access points, as well as to support the reverse resolution of the MAC address of the previous access point to its IP address, so as to allow the two access points to communicate via IAPP. Since the two access points might not be on the same link, Inverse ARP [RFC2390] was not considered sufficient in all cases.
IEEE802.11に、FはInter-アクセスPoint Communicationsのために推奨案の開発でチャーターされました。 Inter-アクセスPointプロトコル(IAPP)の開発の一部として、アクセスポイントのコミュニケーションを保証して、前のアクセスポイントのMACアドレスの逆の解決をIPアドレスに支持するのが必要でした、2つのアクセスポイントがIAPPを通って交信するのを許容するために。 以来、同じリンクの上に2つのアクセスポイントがなかったかもしれなくて、またInverse ARP[RFC2390]はすべての場合に十分であると考えられませんでした。
IEEE 802.11F elected to extend the RADIUS protocol [RFC2865] to provide inverse address resolution as well as IPsec key management. This was accomplished via use of Vendor-Specific Attributes (VSAs), as well as new RADIUS commands, added through definition of additional values for the RADIUS Service-Type attribute. As a result, IETF review was not required under the IANA considerations included in [RFC2865]. Subsequently, the RADIUS IANA considerations [RFC3575] were revised so as to require IETF review in most cases.
IEEE802.11に、Fは、IPsecかぎ管理と同様に逆さのアドレス解決を提供するために、RADIUSプロトコル[RFC2865]を広げるのを選びました。 これはRADIUS Service-タイプ属性のために加算値の定義で新しいRADIUSが命令するのと同じくらい上手に加えられたVendor特有のAttributes(VSAs)の使用で達成されました。 その結果、[RFC2865]に問題を含んで、IETFレビューはIANAの下で必要ではありませんでした。 次に、RADIUS IANA問題[RFC3575]は、多くの場合、IETFレビューを必要とするように改訂されました。
IAB Informational [Page 19] RFC 4441 IEEE 802/IETF Relationship March 2006
2006年の[19ページ]RFC4441IEEE802/IETF関係行進の情報のIAB
No liaison arrangement was developed between IEEE 802.11F and IETF WGs such as AAA WG or SEAMOBY WG, so as to allow IETF participants access to the IEEE 802.11F specifications prior to publication. Once IEEE 802.11F entered into Recirculation ballot, only comments relating to changes in the specification could be considered. As a result, issues raised relating to the IEEE 802.11F RADIUS extensions were rejected.
連絡アレンジメントは全くAAA WGかSEAMOBY WGなどのIEEE802.11FとIETF WGsの間で開発されませんでした、公表の前にIEEEの802.11Fの仕様への関係者アクセスをIETFに許すために。 かつてのFがRecirculation投票に入れたIEEE802.11、仕様に基づく変化に関連するコメントしか考えることができませんでした。 その結果、802.11FのIEEE RADIUS拡張子に関連しながら提起された問題は拒絶されました。
IEEE 802.11F was a Trial Use Recommended Practice. The IEEE 802 Executive Committee approved its withdrawal on November 18, 2005. As a result, the RADIUS parameters allocated for use by IEEE 802.11F are available to be reclaimed.
IEEE802.11に、FはTrial Use Recommended Practiceでした。 IEEE802執行委員会は2005年11月18日に退出を承認しました。 結果、IEEE802.11によるFが利用可能である使用のために割り当てられたRADIUSパラメタとして、開墾されてください。
IAB Informational [Page 20] RFC 4441 IEEE 802/IETF Relationship March 2006
2006年の[20ページ]RFC4441IEEE802/IETF関係行進の情報のIAB
Appendix B. IAB Members at the Time of This Writing
この書くこと時点の付録B.IABメンバー
Bernard Aboba Loa Andersson Brian Carpenter Leslie Daigle Patrik Falstrom Bob Hinden Kurtis Lindqvist David Meyer Pekka Nikander Eric Rescorla Pete Resnick Jonathan Rosenberg Lixia Zhang
バーナード・Aboba Loaアンデション・ブライアン・大工のレスリー・Daigleパトリク・Falstromボブ・Hindenカーティス・リンクヴィスト・デヴィッド・マイヤー・ペッカ・Nikanderエリック・レスコラ・ピートレズニック・ジョナサン・ローゼンバーグ・Lixiaチャン
Author's Address
作者のアドレス
Bernard Aboba Microsoft One Microsoft Way Redmond, WA 98052 USA
バーナードAbobaマイクロソフト1マイクロソフト、道のワシントン98052レッドモンド(米国)
EMail: bernarda@microsoft.com
メール: bernarda@microsoft.com
IAB Informational [Page 21] RFC 4441 IEEE 802/IETF Relationship March 2006
2006年の[21ページ]RFC4441IEEE802/IETF関係行進の情報のIAB
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
IAB Informational [Page 22]
IAB情報です。[22ページ]
一覧
スポンサーリンク
