IETF Logo Mail Archive

Re: [weirds] Scope and guiding principles (was Re: I-D Action: draft-hollenbeck-dnrd-ap-query-00.txt)

"Murray S. Kucherawy" <msk@cloudmark.com> Fri, 04 May 2012 13:33 UTC

Return-Path: <msk@cloudmark.com>
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DBA21F86E2 for <weirds@ietfa.amsl.com>; Fri, 4 May 2012 06:33:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.624
X-Spam-Level:
X-Spam-Status: No, score=-102.624 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 w-WpgCZnJduQ for <weirds@ietfa.amsl.com>; Fri, 4 May 2012 06:33:31 -0700 (PDT)
Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 23F8721F86D5 for <weirds@ietf.org>; Fri, 4 May 2012 06:33:31 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 5pZw1j0020ZaKgw01pZwMZ; Fri, 04 May 2012 06:33:56 -0700
X-CMAE-Match: 0
X-CMAE-Score: 0.00
X-CMAE-Analysis: v=2.0 cv=Xth4yC59 c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=cIfftXLV_isA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=fZa_VbU_MVPQ_Ii37BcA:9 a=g3nbLYVPWSGVCTMl0LUA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Fri, 4 May 2012 06:33:30 -0700
From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: "weirds@ietf.org" <weirds@ietf.org>
Thread-Topic: [weirds] Scope and guiding principles (was Re: I-D Action: draft-hollenbeck-dnrd-ap-query-00.txt)
Thread-Index: AQHNKYhU9hG9JbAMAUyQ2cDPern63pa5oVRw
Date: Fri, 04 May 2012 13:33:30 +0000
Message-ID: <9452079D1A51524AA5749AD23E00392810E14A@exch-mbx901.corp.cloudmark.com>
References: <4FA1610E.3050706@abenaki.wabanaki.net> <CBC86177.2C58A%francisco.arias@icann.org>
In-Reply-To: <CBC86177.2C58A%francisco.arias@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [67.160.203.60]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1336138436; bh=GRpKvNZLu5mvWOSXeaEabUW2Dsk9Hli1k15m2cSsxEU=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=F5a3dp5RTe5hDXkI5hWWNmJr6tXjwV/1U2pqkIIV5BV/P0hYcFcPb1GB6PXWaCz5h mVN6WJ1zouqhMVzoFNFRH1yjR8O8KIo78S1KPYj0kOkY38QXSy4jqV3noy2AeoGlc4 poiN825h1G5ioQatNP36KCBuPE/i9ZdUl3E0P3EU=
Subject: Re: [weirds] Scope and guiding principles (was Re: I-D Action: draft-hollenbeck-dnrd-ap-query-00.txt)
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" <weirds.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/weirds>, <mailto:weirds-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/weirds>
List-Post: <mailto:weirds@ietf.org>
List-Help: <mailto:weirds-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/weirds>, <mailto:weirds-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 May 2012 13:33:32 -0000

> -----Original Message-----
> From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Francisco Arias
> Sent: Thursday, May 03, 2012 4:56 PM
> To: weirds@ietf.org
> Subject: [weirds] Scope and guiding principles (was Re: I-D Action: draft-hollenbeck-dnrd-ap-query-00.txt)
> 
> 1. The protocol MUST enable policy options, not dictate them. (We
> should specify all the features that are requested, subject to
> principle #2 below, without requiring them to be implemented. What to
> implement is a registry/registrar/policy-maker decision outside of the
> scope of this
> effort.)
> 
> 2. We MUST only specify features that are already required/implemented
> by registries/registrars. )Other features can be specified later by
> those interested in extensions to the protocol.)

These make sense from a specification standpoint.  Where we need to be careful is that if such limitations end up being complete (i.e., no extensions to the current query model are ever implemented), then it still has to have been worthwhile to both clients and servers.

-MSK

v2.23.0 | Report a Bug | By Email