Perhaps the document should only update RFC 2672 instead of obsoleting it?
As for the nits:
On Tue, Jun 7, 2011 at 6:35 PM, Ben Campbell <ben(_at_)nostrum(_dot_)com> wrote:
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.
Will change to say that this doc updates all three RFC's.
-- 3.1, 1st paragraph: "Relevant includes the following cases:"
Awkward sentence. Maybe "Relevant cases include the following:"?
Will re-write to make it flow better.
-- 3.1, 5th paragraph: "is synthesized and included in the answer
section"
What synthesized it? The server? (passive voice obscures responsibility)
The caching servers in this case. Will re-write to clarify that.
-- ... "The DNAME has an RRSIG"
A _signed_ DNAME has an RRSIG, right?
Correct, will make more explicit.
-- 4, 4th paragraph: "...should be revised..."
This document actually executes the revision, right? Better to say "this
document revises..." rather than "should be revised"
Yes, will correct.
-- ..., 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?
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf