Re: [apps-discuss] [dnsext] AppsDir Review of draft-ietf-dnsext-xnamercode

[Donald Eastlake <[e-mail]>]

Hi Murray,

Thanks for the review, see responses below...

On Thu, Jan 12, 2012 at 1:35 PM, Murray S. Kucherawy <[e-mail]> 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.
>
> 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.

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   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]