Re: [dnsext] Moving policy data away from DNS

Otmar Lendl <lendl@nic.at> Mon, 27 December 2010 10:34 UTC

Return-Path: <lendl@nic.at>
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>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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>
X-List-Received-Date: Mon, 27 Dec 2010 10:34:03 -0000

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 //