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

"Murray S. Kucherawy" <msk@cloudmark.com> Thu, 12 January 2012 18:35 UTC

From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "draft-ietf-dnsext-xnamercode.all@tools.ietf.org" <draft-ietf-dnsext-xnamercode.all@tools.ietf.org>
Date: Thu, 12 Jan 2012 10:35:00 -0800
Thread-Topic: AppsDir Review of draft-ietf-dnsext-xnamercode
Thread-Index: AczRWOSb3T5cxrYTTDKTQq7fMmXudQ==
Message-ID: <F5833273385BB34F99288B3648C4F06F19C6C15851@EXCH-C2.corp.cloudmark.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C15851EXCHC2corpclo_"
MIME-Version: 1.0
Cc: "dnsext@ietf.org" <dnsext@ietf.org>
Subject: [apps-discuss] AppsDir Review of draft-ietf-dnsext-xnamercode
Precedence: list

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.

[apps-discuss] AppsDir Review of draft-ietf-dnsex… Murray S. Kucherawy
Re: [apps-discuss] [dnsext] AppsDir Review of dra… Murray S. Kucherawy
Re: [apps-discuss] [dnsext] AppsDir Review of dra… Donald Eastlake
Re: [apps-discuss] [dnsext] AppsDir Review of dra… Donald Eastlake