Network Working Group B. Aboba, Ed.
Request for Comments: 4441 Internet Architecture Board
Category: Informational March 2006
The IEEE 802/IETF Relationship
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).
著作権（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年代後半以来、IEEE 802とIETFは、簡易ネットワーク管理プロトコル（SNMP）のMIBと認証、認可、アカウンティング（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
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年代後半以来、IEEE 802とIETFの参加者は、管理情報ベース（MIB）の開発およびIEEE標準規格に関連する認証、認可、アカウンティング（AAA）アプリケーションに協力してきました。これは、マルチキャストフィルタリング、およびVLAN拡張MIB [RFC2674]、[RFC4363]、ハブMIB [RFC2108]、イーサネット（登録商標）のようなインタフェースMIB [RFC3635]、MAU MIB [RFC3636]をブリッジMIB [RFC1493]、[RFC4188]を含んでいました、WANインターフェイスサブレイヤMIB [RFC3637]、パワーイーサネットMIB [RFC3621]、IEEE 802.1X RADIUSの使用ガイドライン[RFC3580]、改訂された拡張認証プロトコル（EAP）仕様[RFC3748]、RADIUS / EAP [RFC3579]、およびEAPステートマシンの仕様[RFC4137]。この文書は、付録Aに含まれている関係の歴史のIETFおよびIEEE 802の詳細間の協力を奨励するための場所に置かれているポリシーと手順を説明し
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およびIEEE 802との間の通信を改善するために、インターネットエンジニアリング運営グループ（IESG）とインターネットアーキテクチャ委員会（IAB）のメンバーは、（バートWijnen、ジェームズケンプ、およびバーナードAboba含む）バンクーバーのIEEE 802執行委員会で会いましたカナダは、その会議では2004年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ワーキンググループは、一つ以上のエリアディレクターを持っている分野に編成されています。エリアディレクター、プラスIETF議長は、インターネットEngineering Steering Group（IESG）からなります。 IEEE 802のワーキンググループは、一つ以上のタスクグループを持っています。 IEEE 802ワーキンググループの議長、プラスIEEE 802委員長は、IEEE 802執行委員会（エクスコム）を含みます。
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によって他の組織へのリエゾンとして任命されています。これは、IEEE 802にリエゾンならびに特定のIEEE 802のワーキンググループへのリエゾンを含んでいます。 IETF連絡ウェブページには、IETFリエゾンのリストだけでなく、IETF [連絡-ページ]で受信した連絡文のアーカイブへのポインタを含みます。連絡関係を管理するためのIETFプロセスは[BCP102]に記載されています。着信連絡文を処理するための手順は、[BCP103]に記載されています。 IETFへのIEEE 802からの連絡文を確保するためにアーカイブされ、IETFにIEEE 802リエゾンは、リエゾン通信を提出するIETFリエゾン管理ツールを利用すべきであるに反応しました。ツールで使用するのに適したユーザ名とパスワードはiesg-secretary@ietf.orgにメールを送信することによって得ることができます。連絡管理アカウントが使用できない場合、連絡通信は、IEEE 802にIETF連絡（S）に送られ、statements@ietf.orgにコピーすることができます。
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.
IEEE 802にIETFから連絡要求は、IEEE 802 WGの椅子に送信されるべき要求がIEEE 802議長とIETFにIEEE 802リエゾン（複数可）に送信コピーと、属します。他の標準化団体と通信するためのIEEE 802回の手順は、[ポリシー]のセクション14.1に記載されています。 IEEE 802のWGへの連絡通信は、個々のWGでアーカイブされます。
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.
半年以上古いIEEE 802の規格へのアクセスは、Get IEEE 802プログラム[GetIEEE-802]を経由してIEEE 802のウェブサイト上で無料で提供されています。 IEEE 802へのアクセスは過去のIETFのワーキンググループ（作業部会）で正常にIEEE 802作業中へのアクセスを交渉しているが、頻繁にIETFおよびIEEE 802の間で協力して問題として生じた作業中、各インスタンスはされています個別に処理し、完了するまでにかなりの時間と労力を要しました。より容易にIEEE 802と協力IETFのWGのドキュメントへのアクセスを可能にするために、連絡文はIETFのWGを得ることが可能なプロセスを説明する、ポールNikolich、IEEE 802の椅子[IEEE-802Liaison]によって2004年7月にIETFに送られましたIEEE 802作業中にアクセスします。 IEEE 802 WGの議長は、その各WGのメンバーシップを付与する権限を持っており、要求に応じてIETF WGいすにメンバーシップを付与するために、この権限を使用することができます。 IETF WGいすは、IEEE 802 WGアーカイブ用のユーザー名/パスワードへのアクセスが提供され、IETF WGの参加者とその情報を共有することが許可されています。それは会議に出席することなく、IETFに参加することが可能である、あるいはメーリングリストに入社して以来、IETF WGいすはそれを要求し、誰に情報を提供します。しかし、IEEE以来802進行中の作業IETF文書に材料を組み込むか、許可されていないメーリングリストやウェブサイト上のユーザ名/パスワードを掲示、著作権で保護されています。
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憲章のIEEE 802のレビューを可能にするだけでなく、提案IEEE 802プロジェクトの承認要求（のPAR）のIETFレビューを可能にするためには、新しい作業メーリングリストが使用されています。それが提案されているIETF WG憲章を受け取ることができるようにIEEE 802執行委員会は、リストに登録されています。提案されたIEEE 802のPARは、同様に新しい作業リストに掲載されています。新作発表は特に重要である場合、それは、関連するIETFおよびIEEE 802メーリングリストに転送（手動）もあります。
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.
しかし、IETF WG憲章またはIEEE 802 PARが新しい仕事に表示された時間で、IETF BOFまたはIEEE 802「は、対象者募集」既に発生している、関心が実証されているとかなりの仕事は、憲章やPARの開発に行ってきました。問題は、その時点で発見された場合、それは遅すぎるの主要な変更を行うプロセスであることが多いです。潜在的な作業項目が物議を醸す可能性が高いですので、IETFおよびIEEE 802の間での議論は、以前のプロセスで発生することが奨励されています。
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.
企業は従業員がIEEE 802とIETFミーティングの両方に出席するために資金を提供するための圧力の下での旅行の予算で、それはますます困難になってきています。その結果、代替は、IETF WG内のMIBの作業項目をチャーター関与過去の構成に必要とされています。 IEEE 802のWGが開発したMIBの広い見直しを奨励するためには、IEEE 802で開発された簡易ネットワーク管理プロトコル（SNMP）のMIBは、MIBのガイドライン[RFC4181]を辿ると（IETF SNMP品質管理プロセスの一環として検討することをお勧めします'MIB医師'）。 IEEE 802のグループは、IETF操作と管理領域ディレクターを接触させることにより、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 802 SNMP品質管理プロセスを利用しながら、内IEEE 802のMIBを標準化することによって、IETFおよびIEEE 802は、オーバーヘッドを減少させながら品質を確保しようとします。このプロセスの試運転は、MIB医師（デヴィッド・ハリントン）はIEEE 802.1 MIBを見直すことに合意したIEEE 802.1で行われました。現在、議論はRFCはIEEE 802.1 [MIB-TRANSFER]に転送することができるように公開選ばIEEE 802.1 MIBドキュメントの制御を変更する方法に進んでいます。
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の]を含むいくつかのIEEE 802の規格は、[KEYFRAME]に記載の、EAP [RFC3748]及びEAPキー管理に依存します。むしろ、自分のEAPメソッドを開発するよりも、またはEAP鍵管理のための拡張機能、IEEE 802のワーキンググループは、必要な機能を概説や文書案の見直しを要求し、IETFに連絡手紙を送る必要があります。最近では、IEEE 802.16eのD8は、[EAPREVIEW] IEEE 802.16委員長、ロジャー・マークス[IEEE-802.16-Liaison1] [IEEE-802.16-Liaison2]の要請で、EAP WGによって行われてきた。のセキュリティレビュー
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のアプリケーションを必要とするIEEE 802のWGは、IETFに連絡要求を送信する必要があります。新しい属性は、新しいアプリケーションではなく、必要とされている場合は、インターネットドラフトを提出することができ、見直しは、AAAやRADEXTのWGとしてAAA関連のWGから要求することができます。一般的なユーティリティの属性のため、および複数の潜在的用途において特に有用なもの、IETF標準属性空間から割り当ては、IEEE 802ベンダー固有アトリビュート（VSA）の作成に好ましいです。 [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は、ベンダー固有の拡張のためのメカニズムを定義し（26属性）とその使用は、何らの相互運用性が有用とみなされていない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.
VSAの割り当てが必要とされる場合、それはIEEE 802は、IEEE 802の全ての統一フォーマットを作成することをお勧めし、むしろ各IEEE 802基を有するよりも、独自のVSAのフォーマットを作成します。 Typeフィールドのみ255の属性を考慮して、単一のオクテットであるので、[IEEE-802.11F]で定義されたVSAフォーマットは、このためには不適切です。最近、AAA医師のリストは、MIB医師と同様の機能を果たし、IETF操作と管理領域総局内に作成されています。 AAA医師はまだIETFの外でAAAの作品で、レビューを支援するために呼び出されていないが、このグループは、潜在的にAAAとの助けを必要とIEEE 802のワーキンググループへの支援の可能性があります。
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.
IEEE 802とIETFとの協力の領域が増加すると、ドキュメントのレビュープロセスは、SNMP MIBとAAAの伝統的な科目を超えて拡張しています。例えば、IETF CAPWAP WG憲章の一環として、IEEE 802.11は、CAPWAPタクソノミー文書[RFC4118]を確認するように頼まれました。ドロシー・スタンレーは、この目的のためにアドホックグループを組織しました。 IEEE 802.11はまた、[IABLINK] [IDSEL]見直さとしています。 IETF内では、IEEE 802のコメントは、通常の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.
IETFの参加者は、IEEE 802投票プロセスの一部としてコメントすることができ、関係なく、彼らの投票状況のIEEE 802のコメントの中には、投票のために指定された形式で構成され、投票期限までに提出しなければなりません。
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は、追加のフィールドは、サブプロトコル識別子としてではなく、複数のEtherTypeのために適用して、要求されなければなりません。 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.
料金は通常のEtherTypeの割り当てのためにIEEE 802で充電している間、IEEE 802はIESGからの要求に基づいて、文書を追跡IETF標準に関連する配分のための手数料を免除検討します。
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.
IEEE 802は、リンク層のセキュリティのための標準規格の仕様にますます関与なると、経験が、作業中の前の出版物への外部の見直しを取得するために有用であることが示されています。 IEEE 802作業中のドキュメントへのアクセスは、多くの場合、厳密に制御されているので、これはやや挑戦的であることが証明されました。例えば、特別な許可は、そのセキュリティ標準進行中レビューのためのバージョンを循環できるようにするにはIEEE 802.11iのために取得する必要がありました。 IEEE 802グループと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規格はIEEE 802の標準化プロセスで必要とされる明確さのレベルに書き込まれないかもしれないことを示しています。 EAP [RFC3748]の場合には、EAPステートマシン仕様[RFC4137]を開発するプロセスは、明確化を必要とする態様を明らかに有用であることが証明され、より広いレビューにIEEE 802とIETFドキュメント進行中の露出した共同レビュープロセスは、そうでなければかもしれません可能でした。
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の]で説明したように、そのような[KEYFRAME]で提供される分析として、セキュリティ分析を完了せずに新しいAAAキー管理アプリケーションを開発することはお勧めできません。
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]の弱点に、それは重大なセキュリティ上の脆弱性を導入するためのプロトコルの拡張のために比較的容易です。その結果、IEEE 802 RADIUS拡張のIETFレビューは賢明であり、ほとんどの場合、このような見直しを要求するようにRADIUS IANAの考慮事項[RFC3575]は改訂されました。
[BCP102] Daigle, L. and Internet Architecture Board, "IAB Processes for Management of IETF Liaison Relationships", BCP 102, RFC 4052, April 2005.
[BCP102] Daigle氏、L.およびインターネットアーキテクチャ委員会、BCP 102、RFC 4052、2005年4月 "IETFリエゾン関係の管理のためのIABのプロセス"。
[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へとから連絡文を処理するための手順"、BCP 103、RFC 4053、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規格協会は、IEEE 802（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.、Lortz、V.、バーリ、F.、およびP. Eronenは、2006年1月、RFC 4284 "アイデンティティの選択は、拡張認証プロトコル（EAP）のためのヒント"。
[Housley] Housley, R. and B. Aboba, "AAA Key Management", Work in Progress, November 2005.
[Housley氏] Housley氏、R.とB. Aboba、 "AAAキー管理"、進歩、2005年11月に作業。
[IABLINK] Aboba, B., "Architectural Implications of Link Indications", Work in Progress, August 2005.
[IABLINK] Aboba、B.、 "リンク適応の建築的意味"、進歩、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] IEEE 802.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]法上のIETF EAPワーキンググループへの入力とキーの強度、2003年3月、http://www.ietf.org/IESG/LIAISON/LS-ieee-80211.txt。
[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]研究所、IEEE 802.11F、2003年6月（「IEEE試用は、IEEE 802.11動作をサポート物流システム間インターアクセスポイントプロトコル経由でマルチベンダーアクセスポイントの相互運用性のための練習を推奨」今）は非推奨。
[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] IEEE 802リエゾンの手紙。
[IEEE-802.1X-MIB] Norseth, K., "Definitions for Port Access Control (IEEE 802.1X) MIB", Work in Progress, November 2003.
[IEEE-802.1X-MIB] Norseth、K.、進歩、2003年11月の作業 "ポートアクセス制御（IEEE 802.1X）MIBの定義"。
[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規格：ポートベースのネットワークアクセスコントロール、IEEE P802.1X-2001、2001年6月。
[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規格：ポートベースのネットワークアクセスコントロール、IEEE P802.1X-2004、2004年12月。
[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 / IEC 15802-3情報技術 - 電気通信及びシステム間の情報交換 - 地方とメトロポリタンエリアネットワーク - 共通仕様 - 第3部：メディアアクセス制御（MAC）ブリッジ、（また、ANSI / IEEE規格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標準：仮想ブリッジローカルエリアネットワーク、P802.1Q、1998年1月のための標準案。
[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 / IEC 8802-3情報技術 - 電気通信及びシステム間の情報交換 - 地方とメトロポリタンエリアネットワーク - 共通仕様 - パート3：衝突検出（CSMA / CD）アクセス方法および物理層でのキャリア検知多重アクセス仕様、（また、ANSI / IEEE規格802.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]情報技術 - 電気通信及びシステム間の情報交換 - 地方とメトロポリタンエリアネットワーク - 固有の要件パート11：無線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 / MAN具体的な要件 - パート11：無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様：セキュリティ強化のための仕様、IEEE P802 .11i、2004年7月。
[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]バーナードAboba、2005年3月17日、http://ieee802.org/16/liaison/docs/L80216-05_025.pdfにIEEE 802.16からの連絡の手紙。
[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]バーナードAboba、2005年5月5日、http://ieee802.org/16/liaison/docs/L80216-05_039.pdfにIEEE 802.16からの連絡の手紙。
[KEYFRAME] Aboba, B., Simon, D., Arkko, J., Eronen, P., and H. Levkowetz, "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress, October 2005.
[KEYFRAME] Aboba、B.、サイモン、D.、Arkko、J.、Eronen、P.、およびH. Levkowetz、 "拡張認証プロトコル（EAP）鍵管理フレームワーク"、進歩、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-TRANSFER]ハリントン、D.、進歩、2005年10月に作品 "IEEE 802.1 WGにIETFブリッジWGからMIB作業を転送します"。
[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.
[ミシュラ]ミシュラ、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プロジェクト802 LAN MAN標準委員会（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.
[RFC1493]デッカー、E.、Langille、P.、Rijsinghani、A.、およびK. McCloghrie、 "ブリッジのための管理オブジェクトの定義"、RFC 1493、1993年7月。
[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]グラーフ、K.、Romascanu、D.、マクマスター、D.、およびK. McCloghrieド、RFC 2108、1997年2月 "SMIv2のを使用してIEEE 802.3リピータデバイスのための管理オブジェクトの定義"。
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[RFC2284]ブルンク、L.及びJ. Vollbrecht、 "PPP拡張認証プロトコル（EAP）"、RFC 2284、1998年3月。
[RFC2390] Bradley, T., Brown, C., and A. Malis, "Inverse Address Resolution Protocol", RFC 2390, September 1998.
[RFC2390]ブラッドリー、T.、ブラウン、C.、およびA. Malis、 "逆アドレス解決プロトコル"、RFC 2390、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、RFC 2674 "トラフィッククラス、マルチキャストフィルタリングおよび仮想LAN拡張機能を持つブリッジのための管理オブジェクトの定義"、 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.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C.、 "RADIUSアカウンティング"、RFC 2866、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.ミトン、 "トンネルプロトコルサポートのためのRADIUSアカウンティングの変更"、RFC 2867、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.、Leifer、D.、ルーベンス、A.、シュライバー、J.、ホールドレッジ、M.、およびI. Goyret、RFC 2868、2000年6月 "RADIUSトンネルプロトコルサポートのための属性"。
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[RFC2869] Rigney、C.、Willats、W.、およびP.カルフーン、 "RADIUS拡張機能"、RFC 2869、2000年6月。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba、B.、ゾルン、G.、およびD.ミットン、 "RADIUSとIPv6"、RFC 3162、2001年8月。
[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月。
[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.カルフーン、 "RADIUS（ユーザサービスにおけるリモート認証ダイヤル）拡張認証プロトコル（EAP）のサポート"、RFC 3579、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] Congdon氏、P.、Aboba、B.、スミス、A.、ゾルン、G.、およびJ.レーゼ、 "IEEE 802.1Xのリモート認証ダイヤルインユーザーサービス（RADIUS）使用上のガイドライン"、RFC 3580、2003年9月。
[RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB", RFC 3621, December 2003.
[RFC3621]バーガー、A.とD. Romascanu、 "パワー・イーサネットMIB"、RFC 3621、2003年12月。
[RFC3635] Flick, J., "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 3635, September 2003.
[RFC3635]フリック、J.、RFC 3635、2003年9月「イーサネットのようなインターフェース型のための管理オブジェクトの定義」。
[RFC3636] Flick, J., "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", RFC 3636, September 2003.
[RFC3636]フリック、J.、RFC 3636、2003年9月 "IEEE 802.3媒体接続ユニット（MAUに）のための管理オブジェクトの定義"。
[RFC3637] Heard, C.M., Ed., "Definitions of Managed Objects for the Ethernet WAN Interface Sublayer", RFC 3637, September 2003.
[RFC3637]聞いた、C.M.、エド。、 "イーサネットWANインタフェース副層のための管理オブジェクトの定義"、RFC 3637、2003年9月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、 "拡張認証プロトコル（EAP）"、RFC 3748、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）メソッド要件"、RFC 4017、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、RFC 4118、2005年6月の "コントロールおよびワイヤレスアクセスポイントのプロビジョニング（CAPWAP）のためのアーキテクチャ分類学"。
[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）ピアとオーセンティケータ"、RFC 4137、2005年8月。
[RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005.
[RFC4181]聞いた、C.、エド。、 "MIBドキュメントの著者と査読のためのガイドライン"、BCP 111、RFC 4181、2005年9月。
[RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects for Bridges", RFC 4188, September 2005.
[RFC4188] Norseth、K.およびE.ベル、 "ブリッジのための管理オブジェクトの定義"、RFC 4188、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.ハリントン、RFC 4363、2006年1月「トラフィッククラス、マルチキャストフィルタリング、および仮想LAN拡張機能を持つブリッジのための管理オブジェクトの定義」。
[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-TUT] IEEE規格協会、 "IEEE 802.3、1998年版地方とメトロポリタンエリアネットワークでIEEE割り当てのEtherTypeフィールドの使用"、http://standards.ieee.org/regauth/ethertype/型tut.html 。
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.聞いを確認したいと思います。
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.
IETFおよびIEEE 802との間の関係は、元のIEEE 802.1D規格用に開発されたSNMP MIBの1980年代後半に始まりました。 IEEE仕様[IEEE 802.1D-は]カウンタと操作の唯一の機能的な定義が含まれているため、IETFのブリッジMIB WGは、RFCとして公開されたブリッジMIB [RFC1493]を、定義の役割を引き受けました。フレッド・ベイカー以降キースMcCloghrieは橋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.
ブリッジMIBは、アニルRijsinghaniが提供する、スパニングツリーの専門知識を持つキースMcCloghrie、エリック・デッカー、そしてポール・Langilleの仕事を、組み合わせます。ミック・シーマン（802.1Dの作者）と（デジタル機器のスパニングツリーの実装のためのコードを書いていた）フロイドBackesは、IEEE 802.1内の主接点ました。ミック、フロイド、アニル、そしてポール全てが一度にディジタル・イクイップメント・コーポレーションのために働いているので、IEEE 802.1およびブリッジMIB WG間の調整の多くは、むしろ公式チャンネル内よりも、デジタルで廊下で開催されました。
A.1.2. MAU and Hub MIBs
A.1.2。 MAUとハブのMIB
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.
IEEE 802.3は、最初のイーサネット規格を完成された1990年代初めには、SNMPはまだ支配的なネットワーク管理プロトコルではありませんでした。結果として、「プロトコル独立」MIBは、IEEE 802.3標準[IEEE-802.3]、イーサネット標準はより高い速度をサポートするように拡張されるたびに更新されるの節30に含まれています。並行して、ネットワーク管理に興味がIEEE 802の参加者は、標準化過程RFCとして文書のSNMP MIBにIEEE 802の定義を変換するタスクを引き受けたIETF HUBMIB WGの形成に活性でした。これはダンRomascanu、1996年以来、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の憲章は、明示的にIEEE 802.3標準イーサネットMIBのための出発点であるが、同時にIEEEモデルから逸脱する権利を留保していることに言及します直接IEEEモデル（主にソフトウェアで実現される）から誘導されていないMIBオブジェクトを追加します。管理のニーズがハードウェアサポートのための要件につながる場合は、IETF HUBMIB WGは、タイムリーにIEEE 802.3に、この入力を提供することです。
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とIEEE 802.3の間の協力は、主にIEEE規格を取得し、管理データモデルとのMIBにそれらをマッピングしている自分の会社、でサポートされているいくつかの編集者の仕事に基づいて、今日まで10年以上にわたり続けてきました。作業項目は、次のとおりです。
- 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.
- 3回の反復を経たハブMIB [RFC2108]、およびリピータはイーサネットではあまり使用されているとして、おそらく、その進化を終了しています。 - [RFC3636]は10 Gbpsイーサネットを収容するとともに、新たなイーサネット速度が開発されるたびに更新されたMAU MIB、。 - イーサネットのようなインタフェースMIBはHUBMIB WGの作業項目はもともとありませんでしたが、WGは、[RFC3635]として発行され、改訂のための責任を取りました。 - WANインタフェースサブレイヤMIB [RFC3637]及び電力イーサネットMIB [RFC3621]はIEEE 802.3およびIETF WG HUBMIBに開発されました。
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年には、公式の連絡は、IEEE 802.3およびIETF HUBMIB WGの間で設立された、とダンRomascanuは、IETFのリエゾンを任命されました。リエゾン契約の条件は、標準のリリース前のMIBで作業の目的のために、個人的にIEEE 802.3で作業中のドラフトのIETF HUBMIB WGへのアクセスに編集者や他の参加を可能にします。しかし、IEEE 802.3ドキュメントにアクセスするためのユーザー名とパスワードは、任意のIETFのWebサイトやメーリングリストで公表のためではありません。
A.1.3. 802.1p/Q MIB
A.1.3。 802.1P / 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-]規格が完成されていたとして1996年に、必要性は、それらの規格の管理条項に基づいて、SNMP MIBの開発のための知覚されました。 IEEE 802管理句は、それらを実装するために使用することができる任意のプロトコルとは独立した様式で書かれています。
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管理のMIBの数がありました。その結果、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.1 WGからの参加者の小グループは、自分の仕事を組み合わせ、その後、独立して問題に取り組んで始まりました。作品の一部が基になったブリッジMIBの原作者は、初期の作品を検討しました。
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、ブリッジ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ブリッジMIBおよびIEEE 802.1群間で公式インターワーキングはありませんでした。メインの開発者（アンドリュー・スミスとレベル）はIEEE 802.1およびIETFブリッジMIBのWGの両方に関与していたので、このMIBの開発は、成功しました。
A.1.4. 802.3ad and 802.1X MIBs
A.1.4。 802.3adのと802.1XのMIB
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規格の一部として動作し、なるように、標準規格の一部としてMIBを開発するのではなく、IETF WGが形成されるまで待って、別途の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.
レベルは、IEEE 802.3adのとSNMP MIBの開発に最も精通したIEEE 802.1に参加したとして、彼はグループが思い付くていた管理フレームワークに基づいて初期のMIBをまとめます。追加の支援をしてから、IEEE 802.3adのとIEEE 802.1Xグループ内からの両方のMIBのために受信されました。トニーJEFFREE、両方の規格の編集者は、同様のMIBの編集者を務めました。
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.
IEEE 802は、IETF関与することなくこれらのMIBの開発に伴う問題は、レビューの欠如でした。 IEEE 802のメンバーは、一般のMIBに慣れていない、と非常にいくつかのコメントは、いずれかの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は、ブリッジWG以内に審査し、いくつかの構文エラーが見つかりました。これらは、[IEEE-802.1X-2004]の一部として開発されたMIBモジュールのバージョンで修正されました。もともとブリッジWG内で進行中の作業として出版された[IEEE-802.1X-MIB]ながら、しかし、RFCとしてその出版を完了するのに十分な関心がありませんでした。その結果、ドラフトは現在有効期限が切れています。
A.1.5. 802.1t, 802.1u, 802.1v, and 802.1w MIBs
A.1.5。 802.1トン、802.1u、802.1v、および802.1ワットのMIB
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トンと802.1uは、[RFC2674]に掲載されたMIBにいくつかの追加を必要とし、802.1Dと802.1Q標準にマイナーな修正をしました。 802.1vはまた、[RFC2674]の拡張機能を必要とする、802.1Q VLANの分類スキームを拡張新機能でした。 802.1ワット[RFC1493]の一部の書き換えが必要な、スパニングツリーの新しいバージョンでした。
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ブリッジMIB WGの議長の役割を引き受けた場合には、これらの問題は、新しい作業項目として提起し、2人のボランティアは、インターネットドラフトの編集者になることが分かりました。作業項目は、また、情報の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年代後半以来、IEEE 802.1は、[RFC2284]と[RFC2869]を含むいくつかのIETF仕様に問題の発見につながった認証および承認[IEEE-802.1X]に関連する仕事に携わってきました。同様に、IETFの参加者は、[RFC3580]、ならびにIEEE 802.1XステートマシンとしてRADIUSの使用仕様の初期バージョン[ミシュラ]で問題を発見しました。
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].
これらの問題に対処し、IEEE 802.1およびIETF EAPとAAAのWG間の同期を確保するために、連絡配置は[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.
そのようなIEEE 802.11i規格やIEEE 802.11FとしてIEEE 802.11グループもEAPとAAAの仕事に依存になってきました。この関係は、EAP方式のIEEE 802.11必要な開発およびIEEE 802.1で必要とされる明確化や更新は対照的に、かなりの新しいIETF仕事を表現EAP鍵管理フレームワーク、以来、より挑戦的でした。
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の関節動作のためにIEEE 802上EAP [RFC2284]、ならびにステートマシンのカプセル化を定義しました。
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]は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ステートマシンの正式な分析は、複数のセキュリティ問題[ミシュラ]を開示します。 IEEE 802.1内の議論は、EAP状態マシン仕様の仕様が存在しないことに起因[RFC2284]における明確性の欠如を指摘しました。
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内で処理されていました。改訂されたEAPの仕様だけでなく、EAPステートマシンの仕様に関する作業を行うためには、IETF EAP WGは、2002年7月バーナードAboba、IEEE 802.1で参加者だけでなく、PPPEXTに形成された共同議長に選ばれました。
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]の作業は[IEEE-802.1X-2004の他のドキュメントへの変更並びに修正を必要とする一つの文書に問題や変更で、EAP WG内で並列に進行しました]。その時点でRADEXT WGがまだ形成されていないので、改訂されたRADIUS / EAP仕様[RFC3579]はまた、EAP 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]
- [RFC3580]に基づいて改訂されたRADIUS使用付録 - [RFC3748]及び[RFC4137]に基づいて改訂されたIEEE 802.1Xステートマシン、 - [RFC3579]に基づいて明確化
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]に、リエゾンは、これは、IETF EAPの参加者を有効に2002年8月にIEEE 802.1X-REVおよびIETF EAP WGとの間で確立されました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 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のグループに関係なく、その起源の、受け取ったすべてのコメントを検討する義務があります。これは、IETFの参加者が積極的な協力、IETFのWGは、IEEE 802投票用紙が発生していることと、彼らのコメントは歓迎されていることを認識してもよいがあるIEEE 802の中にかかわらず、投票状況の、IEEE 802投票プロセスの一部としてコメントすることができます。 IEEE 802.1X-REVおよびIEEE 802.11i規格の投票用紙は、IEEE 802暫定会議手配されているとして、EAP WGメーリングリストで発表されました。
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の問題一覧に追跡した、その後、文書で対処されました。
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として公表のために承認されました。両方のドラフトのための検討プロセスは、最後の呼び出しIETFに書類を持参して、IEEE 802.1メーリングリスト上でIETFの最後の呼び出しの発表を再ポスト関与しました。 IEEE 802.1X-REVの投票コメントはまた、両方のドキュメントへの変更に反映されたが、両方の文書が時間内に割り当てられることRFC番号を確保するために、十分スポンサー投票の前に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]、文書は不当な遅延なしに製造されました。これは主に、IEEE 802.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規格およびIEEE 802.1は、IEEE 802プレナリーで合同会議を開催した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.1X-2004]に依存[IEEE-802.11i規格]ので、EAPの作業、EAPメソッド、およびEAPのためのAAAサポートを含む、[IEEE-802.1X-2004]の依存性を継承しました。 [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月に、IEEE 802.11は、EAPの追加作業、EAPメソッド、およびEAPキー管理を要求IESG [IEEE-80211Liaison1]への連絡の手紙を送りました。この手紙は、IETF 53で第2のEAP BOFで発表された、及びEAP WGチャーターへの入力として使用されました。 2003年3月には、別の連絡書簡は[IEEE-80211Liaison2] EAP方式の作業のための要件の更なる明確化を提供し、発表されました。これはのためのIEEE 802.11i規格からの要求が含まれて
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規格のセキュリティ要件を提供するように、EAP WGは、[RFC3748]の中に実装に必須のEAP方式を変更することを検討します。
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].
IETF 56の間、強制的に実装方法を変更するための要求はEAP WGによって考えられました。勧告は、IEEE 802.11iの要件は、RFCで文書化されていることと、EAP WGは、様々な状況でのEAPメソッドのためのセキュリティ要件を考慮することを、インターネットエリアディレクターエリックNordmarkとによって作られました。 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月には、ドロシー・スタンレーはAAA、BMWG、CAPWAP、およびEAPなどの、IEEE 802.11およびIETFのWG間の調整を支援するために、IETFへのIEEE 802.11からの連絡に任命されました。
A.2.3. IEEE 802.11F
A.2.3。 IEEE 802.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.
IEEE 802.11Fは、アクセスポイント間の通信のためのお勧めの開発をチャーターしました。インターアクセスポイントプロトコル（IAPP）の開発の一環として、それように、アクセスポイント間の通信を保護するために、ならびにそのIPアドレスへの前のアクセスポイントのMACアドレスの逆引きをサポートするために必要でした2つのアクセスポイントは、IAPPを介して通信することを可能にします。 2つのアクセスポイントが同じリンク上ではないかもしれないので、インバース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.
IEEE 802.11Fは、逆アドレス解決並びにIPsecの鍵管理を提供するために、RADIUSプロトコル[RFC2865]を拡張するために選択しました。これは、ベンダー固有アトリビュート（VSA）、および新しいRADIUSコマンドを使用することにより達成された、RADIUSサービスタイプ属性の付加価値の定義を介して追加。その結果、IETFレビューは、[RFC2865]に含まIANAの考慮の下で要求されていませんでした。ほとんどの場合、IETFレビューを必要とするようにその後、RADIUS IANA問題[RFC3575]は修正されました。
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.
IETFの参加者が出版前にIEEE 802.11F仕様へのアクセスを可能にするように何の連絡装置は、IEEE 802.11FそのようなAAA WG又はSEAMOBY WGとしてIETFのWGとの間に開発されませんでした。 IEEE 802.11Fは、再循環投票に入った後は、仕様の変更に関連するコメントだけを考えることができます。その結果、IEEE 802.11F 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.
IEEE 802.11Fトライアル使用推奨の練習でした。 IEEE 802執行委員会は、結果として11月18日、2005年に撤退を承認し、IEEE 802.11Fで使用するために割り当てられRADIUSパラメータを再利用することが可能です。
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ロア・アンダーソン、ブライアン・カーペンター、レスリーDaigle氏、パトリックFalstromボブHindenとカーティスLindqvistデビッド・マイヤーペッカNikanderエリックレスコラピートレズニックジョナサン・ローゼンバーグLixiaチャン
Author's Address
著者のアドレス
Bernard Aboba Microsoft One Microsoft Way Redmond, WA 98052 USA
バーナードAbobaマイクロソフト1マイクロソフト道、レッドモンド、ワシントン98052 USA
EMail: bernarda@microsoft.com
メールアドレス：bernarda@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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エディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。