Subject: [DNSOP] NSCP Pros and Cons: draft-dickinson-dnsop-nameserver-control

From: Stephen Morris <[email-masked]>
Date: Tue, 7 Dec 2010 11:36:02 +0000

At the WG meeting in Beijing, the somewhat inconclusive discussion on a nameserver control protocol was ended by the suggestion that the authors of the two drafts discussed should write a short piece discussing the pros and cons of their proposals and post it to the list.  This is that piece for draft-dickinson-dnsop-nameserver-control.

Pros
1) A standard data model
This was one of the requirements identified in draft-ietf-nameserver-management-reqs and is the core of NSCP.  If a sufficiently complete model covering a reasonable number of nameservers can be identified, it will be possible for even basic clients to perform a useful set of functions.

2) Use of a standard protocol
Use of NETCONF provides the necessary protocol superstructure to support remote management of nameservers.  Amongst other things it provides:

* Persistent connections
* Secure authentication
* Basic set of commands for listing and manipulating elements in the server
* Means of matching commands and responses
* Reporting of errors
* Ability to define new commands
* Concurrent access to a server by multiple clients: locking is supported and an access control model allowing different clients to access different parts of the server is under development
* A defined extension mechanism, allowing seamless incorporation of both protocol and vendor extensions.

Cons
1) No mechanism for automatically copying configuration from one nameserver to another.

Work Required
At present, the data model is still rudimentary.  Detailed attributes still need to be defined for each entity, in particular for the "DNSSEC Policy" object. As a way forward, the first step should be to concentrate on refining the data model.

Stephen

---

From: Jelte Jansen <[email-masked]>
Date: Mon, 13 Dec 2010 09:51:07 +0100

> This was one of the requirements identified in draft-ietf-nameserver-management-reqs and is the core of NSCP.  If a sufficiently complete model covering a reasonable number of nameservers can be id…

It has been said (perhaps by you) that perhaps we ought to think about splitting
up the data model and the protocol. I'm not sure about the advantage of that
(well, apart from doc length), but thought i'd mention it.

> Use of NETCONF provides the necessary protocol superstructure to support remote management of nameservers.  Amongst other things it provides:
<snip>
> 1) No mechanism for automatically copying configuration from one nameserver to another.

especially missing for that is a classification of what is considered 'local'
and 'general', if such a classification can be made at all

> At present, the data model is still rudimentary.  Detailed attributes still need to be defined for each entity, in particular for the "DNSSEC Policy" object. As a way forward, the first step should…

+1

Two more things, I've also heard complaints about Netconf/yang being overkill,
do we know if this is about netconf, yang, or both?

Related to that, someone proposed a RESTful protocol, but noone made a specific
proposal for that. Should we try to get someone to do that? :)