[要約] RFC 4441は、IEEE 802とIETFの関係についてのガイドラインを提供しています。このRFCの目的は、両組織間の協力とコラボレーションを促進し、ネットワーキング技術の進歩を支援することです。
Network Working Group B. Aboba, Ed.
Request for Comments: 4441 Internet Architecture Board
Category: Informational March 2006
The IEEE 802/IETF Relationship
IEEE 802/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）The Internet Society（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）MIBSおよび認証、承認、および会計（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の参加者は、IEEE標準に関連する管理情報ベース（MIBS）および認証、承認、会計（AAA）アプリケーションの開発に協力してきました。これには、ブリッジMIB [RFC1493] [RFC4188]、マルチキャストフィルタリングとVLAN拡張MIB [RFC2674] [RFC4363]、ハブMIB [RFC2108]、イーサネット様インターフェイスMIB [RFC3635]、マウミブ[RFC3636]、WANインターフェイスSublayer MIB [RFC3637]、Power Ethernet MIB [RFC3621]、IEEE 802.1x半径使用ガイドライン[RFC3580]、修正された拡張認証プロトコル（EAP）仕様[RFC3748]EAP状態マシン仕様[RFC4137]。このドキュメントでは、IETFとIEEE 802の協力を促進するために導入されたポリシーと手順について説明します。関係履歴の詳細は、付録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とIEEE 802の間のコミュニケーションを改善するために、インターネットエンジニアリングステアリンググループ（IESG）とインターネットアーキテクチャボード（IAB）のメンバー（Bert Wijnen、James Kempf、およびBernard Abobaを含む）は、Vancouververの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ワーキンググループは、1つ以上のエリアディレクターがいるエリアに編成されています。エリアディレクターとIETFチェアは、インターネットエンジニアリングステアリンググループ（IESG）で構成されています。IEEE 802ワーキンググループには、1つ以上のタスクグループがあります。IEEE 802ワーキンググループチェアとIEEE 802議長は、IEEE 802執行委員会（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によって他の組織の連絡剤として任命されます。これには、IEEE 802へのリエゾンと、特定のIEEE 802ワーキンググループへの連絡が含まれます。IETFリエゾンWebページには、IETFリエゾンのリストと、IETF [Liaison-Page]が受け取ったリエゾンステートメントのアーカイブへのポインターが含まれています。リエゾン関係の管理のためのIETFプロセスは[BCP102]で説明されています。着信リエゾンステートメントの処理手順は、[BCP103]で説明されています。IEEE 802からIETFへのリエゾンステートメントがアーカイブおよび応答されるようにするために、IEEE 802リエゾンはIETFにリエゾン管理ツールを利用してリエゾン通信を提出する必要があります。ツールで使用するのに適したユーザー名とパスワードは、iesg-secretary@ietf.orgにメールを送信することで取得できます。リエゾン管理アカウントが利用できない場合、リエゾン通信をIETFリエゾンにIEEE 802に送信し、Statement@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.
IETFからIEEE 802へのリエゾンリクエストは、IEEE 802 WGの椅子に送信する必要があります。この椅子は、リクエストがIEEE 802椅子に送信され、IEEE 802リエゾン（s）にIETFに送信されます。IEEE 802他の標準団体と通信するための手順は、[ポリシー]のセクション14.1で説明されています。IEEE 802 WGSへの連絡通信は、個々のWGSによってアーカイブされます。
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標準へのアクセス6か月以上は、IEEE 802プログラム[GetIeee-802]を介してIEEE 802 Webサイトで無料で提供されます。IEEE 802へのアクセスは、IETFとIEEE 802の間で協力して問題として頻繁に発生しました。別々に処理され、完了するのにかなりの時間と労力を費やしました。IEEE 802と協力するIETF WGSのドキュメントアクセスをより簡単に有効にするために、IEEE 802 [IEEE-802Liaison]の議長であるPaul Nikolichによって、2004年7月にIETFにリエゾンステートメントが送信され、IETF WGSが取得できるプロセスを説明しました。IEEE 802作業へのアクセス。IEEE 802 WG椅子には、WGSのメンバーシップを付与する権限があり、この権限を使用して、リクエストに応じてIETF WG椅子にメンバーシップを付与できます。IETF WG椅子は、IEEE 802 WGアーカイブのユーザー名/パスワードへのアクセスとともに提供され、IETF WGの参加者とその情報を共有することができます。IETFに参加せずにIETFに参加したり、メーリングリストに参加したりすることさえ可能であるため、IETF WGチェアはそれを要求する人に情報を提供します。ただし、IEEE 802作業は著作権で保護されているため、IETFドキュメントに素材を組み込むか、メーリングリストまたはWebサイトにユーザー名/パスワードを投稿することは許可されていません。
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レビューを有効にするために、新しい作業郵送リストが使用されます。IEEE 802執行委員会は、提案されたIETF WGチャーターを受け取ることができるように、リストに購読されています。提案された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「Call for Interest」がすでに発生しており、関心が実証されており、憲章または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 WGSによって開発されたMIBSのより広いレビューを奨励するために、IEEE 802で開発された単純なネットワーク管理プロトコル（SNMP）MIBSがMIBガイドライン[RFC4181]に従い、IETF SNMP品質管理プロセスの一部としてレビューすることをお勧めします（「MIB医師」）。IEEE 802グループは、IETF運用および管理エリアディレクターに連絡することにより、MIBレビューを支援するために「MIB Doctor」の割り当てを要求する場合があります。
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 MIBSをIEEE 802内でのみ標準化することにより、SNMP品質制御プロセスを利用している間、IETFとIEEE 802は、オーバーヘッドを減らしながら品質を確保しようとします。このプロセスの試験実行は、IEEE 802.1で行われました。そこでは、MIBドクター（David Harrington）がIEEE 802.1 MIBSのレビューに同意しました。現在、RFCとして公開された選択されたIEEE 802.1 MIBドキュメントの変更制御をIEEE 802.1 [MIB-Transfer]に転送する方法について議論が進行中です。
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キー管理に依存します。IEEE 802のワーキンググループは、独自のEAPメソッド、またはEAPキー管理用の拡張機能を開発するのではなく、IETFにリエゾンレターを送信し、必要な機能の概要を説明するか、ドラフトテキストのレビューを要求する必要があります。最近では、IEEE 802.16E D8 [EAPREVIEW]のセキュリティレビューがEAP WGによって実施されました。IEEE802.16議長、Roger Marks [IEEE-802.16-Liaison1] [IEEE-802.16-Liaison2]。
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 WGSは、IETFにリエゾンリクエストを送信する必要があります。新しいアプリケーションではなく新しい属性が必要な場合、インターネットドラフトを提出し、AAAやRadext WGSなどのAAA関連WGSからレビューを要求できます。一般的なユーティリティの属性、特に複数の潜在的なアプリケーションで有用な属性の場合、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）のメカニズムを定義し、グローバル属性タイプの割り当てではなく、その使用を奨励する必要があります。
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グループに独自のVSA形式を作成するのではなく、IEEE 802のすべての均一な形式を作成することをお勧めします。[IEEE-802.11F]で定義されているVSA形式は、タイプフィールドは単一のオクテットであり、255の属性のみが可能になるため、これには不適切です。最近、AAAドクターズリストはIETF運用および管理エリア局に作成され、MIB医師と同様の機能を果たしています。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 MIBSとAAAの従来の主題を超えて拡張されました。たとえば、IETF CAPWAP WGチャーターの一部として、IEEE 802.11はCapWap分類文書[RFC4118]をレビューするように求められました。ドロシー・スタンレーは、この目的のためにアドホックグループを組織しました。IEEE 802.11は[idsel]および[iablink]もレビューしました。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フィールドは非常に限られているため、割り当ては「必要に応じて」のみで行われます。関連する使用については、複数のeteryTypesを適用するのではなく、サブプロトコル識別子として機能する追加フィールドを使用して、単一のeteryTypeを要求する必要があります。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.
半径の仕様[RFC2865]の弱点により、プロトコル拡張が深刻なセキュリティの脆弱性を導入することは比較的簡単です。その結果、IEEE 802 Radius拡張機能のIETFレビューが推奨され、ほとんどの場合、そのようなレビューが必要になるように、半径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。およびInternet Architecture Board、「IETFリエゾン関係の管理のためのIABプロセス」、BCP 102、RFC 4052、2005年4月。
[BCP103] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for Handling Liaison Statements to and from the IETF", BCP 103, RFC 4053, April 2005.
[BCP103] Trowbridge、S.、Bradner、S。、およびF. Baker、「IETFとの連絡ステートメントを処理する手順」、BCP 103、RFC 4053、2005年4月。
[EAPREVIEW] EAP WG letter to Roger Marks, June 2005, http://www.drizzle.com/~aboba/EAP/review.txt.
[Eapreview] EAP WG To Roger Marksへの手紙、2005年6月、http：//www.drizzle.com/~aboba/eap/review.txt。
[GetIEEE-802] IEEE Standards Association Get IEEE 802 (R) Program, http://standards.ieee.org/getieee802/portfolio.html.
[Getieee-802] IEEE Standards Association Get 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.、Bari、F.、およびP. Eronen、「拡張可能な認証プロトコル（EAP）のアイデンティティ選択のヒント」、RFC 4284、2006年1月。
[Housley] Housley, R. and B. Aboba, "AAA Key Management", Work in Progress, November 2005.
[Housley] Housley、R.およびB. Aboba、「AAA Key Management」、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.
[IEEE-80211LIAISON1] IEEE 802.11 2002年2月、ハラルドアルベストランへのリエゾンレター、https：//www.ietf.org/iesg/liaison/ieee802.11.txt。
[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-80211Liason2] Method and Key強度に関する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.11操作をサポートする流通システムを介したアクセスポイント間プロトコルを介したマルチベンダーアクセスポイントの相互運用性のIEEE試行用の推奨慣行」、IEEE 802.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.
[IEEE-802Liasion] IEEE 802 Bert WijnenおよびBernard Abobaへのリエゾンレター、2004年7月26日、http：//www.ietf.org/iesg/liaison/file41.pdf。
[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。、「ポートアクセス制御の定義（IEEE 802.1x）MIB」、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標準：ポートベースのネットワークアクセス制御、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 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/IEC 8802-3情報技術 - システム間の電気通信と情報交換 - ローカルおよびメトロポリタンエリアネットワーク - 共通仕様 - パート3：キャリアセンス衝突検出（CSMA/CD）アクセス方法と物理レイヤーをセンス仕様（ANSI/IEEE STD 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 Standard of Standard for Standard for Standard and Information for Systems -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] IEEE 802.16からBernard Abobaへのリエゾンレター、2005年3月17日、http：//ieee802.org/16/liason/docs/l80216-05_025.pdf。
[IEEE-802.16-Liaison2] Liaison letter from IEEE 802.16 to Bernard Aboba, May 5, 2005, http://ieee802.org/16/liaison/docs/L80216-05_039.pdf.
[IEEE-802.16-Liaison2] IEEE 802.16からBernard Abobaへのリエゾンレター、2005年5月5日、http：//ieee802.org/16/liaison/docs/l80216-05_039.pdf。
[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.、Simon、D.、Arkko、J.、Eronen、P。、およびH. Levkowetz、「拡張可能な認証プロトコル（EAP）キー管理フレームワーク」、2005年10月の作業。
[Liaison-Page] IETF Liaison Activities, http://www.ietf.org/liaisonActivities.html.
[liaison-page] ietf liaisonアクティビティ、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] Harrington、D。、「IETFブリッジWGからIEEE 802.1 WGへのMIB作業の転送」、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プロジェクト802 LAN Man Standards Committee（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] Decker、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] de Graaf、K.、Romascanu、D.、McMaster、D.、およびK. McCloghrie、「SMIV2を使用したIEEE 802.3リピーターデバイスの管理オブジェクトの定義」、RFC 2108、1997年2月。
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[RFC2284] Blunk、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] Bradley、T.、Brown、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] Bell、E.、Smith、A.、Langille、P.、Rijhsinghani、A。、およびK. McCloghrie、「トラフィッククラス、マルチキャストフィルタリング、仮想LAN拡張機能を備えたブリッジの管理されたオブジェクトの定義」、RFC 2674、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.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C。、「Radius Accounting」、RFC 2866、2000年6月。
[RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[RFC2867] Zorn、G.、Aboba、B。、およびD. Mitton、「トンネルプロトコルサポートのための半径会計の修正」、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] Zorn、G.、Leifer、D.、Rubens、A.、Shriver、J.、Holdrege、M。、およびI. Goyret、「トンネルプロトコルサポートのRadius属性」、RFC 2868、2000年6月。
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[RFC2869] Rigney、C.、Willats、W。、およびP. Calhoun、「Radius Extensions」、RFC 2869、2000年6月。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba、B.、Zorn、G。、およびD. Mitton、「Radius and 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. Calhoun、「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.、Smith、A.、Zorn、G。、およびJ. Roese、「IEEE 802.1xリモート認証ダイヤルインユーザーサービス（RADIUS）使用ガイドライン」、RFC 3580、2003年9月。
[RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB", RFC 3621, December 2003.
[RFC3621] Berger、A。およびD. Romascanu、「Power Ethernet MIB」、RFC 3621、2003年12月。
[RFC3635] Flick, J., "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 3635, September 2003.
[RFC3635] Flick、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] Flick、J。、「IEEE 802.3中程度のアタッチメントユニット（MAUS）の管理オブジェクトの定義」、RFC 3636、2003年9月。
[RFC3637] Heard, C.M., Ed., "Definitions of Managed Objects for the Ethernet WAN Interface Sublayer", RFC 3637, September 2003.
[RFC3637] Heard、C.M.、ed。、「イーサネット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.、Blunk、L.、Vollbrecht、J.、Carlson、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] Stanley、D.、Walker、J。、およびB. Aboba、「ワイヤレスLANSの拡張可能な認証プロトコル（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] Yang、L.、Zerfos、P。、およびE. Sadot、「ワイヤレスアクセスポイント（CAPWAP）の制御とプロビジョニングのためのアーキテクチャ分類法」、RFC 4118、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.、Petroni、N。、およびY. Ohba、「拡張可能な認証プロトコル（EAP）ピアおよび認証機のための状態マシン」、RFC 4137、2005年8月。
[RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005.
[RFC4181] Heard、C.、ed。、「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. Bell、「ブリッジの管理オブジェクトの定義」、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] Levi、D。およびD. Harrington、「トラフィッククラス、マルチキャストフィルタリング、仮想LAN拡張機能を備えた橋の管理されたオブジェクトの定義」、RFC 4363、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-Tut] IEEE Standards Association、「IEEEの使用Ethertypeフィールドの使用IEEE STD 802.3、1998 Edition Local and Metropolitan Area Networks」、http://standards.ieee.org/regauth/ethertype/ Type-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.
著者は、レス・ベル、ダン・ロマスカヌ、デイブ・ハリントン、トニー・ジェフリー、フレッド・ベイカー、ポール・コンドン、ポール・ランギーユ、C。M。がこの文書への貢献を聞いたことを認めたいと思います。
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の関係は、1980年代後半に始まり、SNMP MIBSが元のIEEE 802.1D標準向けに開発されました。IEEE仕様[IEEE-802.1D]にはカウンターと操作の機能的定義のみが含まれていたため、IETFのブリッジMIB WGは、RFCとして公開されたブリッジMIB [RFC1493]を定義する役割を引き受けました。フレッド・ベイカーと後にキース・マクログリーは、橋の椅子を務めました。
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は、Keith McCloghrie、Eric Decker、Paul Langilleの作品と、Anil Rijsinghaniが提供するスパニングツリーの専門知識を組み合わせました。Mick Seaman（802.1dの著者）とFloyd Backes（デジタル機器のスパニングツリー実装のコードを書いた）は、IEEE 802.1内の主要な連絡先でした。Mick、Floyd、Anil、およびPaulはすべてDigital Equipment Corporationで働いていたため、IEEE 802.1とBridge Mib WGの間の調整の多くは、公式チャネルではなくデジタルの廊下で行われました。
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の参加者は、IETF Hubmib WGの形成に積極的であり、IEEE 802定義を標準トラックRFCSとして文書化されたSNMP MIBSに変換するタスクを引き受けました。これには、1996年以来IETF Hubmib WGの議長であるDan Romascanuが含まれていました。
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基準を採用し、管理データモデルとMIBSにマッピングしている企業がサポートするいくつかの編集者の作業に基づいて、今日まで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.
- ハブMIB [RFC2108]は、3つの反復を経て、おそらくリピーターがイーサネットであまり使用されていないため、その進化を終わらせています。-Mau Mibは、新しいイーサネット速度が開発されるたびに更新され、[RFC3636]が10 gbpsイーサネットに対応します。 - イーサネットのようなインターフェイスMIBは、もともとHubmib WGの作業項目ではありませんでしたが、WGは[RFC3635]として公開された改訂の責任を負いました。-WANインターフェイスサブレイヤーMIB [RFC3637]およびパワーイーサネットMIB [RFC3621]は、IEEE 802.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年には、IEEE 802.3とIETF Hubmib WGの間に公式のリエゾンが設立され、Dan RomascanuがIETFリエゾンに任命されました。リエゾン契約の条件により、IETF HubMib WGの編集者やその他の参加者は、標準のリリース前にMIBSに取り組む目的で、個人ベースでIEEE 802.3の進行中のドラフトへのアクセスにアクセスできます。ただし、IEEE 802.3ドキュメントアクセスのユーザー名とパスワードは、IETF Webサイトまたはメーリングリストに公開されていません。
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.
1996年には、802.1pおよび802.1q [IEEE-802.1q]基準が完了したため、これらの基準の管理条項に基づいて、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年末までに、この作業はより多くの聴衆によるレビューの準備ができていました。Andrew Smithは、Bridge Mib WG（当時休眠中）の議長であるKeith McCloghrieと協力して、1998年3月のIETF会議で会議スロットを取得しました。この後、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グループの間に公式の相互作用はありませんでした。このMIBの開発は成功しました。これは、主な開発者（Andrew SmithとLes Bell）がIEEE 802.1とIETF Bridge MIB WGSの両方に関与していたためです。
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が形成されるまで待つよりも、標準の一部としてMIBを開発し、MIBを個別に開発するよりも、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.
Les BellはIEEE 802.3ADおよびIEEE 802.1の参加者であったため、SNMP MIB開発に最も精通しているため、グループが思いついた管理フレームワークに基づいて最初のMIBSをまとめました。その後、IEEE 802.3ADおよびIEEE 802.1xグループ内から両方のMIBについて追加の支援を受けました。両方の標準の編集者であるトニージェフリーは、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.
IEEE 802がIETFの関与なしにこれらのMIBを開発することの問題は、レビューの欠如でした。IEEE 802メンバーは一般に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がブリッジWG内でレビューされ、いくつかの構文エラーが見つかりました。これらは、[IEEE-802.1x-2004]の一部として開発されたMIBモジュールのバージョンで修正されています。ただし、[IEEE-802.1x-MIB]はもともとブリッジWG内で進行中の作業として公開されていましたが、RFCとしての出版を完了するのに十分な関心はありませんでした。その結果、ドラフトの有効期限が切れています。
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.1Tおよび802.1Uは、802.1Dおよび802.1Q規格の軽微な修正であり、[RFC2674]で公開されたMIBにいくつかの追加が必要でした。802.1Vは、802.1QのVLAN分類スキームを拡張する新機能であり、[RFC2674]の拡張も必要です。802.1Wはスパニングツリーの新しいバージョンであり、[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人のボランティアがインターネットドラフトの編集者になることがわかったために提起されました。IEEE 802.1x MIBを情報RFCとして公開するために、作業項目も含まれていました。
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.
このアプローチはしばらくの間うまく機能しましたが、編集者や椅子を含む参加者が、予算削減によって導入された困難を克服するのに十分な関心レベルを維持することが困難になりました。その結果、ドラフトは現在失効していますが、重要な技術的問題は顕著です。
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]などのRADIUS使用仕様の初期バージョンや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].
これらの問題に対処し、IEEE 802.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.
IEEE 802.11iなどのIEEE 802.11グループやIEEE 802.11fなどのグループも、EAPおよびAAA作業に依存しています。IEEE 802.11がEAPメソッドの開発とEAPキー管理フレームワークの開発が必要であるため、この関係はより困難でした。これは、IEEE 802.1が必要とする明確化と更新とは対照的に、実質的な新しいIETF作業を表していました。
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を介したEAP [RFC2284]のカプセル化と、IEEE 802.1xおよびEAPの共同動作のための状態マシンを定義しました。
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の開発中に、半径/EAP [RFC2869]の仕様でいくつかの問題が発見され、その結果、改訂[RFC3579]で作業が開始されました。さらに、[RFC2865]、[RFC2866]、[RFC2867]、[RFC2868]、[RFC2869]、および[RFC3162]で[RFC2865]、[RFC2866]、[RFC2867]、[RFC2868]、[RFC3162]で定義されている半径属性がどのように定義されているかについて説明が必要でした。これに対処するために、非規範的な半径使用の付録を[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]が明らかになりました。IEEE 802.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内で処理されましたが、これはほとんど不活性でした。改訂されたEAP仕様とEAP状態マシンの仕様に基づいて作業を行うために、IETF EAP WGは2002年7月に形成されました。IEEE802.1とPPPEXTの参加者であるBernard Abobaは、共同議長に指名されました。
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の改訂を必要とします。]。改訂された半径/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]
- [RFC3580]に基づく改訂された半径使用の付録 - [RFC3579]に基づく明確化 - [RFC3748]および[RFC4137]に基づく改訂されたIEEE 802.1x状態マシン
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の間にリエゾンが確立されました。進行中のIEEE 802.1xリビジョンへのアクセスを取得するWG。
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参加者は、IEEE 802内での投票ステータスに関係なく、IEEE 802投票プロセスの一部としてコメントすることができます。積極的な協力がある場合、IETF WGは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]はIESGによってRFCとして公開されて承認され、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の共同参加者の仕事によるものでした。
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プレナリーで共同会議を開催し、いずれかのグループ（およびEAP WG参加者）のメンバーがIEEE 802.11i作業にアクセスできるようにするリエゾンの取り決めを確立しました。
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]に依存していたため、EAP、EAPメソッド、およびEAPのAAAサポートを含む[IEEE-802.1x-2004]の依存関係を継承しました。さらに、IEEE 802.11iは主要な管理にEAPを使用したのに対し、[IEEE-802.1x]はそうではないため、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 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.
2002年2月、IEEE 802.11は、EAP、EAPメソッド、およびEAPキー管理に関する追加の作業を要求するIESG [IEEE-80211Liason1]にリエゾンレターを送信しました。この手紙は、IETF 53の2番目のEAP BOFで提示され、EAP WGチャーターへの入力として使用されました。2003年3月、別のリエゾンレターが提示され、EAPメソッド作業の要件をさらに説明しました[IEEE-80211Liason2]。これには、IEAE 802.11iのセキュリティ要件を満たすメソッドを提供するために、[RFC3748]内の必須のEAPメソッドの変更を検討するためのEAP WGのIEEE 802.11iからのリクエストが含まれていました。
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メソッドのセキュリティ要件を考慮することをインターネットエリアディレクターのErik 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は、AAA拡張機能とEAPキーヒエラルキーの変更を潜在的に必要とする可能性のある高速ハンドオフに関連する議論に関与しています。ただし、この作業の方向はまだ決定されていないため、リエゾンリクエストはまだ策定されていません。
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月、ドロシー・スタンレーは、IEEE 802.11とAAA、BMWG、CapWap、EAPを含むIETF WGSの調整を支援するために、IEEE 802.11からIETFへのリエゾンに任命されました。
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）の開発の一環として、アクセスポイント間の通信を保護するだけでなく、以前のアクセスポイントのMACアドレスのIPアドレスへの逆解像度をサポートする必要がありました。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は、RADIUSプロトコル[RFC2865]を拡張して、逆のアドレス解決とIPSECキー管理を提供することを選択しました。これは、ベンダー固有の属性（VSA）の使用と、RADIUSサービスタイプの属性の追加値の定義を通じて追加された新しいRADIUSコマンドを使用することで実現されました。その結果、[RFC2865]に含まれるIANAの考慮事項では、IETFレビューは必要ありませんでした。その後、ほとんどの場合、IETFのレビューを要求するために、半径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 WGSの間でリエゾンの配置は開発されていません。IEEE 802.11fが再循環投票に入ると、仕様の変更に関するコメントのみを考慮することができます。その結果、IEEE 802.11F半径拡張機能に関連する問題が拒否されました。
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執行委員会は、2005年11月18日に撤退を承認しました。その結果、IEEE 802.11Fが使用するために割り当てられた半径パラメーターは、再生することができます。
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
バーナード・アボバ・ロア・アンダーソン・ブライアン・カーペンター・レスリー・デイグル・パトリック・ファルトロム・ボブ・ヒンデン・クルティス・リンドクヴィスト・デイビッド・マイヤー・ペッカ・ニカンダー・エリック・レスカルラ・ピート・レストニック・ジョナサン・ローゼンバーグ・リキシア・ザン
Author's Address
著者の連絡先
Bernard Aboba Microsoft One Microsoft Way Redmond, WA 98052 USA
バーナード・アボバ・マイクロソフト・ワン・マイクロソフト・ウェイ・レドモンド、ワシントン州98052 USA
EMail: bernarda@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。