Network Working Group D. Harrington, Ed.
Request for Comments: 4663 Effective Software Consulting
Category: Informational September 2006
Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG
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
抽象
This document describes the plan to transition responsibility for bridging-related MIB modules from the IETF Bridge MIB Working Group to the IEEE 802.1 Working Group, which develops the bridging technology the MIB modules are designed to manage.
この文書では、MIBモジュールを管理するように設計されているブリッジング技術を開発IEEE 802.1ワーキンググループ、IETFへのブリッジMIB作業部会からのブリッジング関連のMIBモジュールの責任を移行する計画を説明しています。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Motivation .................................................3
2. New IEEE MIB Work ...............................................3
2.1. New MIB PARs ...............................................3
2.2. IEEE MIB Modules in ASCII Format ...........................4
2.3. OID Registration for New MIB Modules .......................5
3. Current Bridge MIB WG Documents .................................6
3.1. Transferring Current Bridge MIB WG Documents ...............6
3.2. Updating IETF MIB Modules ..................................6
3.3. Clarifications on Variables Mapping and Compliance .........8
4. Mailing List Discussions ........................................9
5. IETF MIB Doctor Reviews .........................................9
5.1. Introduction ...............................................9
5.2. Review Guidelines .........................................10
5.3. Review Format .............................................13
5.4. Review Weight .............................................14
6. Communicating the Transition Plan ..............................15
7. Security Considerations ........................................15
8. IANA Considerations ............................................15
9. Intellectual Property Considerations ...........................16
Appendix A. Contributors .........................................18
Appendix B. Sample Text for IEEE to Request Rights from Authors ..19
Normative References ..............................................20
Informative References ............................................20
This document describes the plan to transition responsibility for bridging-related MIB modules from the IETF Bridge MIB WG to the IEEE 802.1 WG, which develops the bridging technology the MIB modules are designed to manage. The current Bridge MIB WG documents are
この文書では、ブリッジング関連のMIBモジュールをIETFブリッジMIB WGからのMIBモジュールが管理するように設計されているブリッジング技術を開発IEEE 802.1 WGへの責任を移行する計画を説明しています。現在のブリッジMIB WGの文書があります
o "Definitions of Managed Objects for Bridges" [RFC4188],
[RFC4188] O「ブリッジのための管理オブジェクトの定義」、
o "Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol" [RFC4318]
「高速スパニングツリープロトコルとブリッジのための管理オブジェクトの定義」O [RFC4318]
o "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions" [RFC4363], and
「トラフィッククラス、マルチキャストフィルタリング、および仮想LAN拡張機能を持つブリッジのための管理オブジェクトの定義」O [RFC4363]、および
o "Definitions of Managed Objects for Source Routing Bridges" [RFC1525].
[RFC1525] o「はソースルーティングブリッジのための管理オブジェクトの定義」。
This document is meant to establish some clear expectations between IETF and IEEE about the transition of Bridge MIB WG MIB modules to the IEEE 802.1 WG, so that the plan can be reviewed by the IESG, IAB, IETF, and IEEE. Some case-by-case situations might arise, which will be handled by the appropriate liaisons, but this document describes the general strategy.
この文書は、計画はIESG、IAB、IETF、およびIEEEによって確認することができますように、IEEE 802.1 WGへのブリッジMIB WG MIBモジュールの移行に関するIETFとIEEEの間にいくつかの明確な期待を確立することを意味しています。いくつかのケースバイケースの状況は、適切なリエゾンによって処理される、発生するかもしれませんが、このドキュメントでは、一般的な戦略について説明します。
Having SNMP MIB modules to provide management functionality for its technologies is important for the 802.1 community, so it needs to charter this work as part of the Project Authorization Requests (PARs) for each new project, to ensure that resources are being mobilized for execution. This is also true with respect to MIB support for already completed 802.1 projects - maintenance projects need to include the development of SNMP MIB modules.
その技術のための管理機能を提供するために、SNMP MIBモジュールを持つことは802.1コミュニティにとって重要であり、それは資源が、実行のために動員されていることを確実にするために、各新規プロジェクトのプロジェクト承認要求（のPAR）の一環として、憲章にこの作業を必要とします。また、これはすでに完了802.1プロジェクトのためのMIBサポートに関して真実である - メンテナンスプロジェクトは、SNMP MIBモジュールの開発を含める必要があります。
The IESG has mandated that IETF WGs that produce a protocol are also required to develop the corresponding MIB module rather than leave that to "the SNMP experts" to do later. Part of the motivation was obviously to make the protocols more manageable, but part of the motivation was also balancing the workload better and getting the content experts more involved in the management design. If such work comes into the IETF from other standards development organizations (SDOs), then we encourage the other SDO to bring in subject matter expertise to work with us, or, even better, to take the lead themselves.
IESGは、プロトコルを生成IETFのWGにも対応するMIBモジュールを開発するのではなく、後に行うには、「SNMPの専門家」にそれを残すために必要とされることが義務付けられています。動機の一部は、プロトコルが管理しやすくするために、明らかだったが、動機の一部はまた、より良いワークロードのバランスを取ると管理設計におけるコンテンツの専門家はより複雑になりました。このような作業は、他の標準開発機関（SDOの）からIETFに来れば、我々はリード自体を取るために、より良い、私たちと一緒に仕事、またはする主題の専門知識をもたらすために、他のSDOを奨励します。
The manpower problem is certainly an aspect that is relevant. IEEE 802 MIB documents could be developed in the IETF, but only if the subject matter experts come to IETF to participate in (lead) the work. The content experts need to be more involved in the MIB module development, and resources need to be dedicated to completing the work, whether editing is done in the IEEE or the IETF. The IETF finds it acceptable if other organizations (like IEEE 802) do MIB documents themselves, and the IETF offers to help review them from an SNMP/MIB/Structure of Management Information (SMI) perspective. This is true even after the transition, since quality MIB modules are important for smooth management of the Internet and the technologies it runs on.
マンパワーの問題は確かに関連性がある側面です。 IEEE 802のMIBの文書は、IETFで開発することができますが、主題の専門家は、（リード）の作業に参加するIETFに来ている場合のみ。コンテンツの専門家は、MIBモジュールの開発にもっと関与する必要があり、編集はIEEEやIETFで行われているかどうかのリソースは、作業を完了に専念する必要があります。 （IEEE 802のような）他の組織は、MIBのドキュメント自体、および管理情報（SMI）の視点のSNMP / MIB /構造からそれらを確認するのに役立つIETF申し出をすればIETFは、それが許容できる見つけます。品質のMIBモジュールがスムーズにインターネットの管理とそれが実行された技術のために重要であるため、これは、も、移行後に真です。
The IEEE-SA Standards Board New Standards Committee (NesCom) deals with the Projects Approval Requests; see http://standards.ieee.org/board/nes/. PARs are roughly the
IEEE-SA基準審議会新基準委員会（NesCom）は、プロジェクトの承認要求を扱います。 http://standards.ieee.org/board/nes/を参照してください。 PARはおおよそです
equivalent of IETF Working Group Charters and include information concerning the scope, purpose, and justification for standardization projects.
IETFワーキンググループチャーターの同等と範囲、目的、および標準化プロジェクトのための正当化に関する情報が含まれます。
Following early discussions concerning the transfer of MIB work from the IETF Bridge MIB WG to the IEEE 802.1 WG, the development of SMIv2 MIB modules associated with IEEE 802.1 projects has been included within the scope of the work of new projects.
IEEE 802.1 WGにIETFブリッジMIB WGからのMIB作業の移転に関する初期の議論に続いて、IEEE 802.1プロジェクトに関連付けられているのSMIv2 MIBモジュールの開発は、新規プロジェクトの仕事の範囲に含まれています。
The latest Project Approval Requests (PAR) of the 802.1 projects, starting with the P802.1ah (Provider Backbone Bridges) approved in December 2004, include explicit text on this respect.
802.1プロジェクトの最新プロジェクト承認要求（PAR）、2004年12月に承認されたP802.1ah（プロバイダーバックボーンブリッジ）で始まり、この点について明示的なテキストが含まれています。
For example, the PAR form of the IEEE 802.1ah, Provider Backbone Bridges [PAR-IEEE802.1ah], includes in Section 13, "Scope of Proposed Project", an explicit reference to 'support management including SNMP'.
例えば、IEEEの802.1ahのPARの形態、プロバイダ・バックボーン・ブリッジ[PAR-IEEE802.1ah]は、第13に、「SNMPを含む支持管理」を明示的に参照「提案されたプロジェクトの範囲」を含みます。
Although it is not mandatory that the MIB development work be specified explicitly in a new PAR to have the work done (see work done in IEEE 802.1AB [IEEE802.1AB] and IEEE 802.1AE [IEEE802.1AE]), it is recommended that IEEE 802.1 WG PARs include explicit wording in the scope section wherever there is a need for MIB development as part of the standard.
MIBの開発作業は作業が、それはすることをお勧めします（IEEE 802.1AB [IEEE802.1AB]およびIEEE 802.1AE [IEEE802.1AE]で行われた作業を参照）を行っているために、新しいPARで明示的に指定することは必須ではありませんが標準の一部として、MIBの開発の必要性がある場所にIEEE 802.1 WGのPARは、スコープ部で明示的な文言が含まれています。
Since the IETF Bridge MIB WG does not intend to develop MIB modules in the future, submitters of new work in the bridge management space should be directed to the IEEE 802.1 WG, and it should be recommended that they not publish their proposed MIB modules as Internet-Drafts.
IETFブリッジMIB WGは、将来的にMIBモジュールを開発する予定はありませんので、ブリッジ管理スペースに新しい作品の提出者は、IEEE 802.1 WGに向けられるべきであり、彼らがインターネットのような彼らの提案MIBモジュールを公開しないことをお勧めしなければなりません-Drafts。
Making MIB modules freely and openly available in an ASCII format will be a critical factor in having the SNMP community accept the transfer of 802.1 MIB development from IETF Bridge MIB WG to IEEE 802.1 WG. Although 802.1 can certainly decide to publish MIB modules only in the PDF format that they use for their documents, without publishing an ASCII version, most network management systems can import a MIB module that is in ASCII format but not one in PDF format. Not publishing an ASCII version of the MIB module would negatively impact implementers and deployers of MIB modules and would make IETF review of MIB modules more difficult.
ASCII形式で自由に公然と利用できるMIBモジュールを作ることはSNMPコミュニティは、IEEE 802.1 WGにIETFブリッジMIB WGから802.1 MIB開発の移転を受け入れた上で重要な要因となります。 802.1は確かにのみ、彼らは彼らの文書に使用するPDF形式のMIBモジュールを公開することを決定することができますが、ASCIIバージョンを公開せずに、ほとんどのネットワーク管理システムには、ASCII形式ではなく、PDF形式のいずれかであるMIBモジュールをインポートすることができます。 MIBモジュールのASCIIバージョンを公開しないと、負MIBモジュールの実装およびデプロイヤに影響を与えるし、MIBモジュールのIETFレビューがより困難になるだろう。
The 802.1 WG web site requires a password for access to standards in development. The WG has started making the MIB module portion of their documents available as separate ASCII files during project development and allowing IETF participants to access these documents for pre-standard review purposes.
802.1 WGのWebサイトには、開発中の規格にアクセスするためのパスワードが必要です。 WGは、プロジェクトの開発中に別のASCIIファイルとして利用でき、その文書のMIBモジュール部分を作り、IETF参加者は事前に標準の見直しのためにこれらのドキュメントにアクセスできるように開始しました。
IEEE 802 has a policy whereby approved specifications are available for a fee for the first six months after approval, and freely available six months after they are approved. Once the specification is approved, the ASCII version of the MIB module is made freely available on the 802.1 WG website (see http://www.ieee802.org/1/files/public/MIBs/ or http://www.ieee802.org/1/pages/MIBS.html).
IEEE 802は、承認された仕様は、承認後の最初の6ヶ月間の料金で利用可能であり、彼らが承認されている6カ月後に自由に利用できることにより、ポリシーを持っています。仕様が承認されると、MIBモジュールのASCIIバージョンは802.1 WGのウェブサイト上で自由に利用できるようになる（参照http://www.ieee802.org/1/files/public/MIBs/またはhttp：//www.ieee802 .ORG / 1 /ページ/ MIBS.html）。
There may be some issues about what gets included in the freely available specification. The SMIv2 MIB module alone will probably be insufficient; some discussion of the structure of the MIB, the relationship to other MIB modules, and security considerations will also need to be made available to ensure appropriate implementation and deployment of the MIB module within the Internet environment. For most implementers, the freely available specification six months after approval will be adequate.
自由に利用可能な仕様に含まれますかについていくつかの問題があるかもしれません。単体のSMIv2 MIBモジュールはおそらく不十分になります。 MIBの構造、他のMIBモジュールとの関係、およびセキュリティ上の考慮事項のいくつかの議論はまた、インターネット環境の中にMIBモジュールの適切な実装と展開を確実にするために利用できるようにする必要があります。ほとんどの実装では、半年承認後、自由に利用できる仕様には十分です。
The IETF and IEEE 802 have separate registration branches (arcs) in the Object Identifier (OID) tree. The Bridge MIB modules are registered under the IETF branch, and some assignments are maintained by IANA. The administration of the IEEE 802 arc is documented in [IEEE.802b].
IETFおよびIEEE 802は、オブジェクト識別子（OID）ツリー内の別登録枝（アーク）を有します。ブリッジMIBモジュールは、IETFの枝の下で登録されている、といくつかの割り当てはIANAによって維持されています。 IEEE 802アークの投与は、[IEEE.802b]に記載されています。
As the IEEE 802.1 WG updates the IEEE 802.1 standards, the changes may include needed modifications to supplement the existing tables. This can be handled by developing an IEEE MIB module that augments the existing tables, or that reuses the indexing of the existing tables. The new modules can be registered under the 802.1 registration branch, as was done with the 802.1X MIB module.
IEEE 802.1 WGは、IEEE 802.1規格を更新として、変更は既存のテーブルを補完するために必要な修飾を含んでいてもよいです。これは、既存のテーブルを補強IEEE MIBモジュールを開発することによって処理することができ、またはそれは、既存のテーブルのインデックスを再利用します。 802.1X MIBモジュールで行ったように、新しいモジュールは、802.1登録枝の下に登録することができます。
When the changes only require the addition of one or two objects to the existing MIB modules, it may seem simpler for the 802.1 WG to define additional managed objects within the IANA-controlled registration tree. This approach is not recommended because of the difficulties of coordinating the changes between the two organizations, and of working the changes through the processes while trying to remain timely for each organization. Such additions would probably require approval by the Area Directors of Operations and Management after IETF MIB Doctor review. This would create dependencies between the work of the two organizations, and it might generate special cases for IANA to prevent the IEEE from being bogged down by IETF processes.
変更は、既存のMIBモジュールに一つまたは二つのオブジェクトの追加を必要とすると802.1 WGは、IANA制御の登録ツリー内の追加の管理対象オブジェクトを定義するために、それは単純に見えるかもしれません。このアプローチは、理由は2つの組織間の変化を調整し、各組織のためのタイムリーなままにしようとしているときのプロセスを使用して変更を作業のことの難しさをお勧めしません。このような追加は、おそらくIETF MIB医師レビュー後の運用・管理の地域の取締役の承認を必要とします。これは、両機関の作業間の依存関係を作成し、それはIETFのプロセスで行き詰まるされることからIEEEを防ぐために、IANAのための特別なケースを生成することがあります。
The approach of developing an IEEE MIB module and defining a new compliance clause is simpler than dealing with such dependencies.
IEEE MIBモジュールを開発し、新たなコンプライアンス句を定義するアプローチは、このような依存関係を扱うよりも簡単です。
We need a balance between disruption to existing implementations and efficiency in making changes. Keeping the existing trees in their place minimizes disruption to existing implementations.
私たちは、変更を行うことで既存の実装と効率の中断の間のバランスを必要としています。その場所で、既存の樹木を維持する既存の実装への中断を最小限に抑えることができます。
During review of the legal issues associated with transferring Bridge MIB WG documents to the IEEE 802.1 WG, it was concluded that the IETF does not have sufficient legal authority to make the transfer without the consent of the document authors.
IEEE 802.1 WGへのブリッジMIB WG文書を転送に関連した法的問題の検討中に、IETFは、文書の作成者の同意なしに転送を行うための十分な法的権限を持っていないと結論されました。
RFC1286, RFC1493, and RFC1525 apparently precede any specific IETF document describing the copyright and intellectual property rights that authors grant to the IETF. RFC2674 falls under RFC 2026 [RFC2026] rules. The three recent updates, [RFC4188], [RFC4318], and [RFC4363], fall under BCP 78, as documented in RFC3978 [RFC3978].
RFC1286、RFC1493、RFC1525とは明らかに著者はIETFに付与著作権および知的財産権を記述した任意の特定のIETFの文書の前に。 RFC2674は、RFC 2026 [RFC2026]のルールに該当します。 3つの最近のアップデート、[RFC4188]、[RFC4318]、および[RFC4363]、RFC3978に記載されているように、BCP 78に該当[RFC3978]。
To permit them to perform maintenance and development of derivations works from documents containing the BRIDGE-MIB [RFC4188], P-BRIDGE-MIB, Q-BRIDGE-MIB [RFC4363], and RSTP-MIB [RFC4318], the IEEE 802.1 WG will need to get permission from the authors and/or the companies to whom the authors have assigned their intellectual property rights in these documents.
BRIDGE-MIB [RFC4188]を含む文書から作品派生の維持・発展を実行するためにそれらを許可し、P-BRIDGE-MIB、Q-BRIDGE-MIB [RFC4363]、およびRSTP-MIB [RFC4318]、IEEE 802.1 WG意志著者らは、これらの文書に自分の知的財産権を割り当てた人に、著者および/または会社からの許可を取得する必要があります。
The IETF legal counsel for IPR matters and the IEEE Standards Association Manager of Standards Intellectual Property have agreed upon a sample letter for use by the IEEE 802.1 WG to request the necessary permissions from the authors, which is shown in Appendix B. The Bridge MIB WG chairs reviewed the author lists for the documents and provided the list of authors and their last known addresses and the documents with which they were associated to the IEEE Standards Association Manager of Standards Intellectual Property.
知的財産権問題と標準知的財産のIEEE規格協会マネージャのためのIETFの弁護士は、付録B.ザ・ブリッジMIB WGに示されている著者からの必要な権限を要求するIEEE 802.1 WGで使用するためのサンプルレターに合意しています椅子は、文書のための著者のリストを見直し、それらが標準知的財産のIEEE規格協会マネージャーに関連していたたと著者と彼らの最後の既知のアドレスと文書のリストを提供します。
The IETF will retain all the rights granted at the time of publication in the published RFCs.
IETFが公開するRFCで発行時点のもので付与されたすべての権利を保持します。
The updates to the Bridge MIB WG documents addressed changes documented in 802.1t, 802.1u, 802.1v, and 802.1w. These amendments were merged with 802.1D-1998 by the IEEE 802.1 WG to form 802.1D-2004. The Bridge MIB WG did not address changes that resulted from that merger of documents.
ブリッジMIB WGドキュメントの更新は802.1トン、802.1u、802.1v、および802.1ワットで文書の変更を取り上げました。これらの改訂は、802.1D-2004を形成するために、IEEE 802.1 WGで802.1D-1998と合併しました。ブリッジMIB WGは、文書の合併から生じた変化に対応していませんでした。
The 802.1 WG will need to work through the management objects in the existing documents to determine whether they are consistent with new emerging specifications, including 802.1D-2004. During the final work on these documents in the Bridge MIB WG, there were some issues that we decided not to resolve, which allows them to be dealt with as part of the future work in the 802.1 WG.
802.1 WGは、彼らが802.1D-2004を含む新興仕様と一致しているかどうかを判断するために、既存のドキュメント内の管理オブジェクトを介して動作する必要があります。ブリッジMIB WGにおけるこれらの文書の最終作業中は、我々は彼らが802.1 WGにおける今後の作業の一部として扱われることを可能にする、解決しないことに決めたいくつかの問題がありました。
Work on the following items was deferred to the IEEE:
以下の項目の作業は、IEEEに延期されました。
o The 'autoEdgePort' parameter (802.1D-2004 clause 17.3.3).
'autoEdgePort' パラメータ（802.1D-2004節17.3.3）O。
o The BridgeID object.
BridgeIDオブジェクトO。
o References to 802.1D-1998 were not updated to 802.1D-2004.
O 802.1D-1998への参照は、802.1D-2004に更新されませんでした。
o Some objects in RFC4363 may have been obsoleted in 802.1D-2004
O RFC4363の一部のオブジェクトは、802.1D-2004年に廃止された可能性があります
o Description of dot1dPortOutboundAccessPriority seems wrong, but it followed the description in 802.1D-1998.
O dot1dPortOutboundAccessPriorityの説明が間違っているようだが、それは802.1D-1998で説明を行いました。
o An issue was raised concerning dot1dTpPortInFrames and dot1dTpPortOutFrames. This is an issue left over from RFC 1493.
O問題がdot1dTpPortInFramesとdot1dTpPortOutFramesに関する上げました。これは、RFC 1493から残された問題です。
It was thought that the IEEE might be able to write separate documents containing updates to their technologies, such as 802.1Q, and to include a separate MIB module to augment the IETF MIB modules. However, recent changes to the IEEE standards are expected to require that the way the MIB tables are INDEXED be changed, which is not allowed under SMI rules, so the IEEE will need to rewrite the MIB modules and assign object identifiers under the ieee802 branch.
これは、IEEE 802.1Qは、そのような技術への更新を含む別の文書を、書くこと、およびIETF MIBモジュールを強化するために別のMIBモジュールを含めることができるかもしれないと考えられていました。しかし、IEEE標準規格への最近の変更は、IEEEがIEEE802枝の下にオブジェクト識別子をMIBモジュールを書き換えして割り当てる必要がありますので、MIBテーブルのインデックスが作成されている方法は、SMIの規則の下で許可されていない、変更されることを必要とすると予想されています。
For backwards compatibility, the existing IETF documents will still be valid and remain unchanged.
後方互換性のために、既存のIETFの文書がまだ有効であると変わりません。
If an 802.1 WG document must update or obsolete the IETF version of a Bridge MIB document, the 802.1 WG can create and submit an internet-draft to the IESG to be published as an RFC that points to the openly available IEEE copy and the IEEE standard. The IESG would need to approve the publication of the RFC. The RFC status would be reflected in the RFC-INDEX and also in the database, so it will be reflected on the RFC-Editor web page. Thus, we don't have a problem with synchronization between the copies being published.
802.1 WG文書はブリッジMIBドキュメントのIETFバージョンを更新または廃止されなければならない場合は、802.1 WGは公然と利用できるIEEEコピーおよびIEEE標準を指すRFCとして公開されるようにIESGにインターネットドラフトを作成し、提出することができます。 IESGは、RFCの公表を承認する必要があります。それはRFC-エディタのウェブページに反映されますので、RFCのステータスは、RFC-INDEXにしても、データベースに反映されるだろう。したがって、我々は、公開されているコピー間の同期に問題はありません。
As the 802.1 WG handles the MIB development, the IEEE-standard "managed variables" and the associated IEEE MIB module objects will probably correspond, as many existing BRIDGE-MIB objects already correspond to 802.1 management variables, such as these from 802.1Q.
802.1 WGは、MIBの開発を担当したよう、IEEE標準には、「変数の管理」および関連するIEEE MIBモジュールオブジェクトは、おそらく多くの既存のBRIDGE-MIBオブジェクトはすでに802.1Qからこれらとして802.1管理変数に対応し、対応させていただきます。
Virtual Bridge MIB object IEEE 802.1Q-2003 Reference
仮想ブリッジMIBオブジェクトIEEE 802.1Q-2003リファレンス
dot1qBase dot1qVlanVersionNumber 12.10.1.1 read bridge vlan config dot1qMaxVlanId 12.10.1.1 read bridge vlan config dot1qMaxSupportedVlans 12.10.1.1 read bridge vlan config dot1qNumVlans dot1qGvrpStatus 12.9.2.1/2 read/set garp applicant controls
dot1qBase dot1qVlanVersionNumber 12.10.1.1は、ブリッジVLANの設定dot1qMaxVlanId 12.10.1.1は、ブリッジVLANの設定dot1qMaxSupportedVlans 12.10.1.1は、ブリッジVLANの設定dot1qNumVlans dot1qGvrpStatus 12.9.2.1/2が/セットGARPの申請者のコントロールを読んで読んで読んで読んで
IEEE allows definitions to be clarified in a manner that can actually alter the semantics of a managed variable somewhat, such as by changing the range. SMI rules generally prevent changing the semantics of defined MIB objects without obsoleting the current object and replacing it with an object with a new descriptor and OID registration. It is expected that, once both an IEEE MIB definition and the "managed variable" descriptions are in the same document, this problem will go away, as IEEE can update both at the same time in the approved manner.
IEEEは、定義は、実際にそのような範囲を変更することなどによって、多少管理変数の意味論を変えることができるようにして明らかにされることを可能にします。 SMI規則は、一般的に現在のオブジェクトを時代遅れにして、新しい記述子とOID登録とオブジェクトとそれを交換することなく、定義されたMIBオブジェクトのセマンティクスを変更できません。一度IEEE MIB定義および「管理変数」の記述の両方が同じ文書内にある、ということが予想され、この問題は、IEEEが承認された方法で、両方を同時に更新できるよう、離れて行きます。
The need to fix a description in an IETF Bridge MIB module in a manner that would not be SMI legal would precipitate the need to define an IEEE MIB module, which might copy and replace the whole IETF MIB module or just add the necessary objects. Copying the IETF MIB module, changing the descriptors, and reassigning new IEEE OIDs would not be backwards compatible, and existing applications would need to be updated to access the new objects. Therefore it is recommended that the IETF MIB module not be copied and modified unless doing so is really necessary.
SMI法的ではないであろうようにしIETFブリッジMIBモジュールに記述を修正する必要がコピーして置き換える全体IETF MIBモジュールをあるいは単に必要なオブジェクトを追加する可能性があるIEEE MIBモジュールを定義する必要が沈殿します。 、IETF MIBモジュールをコピーする記述子を変更し、新しいIEEE OIDを再割り当てすることは後方互換性がないだろう、と既存のアプリケーションは、新しいオブジェクトにアクセスするために更新する必要があります。したがって、そうすることが本当に必要でない限り、IETF MIBモジュールは、コピーして変更しないことをお勧めします。
The current practice in the 802.1 WG is to define the management variables and then a mapping table to associated MIB module objects (as shown above). The 802.1 WG could redefine the mapping from an IEEE managed variable to a new IEEE MIB object if the 802.1 management variable semantics changed, thus allowing the 802.1 WG to 'do it right' by SMI rules, supplementing the old MIB object with a new one. An updated mapping would be reflected in the compliance clause of the supplemental SMIv2 MIB module; it may be desirable to document the old mapping information in the description clause of the new object in the SMIv2 MIB module.
（上記のように）802.1 WGにおける現在の慣行は、管理変数と、関連するMIBモジュールオブジェクトへのマッピングテーブルを定義することです。 802.1管理変数の意味は、新しいものと古いMIBオブジェクトを補完する、これ802.1 WGは、SMI規則によって「右のそれを行う」をすることができ、変更された場合はIEEEが新たなIEEE MIBオブジェクトに変数を管理から802.1 WGは、マッピングを再定義することができ。更新されたマッピングは、補足のSMIv2 MIBモジュールのコンプライアンス条項に反映されます。 SMIv2のMIBモジュールに新しいオブジェクトの記述節で古いマッピング情報を文書化することが望ましい場合があります。
Often, the mapping of 802 variables to MIB objects isn't a 1:1 mapping and doesn't have to be. In the future, 802.1 variables may be invented with Web-based services in mind, but today the primary focus is on SNMP usage, and incorporating MIB modules into the specs themselves will likely further that focus. The level of redirection that exists today between 802 variables and MIB objects might be useful for the transition process when 802.1 management variable semantics are changed and MIB objects are supplemented.
1マッピングとする必要はありません。多くの場合、MIBオブジェクトへの802個の変数のマッピングが1ではありません。将来的には、802.1変数を念頭に置いて、Webベースのサービスを考案することができるが、今日の主な焦点は、SNMPの使用状況にあり、そしてそれ自身はおそらくさらにスペックにその焦点をMIBモジュールを組み込むます。 802.1管理変数のセマンティクスが変更され、MIBオブジェクトが補完されたときに802個の変数とMIBオブジェクト間で、今日存在するリダイレクトのレベルは、移行プロセスのために有用であるかもしれません。
The existing Bridge documents represent the current state of bridging management, and the documents contain compliance clauses describing the current requirements to be compliant to the IETF standards. As the IEEE develops addition MIB modules, new compliance clauses will define the new "state of the art", without needing to obsolete the old MIB objects or the old compliance clauses. Therefore, the plan is that the current Bridge MIB modules will be "frozen in time", and updated only via the development of independent MIB modules by the 802.1 WG.
既存のブリッジ文書は、ブリッジ管理の現在の状態を表し、およびドキュメントは、IETF標準に準拠するように、現在の要件を記述したコンプライアンス条項が含まれています。 IEEEが加算MIBモジュールを開発したように、新しいコンプライアンス条項は廃止に古いMIBオブジェクトまたは古いコンプライアンス条項を必要とせずに、新しい「芸術の状態」を定義します。そのため、計画は現在のブリッジMIBモジュールは「時間に凍結」、および802.1 WGによって独立したMIBモジュールの開発を経てのみ更新されるということです。
The Bridge MIB WG has completed its documents, and the WG has been closed.
ブリッジMIB WGは、その書類を完了し、WGはクローズされています。
The mailing list will remain open for a while. The mailing list administrators will discourage discussion of ongoing IEEE MIB module work on the Bridge MIB WG list and ask that the discussion be moved to the IEEE list, with a notice comparable to the following:
メーリングリストは、しばらくの間、開いたままになります。メーリングリストの管理者は、ブリッジMIB WGリスト上の継続的なIEEE MIBモジュールの仕事の議論を阻止し、議論は次のように匹敵する通知を、IEEEのリストに移動することを要求します：
This work is out of scope for the Bridge MIB WG mailing list. The appropriate mailing list for IEEE 802.1 MIB module discussion is STDS-802-1-L@listserv.ieee.org. To subscribe to the STDS-802-1-L list, go to http://www.ieee802.org/1/email-pages/ To see the general information about 802,1, including how they work and how to participate, go to http://www.ieee802.org/1/ To see presentations on the technology, go to http://www.ieee802.org/1/files/public/ and look in the docs2004, docs2005, and docs2006 directories.
この作品は、ブリッジMIB WGメーリングリストの範囲外です。 IEEE 802.1 MIBモジュールの議論のための適切なメーリングリストはSTDS-802-1-L@listserv.ieee.orgです。 STDS-802-1-Lリストを購読するには、彼らがどのように動作するかを含め、どのように参加するには、802,1に関する一般的な情報を表示するにはhttp://www.ieee802.org/1/email-pages/に行き、 、技術上のプレゼンテーションを表示するにはhttp://www.ieee802.org/1/に行くhttp://www.ieee802.org/1/files/public/に行き、docs2004に見て、docs2005、およびdocs2006ディレクトリ。
The leaders of the Bridge MIB WG, 802.1 WG, IETF O&M area, and IEEE 802 project have discussed having IETF MIB Doctors review IEEE 802 developed MIB modules. This is a loose offering.
ブリッジMIB WG、802.1 WG、IETF O＆Mエリア、およびIEEE 802プロジェクトのリーダーは、IETF MIB医師は、IEEE 802先進MIBモジュールを確認した議論してきました。これは緩い製品です。
The expectation is that IETF will maintain a group of MIB Doctors who can review IEEE 802 - developed MIB modules, when a MIB Doctor is available and willing to do such review. It is the choice of individual MIB Doctors to provide technical advice and MIB Doctor reviews, and it is the willingness of the 802.1 editors and the support of the 802.1 chairs that determine whether the advice is accepted. This is not as formalized as it is in the IETF.
MIB医師が利用できると、そのような見直しをしても構わないと思っているとき、MIBモジュールを開発 - 期待はIETFはIEEE 802を確認することができMIB医師のグループを維持することです。技術的なアドバイスやMIB医師レビューを提供するために、個々のMIB医師の選択であり、それは802.1編集者の意欲やアドバイスが受け入れられるかどうかを判断802.1椅子のサポートです。それはIETFであるとして定式としてこれではありません。
In the IETF, the O&M area directors get "pushed" by other area directors to have MIB module documents reviewed by MIB Doctors when they start to come to WG Last Call, IETF Last Call, and certainly no later than when they appear on the IESG agenda. This demand requires prioritization of requests for MIB Doctor reviews by the area directors and prioritization by MIB Doctors when deciding whether to accept a request to review documents.
IETFでは、O＆Mエリアディレクターは、彼らは確かに遅くとも彼らはIESGに表示されたときよりもWGラストコール、IETFラストコール、とに来て起動したときにMIB医師によってレビューMIBモジュールの文書を持っているために、他の地域ディレクターで「プッシュ」を取得します議題。この需要は、ドキュメントを確認するための要求を受け入れるかどうかを決定する際にMIB医師によるエリアディレクターと優先順位付けにより、MIB医師レビューに対する要求の優先順位付けが必要です。
When there are many IETF MIB documents in the queue and an IEEE MIB module document comes along for review, it will be the choice of the individual MIB Doctors whether to accept such a request, and how to prioritize their work.
多くのIETF MIBキュー内の文書やIEEE MIBモジュールのドキュメントはレビューのためにやって来るがある場合、そのような要求を受け入れるかどうかを個々のMIB医師の選択、そしてどのように自分の仕事に優先順位を付けることになります。
It will be helpful to MIB Doctors if the 802.1 chair requests a review early in development, after a MIB module design has been established but before an editor has done much detailing of the MIB module, so that a MIB Doctor can ensure that the table relationships and indexing are reasonable. Then it will be helpful if the 802.1 chair requests reviews only for important ballots, such as sponsor ballots, rather than for every revision.
MIB医師がそのテーブルの関係を確保することができるように802.1椅子は、MIBモジュールの詳細多くを行っているMIBモジュールの設計が確立された後で編集する前に、開発の早い段階で見直しを要求した場合には、MIB医師に参考になりますそして、インデックスは合理的です。 802.1椅子だけなスポンサー投票用紙などの重要な投票のためではなく、すべてのリビジョンのレビューを要求した場合、それは役に立つでしょう。
It is recommended that the 802.1 WG establish its own MIB Doctor review team, to provide a review of MIB modules and to resolve most issues before requesting a review from the IETF MIB Doctors. This will help the 802.1 WG avoid delays caused by dependency on IETF MIB Doctors, and pre-reviewed documents will make it easier for an IETF MIB Doctor to find time to perform a requested review. The IETF is willing to make a loose offering to help the 802.1 WG establish and train such an IEEE MIB Doctor team.
802.1 WGは、MIBモジュールの見直しを提供し、IETF MIB医師からの見直しを要求する前にほとんどの問題を解決するために、独自のMIB医師レビューチームを確立することをお勧めします。これは802.1 WGは、IETF MIB医師への依存による遅延を防ぐことができますし、事前審査書類は、それが簡単にIETF MIB医師は、要求された見直しを行うための時間を見つけるために作るだろう。 IETFは802.1 WGは、IEEE MIB医師チームを確立し、訓練を支援するために緩い提供を作るために喜んでいます。
The IETF has developed Guidelines for Authors and Reviewers of MIB Documents [RFC4181] so that authors and other WG members can check their document against the guidelines before requesting a MIB Doctor review. The 802.1 WG editor should use the RFC4181 guidelines before requesting a MIB Doctor review.
著者および他のWGメンバーがMIB医師レビューを要求する前に、ガイドラインに対する彼らの文書を確認することができるようにIETFは、MIBドキュメント[RFC4181]の著者と査読のためのガイドラインを開発しました。 802.1 WGエディタは、MIB医師レビューを要求する前にRFC4181ガイドラインを使用する必要があります。
RFC4181 also intended to help editors by guiding MIB Doctors, so reviews by different MIB Doctors will remain fairly consistent. Each MIB Doctor has his or her own "pet peeves", and RFC4181 can help an editor know whether a review point is based on the consensus of the MIB Doctors, or on a pet peeve.
RFC4181は、異なるMIB医師によってレビューはかなり一貫性が保たれますので、MIB医師を誘導することにより、編集者を支援するためのもの。各MIB医師は、彼または彼女自身の「いらいら」を持っている、とRFC4181は、編集者が審査ポイントは、MIB医師の合意、またはペットpeeveに基づいているかどうかを知ることができます。
Many SMI constraints, IETF editing constraints, and best current practices are discussed in RFC4181. However, many aspects of good MIB design (e.g., table fate-sharing, good index choices) are more art than science and are not discussed in the guidelines. Those might be more useful to other SDOs (and IETF editors) than guidelines relating to IETF boilerplate requirements. The MIB Doctors have discussed starting a design guidelines document.
多くのSMIの制約、IETF編集制約、およびベストプラクティス現在はRFC4181で説明されています。しかし、良いMIB設計の多くの側面（例えば、テーブルの運命共有、良い指標の選択肢）は、科学よりも芸術であり、ガイドラインで議論されていません。これらは、IETF定型要件に関するガイドライン以外のSDO（およびIETF編集者）に、より便利かもしれません。 MIB医師は、設計ガイドラインの文書を開始議論してきました。
RFC4181 was used for reviewing the 802.1AB [IEEE802.1AB] and 802.1AE [IEEE802.1AE] documents. During those reviews, there were some anomalies about the IEEE use of the guidelines that we need to evaluate further.
RFC4181は802.1AB [IEEE802.1AB]と802.1AE [IEEE802.1AE]文書をレビューするために使用されました。これらのレビュー時には、我々はさらに検討する必要があるガイドラインのIEEE使用に関するいくつかの異常がありました。
For example, in the IETF boilerplates, some of the terms have different meanings in IETF and IEEE, and different editing style guidelines are being used by the different bodies. It would be good to develop an 802 MIB boilerplate that is consistent with the IETF boilerplate, in purpose if not in terminology.
例えば、IETFボイラープレートでは、用語のいくつかは、IETFおよびIEEEで異なる意味を持っている、と別の編集スタイルガイドラインは異なる機関によって使用されています。専門用語ではない場合目的に、IETF定型と一致している802 MIBの決まり文句を開発するのが良いでしょう。
The IETF uses [RFC4181] as a reference document for IETF documents containing MIB modules. It is recommended that in time IEEE 802.1 WG develop its own guidelines for IEEE MIB modules review. Until this happens, Section 3 (General Documentation Guidelines) and Section 4 (SMIv2 Guidelines) in RFC4181 can be used, with the following exceptions and modifications:
MIBモジュールを含むIETFドキュメントの参照文書としてIETF用途[RFC4181]。時間にIEEE 802.1 WGは、IEEE MIBモジュールの見直しのための独自のガイドラインを作成することをお勧めします。これが起こるまでは、RFC4181でセクション3（一般的なドキュメントのガイドライン）及び第4（SMIv2のガイドライン）は、以下の例外と修正を加えて、使用することができます。
o In the introductory paragraphs of Section 3, the list of sections that must be included in a MIB document should be adapted to the IEEE needs and style guide.
O第3の導入の段落では、MIB文書に含まれなければならないセクションのリストは、IEEEニーズやスタイルガイドに適合させる必要があります。
o Sections 3.1 through 3.4 apply as in the IETF document, with the mention that the IETF boilerplate could be edited to comply to the IEEE needs and style guide.
Oセクション3.1 3.4までは、IETF定型がIEEEニーズやスタイルガイドに準拠して編集することができ言及して、IETF文書のように適用されます。
o Section 3.5 (IANA Considerations) does not apply but may be replaced by a section with IEEE recommendations on naming and OID space assignments.
O 3.5節（IANAの考慮事項）は適用されませんが、スペースの割り当てを命名し、OID上のIEEE勧告のセクションに置き換えることができます。
o Sections 3.6 does not apply.
Oセクション3.6は適用されません。
o Section 3.7 (Copyright Notices) does not apply and may be replaced with text corresponding to the IEEE copyright rules. The exception is the case where a document was originally issued by the IETF, and then taken over by the IEEE, in which case, unless the document authors agree otherwise, notices concerning the IETF copyrights (as described in Section 3.7) and IEEE copyrights must be included.
O部3.7（著作権）が適用されないと、テキストはIEEE著作権のルールに対応するに置き換えてもよいです。例外は、文書が最初にIETFによって発行された場合で、その後IEEEによって引き継がれ、その場合には、文書の作成者が別段の合意をしない限り、IETF著作権（3.7節で説明したように）とIEEEの著作権に関する通知がなければなりません含まれます。
o Section 3.8 (Intellectual Property) does not apply and may be replaced with a notice reflecting the intellectual property rules of the IEEE.
O 3.8節（知的財産）が適用されず、IEEEの知的財産規則を反映通知に置き換えてもよいです。
o Sections 4.1 and 4.2 apply as in the IETF document.
Oセクション4.1および4.2は、IETF文書のように適用されます。
o Section 4.3 (Naming Hierarchy) applies with changes related to the OID root of the IEEE 802.1 MIB modules.
Oセクション4.3（階層命名）IEEE 802.1 MIBモジュールのOIDルートに関連する変更を適用します。
o Sections 4.4 to 4.8 apply as in the IETF document
4.4〜4.8 Oセクションは、IETF文書のように適用されます
o Section 4.9 applies, but some interesting problems may arise if IETF-designed modules are being taken over and continued by the IEEE. In order to comply to the requirement, the IEEE should continue to work and maintain the MIB module in the IETF OID space.
O部4.9が適用されますが、IETFに設計されたモジュールが引き継がおよびIEEEによって続けられている場合は、いくつかの興味深い問題が発生する可能性があります。要件に準拠するために、IEEEは、仕事とIETF OID空間のMIBモジュールを維持し続ける必要があります。
An IETF MIB document template that contains all the required sections, following RFC Editor guidelines and the MIB review guidelines, is under development to help editors get started developing a MIB module document. The template will help MIB Doctors check new MIB modules more efficiently by providing the most up-to-date MIB module boilerplate, with sections in the preferred order, suggestions for what to include in certain sections, and the references required to support boilerplate text. It is recommended that the IEEE 802.1 WG establish a comparable template, following the IEEE editing guidelines and the RFC4181 guidelines, where appropriate.
すべての必要なセクションが含まれているIETF MIBのドキュメントテンプレートは、RFC EditorのガイドラインとMIBの審査ガイドラインに従って、編集者は、MIBモジュールのドキュメントを開発し始めるのに役立つ開発中です。テンプレートは、MIB医師は優先順位、特定のセクションに含める内容のための提案、および定型テキストをサポートするために必要な参照のセクションで、最新のMIBモジュールの定型を提供することにより、より効率的に新しいMIBモジュールをチェックするのに役立ちます。 IEEE 802.1 WGは、適切な場合にはIEEEの編集ガイドラインとRFC4181ガイドラインを、以下、比較可能なテンプレートを確立することをお勧めします。
Such an IEEE template could simply be the management clause of an 802.1 document, to be filled in with technology-specific information. In 802.1AB, the MIB clause was restructured to include modified IETF boilerplates and security considerations. This might be a good start on such an IEEE template. It would be helpful to MIB Doctors and editors if the unmodified template was available in ASCII format for automated comparison to a document in development, to verify that the appropriate boilerplate text is being used.
このようなIEEEテンプレートは、単に技術固有の情報で満たされるように、802.1文書の管理句である可能性があります。 802.1ABでは、MIB句は修正IETFボイラープレートおよびセキュリティ上の考慮事項が含まれるように再構築されました。これは、IEEEテンプレートの良いスタートかもしれません。無修正テンプレートは、適切な定型テキストが使用されていることを確認するために、開発中のドキュメントへの自動比較のためにASCII形式で利用した場合には、MIB医師と編集者に役立つだろう。
When the 802.1 WG creates a PAR for 802.1 Bridge MIB maintenance, the creation of such a template might be included in the PAR.
802.1 WGは802.1ブリッジMIBのメンテナンスのためのPARを作成するとき、ようなテンプレートの作成はPARに含まれている場合があります。
The IETF MIB documents include the following text relative to the Internet Management Framework as part of the standard boilerplate:
IETF MIBドキュメントは、標準の定型の一環として、インターネット管理フレームワークに次のテキストの相対が含まれています。
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to Section 7 of RFC 3410 [RFC3410].
現在のインターネット標準の管理フレームワークを記述したドキュメントの詳細な概要については、RFC 3410 [RFC3410]のセクション7を参照してください。
Managed objects are accessed via a virtual information store, termed the Management Information Base, or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580 [RFC2580].
管理対象オブジェクトが仮想情報店を介してアクセスされ、管理情報ベース、またはMIBと呼ばれます。 MIBオブジェクトは、一般的に簡易ネットワーク管理プロトコル（SNMP）を介してアクセスされます。 MIBのオブジェクトは、管理情報（SMI）の構造で定義されたメカニズムを使用して定義されています。このメモは、STD 58、RFC 2578 [RFC2578]、STD 58、RFC 2579 [RFC2579]に記載されているのSMIv2、およびSTD 58、RFC 2580 [RFC2580]に準拠しているMIBモジュールを指定します。
It is recommended that the IEEE 802.1 standards that contain MIB modules include a similar sub-section in the MIB section of the IEEE document, and the appropriate references in their reference section.
MIBモジュールを含むIEEE 802.1規格はIEEE文書のMIBセクションの類似サブ部、およびそれらの基準セクションの適切な参照を含むことが推奨されます。
If IEEE 802.1 WG wants to craft its own guidelines, based on RFC4181, it will need to get the author's permission.
IEEE 802.1 WGは、独自のガイドラインを作るしたい場合は、RFC4181に基づいて、それは著者の許可を取得する必要があります。
The 802.1 WG uses a template for comments, in the following format, so the onus to provide new text is on the reviewer, not on the editor.
802.1 WGは、次の形式で、コメント用のテンプレートを使用していますので、新しいテキストを提供する責任は審査のではなく、エディタです。
NAME: COMMENT TYPE: [E=Editorial, ER=Editorial Required] [T=Technical, TR=Technical Required] CLAUSE: PAGE: LINE: COMMENT START: COMMENT END: SUGGESTED CHANGES START: SUGGESTED CHANGES END:
NAME：COMMENTタイプ：[E =編集、ER =社説必須] [T =技術、TR =技術必須] CLAUSE：PAGE：LINE：COMMENT START：COMMENT END：提案された変更は、START：提案された変更のEND：
MIB Doctor reviews in the IETF are typically done in simple text email and often contain a long list of review comments. MIB Doctor reviews sometimes raise a general design issue rather than an issue with specific text, and some MIB Doctor comments refer to "global" problems, such as many objects that do not specify persistence requirements.
IETFでのMIB医師レビューは、通常、単純なテキストメールで行われ、多くの場合、レビューコメントの長いリストが含まれています。 MIB医師は時々特定のテキストで一般的な設計上の問題ではなく、問題を提起し、いくつかのMIB医師のコメントは、このような永続性要件を指定していない多くのオブジェクトとして「グローバル」の問題を参照してくださいレビュー。
For global problems, IETF MIB Doctors are not required to provide the replacement text for each of these instances when doing 802.1 MIB module reviews. For example, if the naming of objects does not follow recommended conventions throughout the document, the MIB Doctor can point out the relevant clause in RFC4181 without suggesting each replacement object name. This is an important concession to the IETF MIB Doctors, to better suit the nature of their reviews, even though this puts the onus on the editor to fix the problem without explicit suggested changes.
地球規模の問題のために、IETF MIB医師は、802.1 MIBモジュールのレビューを行っているときに、これらの各インスタンスの代替テキストを提供する必要はありません。オブジェクトの命名は、文書全体推奨の規則に従わない場合たとえば、MIB医師は、各置換オブジェクト名を示唆することなく、RFC4181で関連句を指摘することができます。これは、これは明示的な提案された変更せずに問題を解決するために、エディタ上の責任を置いていても、より自分のレビューの性質に合わせて、IETF MIB医師に重要な譲歩です。
During the transition, the chair and vice-chair of the 802.1 WG are willing to accept simple emails, as long as they give enough information to understand what the problem is and how to fix it. The comments should include a problem description, a suggested resolution, and a page and line number. It would be helpful if comments are submitted in the preferred format, since this makes it easier for the editor to understand exactly what is being requested, to log the comment for review, and to review the comment in the meeting environment. The majority of MIB comments can usually be handled outside the official balloting process.
移行時には、椅子と802.1 WGの副議長は、限り、彼らは問題があるとどのようにそれを修正するかを理解するのに十分な情報を与えるよう、シンプルなメールを受け入れようとしています。コメントは、問題の説明、提案解像度、およびページと行番号を含める必要があります。これは、それが簡単に編集者がレビューにコメントをログに記録すると、会議の環境でのコメントを確認するために、要求されているかを正確に把握できるようになりますので、コメントは、好ましい形式で提出された場合には参考になります。 MIBのコメントの大半は、通常、公式投票プロセス外で処理することができます。
In the IETF, MIB Doctor review happens as part of the process of approving a standard. When a document is submitted to the IESG for approval as a standard, the area director/IESG requests a MIB Doctor review. Failure to pass the review can stop forward progress of a document in the standardization process at the discretion of the area director. MIB Doctors take their role seriously and perform detailed reviews.
IETFでは、MIB医師レビューは、標準の承認プロセスの一部として行われます。文書が標準として承認を得るためにIESGに提出された場合、エリアディレクター/ IESGは、MIB医師レビューを要請します。審査に合格しないと、地域ディレクターの裁量で標準化プロセスにおける文書の前進を停止することができます。 MIB医師は、自分の役割を真剣に取り、詳細なレビューを行います。
In the IEEE, the board that approves a standard is separate from the 802.1 WG, and the reviews MIB Doctors will do according to this transition plan are done within the 802.1 WG. So a MIB Doctor review in the 802.1 WG is akin to an IETF WG chair asking for a MIB Doctor to sanity-check the work, rather than to a formal "MIB Doctor review".
IEEEでは、標準を承認ボードは802.1 WGから分離され、およびMIB医師は、この移行計画に沿って行いますレビューは802.1 WG内で行われています。だから、802.1 WGにおけるMIB医師レビューではなく、正式な「MIB医師レビュー」よりも、仕事をチェック正気にMIB医師を求めてIETF WGいすに似ています。
Formally, comments from any origin carry the same weight in 802.1; even voting status in the WG doesn't make one's comments more weighty than those of a non-voter. The 802.1 WG is not permitted to ignore any comments, regardless of origin. Serious comments are always taken seriously and never ignored.
正式には、任意の起源からのコメントは802.1で同じ重量を運びます。 WGでさえ投票ステータスが非有権者よりも自分のコメントがより重いことはありません。 802.1 WGは関係なく、起源の、任意のコメントを無視することは許されません。深刻なコメントは、常に真剣に受け止め、無視されることはありません。
The IEEE typically requires that comments be officially submitted in a specific format, including proposed replacement text, which is then reviewed at the meetings, and the decisions are documented in disposition documents. These comments and dispositions are available from the 802.1 private website. IETF participants can be given the password to the website by the 802.1 WG chair, so that they can see previous and current comments and dispositions.
IEEEは、一般的なコメントが公式その後、会議で検討され、決定は処分の文書に記載されてい提案置換テキストを含め、特定の形式で提出されている必要があります。これらのコメントや処分は802.1個人のウェブサイトから入手可能です。彼らは以前と現在のコメントや処分を見ることができるようにIETFの参加者は、802.1 WGの議長によりウェブサイトにパスワードを付与することができます。
We should not give the impression that the IEEE documents have received the organized, coordinated, and formalized MIB Doctor review as done in the IETF, if such review is done on an ad hoc basis, and not necessarily as part of the advancement process. We need to be clear what is said, because the phrase "This document has passed MIB Doctor review" has quite some weight in the IETF. We need to clarify whether to describe the reviews done as having been done by an "IETF MIB Doctor" or "IEEE 802 MIB Doctor", or by a generic "MIB Doctor".
私たちは、コーディネート、IEEE文書が整理を受けているような印象を与え、IETFに行ったようなレビューは場当たり的で、必ずしも前進プロセスの一環として行われている場合、MIB医師レビューを正式にはなりません。フレーズはIETFでのかなりの量を有している「このドキュメントは、MIB医師レビューが経過している」ので、私たちは、言われている明確にする必要があります。私たちは、「IETF MIBドクター」または「IEEE 802 MIBドクター」によって行われたものとして、または一般的な「MIBドクター」によって行わレビューを記述するかどうかを明確にする必要があります。
MIB Doctor reviews be copied to the document editor, and to the 802.1 chair.
MIB医師レビューは、文書エディタにコピーし、そして802.1椅子にすること。
The transition plan was discussed in the Bridge MIB WG at IETF61 and included a presentation, "Bridge MIB Transition to IEEE 802.ppt", available in the proceedings.
移行計画はIETF61でブリッジMIB WGで議論し、手続きで利用可能なプレゼンテーション、「IEEE 802.pptへのブリッジMIBの移行」を、含まれていました。
The intent to transition was also posted on the Bridge MIB WG mailing list during notices of the Bridge MIB WG closure, including the WG Action announcement of February 15, 2006.
移行への意思も2006年2月15日のWGアクションの発表など、ブリッジMIB WGの閉鎖の通知時にブリッジMIB WGメーリングリストに投稿されました。
The transition was discussed with the 802.1 WG at the San Antonio, San Francisco, and Garden Grove meetings. Presentations are available in http://www.ieee802.org/1/files/public/docs2004/ new-bridge-mib-transition-1104.ppt, http://www.ieee802.org/1/files/ public/docs2005/liaison-ietf-congdon-0705.pdf, and http://www.ieee802.org/1/files/public/docs2005/ liaison-ietf-congdon-0905.pdf.
移行は、サンアントニオ、サンフランシスコ、そしてガーデングローブ会議で802.1 WGで議論されました。プレゼンテーション/ http://www.ieee802.org/1/files/、http://www.ieee802.org/1/files/public/docs2004/新しいブリッジ-MIB-遷移1104.pptに公共利用可能ですdocs2005 /リエゾン-IETF-コングドン-0705.pdf、およびhttp://www.ieee802.org/1/files/public/docs2005/リエゾン-IETF-コングドン-0905.pdf。
This document describes a plan to transition MIB module responsibility from the IETF Bridge MIB WG to the IEEE 802.1 WG. It does not impact security.
このドキュメントでは、IEEE 802.1 WGにIETFブリッジMIB WGからのMIBモジュールの責任を移行する計画を説明しています。これは、セキュリティに影響を与えません。
Although this document discusses issues related to IANA assignment of OIDs, no IANA actions are required by this document.
このドキュメントは、OIDのIANAの割り当てに関連する問題について説明しますが、何のIANAのアクションは、この文書で必要ありません。
On November 29, 2005, a teleconference was held that included Jorge Contreras, Scott Bradner, Bernard Aboba, Bert Wijnen, and David Harrington, to discuss the Intellectual Property Issues. The following is a summary of the conclusions:
2005年11月29日には、会議は知的財産の問題を議論するために、ホルヘ・コントレラス、スコット・ブラッドナー、バーナードAboba、バートWijnen、およびデヴィッドハリントンが含まれていることが開催されました。以下は、結論の要約です：
The IETF/ISOC gets a non-exclusive copyright license from RFC authors so that the IETF can publish RFCs, let third parties translate RFCs into other languages, let third parties reproduce RFCs as-is and create derivative works within the IETF standard process. The author(s) retain all of their rights other than the right to withdraw the permission for the IETF to do the above.
IETF / ISOCは、RFC著者からの非独占的な著作権のライセンスを取得するIETFは、RFCを発行する第三者が他の言語にRFCを翻訳してみましょう、第三者がそのままRFCを再現し、IETF標準プロセス内の派生作品を作成させることができるように。著者（複数可）上記を行うためのIETFの許可を撤回する権利以外の権利のすべてを保有します。
If anyone (including the IEEE) wants to reproduce any RFC as-is, he or she can do so without any specific permission, but it has to be "as-is" (and that includes the ISOC copyright notice) since the right for third parties to reproduce RFCs is part of the rights the IETF gets from the author(s).
（IEEE含む）誰でも、そのまま任意のRFCを再生したい場合は、彼または彼女は、特定の許可なしに行うことができますが、それは「そのまま」（とそれがISOCの著作権表示を含んでいる）である必要がありますのために右からRFCを再現する第三者は、IETFは、著者（複数可）から取得する権利の一部です。
The author(s) of a RFC can tell another group (e.g., the IEEE) that the other group can produce its own versions of the RFC, since the IETF does not get from the author(s) the right to stop them from doing so.
RFCの著者（複数可）IETFは、著者（複数可）からやってからそれらを停止する権利を取得していないので、他のグループは、RFCの独自のバージョンを作り出すことができるという別のグループ（例えば、IEEE）を伝えることができますそう。
If the author(s) give another group the permission to create derivative works, this has nothing (legally) to do with the IETF, since the agreement is just between the author(s) and the other group. Because of that, there is no reason for an ISOC copyright to appear, since the new document is not an IETF document. It would be nice if the other group were to include a note to say that their document is based on RFC XXXX, and the authors can insist on that if they want to, but the IETF has no formal role in granting permissions, so the IETF cannot require the pointer to the RFC.
著者（s）は、別のグループに派生物を作成する権限を与えると契約したばかりの著者（複数可）および他のグループの間であることから、これは、IETFとは何の関係も（法的に）を持っていません。そのため、新しい文書がIETF文書ではないので、ISOCの著作権は、表示されるために理由はありません。他のグループはその文書がRFC XXXXに基づいていると言って、ノートを含めるようにした場合、それはいいだろう、と彼らがしたい場合は、著者がその主張することができますが、IETFは、権限を付与するには、正式な役割を持っていないので、IETF RFCへのポインタを必要とすることはできません。
There is a desire to ensure that the IETF has sufficient rights to do derivatives of its own works. If the IETF decides, as part of a liaison arrangement with another SDO, to hand over maintenance of a specification to them, and if the authors give the other SDO permission to create derivative works, the IETF still retains the permission granted by the authors to create derivative works within the IETF standard process.
IETFは、自身の作品の誘導体を行うための十分な権限を持っていることを確認することが望まれています。 IETFは、彼らに仕様のメンテナンスを引き渡すために、別のSDOとの連絡配置の一環として、決定した、と著者は派生物を作成するために、他のSDOの許可を与える場合は、IETFはまだに著者によって付与された権限を保持している場合IETF標準プロセス内の派生物を作成します。
The IETF strongly recommends that any derivative works developed by another standards body DO acknowledge that the work builds on prior IETF work, with reference to the RFC(s) the work derives from. MIB modules compliant to the IETF Best Current Practices documented in RFC4181 contain REVISION clauses that document how/where earlier versions were published.
IETFは強く、他の標準化団体によって開発された任意の派生物は、仕事は仕事から派生RFC（複数可）を参照して、以前のIETF仕事の上に構築することを認めることをお勧めします。 RFC4181に記載IETFベスト現在のプラクティスに準拠したMIBモジュールは、以前のバージョンが公開された場所か/改訂条項が含まれています。
On January 11, 2006, another teleconference was held, to review the legal issues with Claudio M. Stanziola, the IEEE Standards Association Manager of Standards Intellectual Property. As a result of that discussion, the IETF Legal Counsel on IPR matters has crafted a sample document that other SDOs may use as a guideline for producing their own documents on "how to ask the question" to solicit authors' permissions. The template is included in this document in Appendix B.
2006年1月11日には、別の会議は、クラウディオ・M. Stanziola、標準知的財産のIEEE規格協会マネージャーと法的問題を検討するために、開催されました。その議論の結果、知的財産権問題に関するIETF法律顧問は、上の他のSDOが自分のドキュメントを生成するためのガイドラインとして使用することができますサンプル文書を細工している著者の許可を求めるために、「どのように質問をします」。テンプレートは、付録Bでこの文書に含まれています
Appendix A. Contributors
付録A.協力者
Dan Romascanu Avaya Atidim Technology Park, Bldg. #3 POB 58173 Tel Aviv, 61581 Israel Phone +972 3-645-8414 EMail: dromasca@avaya.com
ダンRomascanu AvayaのATIDテクノロジーパーク、ビル。 ＃3 POB 58 173テルアビブ、イスラエル61 581電話番号+972 3-645-8414 Eメール：dromasca@avaya.com
Tony Jeffree Chair, 802.1 WG 11A Poplar Grove Sale Cheshire M33 3AX UK Phone: +44 161 973 4278 EMail: tony@jeffree.co.uk
トニーJEFFREE議長、802.1 WG 11Aポプラグローブ販売チェシャーM33 3AX英国電話：+44 161 973 4278 Eメール：tony@jeffree.co.uk
Paul Congdon Vice Chair, 802.1 WG Hewlett Packard Company HP ProCurve Networking 8000 Foothills Blvd, M/S 5662 Roseville, CA 95747 US Phone: +1 916 785 5753 EMail: paul.congdon@hp.com
ポールコングドン副議長、802.1 WGヒューレット・パッカード社HPのProCurveネットワーキング8000山麓ブルバード、M / S 5662ローズ、CA 95747米国電話：+1 916 785 5753 Eメール：paul.congdon@hp.com
Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten NL Phone: +31-348-407-775 EMail: bwijnen@lucent.com
バートWijnenルーセント・テクノロジーショームバーグ33 3461 GL Linschoten英国電話：+ 31-348-407-775 Eメール：bwijnen@lucent.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 US Phone: +1 425 818 4011 EMail: bernarda@microsoft.com
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052米国電話：+1 425 818 4011 Eメール：bernarda@microsoft.com
Appendix B. Sample Text for IEEE to Request Rights from Authors
IEEEは、著者からの権利を要求することについては、付録B.サンプルテキスト
> "Dear Author,
>「親愛なる者、
The IEEE P802.1 working group wishes to incorporate portions of IETF RFC XXXX (specifically YYY MIB modules) as part of IEEE Draft Standard P802.1 and to develop, modify and evolve such portions as part of the IEEE standardization process.
IEEE P802.1ワーキンググループは、IEEEドラフト規格P802.1の一部としてIETF RFC XXXX（具体YYY MIBモジュール）の部分を組み込むようにし、IEEE標準化プロセスの一環として、このような部分を、開発変更および進化することを望みます。
Because the authors of contributions to the IETF standards retain most intellectual property rights with respect to such contributions under IETF policies in effect during the development of RFC XXXX, and because you are an author of said document, the IEEE hereby requests that you kindly agree to submit your contributions in RFC XXXX to the IEEE for inclusion in IEEE P802.1. Please note that IETF is aware of and supports this request.
IETF標準化への貢献の著者は、RFC XXXXの開発時に有効なIETFの方針の下で、このような貢献に関しては、ほとんどの知的財産権を保持し、あなたが言った文書の作成者であるため、IEEEはここにあなたが親切に同意することを要求しているのでIEEE P802.1に含めるためIEEEにRFC XXXXであなたの貢献を提出します。 IETFが認識していると、この要求をサポートしていることに注意してください。
Attached hereto, please find a copyright permission letter template that we ask you kindly to sign and return, granting the aforementioned rights to the IEEE.
添付これに、我々はIEEEに前述の権限を付与、署名し、返すように親切にお聞き著作権許可の手紙のテンプレートを見つけてください。
Sincerely yours, IEEE"
敬具、IEEE」
References
リファレンス
Normative References
引用規格
[RFC1525] Decker, E., McCloghrie, K., Langille, P., and A. Rijsinghani, "Definitions of Managed Objects for Source Routing Bridges", RFC 1525, September 1993.
[RFC1525]デッカー、E.、McCloghrie、K.、Langille、P.、およびA. Rijsinghani、RFC 1525、1993年9月 "ソースルーティングブリッジのための管理オブジェクトの定義"。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
[RFC3978]ブラドナーの、S.、 "質問の投稿IETF権"、BCP 78、RFC 3978、2005年3月。
[RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects for Bridges", RFC 4188, September 2005.
[RFC4188] Norseth、K.およびE.ベル、 "ブリッジのための管理オブジェクトの定義"、RFC 4188、2005年9月。
[RFC4318] Levi, D. and D. Harrington, "Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol", RFC 4318, December 2005.
[RFC4318]レビとD.とD.ハリントン、RFC 4318、2005年12月「ラピッドスパニングツリープロトコルとブリッジのための管理オブジェクトの定義」。
[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拡張機能を持つブリッジのための管理オブジェクトの定義」。
Informative References
参考文献
[IEEE802.1AB] "IEEE Std 802.1AB-2005, Standard for Local and metropolitan area networks - Station and Media Access Control Connectivity Discovery", IEEE Std 802.1AB-2005 IEEE Std, 2005.
[IEEE802.1AB] "IEEE STD 802.1AB-2005、ローカルおよびメトロポリタンエリアネットワークのための標準 - 駅やメディアアクセス制御接続ディスカバリー"、IEEE規格802.1AB-2005 IEEE STD 2005。
[IEEE802.1AE] "IEEE P802.1AE-2006, Draft Standard for Local and metropolitan area networks - Media Access Control (MAC) Security.", http://www.ieee802.org/1/files/ private/ae-drafts/d4/802-1ae-d4-0.pdf IEEE Draft, January 2006.
[IEEE802.1AE] "IEEE P802.1AE-2006、ドラフト標準ローカルおよびメトロポリタンエリアネットワークのために - 。メディアアクセス制御（MAC）セキュリティ" は、http://www.ieee802.org/1/files/プライベート/ AE-ドラフト/ D4 / 802-1ae-d4-0.pdf IEEEドラフト、2006年1月。
[IEEE.802b] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Overview and Architecture, Amendment 2: Registration of Object Identifiers", IEEE Standard 802, 2004.
[IEEE.802b]電気電子学会、「地方とメトロポリタンエリアネットワーク：概要とアーキテクチャ、修正2：オブジェクト識別子の登録」の研究所、IEEE規格802、2004。
[PAR-IEEE802.1ah] "http://standards.ieee.org/board/nes/ projects/802-1ah.pdf", 802-1ah IEEE PAR, December 2004.
[PAR-IEEE802.1ah] "http://standards.ieee.org/board/nes/プロジェクト/ 802-1ah.pdf"、802-1ah IEEE PAR、2004年12月。
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、パーキンス、D.、およびJ. Schoenwaelder、STD 58、RFC 2578、1999年4月 "管理情報バージョン2（SMIv2）の構造"。
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、パーキンス、D.、およびJ. Schoenwaelder、 "SMIv2のためのテキストの表記法"、STD 58、RFC 2579、1999年4月。
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrie、K.、パーキンス、D.、およびJ. Schoenwaelder、 "SMIv2のための適合性宣言"、STD 58、RFC 2580、1999年4月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、 "インターネット標準の管理フレームワークのための序論と適用性声明"、RFC 3410、2002年12月。
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005.
[RFC4181]聞いた、C.、 "MIBドキュメントの著者と査読のためのガイドライン"、BCP 111、RFC 4181、2005年9月。
Author's Address
著者のアドレス
David Harrington (editor) Effective Software Consulting Harding Rd Portsmouth NH USA
デヴィッド・ハリントン（エディタ）効果的なソフトウェアコンサルティングハーディングRdのポーツマスNH USA
Phone: +1 603 436 8634 EMail: dbharrington@comcast.net
電話：+1 603 436 8634 Eメール：dbharrington@comcast.net
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）によって提供されます。