[要約] RFC 4663は、IETF Bridge MIB WGからIEEE 802.1 WGへのMIB作業の移行に関する要約です。その目的は、MIB作業を適切な標準化団体に移管し、効果的な管理と進行を確保することです。
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
IETFブリッジMIB WGからIEEE 802.1 WGにMIB作業を転送する
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
概要
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.
このドキュメントでは、IETF Bridge MIBワーキンググループからIEEE 802.1ワーキンググループへのブリッジング関連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
このドキュメントでは、IETFブリッジMIB WGからIEEE 802.1 WGへのブリッジング関連MIBモジュールの責任を移行する計画について説明します。これにより、MIBモジュールが管理するように設計されたブリッジングテクノロジーが開発されています。現在のブリッジMIB WGドキュメントはです
o "Definitions of Managed Objects for Bridges" [RFC4188],
o 「ブリッジの管理されたオブジェクトの定義」[RFC4188]、
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
o 「トラフィッククラス、マルチキャストフィルタリング、仮想LAN拡張機能を備えた橋の管理オブジェクトの定義[RFC4363]、および
o "Definitions of Managed Objects for Source Routing Bridges" [RFC1525].
o 「ソースルーティングブリッジ用の管理されたオブジェクトの定義」[RFC1525]。
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.
このドキュメントは、IEEE 802.1 WGへのブリッジMIB WG MIBモジュールの移行に関するIETFとIEEEの間にいくつかの明確な期待を確立することを目的としているため、IESG、IAB、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 WGSが、後で行うために「SNMPの専門家」にそれを残すのではなく、対応するMIBモジュールを開発するためにも必要であることを義務付けています。動機の一部は、明らかにプロトコルをより管理しやすくすることでしたが、動機の一部はワークロードのバランスをより良くし、コンテンツの専門家を管理設計にもっと関与させることでした。そのような作業が他の標準開発組織（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で行われているかどうかにかかわらず、リソースを作業の完了に専念する必要があります。IETFは、他の組織（IEEE 802など）がMIBを文書化している場合、IETFはSNMP/MIB/Management Informationの構造（SMI）の視点からそれらをレビューするのを支援することを申し出ることを認めています。これは、高品質の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 equivalent of IETF Working Group Charters and include information concerning the scope, purpose, and justification for standardization projects.
IEEE-SA Standards Board New Standards Committee（NESCOM）は、プロジェクトの承認要求を扱います。http://standards.ieee.org/board/nes/を参照してください。PARは、ほぼ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.
IETFブリッジMIB WGからIEEE 802.1 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.
2004年12月に承認されたP802.1AH（プロバイダーバックボーンブリッジ）から始まる802.1プロジェクトの最新のプロジェクト承認要求（PAR）には、この点に関する明示的なテキストが含まれています。
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形式であるプロバイダーBackbone Bridges [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開発作業を新しいPARで明示的に指定して作業を行うことは必須ではありませんが（IEEE 802.1AB [IEEE802.1AB]およびIEEE 802.1AE [IEEE802.1AE]）IEEE 802.1 WG PARには、標準の一部としてMIB開発が必要な場合は、スコープセクションに明示的な言葉遣いが含まれています。
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モジュールをインターネットとして公開しないことを推奨する必要があります。 - ドラフト。
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コミュニティにIETFブリッジMIB WGからIEEE 802.1 WGへの802.1 MIB開発の転送を受け入れる重要な要素です。802.1は、ASCIIバージョンを公開せずにドキュメントに使用するPDF形式でのみMIBモジュールを公開することを確実に決定できますが、ほとんどのネットワーク管理システムはASCII形式のMIBモジュールをインポートできますが、PDF形式ではありません。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は、ドキュメントのMIBモジュールの部分をプロジェクト開発中に個別のASCIIファイルとして使用できるようにし、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 Webサイトで自由に利用可能になります（http://www.ieee802.org/1/files/public/mibs/またはhttp：//www.ieee8022を参照してください。.org/1/pages/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モジュールの適切な実装と展開を確保するために利用できるようにする必要があります。ほとんどの実装者にとって、承認後6か月後に自由に利用可能な仕様が適切です。
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）ツリーに個別の登録ブランチ（ARC）があります。Bridge MIBモジュールはIETFブランチの下に登録されており、一部の割り当てはIANAによって維持されます。IEEE 802 ARCの投与は[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モジュールに1つまたは2つのオブジェクトを追加する必要がある場合、802.1 WGがIANA制御登録ツリー内の追加の管理オブジェクトを定義する方が簡単に思える場合があります。このアプローチは、2つの組織間の変化を調整するのが難しいため、プロセスを通じて変更を行いながら、各組織のタイムリーを維持しようとするため、推奨されません。このような追加には、IETF MIB Doctor Reviewの後、エリアオペレーションと管理の地域ディレクターによる承認がおそらく必要になるでしょう。これにより、2つの組織の作業間に依存関係が作成され、IEAEがIETFプロセスによって迷い込まれるのを防ぐために、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.
Bridge MIB WGドキュメントをIEEE 802.1 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]ルールに分類されます。RFC3978 [RFC3978]に記載されているように、最近の3つの更新[RFC4188]、[RFC4318]、[RFC4318]、および[RFC4363]はBCP 78に該当します。
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.
彼らが派生物のメンテナンスを実行できるようにするために、ブリッジ-MIB [RFC4188]、P-Bridge-Mib、Q-Bridge-Mib [RFC4363]、およびRSTP-MIB [RFC4318]を含むドキュメントから機能します。著者や著者がこれらの文書に知的財産権を割り当てた企業から許可を得る必要があります。
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.
IETF法務委員会およびIEEE標準協会標準協会の知的財産マネージャーは、IEEE 802.1 WGが使用するためのサンプルレターに同意し、付録Bに示す著者から必要な許可を要求します。チェアは、文書の著者リストをレビューし、著者のリストとその最後の既知の住所、およびそれらがIEEE標準協会の標準的な知的財産のマネージャーに関連付けられていた文書を提供しました。
The IETF will retain all the rights granted at the time of publication in the published RFCs.
IETFは、公開されたRFCSで公開時に付与されたすべての権利を保持します。
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.
Bridge MIB WGドキュメントの更新は、802.1T、802.1U、802.1V、および802.1Wで文書化された変更に対処しました。これらの修正は、IEEE 802.1 WGによって802.1-1-1998と合併して802.1D-2004を形成しました。ブリッジ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を含む新しい新興仕様と一致しているかどうかを判断する必要があります。Bridge 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).
o 「AutoEdgeport」パラメーター（802.1D-2004条項17.3.3）。
o The BridgeID object.
o BridgeIDオブジェクト。
o References to 802.1D-1998 were not updated to 802.1D-2004.
o 802.1-1-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 DOT1DPORTOUTBOUNDACSPRIORITYの説明は間違っているように見えますが、それは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標準の最近の変更は、MIBテーブルのインデックス作成方法を変更する方法を要求すると予想されます。これはSMIルールで許可されていないため、IEEEはMIBモジュールを書き換え、IEEE802ブランチの下にオブジェクト識別子を割り当てる必要があります。
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ドキュメントがBridge MIBドキュメントのIETFバージョンを更新または廃止する必要がある場合、802.1 WGはIESGにインターネットドラフトを作成して提出して、公然と利用可能なIEEEコピーとIEEE標準を指すRFCとして公開することができます。IESGは、RFCの公開を承認する必要があります。RFCステータスはRFC-Indexおよびデータベースにも反映されるため、RFC-EditorのWebページに反映されます。したがって、公開されているコピー間の同期に問題はありません。
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モジュールオブジェクトはおそらく対応するでしょう。
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
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ルールは一般に、現在のオブジェクトを廃止せずに、定義されたMIBオブジェクトのセマンティクスを変更し、オブジェクトに新しい記述子とOID登録に置き換えることを防ぎます。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.
IETFブリッジMIBモジュールで説明を修正する必要性は、SMI合法ではない方法で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 WGは、802.1管理変数セマンティクスが変更された場合、IEEEマネージド変数から新しいIEEE MIBオブジェクトへのマッピングを再定義することができます。したがって、802.1 WGがSMIルールで「Do Right」を許可し、古いMIBオブジェクトに新しいものを補完することができます。。更新されたマッピングは、補足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.
多くの場合、MIBオブジェクトへの802変数のマッピングは1：1のマッピングではなく、そうする必要はありません。将来的には、Webベースのサービスを念頭に置いて802.1変数を発明することができますが、今日では主な焦点は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オブジェクトや古いコンプライアンス条項を廃止する必要なく、新しい「最先端」を定義します。したがって、計画では、現在のBridge MIBモジュールは「時間とともに凍結」され、802.1 WGによって独立したMIBモジュールの開発によってのみ更新されるということです。
The Bridge MIB WG has completed its documents, and the WG has been closed.
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:
メーリングリストはしばらく開いたままになります。メーリングリストの管理者は、Bridge 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.
この作業は、Bridge MIB WGメーリングリストの範囲外です。IEEE 802.1 MIBモジュールディスカッションの適切なメーリングリストは、STDS-802-1-l@listerv.ieee.orgです。STDS-802-1-Lリストを購読するには、http：//www.ieee802.org/1/email-pages/にアクセスして、作業方法や参加方法など、802,1に関する一般情報を確認してください。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 Doctors Review 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.
期待されるのは、IETFが、MIBの医師が利用可能で、そのようなレビューを喜んで行うときに、IEEE 802- MIBモジュールを開発できる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エリアディレクターが他のエリアディレクターに「プッシュ」され、MIBモジュールドキュメントがMIBモジュールドキュメントをLast Call、IETF Last Callに来始めたときにレビューし、IESGに表示されたときよりも確かに終わりではありません。議題。この需要には、ドキュメントをレビューするリクエストを受け入れるかどうかを決定する際に、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モジュールドキュメントがレビューのために登場すると、そのような要求を受け入れるかどうか、そして彼らの仕事を優先順位付けする方法を選択することになります。
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.
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は、IETF MIB医師にレビューをリクエストする前に、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.
IETFは、MIBドキュメント[RFC4181]の著者およびレビュアーのガイドラインを開発しました。これにより、著者や他のWGメンバーは、MIB Doctorのレビューを要求する前に、ガイドラインに対してドキュメントを確認できます。802.1 WGエディターは、MIB Doctorレビューを要求する前に、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医師のコンセンサスに基づいているのか、それともペットのピーブに基づいているかを編集者が知るのに役立ちます。
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:
IETFは、MIBモジュールを含む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 IETFドキュメントのようにセクション3.1から3.4が適用されます。IETFボイラープレートを編集して、IEEEニーズとスタイルガイドに準拠できることに言及しています。
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
o IETFドキュメントのように、セクション4.4〜4.8が適用されます
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.
RFCエディターのガイドラインとMIBレビューガイドラインに従って、必要なすべてのセクションを含むIETF 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 Bridge 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]、およびSTD 58、RFC 2580 [RFC2580]に記載されているSMIV2に準拠した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:
名前：コメントタイプ：[e =編集、er =編集要求] [t =技術、tr =技術要求]節：ページ：行：コメント開始：コメント終了：推奨変更開始：推奨される変更は終了します：
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 Doctorレビューは通常、単純なテキストメールで行われ、多くの場合、レビューコメントの長いリストが含まれています。MIB Doctorのレビューは、特定のテキストの問題ではなく、一般的な設計上の問題を提起することがあり、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 Doctor Reviewは、標準を承認するプロセスの一部として発生します。標準として承認のために文書が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 Doctor Review」ではなく、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プライベートWebサイトから入手できます。IETF参加者は、802.1 WGチェアでWebサイトにパスワードを与えることができ、以前および現在のコメントや処分を見ることができます。
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ドクターレビューを受け取ったという印象を与えるべきではありません。「このドキュメントがMIB Doctor Reviewに合格した」というフレーズは、IETFにかなりの重みがあるため、何が言われているかを明確にする必要があります。「IETF MIB Doctor」または「IEEE 802 MIB Doctor」、または一般的な「MIB Doctor」によって行われたレビューを説明するかどうかを明確にする必要があります。
MIB Doctor reviews be copied to the document editor, and to the 802.1 chair.
MIB Doctorレビューは、ドキュメントエディター、および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のBridge MIB WGで議論され、Proceedingsで利用可能なプレゼンテーション「Bridge MIB Transition to IEEE 802.ppt」を含めました。
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/public/docs2004/ new-bridge-mib-transition-104.ppt、http：//www.ieee802.org/1/files/ public/public/public/docs2005/liaison-ietf-congdon-0705.pdf、およびhttp://www.ieee802.org/1/files/public/docs2005/ liaison-ietf-congdon-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.
このドキュメントでは、IETFブリッジMIB WGからIEEE 802.1 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日に、知的財産の問題について議論するために、ホルヘ・コントレラス、スコット・ブラッドナー、バーナード・アボバ、バート・ウィジネン、デビッド・ハリントンを含む通信が開催されました。以下は結論の要約です。
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をISとして再現し、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をAS-ISに再現したい場合、彼または彼女は特定の許可なしにそうすることができますが、それは「AS-IS」（およびそれは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の著者は、他のグループがRFCの独自のバージョンを作成できることを別のグループ（IEEEなど）に伝えることができます。これは、IETFが著者から得る権利を得ることができないためです。それで。
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.
著者が別のグループにデリバティブ作品を作成する許可を与えた場合、これは著者と他のグループの間にあるため、これは（法的に）IETFに関係するものはありません。そのため、新しいドキュメントはIETFドキュメントではないため、ISOC著作権が表示される理由はありません。他のグループがドキュメントがRFC XXXXに基づいていると言うメモを含め、著者は望むならそれを主張できるが、IETFは許可を付与する上で正式な役割を持っていないので、IETFRFCへのポインターを要求することはできません。
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日に、IEEE Standards Association Managerの知的財産マネージャーであるClaudio M. Stanziolaの法的問題を検討するために、別の通信が開催されました。その議論の結果、IETFの問題に関するIETF法律顧問は、他のSDOが「質問をする方法」に関する独自のドキュメントを作成するためのガイドラインとして使用できるサンプル文書を作成しました。テンプレートは、このドキュメントに付録Bに含まれています。
Dan Romascanu Avaya Atidim Technology Park, Bldg. #3 POB 58173 Tel Aviv, 61581 Israel Phone +972 3-645-8414 EMail: dromasca@avaya.com
Dan Romascanu Avaya Atidim Technology Park、Bldg。＃3 POB 58173 Tel Aviv、61581イスラエル電話972 3-645-8414メール：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
トニージェフリーチェア、802.1 WG 11AポプラグローブセールチェシャーM33 3AX英国電話：44 161 973 4278メール：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
Paul Congdon副議長、802.1 WG Hewlett Packard Company HP Procurve Networking 8000 Foothills Blvd、M/S 5662 Roseville、CA 95747米国電話：1 916 785 5753メール：paul.congdon@hp.com
Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten NL Phone: +31-348-407-775 EMail: bwijnen@lucent.com
Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten NL電話：31-348-407-775メール：bwijnen@lucent.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 US Phone: +1 425 818 4011 EMail: bernarda@microsoft.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond、WA 98052 US電話：1 425 818 4011メール：bernarda@microsoft.com
> "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ワーキンググループは、IETF RFC XXXX（特にYYY MIBモジュール）の一部をIEEEドラフト標準P802.1の一部として組み込み、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に含めるために、RFC XXXXの貢献をIEEEに提出してください。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.
HERETOを添付してください。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] Decker、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] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
[RFC3978] Bradner、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. Bell、「ブリッジの管理オブジェクトの定義」、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] Levi、D。およびD. Harrington、「迅速なスパニングツリープロトコルを備えた橋の管理されたオブジェクトの定義」、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] Levi、D。およびD. Harrington、「トラフィッククラス、マルチキャストフィルタリング、仮想LAN拡張機能を備えた橋の管理されたオブジェクトの定義」、RFC 4363、2006年1月。
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 STD 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/ private/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 Standard 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/ projects/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.、Perkins、D。、およびJ. Schoenwaelder、「管理情報の構造バージョン2（SMIV2）」、STD 58、RFC 2578、1999年4月。
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、Perkins、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.、Perkins、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] Case、J.、Mundy、R.、Partain、D。、およびB. Stewart、「インターネット標準管理フレームワークの紹介と適用声明」、RFC 3410、2002年12月。
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005.
[RFC4181] Heard、C。、「MIB文書の著者およびレビュアーのガイドライン」、BCP 111、RFC 4181、2005年9月。
Author's Address
著者の連絡先
David Harrington (editor) Effective Software Consulting Harding Rd Portsmouth NH USA
David Harrington（編集者）効果的なソフトウェアコンサルティングハーディングRDポーツマスNH USA
Phone: +1 603 436 8634
EMail: dbharrington@comcast.net
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）によって提供されます。