Subject: [Gen-art] Gen-ART LC Review of draft-ietf-dnsext-rfc2672bis-dname-22

From: Ben Campbell <[email-masked]>
Date: Tue, 7 Jun 2011 17:35:10 -0500

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may receive.

Document: draft-ietf-dnsext-rfc2672bis-dname-22
Reviewer: Ben Campbell
Review Date: 2011-06-07
IETF LC End Date:2011-06-09
IESG Telechat date: (if known)

Summary:

This draft does not seem to be quite ready for publication, in that it professes to obsolete RFC 2672, but does not cover all the material from that RFC or explain the absence of the missing material. I also have a few editorial comments that should be considered prior to final publication.

Major issues:

This draft professes to obsolete RFC2672, but there are multiple sections of that RFC that are not replicated here, nor are their absence explained. I assume, since this draft obsoletes RFC2672, it is expected to completely replace it where an implementor would no longer be expected to read 2672.

-- section 4.2 of RFC2672, "Processing by Resolvers", is not replicated here, or if it is, it's in a substantially different form. 

-- section 5, "examples of use" is not replicated here. Similar examples are mentioned in the introduction, but the detail is removed.

None

Minor issues:

None

Nits/editorial comments:

-- IDNits has some comments, please check.

-- Abstract: "This is a revision of the original specification in RFC 2672, also aligning RFC 3363 and RFC 4294 with this revision."

The heading says this obsoletes 2672 and updates the other two. It's probably worth explicitly using those words here.

-- 3.1, 1st paragraph: "Relevant includes the following cases:"

Awkward sentence. Maybe "Relevant cases include the following:"?

-- 3.1, 5th paragraph: "is synthesized and included in the answer section"

What synthesized it? The server? (passive voice obscures responsibility) 

-- ... "The DNAME has an RRSIG"

A _signed_ DNAME has an RRSIG, right?

-- 4, 4th paragraph: "...should be revised..."

This document actually executes the revision, right? Better to say "this document revises..." rather than "should be revised"

-- ..., 7th paragraph: "...replaced with the word "DELETED"."

Won't that just leave the word "deleted" hanging on page without explanation? Wouldn't it be better to just simply delete it?

---

From: Scott Rose <[email-masked]>
Date: Wed, 8 Jun 2011 13:08:00 -0400

Perhaps the document should only update RFC 2672 instead of obsoleting it?

As for the nits:

> -- Abstract: "This is a revision of the original specification in RFC 2672,
> also aligning RFC 3363 and RFC 4294 with this revision."
>

The heading says this obsoletes 2672 and updates the other two. It's
> probably worth explicitly using those words here.
>

Will change to say that this doc updates all three RFC's.

> Awkward sentence. Maybe "Relevant cases include the following:"?
Will re-write to make it flow better.

>
> The caching servers in this case.  Will re-write to clarify that.

> Correct, will make more explicit.

> This document actually executes the revision, right? Better to say "this
> document revises..." rather than "should be revised"
>
>
Yes, will correct.

> Won't that just leave the word "deleted" hanging on page without
> explanation? Wouldn't it be better to just simply delete it?
>
>
Maybe, but I think the logic was that if there is some text there (just
something), it can be cleanly referenced (i.e. "DELETED [RFCXXXX]")if
someone is making a revised version of the RFC for some purpose.  Purely
deleting it accomplishes the task, but this provides a good "hook" for a
paper trail.

Scott

---

From: Scott Rose <[email-masked]>
Date: Wed, 8 Jun 2011 13:11:12 -0400

As for the nits:

Yes, will correct.

Scott

---

From: Ben Campbell <[email-masked]>
Date: Wed, 8 Jun 2011 16:50:26 -0500

Thanks for the response! Comments below, eliding the bits I think need no further comment.

> Perhaps the document should only update RFC 2672 instead of obsoleting it?  

That would resolve my concern, if it fits with the intent of the work group.

> On Tue, Jun 7, 2011 at 6:35 PM, Ben Campbell <[email-masked]> wrote:  

[...]

> Maybe, but I think the logic was that if there is some text there (just something), it can be cleanly referenced (i.e. "DELETED [RFCXXXX]")if someone is making a revised version of the RFC for some purpose.  Purely deleting it accomplishes the task, but this provides a good "hook" for a paper trail.
> 

Okay. On reflection, it's not like we really render the updates the old RFC documents.

> Scott
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Scott Rose <[email-masked]>
Date: Fri, 24 Jun 2011 11:16:30 -0400

FYI:
A new version (-23) of the dname-bis draft has been posted with the two sections re-added (resolver algorithm and examples of DNAME use). I haven't heard any comments from the DNSEXT WG on it, but it was only just posted.

Scott 

> Okay. On reflection, it's not like we really render the updates the old RFC documents.

===================================
Scott Rose
NIST
[email-masked]
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
===================================

---

From: Ben Campbell <[email-masked]>
Date: Fri, 24 Jun 2011 17:18:55 -0500

Thanks!

This version resolves all of my comments, with the exception that while the text now says the draft updates DNAME, the header still says it obsoletes RFC 2672. Is that the intent?

Thanks!

Ben.