Re: [dbound] RDBD Questions

Andrew Sullivan <ajs@anvilwalrusden.com> Tue, 23 July 2019 05:37 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6FD12004F for <dbound@ietfa.amsl.com>; Mon, 22 Jul 2019 22:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=j+NsPWhE; dkim=pass (1024-bit key) header.d=yitter.info header.b=HAduLZVx
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hqov_fjCut-b for <dbound@ietfa.amsl.com>; Mon, 22 Jul 2019 22:37:53 -0700 (PDT)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC9F9120041 for <dbound@ietf.org>; Mon, 22 Jul 2019 22:37:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id D6B71BCD30 for <dbound@ietf.org>; Tue, 23 Jul 2019 05:37:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1563860242; bh=Akpzzx6nWxV73PG4c7Bf/Bz+VFWJ6ikWnl6+mU3WcHQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=j+NsPWhEt31Am00KGggeCVaAurw6VmlVstDECZXNH2kXr279Morg/KbuLM9296Opk ZN7t5pbsN8PdIvXfKA2QsL2QLA9hMgniwyKbJkfSsiRF7Ynlih+yk7/BwRCz2+jPk3 Mc0uvnsoXq1bMylilN7w++whhk38o/QlS4Dy47hU=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYhkZXBwPVmZ for <dbound@ietf.org>; Tue, 23 Jul 2019 05:37:21 +0000 (UTC)
Date: Tue, 23 Jul 2019 01:37:19 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1563860241; bh=Akpzzx6nWxV73PG4c7Bf/Bz+VFWJ6ikWnl6+mU3WcHQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=HAduLZVxfp6lKBrRgt5kIgtB9hOtNr5SdKkgHpQEWCX3xgI0tpy14kj+q1PBYJta1 Tj7NeRjrjDkBOttViCTojN4Gz6uRQk15SJHDfXso6JMIgAxwnFlIH65Lfb4MZ1mt9e XdBJ7yz0FhBQnS/vuAZbQD0s7dmfY6liv20aymQQ=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dbound@ietf.org
Message-ID: <20190723053719.axmhtbizlntvyoe4@mx4.yitter.info>
References: <e90bf1c1071b4255841c6b99bd668cb8@COPDCEX19.cable.comcast.com> <75544bed-e393-b9f6-04c4-00164169f5ea@cs.tcd.ie> <20190722225736.4nz4xziuogtvpapo@mx4.yitter.info> <45d41a2d-1bd2-4562-38fb-6a6c3c9fe4aa@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <45d41a2d-1bd2-4562-38fb-6a6c3c9fe4aa@cs.tcd.ie>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/3Ypr9lA-EyFtVVxh_rRT6U0RWMk>
Subject: Re: [dbound] RDBD Questions
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2019 05:37:56 -0000

Hi,

Same disclaimer as before.  (Sorry that it gets dull, but we really
want to make sure the ISOC/IETF LLC relationship is a bright line
before we stop.)

On Tue, Jul 23, 2019 at 05:52:17AM +0100, Stephen Farrell wrote:
> 
> On 22/07/2019 23:57, Andrew Sullivan wrote:

> > The problem the draft is trying to address, however, is _not_ a DNS
> > relationhip.  Instead, it's an attempt to affirm that there is a
> > _policy_ relationship between two domains.  This is reasonably clear
> > if you look at the use cases in the bullet list.
> 
> Well, we're trying to be agnostic as to the semantics of
> what the relationship is. The logic being that if we get
> the mechanism right, additional tags can be allocated later
> when specific semantics are in play. So I'm not sure if
> describing that as a policy relationship is quite right.

This is possibly the part that's balling me up, and possibly the place
that I need a better understanding.  I think that inside a protocol P,
there are two things you can state:

	1.  This is how A & B relate inside P; or

	2.  This is how A & B, which are objects of P, relate outside P.

I claim that any operator of P has exactly those two choices, and that
from the point of view of the operator of P everything in (2) amounts
to policy.

For the particular thing that RDBD is doing, the draft approaches this
from the point of view of "things I want to put in the DNS about an
obect of management for the DNS".  From the DNS's point of view,
that's a _policy_ expression, whatever you might think it applies to.
You can be agnostic all day long about semantics, but you are not
changing the semantics of the DNS and therefore inside the protocol
you hope to address, you're expressing policy.

I think this is a very fine thing to do, please note.  I just think
that, given the way DNS works, it has to be symmetrical or you won't
be able to express what you think you can.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com