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

From: [email-masked]
Date: Wed, 26 Sep 2007 16:15:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title		: Update to DNAME Redirection in the DNS
	Author(s)	: S. Rose, W. Wijngaards
	Filename	: draft-ietf-dnsext-rfc2672bis-dname-05.txt
	Pages		: 16
	Date		: 2007-9-26
	
The DNAME record provides redirection for a sub-tree of the domain
   name tree in the DNS system.  That is, all names that end with a
   particular suffix are redirected to another part of the DNS.  This is
   an update to the original specification in RFC 2672.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-dnsext-rfc2672bis-dname-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 26 Sep 2007 16:44:00 -0400

This update is really only changing a few typos, and wording to describe the
UD bit.  I'd like this to be the last version, but Wouter and I are at the
mercy of the WG.

Scott

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Wednesday, September 26, 2007 4:15 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: {Blocked Content} I-D
> ACTION:draft-ietf-dnsext-rfc2672bis-dname-05.txt
>
>
> Warning: This message has had one or more attachments removed
> Warning: (not named).
> Warning: Please read the following for more information.
>

Send a message to:
	[email-masked].
In the body type:

--
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: Edward Lewis <[email-masked]>
Date: Fri, 28 Sep 2007 15:46:32 -0400

Referring to:

>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                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.