Subject: [DNSOP] I-D ACTION:draft-regnauld-ns-communication-00.txt

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 20 Dec 2006 10:05:50 +0100

I would like to know if people here believe that this work is on-topic
for the WG. It does not change the protocol (so it does not seem
adapted to DNS Extensions) but it is not really "DNS operations".

Subject: I-D ACTION:draft-regnauld-ns-communication-00.txt
From: [email-masked]
To: [email-masked]
Date: Tue, 19 Dec 2006 15:50:02 -0500
List-Id: i-d-announce.ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Requirments for the Nameserver Communication protocol
	Author(s)	: P. Regnauld, S. Bortzmeyer
	Filename	: draft-regnauld-ns-communication-00.txt
	Pages		: 15
	Date		: 2006-12-19
	
   This document describes the requirments for a protocol to allow DNS
   nameservers to communicate among themselves, possibly outside the
   existing DNS protocol, for purposes of zone discovery and
   provisioning and remote management.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-regnauld-ns-communication-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-regnauld-ns-communication-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-regnauld-ns-communication-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce
_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: bert hubert <[email-masked]>
Date: Wed, 20 Dec 2006 10:19:53 +0100

> adapted to DNS Extensions) but it is not really "DNS operations".

I'm very interested in working on and eventually implementing the results of
this draft.

I don't really care where this happens though, and I'm expert on this.

I do think DNSOP might contain a bit more people that actually care about
"real world DNS". So if I'd have to choose, I'd go for DNSOP.

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: bert hubert <[email-masked]>
Date: Wed, 20 Dec 2006 10:19:53 +0100

Bert

---

From: Roy Arends <[email-masked]>
Date: Wed, 20 Dec 2006 11:03:36 +0100

> adapted to DNS Extensions) but it is not really "DNS operations".

I think it is on topic here (in dnsop).

Roy

---

From: Roy Arends <[email-masked]>
Date: Wed, 20 Dec 2006 11:03:36 +0100

Roy

---

From: Joe Abley <[email-masked]>
Date: Wed, 20 Dec 2006 08:14:07 -0500

On 20-Dec-2006, at 04:05, Stephane Bortzmeyer wrote:

> for the WG.

This seems entirely on-topic for dnsop to me.

Joe

---

From: Joe Abley <[email-masked]>
Date: Wed, 20 Dec 2006 08:14:07 -0500

Joe

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 20 Dec 2006 15:42:27 +0100

> adapted to DNS Extensions) but it is not really "DNS operations".

DNSOP looks about right. 

-- 
Måns Nilsson                     Systems Specialist
+46 70 681 7204   cell                       KTHNOC
+46 8 790 6518  office                  MN1334-RIPE

The Osmonds!  You are all Osmonds!!  Throwing up on a freeway at
dawn!!!
_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 20 Dec 2006 15:42:27 +0100

DNSOP looks about right.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Dec 2006 10:35:22 -0500

>	Title		: Requirments for the Nameserver Communication protocol

I don't know...the choice doesn't matter much to me I think.  That's 
all IETF politic talk.

I read the doc and couldn't help jumping in on the topic (some more).

What I've been screaming for (well, not loudly or even audibly in the 
IETF) is for a way to alter configuration files remotely.  This could 
be the avenue for that.  One question is whether this will also be a 
run-time management tool also.  I'll have to explain, but I'll do 
that in how in a break down of the things the protocol might work on.

1) Zone management.

Zone lifetime management is already in the document.  We would have 
to formalize  zone types beyond master and slave, such as forward and 
stub (from the document).  We'd have to also include all the options 
settings that we want to make interoperable, like TSIG keys per zone.

I would also like to have the ability to send high-volume zone 
updates in small batches before presenting the new zone to the 
public.  To tell the truth, I am not sure if this is practical, but 
what makes me think of it is a potential change of salt in NSEC3.

2) Views.

Views is a concept that a lot of folks like, but is a BINDism.  There 
would need to be (mindful if intellectual property concerns) an open 
definition of what views are and then a way to manage them.  This is 
something that is client-server in the management plane.  Perhaps not 
everyone able to manage a zone can manage a view.  I.e., views may 
only be manageable per IP addresses on the host, as opposed to being 
able to add another slave zone within a view.

3) Nameserver configuration options.

Things like what IP addresses to listen on, port numbers, recursion 
available, cache settings (as opposed to cache cleaning later), 
logging details (as opposed to log level later).  These 
configurations are much different from zone management in the sense 
that a commercial (not necessary for profit) name server operator may 
allow a customer a range of zones to manage but not allow them to 
touch the recursion settings.  This begs the need for a multi-level 
authorization model, akin to what we have seen for dynamic update 
security.

4) Dynamic update security management.

This probably part of #3, but I wanted to call it out because it is 
also like #2 in a way.  We need to figure out the policy rules for 
things like TKEY management.

5) Nameserver runtime options.

Things like cache clearing, logging detail, whether to log queries, 
freeze/thaw dynamic updates.  What I would like here is something 
akin to what RNDC gives BIND 9.

6) Nameserver health and lifetime reporting.

The nameserver ought to remind the zone administrators of events, 
including the termination of the name server's own domain name (if it 
knows).

There are probably other pipe dreams to throw at this.

Other comments - I don't think that this protocol need to be 
restricted to a client-server protocol in the requirements.  It might 
be best implemented that way once we understand the problem, but in 
these modern times we have more options.  Client-server is a 
simplistic protocol model, simple is good but it can be constraining.

For example, I can see a scenario like this...I have a slave zone on 
a server.  First I can ask "what views do you have" and get back a 
list and the criteria used to select the view for a packet.  I would 
then use this to decide if I want my zone to be in any specific view 
on the server.  (And there may only be one view on the server.) 
This is client-server, but a multi-step, state eating operation. 
After all, this is a connection-oriented, pre-arranged credential 
situation.

It would also be good to figure out a way to string command paths 
together.  If I have 5 name server processes behind a load balancer, 
I'd like to be able to send the commands to one and have it repeat 
them to the peers.  This can be repeated between sites too.  IOW, 
this is kind of like a permitted worm (see DARPA active nets research 
projects for background).

This effort could be quite large or quite constrained.  I'm 
indifferent in how large a scope is desired, but whatever scope is 
desired, it has to be made really clear.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Dessert - aka Service Pack 1 for lunch.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Dec 2006 10:35:22 -0500

1) Zone management.

2) Views.

---

From: David Conrad <[email-masked]>
Date: Wed, 20 Dec 2006 08:59:55 -0800

Stephane,

> adapted to DNS Extensions) but it is not really "DNS operations".

It sounds to me like you're wanting to define a new protocol.  I  
think the topic broad enough that it would justify spinning up a BOF  
and a new working group.  But that's probably just me.

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Wed, 20 Dec 2006 08:59:55 -0800

Stephane,

Rgds,
-drc

---

From: Joe Abley <[email-masked]>
Date: Wed, 20 Dec 2006 12:12:20 -0500

On 20-Dec-2006, at 11:59, David Conrad wrote:

> think the topic broad enough that it would justify spinning up a  
> BOF and a new working group.  But that's probably just me.

Well, I haven't read through the requirements document yet, but there  
are approaches which meet the general goals that I think it's talking  
about which don't involve a new protocol.

Consider the various approaches used by ISC and others to populate a  
zone with data that can be extracted by a nameserver and used to  
configure itself, for example. No protocol there -- more like a zone  
schema.

Joe

---

From: Joe Abley <[email-masked]>
Date: Wed, 20 Dec 2006 12:12:20 -0500

Joe

---

From: David Conrad <[email-masked]>
Date: Wed, 20 Dec 2006 09:26:43 -0800

Joe,

On Dec 20, 2006, at 9:12 AM, Joe Abley wrote:
> Well, I haven't read through the requirements document yet, but  
> there are approaches which meet the general goals that I think it's  
> talking about which don't involve a new protocol.

The document specifically mentions one (proprietary) protocol and  
section 5 of the document starts with:

5.  The requirments

    The protocol:

    1.   MUST allow the requestor to authenticate the responder and  
vice-
         versa.
...

> Consider the various approaches used by ISC and others to populate  
> a zone with data that can be extracted by a nameserver and used to  
> configure itself, for example. No protocol there -- more like a  
> zone schema.

Right.  I think the idea (and I'm sure Stephane will correct me if  
I'm wrong) is to come up with a standard way to do this sort of thing.

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Wed, 20 Dec 2006 09:26:43 -0800

Joe,

5.  The requirments

    The protocol:

Rgds,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Dec 2006 17:39:45 +0000

> Right.  I think the idea (and I'm sure Stephane will correct me if I'm
> wrong) is to come up with a standard way to do this sort of thing.
X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1

my read on this document is that it describes something more expansive
than the ISC tool mentioned above.  (see attached PDF.)  it's more like
"junoscript or netconf for DNS authorities", and a standard like it has
been long needed.  as to where it belongs, if it's going to be in-band
(affecting the wire protocol) then it should be in DNSEXT/namedroppers,
but if it's going to be a new protocol (like the regnauld doc describes)
or just new ways to use the existing protocol (like the attached PDF
describes) then it belongs in DNSOP.

the attached paper was published last year but i've not got around to
writing an I-D for it nor releasing the software that implements it.  i
have shared it privately with a number of folks, and it's in fairly wide
use among the folks ISC trades slave nameservice with.  my big worries
are that it's either too BIND-specific or that it'll spawn a dozen
competing non-interoperable schemas (like my QUOTE SITE INDEX hack did
in wu-ftpd).  so if you hate this, plz don't hack up your own -- instead,
write an I-D or help me write an I-D, and let the community drive some
coherence into this functionality.)

> Right.  I think the idea (and I'm sure Stephane will correct me if I'm
> wrong) is to come up with a standard way to do this sort of thing.
X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1

my read on this document is that it describes something more expansive
than the ISC tool mentioned above.  (see attached PDF.)  it's more like
"junoscript or netconf for DNS authorities", and a standard like it has
been long needed.  as to where it belongs, if it's going to be in-band
(affecting the wire protocol) then it should be in DNSEXT/namedroppers,
but if it's going to be a new protocol (like the regnauld doc describes)
or just new ways to use the existing protocol (like the attached PDF
describes) then it belongs in DNSOP.

the attached paper was published last year but i've not got around to
writing an I-D for it nor releasing the software that implements it.  i
have shared it privately with a number of folks, and it's in fairly wide
use among the folks ISC trades slave nameservice with.  my big worries
are that it's either too BIND-specific or that it'll spawn a dozen
competing non-interoperable schemas (like my QUOTE SITE INDEX hack did
in wu-ftpd).  so if you hate this, plz don't hack up your own -- instead,
write an I-D or help me write an I-D, and let the community drive some
coherence into this functionality.)

-- 
Paul Vixie

---

From: Phil Regnauld <[email-masked]>
Date: Wed, 20 Dec 2006 18:28:31 +0100

> configure itself, for example. No protocol there -- more like a zone  

	I am certain that most of the requirements defined in the draft can
	be implemented as third-party tools, and totally out of band with
	regards to the nameserver software itself.  Some of the other stuff
	involving views, for example, will require some level of integration
	with the nameserver.  By that I mean that the tools will need
	some knowledge of what features are implemented by the nameserver,
	maybe through some sort of capability negotiation.

	We were focusing primarily on zone management when we wrote the
	draft, as I consider them to be implementation neutral.  One
	way could be to have some sort of one schema, or pseudo-zone,
	call it "._conf"  Clients implementing the protocol could listen to
	updates on the "._conf" zone, and reconfigure the nameserver as
	required (adding or removing a zone if it appeKMDAwMDA5MzIxOSAwMDAwMCBuIAowMDAwMDM0ODEzIDAwMDAw
MDAwMDA0MzkzMSAwMDAwMCBuIAowMDAwMDQ3MDk5IDared in the pseudo-zone,
	for instance).

	Things like nameserver configuration, runtime options and health
	reporting are definitely nameserver specific.  But to avoid hitting
	a wall too early, we might as well address these things now.

	Phil

AwMDAwIG4gCjAwMDAwNDQxMjEgMDAwMDAg
--=-=-=

-- 
Paul Vixie

--=-=-=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--=-=-=--

---

From: Phil Regnauld <[email-masked]>
Date: Wed, 20 Dec 2006 18:28:31 +0100

required (adding or removing a zone if it appeared in the pseudo-zone,
	for instance).

	Phil

---

From: Phil Regnauld <[email-masked]>
Date: Wed, 20 Dec 2006 18:28:31 +0100

Phil

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Dec 2006 17:39:45 +0000

---

From: Phil Regnauld <[email-masked]>
Date: Wed, 20 Dec 2006 18:48:58 +0100

> coherence into this functionality.)

	Hi Paul,

	Thanks for sharing the paper.  I just checked it out quickly and it
	looks very interesting indeed.  I like the concept of meta-zone.

	Cheers,
	Phil

---

From: Phil Regnauld <[email-masked]>
Date: Wed, 20 Dec 2006 18:48:58 +0100

Hi Paul,

	Cheers,
	Phil

---

From: Paul Vixie <[email-masked]>
Date: 20 Dec 2006 18:08:07 +0000

> 	looks very interesting indeed.  I like the concept of meta-zone.

i'll share the code privately with anyone who wants it, but it's not ready
for public release.  note that the ideas expressed, and the code, will be
open source under a BSD license whenever they're mature enough for release.
-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: 20 Dec 2006 18:08:07 +0000

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 21 Dec 2006 14:32:18 +0100

On Wed, Dec 20, 2006 at 10:05:50AM +0100,
 Stephane Bortzmeyer <[email-masked]> wrote 
 a message of 189 lines which said:

> I would like to know if people here believe that this work is
> on-topic for the WG.

It seems there is a rough consensus for using DNSOP for this work? If
so, I would request a DNSOP slot in IETF 58 / Prague to discuss the
project, the requirments, the candidate protocols...

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 21 Dec 2006 14:32:18 +0100

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 21 Dec 2006 14:40:01 +0100

On Wed, Dec 20, 2006 at 10:35:22AM -0500,
 Edward Lewis <[email-masked]> wrote 

> desired, it has to be made really clear.

Giving your wishlist, I believe you are more a supporter of a large
scope? Because your list is long and it seems that some items (such as
health reporting) may require a strong coupling with the nameserver.

My personal inclination goes toward a constrained scope. A protocol
more like ISC's metazones or PowerDNS' supermaster. I agree that
"views" are may be outside of a really constrained scope, I'll suggest
solution for them. But, in general, I would prefer to stick with zone
management (provisioning, configuring, reloading), not general
nameserver management.

BTW, speaking of nameserver management, what's the opinion of the WG
on RFC 3197?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 21 Dec 2006 14:40:01 +0100

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 21 Dec 2006 14:48:46 +0100

On Wed, Dec 20, 2006 at 09:26:43AM -0800,
 David Conrad <[email-masked]> wrote 
 a message of 29 lines which said:

> I think the idea (and I'm sure Stephane will correct me if I'm

Yes, wether the standard way is a protocol stricto sensu or "just" a
schema + format (over the DNS or over Netconf).

But it needs to be standard, that's why we need a RFC. (Otherwise, we
already have four proprietary protocols to do that job.)

So, it is not purely "operations" but it does not involve any change
in the DNS protocol (even if we adopt ISC "metazones"). So, DNSOP
seems the right place to me.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 21 Dec 2006 14:48:46 +0100

---

From: Roy Arends <[email-masked]>
Date: Thu, 21 Dec 2006 14:54:07 +0100

> project, the requirments, the candidate protocols...

I wouldn't mind if we have a seperate BoF session on it, right after  
DNSOP. The agenda for DNSOP is often busy, and this looks like a fair  
bit of work. We can merge it in later if needed.

Roy

---

From: Roy Arends <[email-masked]>
Date: Thu, 21 Dec 2006 14:54:07 +0100

Roy

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 21 Dec 2006 14:59:15 +0100

On Wed, Dec 20, 2006 at 05:39:45PM +0000,
 Paul Vixie <[email-masked]> wrote 
 a message of 2412 lines which said:

> my read on this document is that it describes something more
> expansive than the ISC tool mentioned above.

Yes, because it includes things like ACL (possibly), server reloading
or views. But one of the purposes of the discussion is to define the
scope of the future protocol: constrained (just a few things like zone
provisioning) or large (everything related to DNS server management)?

> it's more like "junoscript or netconf for DNS authorities",

IMHO, no, we should not try to define a standard way to describe
everything which goes in named.conf or nsd.conf. We should focus on a
few things but it is not obvious what these things are.

[Is it just me or is there a lot of NIH in Netconf, such a filtering
language for XML, instead of XPath and a new RPC protocol when XML-RPC
or SOAP, not mentioning REST, already exist?]

> the attached paper was published last year but i've not got around
> to writing an I-D for it nor releasing the software that implements
> it.

The way I view your "metazone" proposal is as a candidate for the
protocol whose requirments are expressed in
draft-regnauld-ns-communication-00.txt. My vision was that
draft-regnauld-ns-communication-00.txt would become a "Requirments"
RFC and then we could evaluate several candidate protocols.

> my big worries are that it's either too BIND-specific

At least, the vocabulary is, with the names of the zones being
named.conf directives :-)

Part of the challenge for the future protocol will be to define a
standard vocabulary. "Stub" and "forward" zones are another good
example.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 21 Dec 2006 14:59:15 +0100

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 21 Dec 2006 15:49:47 +0100

On Wed, Dec 20, 2006 at 10:35:22AM -0500,
 Edward Lewis <[email-masked]> wrote 
 a message of 104 lines which said:

> 2) Views.
> 
> Views is a concept that a lot of folks like, but is a BINDism.  

Isn't there at least one other name server which implements a similar
concept, may be with a different name?

> Perhaps not everyone able to manage a zone can manage a view.  I.e.,
> views may only be manageable per IP addresses on the host, as
> opposed to being able to add another slave zone within a view.

A possible approach, which would completely wipe out views from the
requirments document, could be, for nameservers which do have the
concept of view, to encode the view name in the identity of the
requestor. Since the requestor must be authenticated, you could
imagine that requestor "foo" would authenticate as "foo-view1" to
manage view "view1" and as "foo-view2" to manage view "view-2".

That way, view management would be completely outside of the protocol,
which would trim it for the great joy of the people who like small and
easy protocols.

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 21 Dec 2006 13:00:34 +0000

On 20 Dec 2006, at 17:39, Paul Vixie wrote:

> competing non-interoperable schemas [ ... ]

It seems to me that the schema and its expression as meta-zone data are
sufficiently abstract for a methodology based on per-implementation
(BIND, NSD, whatever ...) configurator scripts to be "no-brainer- 
obviously"
attractive.  I hope that's a sufficient condition for the worries you
mention not to be big ones.

/Niall

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 21 Dec 2006 13:00:34 +0000

/Niall

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 21 Dec 2006 15:49:47 +0100

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 21 Dec 2006 13:00:34 +0000

/Niall

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 21 Dec 2006 15:49:47 +0100

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 Dec 2006 10:05:05 -0500

>health reporting) may require a strong coupling with the nameserver.

I didn't mean it as a wish list.  What was my motivation?

Well, the one way to defeat a case of creeping features is to start 
with a fully featured spec.  'Course, that'll make it too heavy to 
ever get going.  What a dilemma.

What I like to do is imagine the fully-fledged, impossible to attain 
system first and then cut back from there.  It's find to declare 
parts of the problem space out of scope.  But it's also helpful to 
know what you've cut out in case it can be accommodated at a later 
date.

>management (provisioning, configuring, reloading), not general

It's okay to pick a small goal set, but then the solution ought to be 
built knowing it is a partial solution (or a full solution to a 
partial problem).

>BTW, speaking of nameserver management, what's the opinion of the WG

It was needed to cap off an idea that never flew, a procedural need 
to stamp "HISTORIC" on the DNS MIBs.  (Oddly, we moved more/as many 
DNS Proposed Standards to Historic than to Draft Standards since, 
well, at least the turn of the century plus some of the last.)

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 Dec 2006 10:05:05 -0500

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 Dec 2006 10:06:44 -0500

>project, the requirments, the candidate protocols...

The other option is the BoF route - DNS cluster management as the topic.

(Just a suggestion.)

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 Dec 2006 10:06:44 -0500

(Just a suggestion.)

---

From: David Conrad <[email-masked]>
Date: Thu, 21 Dec 2006 09:23:32 -0800

> concept, may be with a different name?

Yes (Nominum's ANS/CNS).  They are called "views".

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Thu, 21 Dec 2006 09:23:32 -0800

Rgds,
-drc

---

From: Peter Koch <[email-masked]>
Date: Thu, 21 Dec 2006 22:29:56 +0100

> It seems there is a rough consensus for using DNSOP for this work? If

well, this is not solely up for the WG to decide, but the general topic
fits in our charter and since we're about to recharter anyway it is
an opportunity to incorporate another "work basket". More important than
agreement which WG (or BOF) is the right place, though, is to define
the scope and to acquire commitments to discuss, edit and review documents.
Some of the drafts on our plate lack the latter, even in WGLC, and honestly
I'm not sure how to read all the "yes" votes^Wvoices for this new topic.

> project, the requirments, the candidate protocols...

Well, thanks Stephane, for starting the discussion and involving the WG.
{Please contact Rob and me offline for scheduling logistics.}

Going through the contributions I see a rapidly growing wishlist, so we
would need to add negative requirements to the list of deliverables.
Finally, before discussing actual requirements, the WG needs to frame
the work and high level goals: are we looking for a general name server
management protocol, a means to share zone oriented configuration
information between servers or both or even more? I'd suggest to identify and
describe in detail the current operational problems or scenarios that require
an interoperable solution (section 3 in Phil's and Stephane's draft is a good
start IMHO).

Whether or not designing the solution is to happen here or elsewhere and how
that solution actually looks like can be decided later.

-Peter

---

From: Peter Koch <[email-masked]>
Date: Thu, 21 Dec 2006 22:29:56 +0100

-Peter

---

From: Robert Story <[email-masked]>
Date: Fri, 22 Dec 2006 11:22:24 -0500

On Thu, 21 Dec 2006 14:40:01 +0100 Stephane wrote:
SB> BTW, speaking of nameserver management, what's the opinion of the WG
SB> on RFC 3197?

Earlier this year we had some funding to look at DNS Management, and I
started looking at defining some new MIBs, borrowing from the previous
ones as needed. Unfortunately, the funding got cut. Anyways, I'd be
glad to work on a revived effort to define and implement DNS management
MIBs.

SNMP isn't particularly good for pushing around large amounts of data,
but could easily be used to control/trigger some other method of
transferring large zone files and such...

-- 
Robert Story
SPARTA

---

From: Robert Story <[email-masked]>
Date: Fri, 22 Dec 2006 11:22:24 -0500