Re: [dnsext] Moving policy data away from DNS
Otmar Lendl <lendl@nic.at> Mon, 27 December 2010 10:34 UTC
Return-Path: <dnsext-bounces@ietf.org>
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 577273A6879; Mon, 27 Dec 2010 02:34:04 -0800 (PST)
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A05C83A6879 for <dnsext@core3.amsl.com>; Mon, 27 Dec 2010 02:34:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.268
X-Spam-Level:
X-Spam-Status: No, score=-1.268 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_20=-0.74, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOM-phaqPuUq for <dnsext@core3.amsl.com>; Mon, 27 Dec 2010 02:34:02 -0800 (PST)
Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id E64AB3A67AB for <dnsext@ietf.org>; Mon, 27 Dec 2010 02:34:00 -0800 (PST)
Received: from [10.10.0.210] (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTPSA id ACEF14C2CF for <dnsext@ietf.org>; Mon, 27 Dec 2010 11:36:02 +0100 (CET)
Message-ID: <4D186C11.3070306@nic.at>
Date: Mon, 27 Dec 2010 11:36:01 +0100
From: Otmar Lendl <lendl@nic.at>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: dnsext@ietf.org
References: <2E9C54A5-0E2B-4AF9-960E-CE4CA9C1A7BE@nzrs.net.nz> <p06240879c9383836c67e@[10.20.30.150]> <1A550BF6-9B35-4DE1-9A83-1CB486B12DA5@nzrs.net.nz> <p0624087ec93857be2a71@[10.20.30.150]> <A723BDAE-DC0B-43C6-B104-010A390647A6@nzrs.net.nz>
In-Reply-To: <A723BDAE-DC0B-43C6-B104-010A390647A6@nzrs.net.nz>
Subject: Re: [dnsext] Moving policy data away from DNS
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org
On 23.12.2010 03:45, Jay Daley wrote: > > Say I wanted to state, for host X > - here is how hosts that conform to Y should connect to me > - here is how hosts that conform to Z should connect to me > - here is the default how hosts should connect to me > - here is how I intend to connect to hosts that conform to A > - and so on FYI, I proposed a scheme to solve these a few years ago in the context of SIP peering. In hindsight, the proposal was way too ambitious to catch on in the speermint WG. It also relies on the DDDS, which has its own problems, especially the selector within the RDATA. If you want to have a look, check out http://tools.ietf.org/html/draft-lendl-domain-policy-ddds-02 (the generic framework) http://tools.ietf.org/html/draft-lendl-speermint-federations-03 (a use-case for federation-based SIP peering) http://tools.ietf.org/html/draft-lendl-speermint-technical-policy-00 (a use-case similar to what you listed) There is even running code for this: http://www.kamailio.org/docs/modules/stable/modules_k/domainpolicy.html Look for "Usage Scenarios" to see some examples on what could be done with this approach & code. ---- No, I'm not proposing that this list is taking these drafts up again. I just hope that they might inspire some other ideas, and if they are just used to fend off IPR claims in the future, I'm also satisfied. cheers, otmar -- // Otmar Lendl <lendl@nic.at>, T: +43 1 5056416 - 33, F: - 933 // _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext
- Re: [dnsext] Moving policy data away from DNS Jeffrey A. Williams
- [dnsext] Moving policy data away from DNS Jay Daley
- Re: [dnsext] Moving policy data away from DNS Paul Hoffman
- Re: [dnsext] Moving policy data away from DNS Murray S. Kucherawy
- Re: [dnsext] Moving policy data away from DNS Joe Abley
- Re: [dnsext] Moving policy data away from DNS Andrew Sullivan
- Re: [dnsext] Moving policy data away from DNS Jay Daley
- Re: [dnsext] Moving policy data away from DNS Paul Hoffman
- Re: [dnsext] Moving policy data away from DNS Mark Andrews
- Re: [dnsext] Moving policy data away from DNS Jay Daley
- Re: [dnsext] Moving policy data away from DNS Paul Hoffman
- Re: [dnsext] Moving policy data away from DNS Paul Wouters
- Re: [dnsext] Moving policy data away from DNS Phillip Hallam-Baker
- Re: [dnsext] Moving policy data away from DNS Andrew Sullivan
- Re: [dnsext] Moving policy data away from DNS Eric Brunner-Williams
- Re: [dnsext] Moving policy data away from DNS Lawrence Conroy
- Re: [dnsext] Moving policy data away from DNS Paul Vixie
- Re: [dnsext] Moving policy data away from DNS Andrew Sullivan
- Re: [dnsext] Moving policy data away from DNS Eric Brunner-Williams
- Re: [dnsext] Moving policy data away from DNS Lawrence Conroy
- Re: [dnsext] Moving policy data away from DNS Phillip Hallam-Baker
- [dnsext] metaproblem metastatement Paul Vixie
- Re: [dnsext] Moving policy data away from DNS John Levine
- Re: [dnsext] Moving policy data away from DNS Otmar Lendl
- Re: [dnsext] Moving policy data away from DNS Phillip Hallam-Baker
- Re: [dnsext] Moving policy data away from DNS Jay Daley
- Re: [dnsext] Moving policy data away from DNS Phillip Hallam-Baker