Subject: Re: draft-stjohns-secure-notify-00.txt

From: Jim Reid <[email-masked]>
Date: Wed, 02 Jul 2003 05:39:00 -0700

>>>>> "djb" == D J Bernstein <[email-masked]> writes:

    djb> Please don't use vague words like ``serving.'' Very few
    djb> people know what service is actually necessary for
    djb> interoperability. The average parent script writers certainly
    djb> don't; I've seen them try TCP queries in violation of RFC
    djb> 1123, treat the SOA suggestions from a particular book as
    djb> requirements, demand root addresses from the child servers,
    djb> et al.

So what? A parent is entitled to apply and enforce any criteria they
want on the delegations they make. Whether those criteria are good or
bad is irrelevant: if someone wants a name in a certain part of the
tree, they have to play by the parent's rules. The checks you refer to
are not done for reasons of interoperability. They're mainly done to
apply a clue threshold to the people responsible for the DNS for the
name that's being registered. This reduces the load on the registry's
support staff as they don't get swamped by calls from registrants
about how to set up and run name servers. If you've ever visited a TLD
registry -- as I have -- you'd be amazed at the number of calls they
get from people who believe paying $25 or so for a name registration
entitles them to hours of DNS consultancy and hand-holding.

    djb> If tiddlywinks.dom consists of a single machine running an
    djb> HTTP server, an SMTP server, and a DNS server, then demanding
    djb> a second DNS server is a really bad idea: it adds expense
    djb> while decreasing reliability.

This is utter nonsense and you should know better. RFC1034 is very
clear that tiddlywinks.dom should have at least two name servers and
RFC2182 explains why. I suspect that cr.yp.to consists of not much
more than an HTTP server, an SMTP server and a DNS server. Yet this
zone has two NS records.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Jim Reid <[email-masked]>
Date: Sun, 06 Jul 2003 06:48:33 -0700

>> authority: 4.4.e164.arpa 14400 NS ns1.4.4.e164.arpa

    djb> It's always nice to see glue. However, that domain is an
    djb> internal RIPE experiment;

No it's not. You simply don't have the faintest clue what you're
talking about. I registered 4.4.e164.arpa on behalf of the UK
government for the national ENUM trial which is co-ordinated by the UK
ENUM Group, UKEG. The delegation is not an experiment by anyone. And
certainly not by RIPE NCC.

    djb> it has no relevance to the RIPE in-addr.arpa registration

That's wrong too. The template and procedure used by RIPE NCC for
handling ENUM delegations is identical to that for delegations in
their part of the in-addr.arpa tree.

BTW, there is a big difference between RIPE NCC and RIPE, a distinction
that appears to have eluded you.