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

[Edward Lewis <[e-mail]>]

In summary, okay...I'll put these changes into the 48 hours as the 
IESG is supposed to review the -10 document as is.

Hopefully I'll remember these changes when the time comes. ;)

At 16:10 -0500 1/10/06, Kevin Darcy wrote:
>Edward Lewis wrote:
>
>>  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).
>
>OK, no problem, just a suggestion.
>
>>>  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?
>
>Actually, my suggestion doesn't bring up any NCACHE issues, to my 
>knowledge. But the response-description for the zone-cut example 
>might be a little confusing, because the response depends on whether 
>the server in question happens to be authoritative for the child 
>zone.
>
>I was hoping to make the document a little easier to read for those 
>who just *have* to know the responses to the example queries, yet 
>would rather not spend the time and mental energy to think them 
>through. But if it introduces too much clutter, then perhaps it's 
>better to just leave the examples the way they are. Not everyone 
>needs to know what the responses are; synthesis or non-synthesis is 
>the point of the examples.
>
>>>  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.)
>
>I think either spelling is acceptable: it should just be consistent, 
>that's all. If someone wants to do a text search of the document for 
>either "descendant" or "descendent", they should get either 0 hits 
>or all hits, depending, where 0 hits is a trigger to try the other 
>spelling of the word. I'll note in passing that both RFC 1034 and 
>2672 spell it "descendant", and I couldn't find "descendent" in any 
>of the DNS-related RFCs I glanced at.
>
>- Kevin
>
>
>--
>to unsubscribe send a message to [e-mail] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://ops.ietf.org/lists/namedroppers/>

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                [phone]
NeuStar

Inactionable unintelligence is bliss.

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