Requirements for Management of Name Servers for the DNS
RFC 6168

Note: This ballot was opened for revision 05 and is now closed.

(Ron Bonica) Yes

(Dan Romascanu) (was Discuss) Yes

(Jari Arkko) No Objection

Comment (2010-11-18 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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".

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Lars Eggert) (was Discuss) No Objection

Comment (2010-11-17)
No email
send info
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

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.

(Adrian Farrel) No Objection

(Alexey Melnikov) No Objection

(Tim Polk) (was Discuss) No Objection

(Peter Saint-Andre) No Objection