RFC4663 日本語訳
4663 Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG.D. Harrington. September 2006. (Format: TXT=47973 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Harrington, Ed. Request for Comments: 4663 Effective Software Consulting Category: Informational September 2006
ワーキンググループD.ハリントン、エドをネットワークでつないでください。コメントのために以下を要求してください。 4663年の有効なソフトウェアコンサルティングカテゴリ: 情報の2006年9月
Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG
MIBがIETF橋のMIB WGからIEEE802.1WGまで扱う移すこと
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
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作業部会からIEEE802.1作業部会まで橋を架ける関連のMIBモジュールへの変遷責任にプランについて説明して、どれがMIBモジュールが設計されている橋を架ける技術を開発するかは管理されます。
Harrington Informational [Page 1] RFC 4663 802.1 MIB Transition September 2006
[1ページ]RFC4663 802.1MIB変遷2006年9月の情報のハリントン
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
1. 序論…2 1.1. 動機…3 2. 新しいIEEE MIBは働いています…3 2.1. 新しいMIBパー…3 2.2. ASCII形式におけるIEEE MIBモジュール…4 2.3. 新しいMIBモジュールのためのOID登録…5 3. 現在の橋のMIB WGドキュメント…6 3.1. 電流を移して、MIB WGドキュメントに橋を架けてください…6 3.2. IETF MIBモジュールをアップデートします…6 3.3. 変数マッピングと承諾に明確化…8 4. メーリングリスト議論…9 5. IETF MIBはレビューを治療します…9 5.1. 序論…9 5.2. ガイドラインを再検討してください…10 5.3. 書式を見直してください…13 5.4. 重さを見直してください…14 6. 変遷を伝えて、計画してください…15 7. セキュリティ問題…15 8. IANA問題…15 9. 知的所有権問題…16 付録A.貢献者…18 IEEEが要求する付録B.サンプルテキストは作者よりまっすぐになります。19 標準の参照…20 有益な参照…20
1. Introduction
1. 序論
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 Bridge MIB WGからIEEE802.1WGまで橋を架ける関連のMIBモジュールへの変遷責任にプランについて説明して、どれがMIBモジュールが設計されている橋を架ける技術を開発するかは管理されます。 現在のBridge 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]
Harrington Informational [Page 2] RFC 4663 802.1 MIB Transition September 2006
[2ページ]RFC4663 802.1MIB変遷2006年9月の情報のハリントン
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.
このドキュメントはIEEE802.1WGへのBridge MIB WG MIBモジュールの変遷に関してIETFとIEEEの間のいくつかの明確な期待を確立することになっています、IESG、IAB、IETF、およびIEEEがプランを見直すことができるように。 いくつかのその場その場の状況(適切な連絡で扱われる)が起こるかもしれませんが、このドキュメントは一般的な戦略を説明します。
1.1. Motivation
1.1. 動機
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.
802.1共同体に、技術のための管理の機能性を提供するSNMP MIBモジュールを持っているのが重要であるので、それは、それぞれの新しいプロジェクトのためにProject Authorization Requests(PARs)の一部としてこの仕事をチャーターして、資本が実行のために動員されていたのを保証する必要があります。 また、これも既に完成した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は、また、「SNMP専門家」へのそれが後でするのを残すよりプロトコルを作成するIETF WGsがむしろ対応するMIBモジュールを開発しなければならないのを強制しました。 明らかにプロトコルをより処理しやすくしますが、動機の一部がことであった動機の一部で、また、より一層ワークロードのバランスをとって、満足している専門家は管理デザインにさらにかかわります。 そのような仕事が他の規格開発組織(SDOs)から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.
確かに、労働力問題は関連局面です。 内容の専門家が仕事に参加し(導く)にIETFに来る場合にだけ、IEEE802MIBドキュメントはIETFで開発されるかもしれません。 満足している専門家は、MIBモジュール開発にさらにかかわる必要があります、そして、リソースは仕事を終了するのに捧げられる必要があります、IEEEかIETFで編集するか否かに関係なく。 他の組織(IEEE802のような)がMIBに記録自体なら、IETFは、それが許容できるのがわかります、そして、助けるというIETF申し出はManagement情報(SMI)見解のSNMP/MIB/構造からそれらを見直します。 これは変遷の後にさえ本当です、インターネットの円滑な管理とそれが動く技術に、上質のMIBモジュールが重要であるので。
2. New IEEE MIB Work
2. 新しいIEEE MIB仕事
2.1. New MIB PARs
2.1. 新しい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 Standards Board New Standards Committee(NesCom)はProjects Approval Requestsに対処します。 http://standards.ieee.org/board/nes/ を見てください。PARsはおよそそうです。
Harrington Informational [Page 3] RFC 4663 802.1 MIB Transition September 2006
[3ページ]RFC4663 802.1MIB変遷2006年9月の情報のハリントン
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.
MIB仕事のIETF Bridge MIB WGからIEEE802.1WGまでの転送に関して早めの議論に続いて、IEEE802.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(プロバイダーBackboneブリッジス)から始まって、802.1のプロジェクトの最新のProject Approval Requests(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フォーム(Provider Backboneブリッジス[PAR-IEEE802.1ah])は、'SNMPを含む経営者側を支持する'ために13、「提案されたプロジェクトの範囲」というセクションに明白な指示するものを含んでいます。
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.1WG PARsがどこでも、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 Bridge MIB WGが将来MIBモジュールを開発しないつもりであるので、橋の管理スペースでの新しい仕事のsubmittersはIEEE802.1WGに向けられるべきです、そして、インターネット草稿として自己の提案されたMIBモジュールを発行しないのは、お勧めであるべきです。
2.2. IEEE MIB Modules in ASCII Format
2.2. ASCII形式におけるIEEE 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.
SNMP共同体に802.1MIB開発のIETF Bridge MIB WGからIEEE802.1WGまでの転送を受け入れさせることにおいてMIBモジュールを自由でオープンにASCII書式で利用可能にするのは、重要な要素でしょう。 802.1は、それらがドキュメントに使用するPDF形式だけでMIBモジュールを発行すると確かに決めることができますが、ASCII版を発行しないで、ほとんどのネットワーク管理システムがPDF形式における1ではなく、ASCII書式にはあるMIBモジュールを輸入できます。 MIBモジュールのASCII版を発行しないのに、否定的にMIBモジュールのimplementersとデプロイヤに影響を与えて、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.1WGウェブサイトは開発中である規格へのアクセスのためのパスワードを必要とします。 WGは、別々のASCIIがプロジェクト開発の間、ファイルされるのでそれらのドキュメントのMIBモジュール部分を利用可能にして、IETF関係者がプレ標準のレビュー目的のためのこれらのドキュメントにアクセスするのを許容し始めました。
Harrington Informational [Page 4] RFC 4663 802.1 MIB Transition September 2006
[4ページ]RFC4663 802.1MIB変遷2006年9月の情報のハリントン
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).
IEEE802には、それらが承認されていた6カ月承認の、後と自由に空いている6カ月後に1日に、承認された仕様が利用可能である方針が有料であります。 仕様がいったん承認するようになると、自由にMIBモジュールのASCII版を802.1WGウェブサイトで利用可能にします( http://www.ieee802.org/1/files/public/MIBs/ か http://www.ieee802.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カ月後の自由に利用可能な仕様はほとんどのimplementersに関しては、適切になるでしょう。
2.3. OID Registration for New MIB Modules
2.3. 新しいMIBモジュールのためのOID登録
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とIEEE802には、別々の登録ブランチ(アーク)がObject Identifier(OID)木にあります。 Bridge MIBモジュールはIETF支店の下に登録されます、そして、いくつかの課題がIANAによって維持されます。 IEEE802アークの管理は[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.
IEEE802.1WGが802.1の規格、変化がアップデートするIEEEをアップデートするように必要な変更を含めて、既存のテーブルを補ってください。 既存のテーブルを増大させるか、または既存のテーブルのインデックスを再利用する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.1WGがIANAによって制御された登録木の中で追加管理オブジェクトを定義するように、より簡単に思えるかもしれません。 このアプローチは2つの組織の間の変化を調整して、各組織にタイムリーなままで残っていようとしている間、過程による変化を扱うという困難で推薦されません。 そのような追加はIETF MIB医師レビューの後にたぶんOperationsとManagementのAreaディレクターによる承認を必要とするでしょう。 これは2つの組織の仕事の間の依存を引き起こすでしょう、そして、IANAが、IEEEがIETF工程で泥沼に落ち込まれるのを防ぐように、それは特別なケースを発生させるかもしれません。
The approach of developing an IEEE MIB module and defining a new compliance clause is simpler than dealing with such dependencies.
IEEE MIBモジュールを開発して、新しい承諾節を定義するアプローチはそのような依存に対処するより簡単です。
Harrington Informational [Page 5] RFC 4663 802.1 MIB Transition September 2006
[5ページ]RFC4663 802.1MIB変遷2006年9月の情報のハリントン
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.
私たちは既存の実現の分裂と変更を行うことにおける効率の間のバランスを必要とします。 既存の木を付けあがらせると、既存の実現の分裂は最小にされます。
3. Current Bridge MIB WG Documents
3. 現在の橋のMIB WGドキュメント
3.1. Transferring Current Bridge MIB WG Documents
3.1. 現在の橋のMIB WGドキュメントを移します。
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.
IEEE802.1WGにBridge 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はRFC2026[RFC2026]規則の下で落ちます。 3つの最近のアップデート[RFC4188]、[RFC4318]、および[RFC4363]が、RFC3978[RFC3978]に記録されるようにBCP78の下に下がります。
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](WGが作者がこれらのドキュメントの彼らの知的所有権を配属した作者、そして/または、会社から許可を得る必要があるIEEE802.1)を含むドキュメントから働いています。
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.
IPRの件のためのIETF弁護士とStandards Intellectual PropertyのIEEE規格協会のマネージャはIEEE802.1WGによる使用が作者から必要な許容を要求するサンプル手紙に同意しました。(それは、Appendix Bで見せられます); Bridge MIB WGいすは、ドキュメントのための作者リストを再検討して、作者のリストと彼らの最後に知られているアドレスとそれらがStandards Intellectual PropertyのIEEE規格協会のマネージャに関連づけられたドキュメントを提供しました。
The IETF will retain all the rights granted at the time of publication in the published RFCs.
IETFは発行されたRFCsでの公表時点で与えられたすべての権利を保有するでしょう。
3.2. Updating IETF MIB Modules
3.2. IETF MIBモジュールをアップデートします。
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.1のt、802.1u、802.1v、および802.1wに記録された変化を記述しました。 これらの修正は、802.1D-2004を形成するためにIEEE802.1WGによって802.1D-1998に合併されました。 Bridge MIB WGはドキュメントのその合併から生じた変化を記述しませんでした。
Harrington Informational [Page 6] RFC 4663 802.1 MIB Transition September 2006
[6ページ]RFC4663 802.1MIB変遷2006年9月の情報のハリントン
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.1WGは、それらが新しい現れている仕様と一致しているかどうか決定するために既存のドキュメントで管理物を終える必要があるでしょう、802.1D-2004を含んでいて。 Bridge MIB WGのこれらのドキュメントへの最終的な作業の間、私たちがそれらが今後の活動の一部として802.1WGで対応する決議でないのに決めたいくつかの問題がありました。
Work on the following items was deferred to the IEEE:
以下の項目への作業はIEEEに延期されました:
o The 'autoEdgePort' parameter (802.1D-2004 clause 17.3.3).
o 'autoEdgePort'パラメタ(17.3番目の802.1D-2004節.3)。
o The BridgeID object.
o BridgeIDは反対します。
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に関して提起されました。 これはRFC1493から残された問題です。
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テーブルがINDEXEDである方法が変えられるのを必要とすると予想されて、どれが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.1WGドキュメントがBridge MIBドキュメントのIETFバージョンをアップデートしなければならないか、または時代遅れにしなければならないなら、802.1WGは、オープンに利用可能なIEEEコピーとIEEE規格を示すRFCとして発行されるためにインターネット草稿をIESGに作成して、提出できます。 IESGは、RFCの公表を承認する必要があるでしょう。 RFC状態はRFC-INDEXとデータベースにも反映されるでしょう、したがって、それはRFC-エディタウェブページで反映されるでしょう。 したがって、私たちには、コピーの間の発行される同期に関する問題がありません。
Harrington Informational [Page 7] RFC 4663 802.1 MIB Transition September 2006
[7ページ]RFC4663 802.1MIB変遷2006年9月の情報のハリントン
3.3. Clarifications on Variables Mapping and Compliance
3.3. 変数マッピングと承諾に明確化
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.1WGがMIB開発を扱うので、IEEE-規格は「変数を管理しました」、そして、関連IEEE MIBモジュール物はたぶん対応するでしょう、多くの既存のBRIDGE-MIB物が既に802.1の管理変数に対応するとき、802.1Qからのこれらなどのように。
Virtual Bridge MIB object IEEE 802.1Q-2003 Reference
仮想のBridge MIB物のIEEE 802.1Q-2003 Reference
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
.1が読むdot1qBase dot1qVlanVersionNumber12.10.1はコンフィグdot1qNumVlans dot1qGvrpStatus12.9.2.1/2が読むか、または設定する橋のvlanにgarp応募者コントロールを読み込みます橋のvlanコンフィグdot1qMaxVlanId12.10.1.1が、橋のvlanコンフィグdot1qMaxSupportedVlans12.10.1.1を読む。
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.
SMI法的でない方法でIETF Bridge MIBモジュールで記述を修理する必要性はIEEE MIBモジュールを定義するか、またはただ必要な物を加える必要性を沈殿させるでしょう。モジュールは、全体のIETF MIBモジュールをコピーして、置き換えるかもしれません。 IETF MIBモジュールをコピーして、記述子を変えて、新しいIEEE OIDsを再選任するのによる遅れているコンパチブル、そして、既存のアプリケーションが、新しい物にアクセスするためにアップデートする必要があるだろうということでないでしょう。 したがって、そうするのは本当に必要でない場合、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.1WGの現在の習慣は、関連MIBモジュール物と管理変数を定義して、次に、マッピングテーブルを定義することになっています(上に示されるように)。 管理の可変意味論が802.1に変化するなら、802.1WGは可変な状態で管理されたIEEEから新しいIEEE MIB物までマッピングを再定義できるでしょうに、その結果、802.1WGがSMI規則で'まさしくそれをすること'を許容します、新しいもので古いMIB物を補って。 アップデートされたマッピングは補足のSMIv2 MIBモジュールの承諾節に反映されるでしょう。 SMIv2 MIBモジュールで新しい物の記述節の古いマッピング情報を記録するのは望ましいかもしれません。
Harrington Informational [Page 8] RFC 4663 802.1 MIB Transition September 2006
[8ページ]RFC4663 802.1MIB変遷2006年9月の情報のハリントン
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マッピングでなく、マッピングである必要はありません。いてください。 今日、焦点がSNMP用法にあります、そして、将来、802.1の変数が念頭でウェブベースのサービスで発明されるかもしれませんが、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.
既存のBridgeドキュメントは橋を架ける管理の現状を表します、そして、ドキュメントはIETF規格に言いなりになるという現在の要件について説明する承諾節を含んでいます。 新しい承諾節はIEEEが添加MIBモジュールを開発すると新しい「到達技術水準」を定義するでしょう、古いMIB物か古い承諾節を時代遅れにする必要はなくて。 したがって、プランは現在のBridge MIBモジュールが「時間内に、凍っ」て、単に802.1のものの独立しているMIBモジュールの開発でWGをアップデートしたということです。
4. Mailing List Discussions
4. メーリングリスト議論
The Bridge MIB WG has completed its documents, and the WG has been closed.
Bridge 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:
メーリングリストはしばらく、開いたままで残るでしょう。 メーリングリスト管理者は、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メーリングリストのための範囲の外にこの仕事はあります。 IEEE802.1MIBモジュール議論のための適切なメーリングリストは STDS-802-1-L@listserv.ieee.org です。 STDS-802-1-Lに加入するために、記載してください、そして、802、1時頃に http://www.ieee802.org/1/email-pages/ Toにおいて一般情報を見に行ってください、どのように彼らがどのように働くか、そして、参加して、 http://www.ieee802.org/1/ Toにおいてプレゼンテーションを見に技術に行って、 http://www.ieee802.org/1/files/public/ に行って、docs2004、docs2005、およびdocs2006ディレクトリの中を見るかを含んでいて。
5. IETF MIB Doctor Reviews
5. IETF MIB医師レビュー
5.1. Introduction
5.1. 序論
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.
Bridge MIB WG、802.1WG、IETF O、およびM領域、およびIEEE802プロジェクトのリーダーは、IETF MIB医師にIEEE802の開発されたMIBモジュールを見直させるのを議論しました。 これはゆるい提供です。
Harrington Informational [Page 9] RFC 4663 802.1 MIB Transition September 2006
[9ページ]RFC4663 802.1MIB変遷2006年9月の情報のハリントン
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がIEEE802を見直すことができるMIB医師のグループを維持するということです--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では、MIB医師に彼らがWG Last Call、IETF Last Callに来始めて時確かに彼らがIESG議題に現れる時までにMIBモジュールドキュメントを再検討させるように、領域ディレクターが得るO&Mは他の領域ディレクターに「押されました」。 ドキュメントを再検討するために申し込みに応じるかどうか決めるとき、この要求は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.
802.1いすが早く開発中であるのにレビューを要求すると、MIBモジュールデザインが確立された後にもかかわらず、エディタが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.1WGがMIBモジュールのレビューを提供して、IETF MIB医師からレビューを要求する前にほとんどの問題を解決するためにそれ自身のMIB医師レビューチームを設立するのは、お勧めです。 これは、802.1WGがIETF MIB医師で依存によって引き起こされた遅れを避けるのを助けるでしょう、そして、あらかじめ見直されたドキュメントで、要求されたレビューを実行するのはIETF MIB医師が余暇があるのが、より簡単になるでしょう。 IETFは、802.1WGがそのようなIEEE MIB医師チームを設立して、訓練するのを助けるためにゆるい提供を作っても構わないと思っています。
5.2. Review Guidelines
5.2. レビューガイドライン
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.
MIB医師レビューを要求する前に作者と他のWGメンバーがガイドラインに対して彼らのドキュメントをチェックできて、IETFはMIB Documents[RFC4181]のAuthorsとReviewersのためにGuidelinesを開発しました。 MIB医師レビューを要求する前に、802.1WGエディタはRFC4181ガイドラインを使用するべきです。
Harrington Informational [Page 10] RFC 4663 802.1 MIB Transition September 2006
[10ページ]RFC4663 802.1MIB変遷2006年9月の情報のハリントン
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.
RFC4181で多くのSMI規制、規制を編集するIETF、および最も良い現在の実務について議論します。 しかしながら、良いMIBデザイン(例えば、運命共有をテーブルの上に置いてください、良いインデックス選択)の多くの局面について、科学より多くの芸術であり、ガイドラインで議論しません。 それらは役に立つかもしれません。IETF決まり文句の要件に関連するガイドライン以外のSDOs(そして、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とIEEEにIETFの決まり文句では、異なった意味を持っています、そして、異なった編集スタイルガイドラインは異なったボディーによって使用されています。 IETFの決まり文句、目的または用語で一貫した802MIBの決まり文句を開発するのは良いでしょう。
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]を使用します。 そんなに時間内に、IEEE802.1WGがIEEE MIBモジュールレビューのためのそれ自身のガイドラインを開発することが勧められます。 これが起こるまで、RFC4181のセクション3(Documentation Guidelines司令官)とセクション4(SMIv2 Guidelines)を使用できます、以下の例外と変更で:
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ドキュメントのように適用してください、そして、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 Considerations)を適用しませんが、命名のIEEE推薦とOID宇宙課題でセクションに取り替えるかもしれません。
o Sections 3.6 does not apply.
o セクション3.6 適用しません。
Harrington Informational [Page 11] RFC 4663 802.1 MIB Transition September 2006
[11ページ]RFC4663 802.1MIB変遷2006年9月の情報のハリントン
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(Copyright Notices)は適用しないで、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(知的なProperty)は適用しないで、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 (Hierarchyを命名します)が変化で適用するセクション4.3はIEEE802.1のOID根にMIBモジュールを関係づけました。
o Sections 4.4 to 4.8 apply as in the IETF document
o セクション4.4〜4.8 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.
RFC EditorガイドラインとMIBレビューガイドラインに従って、すべての必要なセクションを含むIETF MIB文書テンプレートは、エディタが、MIBモジュールドキュメントを開発するのを開始させるのを助けるために開発中です。 テンプレートは、MIB医師が上から日付へのMIBモジュール最も多くの決まり文句を提供することによって、より効率的に新しいMIBモジュールをチェックするのを助けるでしょう、都合のよいオーダーにおけるセクション、ある一定のセクションに含んでいるべきことのための提案、および決まり文句のテキストを支持するのに必要である参照で。 IEEE802.1WGが匹敵するテンプレートを設立するのは、お勧めです、適切であるところでガイドラインとRFC4181ガイドラインを編集するIEEEに続いて。
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.1WGが802.1Bridge MIBメンテナンスのためにPARを作成すると、そのようなテンプレートの創造はPARに含まれるかもしれません。
Harrington Informational [Page 12] RFC 4663 802.1 MIB Transition September 2006
[12ページ]RFC4663 802.1MIB変遷2006年9月の情報のハリントン
The IETF MIB documents include the following text relative to the Internet Management Framework as part of the standard boilerplate:
IETF MIBドキュメントは標準の決まり文句の一部としてのインターネットManagement Frameworkに比例して以下のテキストを含んでいます:
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to Section 7
of RFC 3410 [RFC3410].
現在のインターネット標準のManagement Frameworkについて説明するドキュメントの詳細な概観について、RFC3410[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].
Management Information基地、またはMIBが、管理オブジェクトが仮想情報店を通してアクセスされると呼びました。 一般に、MIB物はSimple Network Managementプロトコル(SNMP)を通してアクセスされます。 MIBの物は、Management情報(SMI)のStructureで定義されたメカニズムを使用することで定義されます。 このメモはSTD58、RFC2578[RFC2578]、STD58、RFC2579[RFC2579]、およびSTD58RFC2580[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ドキュメントのMIB部の同様の小区分、およびそれらの参照部の適切な指示するものを含むことがIEEE802.1に勧められます。
If IEEE 802.1 WG wants to craft its own guidelines, based on RFC4181, it will need to get the author's permission.
IEEE802.1WGがそれ自身のガイドラインが工芸品に欲しいなら、RFC4181に基づいて、それは、作者の許可を得る必要があるでしょう。
5.3. Review Format
5.3. レビュー形式
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.1WGはコメントにテンプレートを使用します、評論家の上に新しいテキストを提供する重荷がエディタの上にあるのではなく、あって以下の形式で。
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が社説と等しい、えー、必要である=社説] [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医師レビューは、簡単なテキストメールで通常して、しばしばレビューコメントに関する長い一覧表を含んでいます。 MIB医師レビューは時々特定のテキストの問題よりむしろ一般的なデザイン問題を提起します、そして、いくつかのMIB医師コメントが「グローバルな」問題を示します、固執要件を指定しない多くの物などのように。
Harrington Informational [Page 13] RFC 4663 802.1 MIB Transition September 2006
[13ページ]RFC4663 802.1MIB変遷2006年9月の情報のハリントン
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.
802.1のMIBモジュールレビューをするとき、世界的な問題において、IETF 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.1WGのいすと副いすは、簡単なメールを受け入れても構わないと思っています、彼らが問題が何であるか、そして、どのようにそれを修理するかを理解できるくらいの情報を教える限り。 コメントは問題記述、提案された解決、1ページ、および行番号を含むべきです。 都合のよい形式でコメントを提出すれば、助かるでしょう、エディタが、まさに何が要求されているかを理解して、レビューのためのコメントを登録して、ミーティング環境におけるコメントを見直すのがこれで、より簡単になるので。 通常、過程に投票している職員の外でMIBコメントの大部分を扱うことができます。
5.4. Review Weight
5.4. レビューの重さ
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.1WGから別々です、そして、802.1WGの中でMIB医師がこの変遷計画通りにするレビューをします。 それで、正式な「MIB医師レビュー」にというよりむしろMIB医師のために仕事を健全度チェックに尋ねるIETF WGいすに、802.1WGでのMIB医師レビューは同様です。
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.1WGが起源にかかわらずどんなコメントも無視することが許可されていません。 重大なコメントは、いつも真剣に受け止められて、決して無視されません。
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
IEEEは、次にミーティングで批評される提案された交換テキストを含む特定の形式で公式にコメントを提出するのを通常必要とします、そして、決定は気質ドキュメントに記録されます。 これらのコメントと気質は利用可能です。
Harrington Informational [Page 14] RFC 4663 802.1 MIB Transition September 2006
[14ページ]RFC4663 802.1MIB変遷2006年9月の情報のハリントン
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.
802.1の個人的なウェブサイトから。 彼らが802.1WGいすによるウェブサイト前の、そして、現在のコメントと気質を見ることができるように、IETF関係者にパスワードを与えることができます。
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医師レビューに合格する」句がIETFにかなりの重さを持っているので。 私たちは、「IETF MIB医師」か「IEEE802MIB医師」、または一般的な「MIB医師」によって行われたとして行われたレビューについて説明するかどうかはっきりさせる必要があります。
MIB Doctor reviews be copied to the document editor, and to the 802.1 chair.
MIB医師は論評します。ドキュメントエディタと、そして、802.1いすにコピーされます。
6. Communicating the Transition Plan
6. 変遷プランを伝えます。
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で議論して、プレゼンテーション、「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.
また、変遷への意図はBridge MIB WG閉鎖の通知の間、Bridge MIB WGメーリングリストに掲示されました、2006年2月15日のWG Action発表を含んでいて。
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.1WGと変遷について議論しました。 プレゼンテーションは http://www.ieee802.org/1/files/public/docs2004/ の新しい橋のmib変遷1104.ppt、 http://www.ieee802.org/1/files/ 連絡公衆/docs2005/ietf-congdon-0705.pdf、および http://www.ieee802.org/1/files/public/docs2005/ 連絡-ietf-congdon-0905.pdfで利用可能です。
7. Security Considerations
7. セキュリティ問題
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 Bridge MIB WGからIEEE802.1WGまで変遷MIBモジュール責任にプランについて説明します。 それはセキュリティに影響を与えません。
8. IANA Considerations
8. IANA問題
Although this document discusses issues related to IANA assignment of OIDs, no IANA actions are required by this document.
このドキュメントはOIDsのIANA課題に関連する問題について議論しますが、IANA動作は全くこのドキュメントによって必要とされません。
Harrington Informational [Page 15] RFC 4663 802.1 MIB Transition September 2006
[15ページ]RFC4663 802.1MIB変遷2006年9月の情報のハリントン
9. Intellectual Property Considerations
9. 知的所有権問題
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日に、Intellectual Property Issuesについて議論するためにホルヘ・コントレラス、スコット・ブラドナー、バーナード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は、IETFがRFCsを発行して、第三者に他の言語にRFCsを翻訳させて、第三者にRFCsをそのままで再生させて、IETFの標準の過程の中で派生している作品を作成できるように、RFC作者から非排他的な著作権ライセンスを得ます。 作者は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も再生させたいなら、その人は少しも特定アクセス許可なしでそうすることができますが、それは、第三者がRFCsを再生させる権利がIETFが作者から得る権利の一部であるので、「そのままでなければならない」(それはISOC版権情報を含んでいます)。
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を処理するもの(法的である)がありません、作者と他のグループのすぐ間には、協定があるので。 それのために、ISOC著作権が現れる理由が全くありません、新しいドキュメントがIETFドキュメントでないので。 もう片方のグループがそれらのドキュメントが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の標準の過程の中で派生している作品を作成するために作者によって与えられた許可を保有しています。
Harrington Informational [Page 16] RFC 4663 802.1 MIB Transition September 2006
[16ページ]RFC4663 802.1MIB変遷2006年9月の情報のハリントン
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は、標準化団体がする別のことによって開発されたどんな派生している作品もそれを承認することを強く勧めます。先のIETFが仕事が引き出すRFC(s)に関して働いている仕事体格。 RFC4181に記録されたIETF Best Current Practicesへの対応することのMIBモジュールはどのようにを記録するREVISION節を含んでいます。以前のバージョンが発行された/。
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の法律問題を批評するために開催されました、Standards Intellectual PropertyのIEEE規格協会のマネージャ。 その議論の結果、それら自身のを生産するためのガイドラインが作者の許容に請求するために「どう質問するか」に関して記録するようにIPRの件のIETF法律顧問は他のSDOsが使用するかもしれないサンプルドキュメントを作りました。 テンプレートは本書ではAppendix Bに含まれています。
Harrington Informational [Page 17] RFC 4663 802.1 MIB Transition September 2006
[17ページ]RFC4663 802.1MIB変遷2006年9月の情報のハリントン
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 Atidim技術公園、ビルディング #3 POB58173テルアビブ、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
トニーJeffree議長、802.1WG 11Aポプラグローブ販売チェーシャー州M33 3AXイギリスの電話: +44 4278年の161 973メール: 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
Blvd、ProCurveネットワーク8000フットヒルズS5662ローズビル、M/カリフォルニア95747米国が電話をする802.1WGヒューレットパッカード会社馬力のポールコングドンVice議長: +1 5753年の916 785メール: paul.congdon@hp.com
Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten NL Phone: +31-348-407-775 EMail: bwijnen@lucent.com
バートWijnenルーセントテクノロジーズSchagen33 3461GLリンスホーテン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
ワシントン98052レッドモンド(米国)が電話をするバーナードAbobaマイクロソフト社1マイクロソフト道: +1 4011年の425 818メール: bernarda@microsoft.com
Harrington Informational [Page 18] RFC 4663 802.1 MIB Transition September 2006
[18ページ]RFC4663 802.1MIB変遷2006年9月の情報のハリントン
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標準化過程の一部のような部分をIEEE Draft Standard P802.1の一部としてIETF RFC XXXX(明確にYYY MIBモジュール)の一部を取り入れて、開発して、変更して、発展したがっています。
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.
RFC XXXXの開発の間、事実上、IETF規格への貢献の作者がそのような貢献に関して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.
この事に付いて、サインするよう親切にお願いする著作権許可手紙テンプレートを見つけて、戻ってください、IEEEへの前述の権利を与えて。
Sincerely yours, IEEE"
「敬具、IEEE」
Harrington Informational [Page 19] RFC 4663 802.1 MIB Transition September 2006
[19ページ]RFC4663 802.1MIB変遷2006年9月の情報のハリントン
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、「ソースルート設定橋への管理オブジェクトの定義」、RFC1525(1993年9月)。
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP
78, RFC 3978, March 2005.
[RFC3978] ブラドナー、S.、「貢献におけるIETF権利」、BCP78、RFC3978、2005年3月。
[RFC4188] Norseth, K. and E. Bell, "Definitions of Managed
Objects for Bridges", RFC 4188, September 2005.
[RFC4188] NorsethとK.とE.ベル、「橋への管理オブジェクトの定義」、RFC4188、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.ハリントン、「急速なスパニングツリープロトコルがある橋への管理オブジェクトの定義」RFC4318(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.ハリントン、「交通のクラス、マルチキャストフィルタリング、およびバーチャルLAN拡大との橋への管理オブジェクトの定義」RFC4363(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、LocalとメトロポリタンエリアネットワークのためのStandard--、駅とメディアAccess Control Connectivityディスカバリー、」、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、LocalとメトロポリタンエリアネットワークのためのDraft Standard--、メディアAccess Control(MAC)セキュリティ、」、 http://www.ieee802.org/1/files/ ae兵卒/草稿/d4/802-1ae-d4-0.pdf IEEE Draft(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-1IEEE PAR、2004年12月。
Harrington Informational [Page 20] RFC 4663 802.1 MIB Transition September 2006
[20ページ]RFC4663 802.1MIB変遷2006年9月の情報のハリントン
[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、「経営情報バージョン2(SMIv2)の構造」、STD58、RFC2578(1999年4月)。
[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"、STD58、RFC2579、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"、STD58、RFC2580、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.スチュワート、「インターネット標準の管理枠組みのための序論と適用性声明」、RFC3410(2002年12月)。
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers
of MIB Documents", BCP 111, RFC 4181, September
2005.
BCP111、C.、「MIBドキュメントの作者と評論家へのガイドライン」と[RFC4181]が聞いて、RFCが4181であり、9月は2005です。
Author's Address
作者のアドレス
David Harrington (editor) Effective Software Consulting Harding Rd Portsmouth NH USA
有効なデヴィッド・ハリントン(エディタ)のConsultingハーディングポーツマスニューハンプシャーSoftware第米国
Phone: +1 603 436 8634 EMail: dbharrington@comcast.net
以下に電話をしてください。 +1 8634年の603 436メール: dbharrington@comcast.net
Harrington Informational [Page 21] RFC 4663 802.1 MIB Transition September 2006
[21ページ]RFC4663 802.1MIB変遷2006年9月の情報のハリントン
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Harrington Informational [Page 22]
ハリントン情報です。[22ページ]
一覧
スポンサーリンク
