Subject: [dnsext] AppsDir Review of draft-ietf-dnsext-xnamercode

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 12 Jan 2012 10:35:00 -0800

I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see  http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate<http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate>).

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-dnsext-xnamercode
Title: xNAME RCODE and Status Bits Clarification
Reviewer: Murray S. Kucherawy
Review Date: January 12, 2012
IETF Last Call Date: N/A
IESG Telechat Date: N/A

The draft clarifies prior ambiguities with respect to how a resolver is supposed to report answer meta-data when resolving a name where the first answer returned in a potential series of query-responses is actually a pointer to another record.  It is precise and concise.

Summary: This draft is almost ready for publication as a Standards Track RFC but has a couple of issues that should be addressed before publication.

Major Issues:

Given that this is a potentially important clarification with interoperability considerations, I believe this document should say it updates at least RFC1035 (since its ambiguity is specifically called out), and possibly RFC2672 and RFC2308.  Make sure the Abstract also says this explicitly.

Minor Issues:

In Section 1, "There is a proposal for another redirection RR."  Is it appropriate to make reference to that here?  I don't know to which one you're referring or what status it has, so the answer might be "no"; just checking.

Section 2 identifies two status bits as part of this clarification document.  However, it also says explicitly that their definitions are unchanged from the documents that introduced them.  I'm curious then as to why they are included in this document at all; that is, what clarification is being provided?  Unlike Section 3, any ambiguity about their use has not been identified here.  If in fact there isn't any, I think this section can be removed.  If you like, you can introduce references to and overviews of their definitions in a new subsection of Section 1, since you do talk about them in Section 4.

Nits:

In Section 3, the exclamation mark legitimately relays bewilderment here, but unfortunately I think it should just be a period.  Even better would be to end the sentence with "says that some servers are implemented differently" or suchlike.

In Section 4, the clause "if the following apply" should be amended by adding "all of" or "one of" or something more specific.

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 14 Jan 2012 18:53:01 -0500

Hi Murray,

Thanks for the review, see responses below...

On Thu, Jan 12, 2012 at 1:35 PM, Murray S. Kucherawy <[email-masked]> wrote:
> I have been selected as the Applications Area Directorate reviewer for this
> draft (for background on appsdir, please see
>  http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
>
> Please resolve these comments along with any other Last Call comments you
> may receive. Please wait for direction from your document shepherd or AD
> before posting a new version of the draft.
>
> The draft clarifies prior ambiguities with respect to how a resolver is
> supposed to report answer meta-data when resolving a name where the first
> answer returned in a potential series of query-responses is actually a
> pointer to another record.  It is precise and concise.
>
> Summary: This draft is almost ready for publication as a Standards Track RFC
> but has a couple of issues that should be addressed before publication.
>
> Major Issues:
>
> Given that this is a potentially important clarification with
> interoperability considerations, I believe this document should say it
> updates at least RFC1035 (since its ambiguity is specifically called out),
> and possibly RFC2672 and RFC2308.  Make sure the Abstract also says this
> explicitly.

No problem with me to make that addition for these three RFCs.

> Minor Issues:
>
> In Section 1, “There is a proposal for another redirection RR.”  Is it
> appropriate to make reference to that here?  I don’t know to which one
> you’re referring or what status it has, so the answer might be “no”; just
> checking.

This is right at the beginning of Section 1 as motivation for
clarifying the situation and to make it clear that this document is
intended to apply to future redirection RRs (unless, of course, the
document specifying them says otherwise). I could make this a bit more
definite by saying "There has been a proposal for another redirection
RR that would combine the effects of both CNAME and DNAME." In fact,
there is a renewed effort to start work on such an RR just in the past
few days.

> Section 2 identifies two status bits as part of this clarification
> document.  However, it also says explicitly that their definitions are
> unchanged from the documents that introduced them.  I’m curious then as to
> why they are included in this document at all; that is, what clarification
> is being provided?  Unlike Section 3, any ambiguity about their use has not
> been identified here.  If in fact there isn’t any, I think this section can
> be removed.  If you like, you can introduce references to and overviews of
> their definitions in a new subsection of Section 1, since you do talk about
> them in Section 4.

Well, the name of the document is "xNAME RCODE and Status Bits
Clarification". I'm not sure why it would make that much difference to
move Section 2 on status bits to a new subpart of Section 1. As you
say, they are further discussed in Section 4. It seems to me that
something can "clarify" with making any change. Given no objections in
the DNSEXT WG to this material, I am inclined to leave it in.

> Nits:
>
> In Section 3, the exclamation mark legitimately relays bewilderment here,
> but unfortunately I think it should just be a period.  Even better would be
> to end the sentence with “says that some servers are implemented
> differently” or suchlike.

I kind of like it the way it is!!! But I'm OK with changing it to a period.

> In Section 4, the clause “if the following apply” should be amended by
> adding “all of” or “one of” or something more specific.

Sure, should be "all of".

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 14 Jan 2012 20:39:03 -0800

Hi Donald,

> -----Original Message-----
> From: Donald Eastlake [mailto:[email-masked]]
> Sent: Saturday, January 14, 2012 3:53 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [dnsext] AppsDir Review of draft-ietf-dnsext-xnamercode
> 
> > unchanged from the documents that introduced them.  I'm curious then
> > as to why they are included in this document at all; that is, what
> > clarification is being provided?  Unlike Section 3, any ambiguity
> > about their use has not been identified here.  If in fact there isn't
> > any, I think this section can be removed.  If you like, you can
> > introduce references to and overviews of their definitions in a new
> > subsection of Section 1, since you do talk about them in Section 4.
> 

My point is not so much the position of the text as its purpose.  You're right of course about the title, but it's not clear to me what is being clarified with respect to the status bits, since you explicitly say they are unchanged from their definitions.  That is, it seems to me deleting Section 2 entirely wouldn't remove anything from the document.

If the purpose is merely to restate their definitions or refer to them so the Section 4 text is more meaningful, then informative references to the places where those are when you talk about them in Section 4 seems simpler than what's there now.

-MSK

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 17 Jan 2012 08:43:39 -0500

Hi,

> If the purpose is merely to restate their definitions or refer to them so the Section 4 text is more meaningful, then informative references to the places where those are when you talk about them i…

The purpose is to clarify as the title says. I do not accept your
position that text which does not change something therefore cannot be
a clarification.

Thanks,
Donald