Re: Last Call: DNS Server MIB Extensions to Historic (fwd)

[Jon Saperia <[e-mail]>]

>>> The IESG has received a request to consider reclassifying the following
>>> RFCs as Historic:
>>> 
>>> RFC1611 'DNS Server MIB Extensions'
>>> RFC1612 'DNS Resolver MIB Extensions' 
>>> 
>>> The IESG will also consider publication of  Applicability Statement for
>>> DNS MIB Extensions <draft-ietf-dnsext-dnsmib-historical-00.txt> as an
>>> Informational RFC.
>>> 
>> 
>> draft-ietf-dnsext-dnsmib-historical-00.txt, needs revision to be a
>> useful document. While I do not support the move of 1611 and 1612 to
>> historic and would rather that the documents be revised in light of
>> current requirements, I am happy to work with Rob to revise the proposed
>> document that explains the change in status.
> 
> Jon,
> 
> Can you provide some more detail on what you believe is wrong in
> the current I-D?
> 
> It was clear from the rough concensus in dnsext that the WG doesn't
> want to fix 1611 and 1612 but instead invites others to go off and form
> design team(s) to come up with relatively complete proposals for replacement
> MIBs.
> 
> Thanks,
>    Erik
> 

There is only one significant issue even though I disagree with the
movement to historic in this context since is rare. The issue is the
language in the ID. Specifically a number of comments like:

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

The document was well discussed during it's creation and created with
considerable input from a number of people involved with the technology
at the time.

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

Also incorrect, in fact there was a version that was created with
configuration objects - I know I wrote them - that was asked to be
removed during a review because some felt concern for security. The
document does point to some of this which does suggest that there was
review and thinking about what should have gone in at that time. Unless
things have changed, protocols developed in WGs do require MIB Modules
since that is at present still the standard management we use.


   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.

We have learned a lot in the past few years about how to write MIB
Modules. The DNS Resolver and Server Modules are among the first using
SMIv2. If the WG wishes to 'do it over' rather than fix these, that is
one approach.

   Finally, the MIB extensions took much too long to produce.  In
   retrospect, this should have been a clear warning sigh, 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.


Or it may have been that the WG at the time was more interested in the
protocol an not management.

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

I do agree that it was a silly little project if we learned something.

It is not my intent to make more of this than is needed. I am fine with
the movement to historic even though that is not the approach I would
take, much of the 1611 and 1612 documents were based on the foundation
DNS RFCs - the fact that a 'commonly' available implementation supported
them is a good thing.

My issue is more one of tone and poorly supported conclusions that seem
rooted in a predisposition to use alternate methods. Some of the
other conclusions are valuable and have been included in various other
documents - repeating them here is harmless and perhaps even
beneficial. An example:

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

Thanks for giving me the opportunity to comment. I will not raise further
objections.

Thanks,
/jon
--

Jon Saperia		     [e-mail]
			     Phone: [phone]
			     Fax:   [phone]
			     http://www.jdscons.com/

to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.