Subject: [dnsop] draft-kurtis-tld-ops-00.txt

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 8 Aug 2005 21:51:28 +0200

Due to some local mail-problems (sorting rules) on my side I only saw  
the discussion on the above draft today. Just in case some here where  
not in the WG meeting in Paris, I thought I should give a short  
summary of my presentation and the reasoning behind this.

The draft was written by me as a task from the IAB. This had been on  
the IAB TODO list long before I got nominated. After writing the  
first rough outline which is what got published under the name above  
I circulated it to some of the usual DNS suspects. I got a lot of  
feedback. Some similar to what has been echoed here, and some other.  
When reviewing that and trying to update the document I realised that  
there is actually two documents here. One on general zone operation  
BCP, and one on TLD operations. The first document seems reasonable  
to do, and a good thing to have. The second seems somewhat more hard  
to define. In the WG discussion I said that I wasn't sure that was a  
job for the IETF, and if it is, it might not be an issue for DNSOP. I  
said that I volunteered to work on the first document (which will be  
from scratch more or less) and leave the second for later or if  
someone stepped up.

So to summarise, the above document was a "place-holder" for the  
discussion. There will be a new I-D for the next IETF. It will only  
deal with zone operations and it will not contain the abbreviation  
"TLD" anywhere.

I hope that answers some questions. If you feel like I left something  
out from what I or anyone else said in the WG meeting in Paris,  
please let me know.

- kurtis -
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Edward Lewis <[email-masked]>
Date: Mon, 15 Aug 2005 14:02:01 -0400

Referring to http://www.ietf.org/internet-drafts/draft-kurtis-tld-ops-00.txt

At 21:51 +0200 8/8/05, Kurt Erik Lindqvist wrote:

>The draft was written by me as a task from the IAB. This had been on the IAB
>TODO list long before I got nominated. After writing the first rough outline
>which is what got published under the name above I circulated it to some of
>the usual DNS suspects.

Given that, I won't hold the document against you. ;)

DNS is not the critical element for a registry.  DNS is a critical 
element to the network and it is populated by a registry. 
Understanding this is a necessary first step in analyzing the 
document, or what the document is seemingly intended to be.

Titled "tld ops" leads me to believe this is supposed to be guidance 
towards running a registry for, what I would call, a widely-delegated 
zone.  I include in this 207.in-addr.arpa., .info, .us, .co.jp., and 
many others.  On the other hand, .arpa doesn't really fit this mold. 
It doesn't matter how many labels are in the zone's name, it matters 
how the zone is used.

When I think of a full-fledged registry, this is what comes to my 
mind.  First and foremost, it has a database associating Internet 
resources (addresses, domain names, etc.) to legal bodies 
(personified as contacts).  The life of the database is the primary 
concern - if the data is lost or corrupted, you've upset a large 
apple cart.  "Business continuation" is a major concern, the 
technical element of that is replication and escrow of data.

A registry has a number of important interfaces.  Input is 
registration activity (EPP is cited in the document as part of this). 
Output includes directory listing (WhoIs, IRIS) and DNS.  One 
interface often overlooked in engineering circles, but nonetheless 
vital is billing.  There is also the less definable interface with 
law enforcement authorities seeking identifying information when they 
need it.  Unifying the data flows amongst all of the interfaces is 
non-trivial.  Oh, and don't forget customer service.

Besides maintaining the life of the database, maintaining and 
unifying the interfaces, there is policy to deal with.  Policy can 
mean what names are permitted, who is eligible to get a name, and 
what happens when there is a dispute over the use or registration of 
a name.  For the RIRs policy also extends to who can get a resource 
and how much of it.

I didn't write much about DNS.  That's no accident.  I can go so far 
to say that there are many registries that do not operate their own 
DNS servers.  Why?  It's because DNS has been so well defined and so 
modular that it can be out-sourced.  The moral of this point is that 
if you want to talk about TLD operations, don't start with DNS as the 
main focus.

However, I can see that we don't want to neglect running DNS 
altogether.  It is probably the one component of a registry that is 
easiest for the IETF to document.  The DNS has the largest impact on 
the Internet of all registry interfaces.  I agree that there is 
usefulness in preparing requirements for providing DNS services for 
different kinds of zones.  But I wouldn't equate it with describing 
registry operations.

I am trying to find a copy of BCP 40 (but 
http://www.ietf.org/rfc/bcp/bcp40.txt says "access denied" and mail 
has gone to the web admin for the site), but am failing - I guess 
this is the root server operations document.  If so...

The requirements for a root server are not all that closely related 
to the requirements for a "tld" zone server.  Some "tlds" are high 
volume, high churn zones.  For this reason incremental zone updates 
are crucial, in contrast with the zone updating of the root.  The 
propagation time (latency) from registration of a name to seeing it 
in the DNS is much less in some "tlds," as well as name server 
re-listings.

There are a lot of technical differences between the root and the 
next level down.  The set of differences also varies greatly from one 
kind of "tld" to the next.  So, trying to document them will be 
tricky.

I've been through the experience of trying to respond to bids for 
registry operations.  When it comes to DNS, RFP's have asked the 
bidders to describe their DNS and what it conforms to.  Preparing 
this answer is not easy - the IETF isn't good at publishing 
"profiles" and some of the early DNS RFC's are not clear on 
conformance.  So, the IETF'er in me has thought that "it would be 
good to document a DNS profile" but when I think of the process, I 
can't see it would be successful.  E.g., would a "tld" DNS server be 
required to implement CNAME?  I'd rather see RFC 1995 integrated with 
RFC 1034/1035.  How about dynamic update?  Before you say "no, don't 
allow dynamic update to DNS servers in a 'tld'" consider that it is 
one tool for loading database changes into hidden masters.  It's not 
clear what should be in and what should be out.

Facility requirements are sticky.  With the advent of anycast, is it 
detrimental to have a server located in a best-effort facility? 
Should a "tld" be afraid to place servers where the local 
infrastructure hasn't matured?  I wouldn't want a document to make 
operators intolerant of the (service level agreement) risk of 
furthering the spread of the Internet.

One of the questions that came up in the meeting in Paris was "what 
was the motivation behind this?"  If this is to help organizations 
prepare RFP's for registry operations, I'd be leery of trying to do 
this in the IETF.  There are already examples of RFP's available (and 
the resulting bids too).  If I were to be issuing an RFP for a new 
"tld", I'd run off and copy the RFP sections from someone else who 
had a successful procurement. ;)

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

If you knew what I was thinking, you'd understand what I was saying.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html