Re: draft-ietf-dnsext-wcard-clarify-10.txt

Edward Lewis <Ed.Lewis@neustar.biz> Tue, 10 January 2006 04:26 UTC

Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwB5V-0000f8-H5 for dnsext-archive@megatron.ietf.org; Mon, 09 Jan 2006 23:26:25 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00323 for <dnsext-archive@lists.ietf.org>; Mon, 9 Jan 2006 23:25:06 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1EwB2V-0005vu-7Y for namedroppers-data@psg.com; Tue, 10 Jan 2006 04:23:19 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.0
Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from <Ed.Lewis@neustar.biz>) id 1EwB2U-0005vi-7A for namedroppers@ops.ietf.org; Tue, 10 Jan 2006 04:23:18 +0000
Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k0A4Ml7x018277; Mon, 9 Jan 2006 23:22:48 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
Message-Id: <a06200702bfe8e468226a@[192.168.1.100]>
In-Reply-To: <43C32F13.6080903@daimlerchrysler.com>
References: <E1Ew6m1-0000BU-Tz@newodin.ietf.org> <43C32F13.6080903@daimlerchrysler.com>
Date: Mon, 09 Jan 2006 23:22:59 -0500
To: Kevin Darcy <kcd@daimlerchrysler.com>
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: Re: draft-ietf-dnsext-wcard-clarify-10.txt
Cc: namedroppers@ops.ietf.org
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

At 22:50 -0500 1/9/06, Kevin Darcy wrote:
>Some minor editorial-type suggestions, sorry I didn't bring up sooner:
>
>1. Is the $ORIGIN in the Section 2.2.1 master-file example really 
>necessary? All names in the example are fully-qualified anyway, so 
>it seems superfluous.

In the spirit that "we've already gone past the IETF last call, not 
to mention being in the 4th calendar year of this" I would prefer to 
only make necessary changes at this point.

For one, the process of doing a simple document such as this has 
pushed my patience to the limit.  The submission process even whines 
if you neglect to put in the correct year for the copyright in the 
boilerplate.

Sorry for the rant.

I like to use the $ORIGIN just to set the context.  The reader knows 
it's a zone file coming up.  That's why it was there in the first 
place, I think (it's been there for so many years).

>2. Terminally-curious minds always want to know what the response to 
>each example query is, but it's too taxing, and I think distracting, 
>to noodle those out for the 5 "non-synthesized" examples in Section 
>2.2.1. It also seems a little inconsistent to give the responses for 
>the "synthesized" examples, but not the "non-synthesized" ones. 
>Could a brief description of the response be given for each of those 
>examples, i.e.
>
>          QNAME=host1.example., QTYPE=MX, QCLASS=IN
>                the response will be "no error, but no data"
>                *.example. synthesizes no wildcard because 
>host1.example. exists
>
>          QNAME=sub.*.example., QTYPE=MX, QCLASS=IN
>                the response will be "no error, but no data"
>                *.example. synthesizes no wildcard because 
>sub.*.example. exists
>
>          QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
>                the response will be "no such name"
>                *.example. synthesizes no wildcard because 
>_tcp.host1.example. exists (without data)
>
>          QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
>                the response will either be from the child zone, or 
>will be a referral to the child zone
>                *.example. synthesizes no wildcard because 
>subdel.example. exists (and is a zone cut)
>
>          QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
>                the response will be "no such name"
>                *.example. synthesizes no wildcard because *.example. exists
>
>? (Hopefully I got those responses right). Or would that just 
>clutter things up too much?

Admittedly it's (its) late in my day and after reading this a few 
times, I don't understand the issue.  All I am after is showing the 
relationship of names to the synthesis process.  I didn't want to get 
into RFC 2308 (NCACHE) issues, all of the potential sources of 
synthesis is the same - why mention it?

>3. That word in the last paragraph of Section 2.2.1 should be "its" 
>(possessive), not "it's" (contraction of "it is" or "it has").

That's worth fixing...I never got to the its/it's lesson in school. 
That was on senior skip day I guess.

>4. Choose either "descendant[s]" or "descendent[s]" and be 
>consistent with the usage, at least with respect to the noun forms 
>of the word in Section 2.2.3. If "descendant[s]" is chosen, the 
>adjectival form in Section 4.1 should probably also be changed to 
>conform (so that a text search will find all occurrences).

Being only a native speaker and not formally educated in English 
(past high school), what is the difference between descendant and 
descendent?  Tell me which is correct and I'll use that.  (Where I 
come from, the two are pronounced the same, so I probably didn't even 
know they are different - especially if my spell checker accepts 
both.)

Please don't shoot the editor.

BTW, could items #3 and #4 just be done in the 48 hours?  I hate 
dealing with the ID submission monster.

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

Inactionable unintelligence is bliss.

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