Re: I-D ACTION:draft-ietf-dnsext-rfc2672bis-dname-05.txt

[Edward Lewis <[e-mail]>]

Referring to:

At 16:15 -0400 9/26/07, [e-mail] wrote:
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-05.txt

1) Second paragraph of section 1...because I find the phrase "a DNAME 
from example.com to example.net" to be colloquial and a bit confusing 
I am proposing this as a strawman replacement:

# Take for example, looking through a zone (see RFC 1034, section 4.3.2,
# step 3) for the domain name "foo.example.com" and a DNAME resource record
# is found at "example.com" indicating that all queries under "example.com"
# be directed to "example.net".  The lookup process will return to step 1
# with the new query name of foo.example.net.  Had the query name been
# "www.foo.example.com" the new query name would be "www.foo.example.net".

2) Later on:

s/Other usage of DNAME lies in/Another usage of DNAME lies in/

or "Other usages" ...

3) In section 2.2

"suffix owner name" is descriptive but not defined.  Perhaps say that 
the portion of the QNAME ending with the root label that matches the 
owner name of the DNAME RR is replaced with the contents of the DNAME 
RR's RDATA.

4) Rewording/punctuation:

s/It is possible for DNAMEs to form loops.  Just like CNAMEs can form/
   It is possible for DNAMEs to form loops, just as CNAMEs can form

5) Section 2.4

Add "See section 5.2 for further restrictions related to dynamic update."

6) Section 3.1

Also add that the server ought to at least burp when trying to add a 
DNAME to a wild card domain name.  (Meta note - when I see "load a 
zone" I always look to see what's said about dynamic update.)

7) Section 3.2

First sentence add "when one is encountered."

8) Later in 3.2

I don't get the comment on "modern resolvers."  What's that based on? 
What's a "modern resolver?"

9) Section 5.3

Getting into NSEC3 is sticky.  First, you don't reference any NSEC 3 
document.  Second, if you do, it'll get this hung up in the RFC 
Editor queue for a few days.  (At least.)  Third, if you talk about 
NSEC3, you need a reference.  Fourth, you don't need to talk about 
it, leave that to the NSEC3 document if and when it comes out.

I don't want to bet against NSEC3, but this document will stand 
better if it doesn't get into a discussion on NSEC3.  Even if we know 
about NSEC3 while writing this.

10) Section 5.3.3.2

I don't get the comment:

    If the query had been cee.example.com as shown above, then this
    answer would have been validated, because 'cee' does not get
    redirected by the DNAME at 'bar'.

Wasn't this a valid Name Error example?  So "this answer would be validated"?

11) As it is now, you are missing a reference to NSEC3.

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

Think glocally.  Act confused.

--
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/>