Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Applicability Statement for DNS MIB Extensions (RFC3197)

IP.com Disclosure Number: IPCOM000006035D
Original Publication Date: 2001-Nov-01
Included in the Prior Art Database: 2001-Nov-28
Document File: 6 page(s) / 9K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Austein: AUTHOR

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.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 40% of the total text.

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 implementatio...