Requirements for Management of Name Servers for the DNS
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' **)
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
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.