Requirements for Management of Name Servers for the DNS
draft-ietf-dnsop-name-server-management-reqs-05

These comments from a review by Ari Keränen may be considered:

3.3.  Monitoring Requirements

    o  Number of requests sent, responses sent, average response latency
       and other performance counters

Even if these are only examples, I'd add "number of errors" to the list.

3.4.  Alarm and Event Requirements

Here, regarding the previous comment, I'd add "number of errors exceeds 
some threshold".

Section 1., paragraph 2:
>    Previous standardization work within the IETF resulted in the
>    creation of two SNMP MIB modules [RFC1611] [RFC1612] but they failed
>    to achieve significant implementation and deployment.  The perceived
>    reasons behind the failure for the two MIB modules are further
>    documented in [RFC3197].

  Should we move these two MIB modules [RFC1611][RFC1612] to Historic?


Section 2.1.1., paragraph 1:
>    The management solution MUST support both name servers that are
>    serving a small number of potentially very large zones (e.g.  Top
>    Level Domains (TLDs)) as well as name servers that are serving a very
>    large number of small zones.  Both deployment scenarios are common.

  Plus, obviously, name servers that lie somewhere in between these
  extremes.


Section 2.1.2., paragraph 1:
>    Large enterprise network deployments may contain multiple name
>    servers operating within the boundaries of the enterprise network.
>    These name servers may each be serving multiple zones both in and out
>    of the parent enterprise's zone.  Finding and managing a large
>    numbers of name servers would be a useful feature of the resulting
>    management solution.  The management solution MAY support the ability
>    to discover previously unknown instances of name servers operating
>    within a deployed network.

  Clarification question: Do you mean discovery of "rogue" name servers
  that are *not* somehow discoverable based on information in the zones
  themselves? I.e. discovery mechanisms to probe the network, rather
  than analyze zone information?


Section 3.1.1., paragraph 6:
>    o  Restarting the name server

  Restarting seems redundant if stopping and starting are supported.