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 <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/ietf
