RFC 3197 - Applicability Statement for DNS MIB Extensions 日本語訳

URL : https://tools.ietf.org/html/rfc3197
タイトル : RFC 3197 - DNS MIB拡張のための適用性に関する声明
翻訳編集 : 自動生成

Network Working Group                                         R. Austein
Request for Comments: 3197                                 InterNetShare
Category: Informational                                    November 2001

             Applicability Statement for DNS MIB Extensions

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.

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2001）。全著作権所有。

Abstract

抽象

This document explains why, after more than six years as proposed standards, the DNS Server and Resolver MIB extensions were never deployed, and recommends retiring these MIB extensions by moving them to Historical status.

この文書では、提案された標準として6年以上後に、DNSサーバとリゾルバMIBの拡張が展開されなかった理由を、説明し、歴史的な状況に移動して、これらのMIB拡張を引退することをお勧めします。

1. History

1.歴史

The road to the DNS MIB extensions was paved with good intentions.

DNS MIB拡張への道は善意で舗装されました。

In retrospect, it's obvious that the working group never had much agreement on what belonged in the MIB extensions, just that we should have some. This happened during the height of the craze for MIB extensions in virtually every protocol that the IETF was working on at the time, so the question of why we were doing this in the first place never got a lot of scrutiny. Very late in the development cycle we discovered that much of the support for writing the MIB extensions in the first place had come from people who wanted to use SNMP SET operations to update DNS zones on the fly. Examination of the security model involved, however, led us to conclude that this was not a good way to do dynamic update and that a separate DNS Dynamic Update protocol would be necessary.

振り返ってみると、それは我々がいくつかを持っている必要があるだけであること、ワーキンググループはMIBの拡張に属しものに多くの合意がなかったことは明らかです。これは、IETFが一度に働いていたので、我々は最初の場所でこれをやっていた理由の質問は精査の多くをやったことがなかったことを事実上すべてのプロトコルにおけるMIBの拡張のための流行の高さの間に起こりました。非常に遅れ開発サイクルで、我々は最初の場所にMIB拡張を記述するためのサポートの多くは、その場でDNSゾーンを更新するために、SNMP SET操作を使用していた人々から来ていたことを発見しました。関連するセキュリティモデルの検討は、しかし、これは動的更新を行うための良い方法ではなかったことを、別のDNS動的更新プロトコルが必要であろうという結論に私たちを導きました。

The MIB extensions started out being fairly specific to one particular DNS implementation (BIND-4.8.3); as work progressed, the BIND-specific portions were rewritten to be as implementation-neutral as we knew how to make them, but somehow every revision of the MIB extensions managed to create new counters that just happened to closely match statistics kept by some version of BIND. As a result, the MIB extensions ended up being much too big, which raised a number of concerns with the network management directorate, but the WG resisted every attempt to remove any of these variables. In the end, large portions of the MIB extensions were moved into optional groups in an attempt to get the required subset down to a manageable size.

MIBの拡張機能は、ある特定のDNS実装（BIND-4.8.3）にかなり特異的で始まりました。作業が進むにつれて、我々はそれらを作る方法を知っていたが、何とかMIB拡張のすべてのリビジョンがちょうど密接にいくつかのバージョンが保持して統計を一致させるために起こった新しいカウンタを作成するために管理して、BIND特異的部分は、実装中立のように書き直されました練る。その結果、MIB拡張は、ネットワーク管理総局との懸念の数を提起したが、WGは、これらの変数のいずれかを除去するためのあらゆる試みに抵抗した、あまりにも大きなことになりました。最後に、MIB拡張機能の大部分が管理可能なサイズまで必要なサブセットを取得しようとして任意のグループに移動させました。

The DNS Server and Resolver MIB extensions were one of the first attempts to write MIB extensions for a protocol usually considered to be at the application layer. Fairly early on it became clear that, while it was certainly possible to write MIB extensions for DNS, the SMI was not really designed with this sort of thing in mind. A case in point was the attempt to provide direct indexing into the caches in the resolver MIB extensions: while arguably the only sane way to do this for a large cache, this required much more complex indexing clauses than is usual, and ended up running into known length limits for object identifiers in some SNMP implementations.

DNSサーバとレゾルバMIB拡張は、通常、アプリケーション層であると考えプロトコルのMIB拡張を書き込むための最初の試みの一つでした。かなり早いことが明らかになった上で、確かにDNSのためのMIB拡張を書くことが可能であった一方で、あること、SMIは、本当に心の中でこの種のものを使用して設計されていません。その一例は、リゾルバMIB拡張内のキャッシュに直接インデックス付けを提供する試みだった：大きなキャッシュのためにこれを行うには、おそらく唯一のまともな方法ながら、これは通常のものよりはるかに複雑なインデックス句を必要とし、に実行してしまいました一部のSNMP実装でオブジェクト識別子の既知の長さの制限。

Furthermore, the lack of either real proxy MIB support in SNMP managers or a standard subagent protocol meant that there was no reasonable way to implement the MIB extensions in the dominant implementation (BIND). When the AgentX subagent protocol was developed a few years later, we initially hoped that this would finally clear the way for an implementation of the DNS MIB extensions, but by the time AgentX was a viable protocol it had become clear that nobody really wanted to implement these MIB extensions.

さらに、SNMPマネージャで実際のプロキシMIBのサポートや、標準のサブエージェントプロトコルのいずれかの欠如は、支配的な実装（BIND）でのMIB拡張を実装するための合理的な方法はありませんでしたことを意味しました。 AgentXのサブエージェントプロトコルは、数年後に開発されたとき、我々は当初、これは最終的にはDNSの拡張MIBの実装のための道をクリアすることを望んだが、時間によってのAgentXは、それは誰もが本当に実現したかっないことが明らかになっていた実行可能なプロトコルでしたこれらのMIBの拡張機能。

Finally, the MIB extensions took much too long to produce. In retrospect, this should have been a clear warning sign, particularly when the WG had clearly become so tired of the project that the authors found it impossible to elicit any comments whatsoever on the documents.

最後に、MIB拡張は非常に生産するにはあまりにも時間がかかりました。振り返ってみると、これはWGが明確に著者はそれが不可能な文書に一切コメントを惹起することが分かったプロジェクトの疲れになった場合は特に、明確な警告標識されている必要があります。

2. Lessons

2.レッスン

Observations based on the preceding list of mistakes, for the benefit of anyone else who ever attempts to write DNS MIB extensions again:

二度とDNS MIB拡張を書き込もうとする他の誰の利益のためにミスの前のリストに基づいて観察、：

- Define a clear set of goals before writing any MIB extensions. Know who the constituency is and make sure that what you write solves their problem.

- 任意のMIB拡張を書き込む前に目標の明確なセットを定義します。選挙が誰であるかを知っていると何を書くことは彼らの問題を解決していることを確認してください。

- Keep the MIB extensions short, and don't add variables just because somebody in the WG thinks they'd be a cool thing to measure.

- 短いMIB拡張をキープし、WGでの誰かが、彼らは測定するためのクールなものになるだろうと考えているという理由だけで変数を追加しないでください。

- If some portion of the task seems to be very hard to do within the SMI, that's a strong hint that SNMP is not the right tool for whatever it is that you're trying to do.

- タスクの一部がSMI以内に行うことは非常に困難であると思われる場合、それはSNMPが、それはあなたがやろうとしていることは何でものための適切なツールではないという強いヒントです。

- If the entire project is taking too long, perhaps that's a hint too.

- プロジェクト全体に時間がかかりすぎる場合は、おそらくそれはあまりにもヒントです。

3. Recommendation

3.勧告

In view of the community's apparent total lack of interest in deploying these MIB extensions, we recommend that RFCs 1611 and 1612 be reclassified as Historical documents.

これらのMIB拡張を導入への関心のコミュニティの見かけの完全な欠如を考慮して、我々は、RFCの1611年と1612年は歴史的文書として再分類することをお勧めします。

4. Security Considerations

4.セキュリティについての考慮事項

Re-classifying an existing MIB document from Proposed Standard to Historic should not have any negative impact on security for the Internet.

再分類歴史へのProposed Standardから既存のMIBの文書は、インターネットのセキュリティ上の任意の負の影響を持つべきではありません。

5. IANA Considerations

5. IANAの考慮事項

Getting rid of the DNS MIB extensions should not impose any new work on IANA.

IANA上の任意の新しい仕事を課すべきではないDNS MIB拡張子を取り除きます。

6. Acknowledgments

6.謝辞

The author would like to thank all the people who were involved in this project over the years for their optimism and patience, misguided though it may have been.

著者は、彼らの楽観主義と忍耐のために長年にわたってこのプロジェクトに関わった全ての人、見当違いのことがあったかもしれないけれども感謝したいと思います。

7. References

7.参考

[DNS-SERVER-MIB] Austein, R. and J. Saperia, "DNS Server MIB Extensions", RFC 1611, May 1994.

[DNS-SERVER-MIB] Austeinと、R.とJ. Saperia、 "DNSサーバーのMIB拡張機能"、RFC 1611、1994年5月。

[DNS-RESOLVER-MIB] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions", RFC 1612, May 1994.

[DNSリゾルバ-MIB] Austeinと、R.とJ. Saperia、 "DNSリゾルバMIB拡張機能"、RFC 1612、1994年5月。

[DNS-DYNAMIC-UPDATE] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.

[DNSダイナミックUPDATE]いるVixie、P.、トムソン、S.、Rekhter、Y.、およびJ.はバウンド、 "ドメインネームシステムにおける動的更新（DNS更新）"、RFC 2136、1997年4月。

[AGENTX] Daniele, M., Wijnen, B., Ellison, M., and D. Francisco, "Agent Extensibility (AgentX) Protocol Version 1", RFC 2741, January 2000.

[AgentXの]ダニエル、M.、Wijnenの、B.、エリソン、M.、およびD.フランシスコ、 "エージェントの拡張機能（のAgentX）プロトコルバージョン1"、RFC 2741、2000年1月。

8. Author's Address

8.著者のアドレス

Rob Austein InterNetShare, Incorporated 325M Sharon Park Drive, Suite 308 Menlo Park, CA 94025 USA

ロブAusteinとInterNetShare、株式会社325Mシャロンパークドライブ、スイート308メンロパーク、CA 94025 USA

EMail: sra@hactrn.net

メールアドレス：sra@hactrn.net

9. Full Copyright Statement

9.完全な著作権声明

著作権（C）インターネット協会（2001）。全著作権所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。