[dnsext] AppsDir Review of draft-ietf-dnsext-xnamercode
"Murray S. Kucherawy" <msk@cloudmark.com> Thu, 12 January 2012 18:35 UTC
Return-Path: <msk@cloudmark.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FD021F84D7; Thu, 12 Jan 2012 10:35:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.579
X-Spam-Level:
X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlsmHeY0CtDB; Thu, 12 Jan 2012 10:35:03 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8E25521F84D6; Thu, 12 Jan 2012 10:35:03 -0800 (PST)
Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 12 Jan 2012 10:34:55 -0800
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 12 Jan 2012 10:35:02 -0800
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
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C15851EXCHC2corpclo_"
MIME-Version: 1.0
Cc: "dnsext@ietf.org" <dnsext@ietf.org>
Subject: [dnsext] AppsDir Review of draft-ietf-dnsext-xnamercode
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jan 2012 18:35:05 -0000
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.
- [dnsext] AppsDir Review of draft-ietf-dnsext-xnam… Murray S. Kucherawy
- Re: [dnsext] AppsDir Review of draft-ietf-dnsext-… Donald Eastlake
- Re: [dnsext] AppsDir Review of draft-ietf-dnsext-… Murray S. Kucherawy
- Re: [dnsext] AppsDir Review of draft-ietf-dnsext-… Donald Eastlake