RFC3197 日本語訳

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

Austeinがコメントのために要求するワーキンググループR.をネットワークでつないでください: 3197年のInterNetShareカテゴリ: 情報の2001年11月

             Applicability Statement for DNS MIB Extensions

DNS MIB拡張子のための適用性証明

Status of this Memo

この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 (2001).  All Rights Reserved.

Copyright(C)インターネット協会(2001)。 All rights reserved。

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 ServerとResolver MIB拡張子がなぜ決して配備されなかったかを説明して、それらをHistorical状態に動かすことによってこれらの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

MIB拡張子は1つの特定のDNS実現(BIND-4.8.3)にかなり特定であるので、始めました。 仕事が進歩をしたとき、BIND-特定部位は、私たちがそれらを作る方法を知っていましたが、どうにかMIB拡張子のあらゆる改正が何とかただたまたま密接にBINDの何らかのバージョンによって保たれた統計に合っていた新しいカウンタを作成したのと実現同じくらい中立であるために書き直されました。 結果、非常に大きいことへの終わったMIB拡張子過ぎるとして。(拡張子は数を上げました)。

Austein                      Informational                      [Page 1]

RFC 3197      Applicability Statement - DNS MIB Extensions November 2001

Austeinの情報[1ページ]のRFC3197適用性証明--DNS MIB拡大2001年11月

   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.

ネットワークマネージメント管理職がいる関心では、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 ServerとResolver MIB拡張子は通常、応用層にあると考えられたプロトコルのための拡大をMIBに書く最初の試みの1つでした。 早くから、公正に、確かに、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.

その上、MIBがSNMPマネージャでサポートする本当のプロキシか標準の副代理店プロトコルのどちらかの不足は、優位な実現(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が正しいツールでないという強いヒントをしにくいように思えるなら、あなたがしようとしているということです。

Austein                      Informational                      [Page 2]

RFC 3197      Applicability Statement - DNS MIB Extensions November 2001

Austeinの情報[2ページ]のRFC3197適用性証明--DNS MIB拡大2001年11月

   -  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拡張子を配備することにおける共同体の見かけの総無関心から見て、私たちは、Historicalが記録するようにRFCs1611と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からHistoricまで既存のMIBドキュメントに分類し直すと、少しの負の衝撃もインターネットへのセキュリティに持たれるべきではありません。

5. IANA Considerations

5. IANA問題

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

DNS MIB拡張子を取り除くと、少しの新しい仕事もIANAにつけ込むべきではありません。

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サーバMIB] Austein、R.、およびJ.Saperia(「DNSサーバMIB拡張子」、RFC1611)は1994がそうするかもしれません。

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

[DNSレゾルバMIB] Austein、R.、およびJ.Saperia(「DNSレゾルバMIB拡張子」、RFC1612)は1994がそうするかもしれません。

   [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のダイナミックなアップデート] VixieとP.とトムソンとS.、RekhterとY.とJ.バウンド、「ドメインネームシステム(DNSアップデート)におけるダイナミックなアップデート」RFC2136(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インチ、RFC2741、2000年1月。」

Austein                      Informational                      [Page 3]

RFC 3197      Applicability Statement - DNS MIB Extensions November 2001

Austeinの情報[3ページ]のRFC3197適用性証明--DNS MIB拡大2001年11月

8. Author's Address

8. 作者のアドレス

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

ロブAustein InterNetShare、325Mの法人組織のシャロンの公園ドライブ、Suite308メンローパーク、カリフォルニア94025米国

   EMail: sra@hactrn.net

メール: sra@hactrn.net

Austein                      Informational                      [Page 4]

RFC 3197      Applicability Statement - DNS MIB Extensions November 2001

Austeinの情報[4ページ]のRFC3197適用性証明--DNS MIB拡大2001年11月

9. Full Copyright Statement

9. 完全な著作権宣言文

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Copyright(C)インターネット協会(2001)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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機能のための基金は現在、インターネット協会によって提供されます。

Austein                      Informational                      [Page 5]

Austein情報です。[5ページ]