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

[Ben Campbell]

Sorry for the late response--I just got back from vacation.

Yes, I was referring to the title and also the last paragraph of section 1. 
Your proposed change, along with something similar in section 1, would IMHO 
resolve the issue.

Thanks!

Ben.

On Jun 27, 2011, at 9:15 AM, Scott Rose wrote:

> Ben,
> Are you referring to the title ("Update to the DNAME...")?  Then yes, that 
> could be confusing - that was missed in the revision.
> 
> Would trimming the title to the shorter "DNAME Redirection in the DNS" fix 
> that?  It's the simplest fix.
> 
> Scott
> 
> On Jun 24, 2011, at 6:18 PM, Ben Campbell wrote:
> 
>> 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.
>> 
>> On Jun 24, 2011, at 10:16 AM, Scott Rose wrote:
>> 
>>> 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 
>>> 
>>> On Jun 8, 2011, at 5:50 PM, Ben Campbell wrote:
>>> 
 Thanks for the response! Comments below, eliding the bits I think need no 
 further comment.
 
 On Jun 8, 2011, at 12:11 PM, Scott Rose wrote:
 
> 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.
 
 
> 
> As for the nits:
> 
> 
> On Tue, Jun 7, 2011 at 6:35 PM, Ben Campbell  wrote:  
> 
 
 [...]
 
> 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 [RFC]")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
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
 
>>> 
>>> ===
>>> Scott Rose
>>> NIST
>>> scott.r...@nist.gov
>>> +1 301-975-8439
>>> Google Voice: +1 571-249-3671
>>> http://www.dnsops.gov/
>>> ===
>>> 
>> 
> 
> ===
> Scott Rose
> NIST
> scott.r...@nist.gov
> +1 301-975-8439
> Google Voice: +1 571-249-3671
> http://www.dnsops.gov/
> ===
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Scott Rose]

Ben,
Are you referring to the title ("Update to the DNAME...")?  Then yes, that 
could be confusing - that was missed in the revision.

Would trimming the title to the shorter "DNAME Redirection in the DNS" fix 
that?  It's the simplest fix.

Scott

On Jun 24, 2011, at 6:18 PM, Ben Campbell wrote:

> 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.
> 
> On Jun 24, 2011, at 10:16 AM, Scott Rose wrote:
> 
>> 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 
>> 
>> On Jun 8, 2011, at 5:50 PM, Ben Campbell wrote:
>> 
>>> Thanks for the response! Comments below, eliding the bits I think need no 
>>> further comment.
>>> 
>>> On Jun 8, 2011, at 12:11 PM, Scott Rose wrote:
>>> 
 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.
>>> 
>>> 
 
 As for the nits:
 
 
 On Tue, Jun 7, 2011 at 6:35 PM, Ben Campbell  wrote:  
 
>>> 
>>> [...]
>>> 
 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 [RFC]")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
 gen-...@ietf.org
 https://www.ietf.org/mailman/listinfo/gen-art
>>> 
>> 
>> ===
>> Scott Rose
>> NIST
>> scott.r...@nist.gov
>> +1 301-975-8439
>> Google Voice: +1 571-249-3671
>> http://www.dnsops.gov/
>> ===
>> 
> 

===
Scott Rose
NIST
scott.r...@nist.gov
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
===

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Ben Campbell]

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.

On Jun 24, 2011, at 10:16 AM, Scott Rose wrote:

> 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 
> 
> On Jun 8, 2011, at 5:50 PM, Ben Campbell wrote:
> 
>> Thanks for the response! Comments below, eliding the bits I think need no 
>> further comment.
>> 
>> On Jun 8, 2011, at 12:11 PM, Scott Rose wrote:
>> 
>>> 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.
>> 
>> 
>>> 
>>> As for the nits:
>>> 
>>> 
>>> On Tue, Jun 7, 2011 at 6:35 PM, Ben Campbell  wrote:  
>>> 
>> 
>> [...]
>> 
>>> 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 [RFC]")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
>>> gen-...@ietf.org
>>> https://www.ietf.org/mailman/listinfo/gen-art
>> 
> 
> ===
> Scott Rose
> NIST
> scott.r...@nist.gov
> +1 301-975-8439
> Google Voice: +1 571-249-3671
> http://www.dnsops.gov/
> ===
> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Scott Rose]

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 

On Jun 8, 2011, at 5:50 PM, Ben Campbell wrote:

> Thanks for the response! Comments below, eliding the bits I think need no 
> further comment.
> 
> On Jun 8, 2011, at 12:11 PM, Scott Rose wrote:
> 
>> 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.
> 
> 
>> 
>> As for the nits:
>> 
>> 
>> On Tue, Jun 7, 2011 at 6:35 PM, Ben Campbell  wrote:  
>> 
> 
> [...]
> 
>> 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 [RFC]")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
>> gen-...@ietf.org
>> https://www.ietf.org/mailman/listinfo/gen-art
> 

===
Scott Rose
NIST
scott.r...@nist.gov
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
===

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Ben Campbell]

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

On Jun 8, 2011, at 12:11 PM, Scott Rose wrote:

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


> 
> As for the nits:
> 
> 
> On Tue, Jun 7, 2011 at 6:35 PM, Ben Campbell  wrote:  
> 

[...]

> 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 [RFC]")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
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Gen-ART LC Review of draft-ietf-dnsext-rfc2672bis-dname-22

[Scott Rose]

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  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 [RFC]")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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Gen-ART LC Review of draft-ietf-dnsext-rfc2672bis-dname-22

[Scott Rose]

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  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 [RFC]")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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Gen-ART LC Review of draft-ietf-dnsext-rfc2672bis-dname-22

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at .

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?

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf