Subject: [DNSOP] Fwd: New Version Notification for draft-perreault-dnsop-stats-mib-01.txt

From: Simon Perreault <[email-masked]>
Date: Mon, 16 Jul 2012 11:51:12 -0400

Dnsopers,

As suggested by a few people, we added a section to our draft evaluating 
how we stand against RFC 3197. For your convenience, here it is 
verbatim. We would of course appreciate further feedback.

Thanks,
Simon

1.2.  On RFC 3197

    A previous attempt at defining a MIB for DNS servers failed.
    [RFC3197] analyses the causes of that failure and identifies a few
    lessons to be learned.  This section compares those lessons against
    the proposal contained in this draft.

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

       *  There is a single goal: expose usage statistics (i.e.,
          counters) over SNMP.

       *  Constituency: The problem has been identified by TLD operators
          trying to obtain usage statistics from anycast nodes.  One TLD
          operator having this problem is co-authoring this draft.

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

       *  The proposed MIB is short (subjectively).

       *  The stats exposed by the MIB are those already available in a
          popular DNS server used by many TLDs.

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

       *  Writing this MIB was easy and straightforward.

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

       *  From a technical point of view, this could be wrapped up
          quickly.

-------- Original Message --------
Subject: New Version Notification for draft-perreault-dnsop-stats-mib-01.txt
Date: Mon, 16 Jul 2012 08:46:55 -0700
From: [email-masked]
To: [email-masked]
CC: [email-masked], [email-masked]

A new version of I-D, draft-perreault-dnsop-stats-mib-01.txt
has been successfully submitted by Simon Perreault and posted to the
IETF repository.

Filename:	 draft-perreault-dnsop-stats-mib
Revision:	 01
Title:		 DNS Server Statistics Management Information Base (MIB)
Creation date:	 2012-07-16
WG ID:		 Individual Submission
Number of pages: 18
URL: 
http://www.ietf.org/internet-drafts/draft-perreault-dnsop-stats-mib-01.txt
Status: 
http://datatracker.ietf.org/doc/draft-perreault-dnsop-stats-mib
Htmlized: 
http://tools.ietf.org/html/draft-perreault-dnsop-stats-mib-01
Diff: 
http://tools.ietf.org/rfcdiff?url2=draft-perreault-dnsop-stats-mib-01

Abstract:
    This memo defines a portion of the Management Information Base (MIB)
    for monitoring statistics of DNS servers.

The IETF Secretariat

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 23 Jul 2012 12:47:54 +0200

On Mon, Jul 16, 2012 at 11:51:12AM -0400,
 Simon Perreault <[email-masked]> wrote 
 a message of 92 lines which said:

> As suggested by a few people, we added a section to our draft
> evaluating how we stand against RFC 3197.

I won't be in Vancouver, sorry, but I've read this draft (background:
I work for a TLD operator and we have problems similar to the ones
described in the draft).

Main comment: I am not convinced by the whole idea of "Discontinuity
Time". Isn't the whole idea of SNMP to have dumb agents, often without
stable memory, and the manager is supposed to know that, to detect
discontinuities and to deal with it? Why is DNS different from typical
MIB-II counters, which can go back to zero when the router reboots?

Second, the draft requires a mention of RFC 6168, which covers also
statistics.

Otherwise, the draft seems sensible, addresses a real problem for DNS
operators who have subcontractors, and, IMHO, correctly answer the
warnings of RFC 3197.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 23 Jul 2012 09:12:38 -0400

> MIB-II counters, which can go back to zero when the router reboots?

The main use case is when the DNS daemon restarts and loses state. This 
creates a discontinuity in the DNS MIB counters but not in the global 
MIB-II counters. That's why we introduced a separate discontinuity 
indicator that the manager can monitor to identify discontinuities, just 
like it does with MIB-II.

Other MIBs use the same technique (e.g. the OSPFv2 MIB [RFC4750]).

> Second, the draft requires a mention of RFC 6168, which covers also

Clearly we can add a reference to that RFC.

But it looks like it doesn't go into much detail about what statistics 
are needed, just that some are. So, not much guidance for us. Or did I 
overlook something?

> operators who have subcontractors, and, IMHO, correctly answer the

Thank you! That's very encouraging!

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca