Re: [dnsext] AppsDir Review of draft-ietf-dnsext-xnamercode
"Murray S. Kucherawy" <msk@cloudmark.com> Sun, 15 January 2012 04:39 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 49CB321F848B; Sat, 14 Jan 2012 20:39:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.581
X-Spam-Level:
X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, 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 es-lq0UJYN1n; Sat, 14 Jan 2012 20:39:06 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 58B8A21F8486; Sat, 14 Jan 2012 20:39:02 -0800 (PST)
Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 14 Jan 2012 20:38:54 -0800
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 14 Jan 2012 20:39:01 -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>, "dnsext@ietf.org" <dnsext@ietf.org>
Date: Sat, 14 Jan 2012 20:39:03 -0800
Thread-Topic: [dnsext] AppsDir Review of draft-ietf-dnsext-xnamercode
Thread-Index: AczTF7h+C89jFOt7SQi7vDe/yejG+gAJy4UA
Message-ID: <F5833273385BB34F99288B3648C4F06F19C6C158A4@EXCH-C2.corp.cloudmark.com>
References: <AczRWOSb3T5cxrYTTDKTQq7fMmXudQ==> <F5833273385BB34F99288B3648C4F06F19C6C15851@EXCH-C2.corp.cloudmark.com> <CAF4+nEGMaWaAfWn+5RjJ56yrYoD5ckMgebyx3v666=mSSV5wKA@mail.gmail.com>
In-Reply-To: <CAF4+nEGMaWaAfWn+5RjJ56yrYoD5ckMgebyx3v666=mSSV5wKA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [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: Sun, 15 Jan 2012 04:39:07 -0000
Hi Donald, > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3@gmail.com] > Sent: Saturday, January 14, 2012 3:53 PM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org; draft-ietf-dnsext-xnamercode.all@tools.ietf.org; dnsext@ietf.org > Subject: Re: [dnsext] AppsDir Review of draft-ietf-dnsext-xnamercode > > > 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. 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
- [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