To:
Rob Austein <sra+dnsop@hactrn.net>
Cc:
dnsop@cafax.se
From:
David Conrad <david.conrad@nominum.com>
Date:
Sun, 27 Apr 2003 19:22:06 -0700
In-Reply-To:
<20030427201649.89A5518E6@thrintun.hactrn.net>
Sender:
owner-dnsop@cafax.se
Subject:
Re: draft-ietf-dnsop-serverid-01.txt
Hi, Given their fundamental nature, I am curious as to why you didn't raise these issues way back when I first submitted this draft or at the DNSOP meeting where this was discussed, however... On Sunday, April 27, 2003, at 01:16 PM, Rob Austein wrote: > While I understand and respect the author's intentions in attempting > to remove the BIND-specific aspects of an existing hack, this opens up > a nasty can of worms: It would seem difficult to do pretty much anything in the IETF these days without opening up a nasty can of worms. > 1) The draft asks IANA to allocate a new TLD, and a class-specific TLD > at that; > > 2) The draft specifies behavior for the (conceptual) zone > corresponding to that new class-specific TLD which is totally > inconsistant with the usual DNS data coherence model. > > Furthermore, even ignoring the above issues, this looks like a > protocol document than an ops document. The draft attempts to document existing operational practice and modify that practice slightly so it is more generally acceptable to non-BIND implementations. It also tries to address an operational requirement of being able to identify which machine is responding to a query by extending the existing practice. It is working code (in at least 3 independent DNS servers I am aware of). There is no modification to the DNS protocol proposed in the draft. There are no new RR types defined or clarification of any existing RR type behavior. I do not believe it appropriate for this draft to be in DNSEXT. > I can see two ways forward, depending on what the author and the WG > want to do: > > a) Strip this back down to an Informational doc describing an existing > BIND hack; or It was always my intent for this to be informational. > b) Change focus to trying to draft some useful behavior for the STATUS > opcode, and move the work over to DNSEXT. You forgot the smiley. > Comments? This draft attempts to extend an existing practice in as simple a way as possible to address an immediate operational concern, namely being able to determine which nameserver out of a set of anycast'ed nameservers is responding to a request. It would be distressing if this were to get bogged down in yet another IETF swamp. Rgds, -drc #---------------------------------------------------------------------- # To unsubscribe, send a message to <dnsop-request@cafax.se>.