From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3197.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 doc/rfc/rfc3197.txt (limited to 'doc/rfc/rfc3197.txt') diff --git a/doc/rfc/rfc3197.txt b/doc/rfc/rfc3197.txt new file mode 100644 index 0000000..94cefa4 --- /dev/null +++ b/doc/rfc/rfc3197.txt @@ -0,0 +1,283 @@ + + + + + + +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. + +Copyright Notice + + Copyright (C) The Internet Society (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. + +1. History + + The road to the DNS MIB extensions was paved with good intentions. + + 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. + + 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 + + + +Austein Informational [Page 1] + +RFC 3197 Applicability Statement - DNS MIB Extensions November 2001 + + + 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. + + 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. + + 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. + + 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. + +2. Lessons + + Observations based on the preceding list of mistakes, for the benefit + of anyone else who ever attempts to write DNS MIB extensions again: + + - 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. + + - 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. + + - 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. + + + +Austein Informational [Page 2] + +RFC 3197 Applicability Statement - DNS MIB Extensions November 2001 + + + - If the entire project is taking too long, perhaps that's a hint + too. + +3. Recommendation + + 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. + +4. Security Considerations + + Re-classifying an existing MIB document from Proposed Standard to + Historic should not have any negative impact on security for the + Internet. + +5. IANA Considerations + + Getting rid of the DNS MIB extensions should not impose any new work + on IANA. + +6. Acknowledgments + + 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 + + [DNS-SERVER-MIB] Austein, R. and J. Saperia, "DNS Server MIB + Extensions", RFC 1611, May 1994. + + [DNS-RESOLVER-MIB] Austein, R. and J. Saperia, "DNS Resolver MIB + Extensions", RFC 1612, May 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. + + [AGENTX] Daniele, M., Wijnen, B., Ellison, M., and D. + Francisco, "Agent Extensibility (AgentX) + Protocol Version 1", RFC 2741, January 2000. + + + + + + + + + + +Austein Informational [Page 3] + +RFC 3197 Applicability Statement - DNS MIB Extensions November 2001 + + +8. Author's Address + + Rob Austein + InterNetShare, Incorporated + 325M Sharon Park Drive, Suite 308 + Menlo Park, CA 94025 + USA + + EMail: sra@hactrn.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Austein Informational [Page 4] + +RFC 3197 Applicability Statement - DNS MIB Extensions November 2001 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (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. + + 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. + + + + + + + + + + + + + + + + + + + +Austein Informational [Page 5] + -- cgit v1.2.3