Re: [dbound] RDBD Questions

"Murray S. Kucherawy" <superuser@gmail.com> Sat, 29 February 2020 18:48 UTC

Return-Path: <superuser@gmail.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 E205E3A1102 for <dbound@ietfa.amsl.com>; Sat, 29 Feb 2020 10:48:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=gmail.com
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 kaJjY8-cYwRR for <dbound@ietfa.amsl.com>; Sat, 29 Feb 2020 10:48:25 -0800 (PST)
Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202803A1100 for <dbound@ietf.org>; Sat, 29 Feb 2020 10:48:25 -0800 (PST)
Received: by mail-ua1-x92d.google.com with SMTP id k24so2183140uaq.12 for <dbound@ietf.org>; Sat, 29 Feb 2020 10:48:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ssd8wu8+eIGBUEMsdweFpEPPo21tiBzAyvCd7lSaEBs=; b=h4WEnWK3c1/nEGH8zDWxjMNiUBkZVnAjC69zGdbsktzB8CIU1oChqRCk3g1qTqbH9Y AyBNrqB1XMJ496p9r9+VJOnIjmajLLIoLAWX8FHRB/EcIVw7dZZiW1qHHJyxZsUSuDyl MKvEJDgZNr+9LETIswrJGQzzYzz+UKTVH47MkqsTbZOhkNiXoFLEcxX3ivukwSujuiBT 9XLloo7njiyacUEQUIHqxW61JU3m2T8rnuyOHz5/FoRCSqQvJP9XXRKcBFxy54ewEBiT RljjzsSrpHvMk9xOzZbUdAMXgEzt142+ACuNzN+7ZL/76l2k6Kb0CCoC2LVOj5eQTcto RGXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ssd8wu8+eIGBUEMsdweFpEPPo21tiBzAyvCd7lSaEBs=; b=cNpS41OCYZdTyXI61CHNIZqyckFu5Ae35QmUn71c10ryfQbarEXA7fYIO6M3Ml5dVt xD2MLI7tk4E5LJo1O28LuoMhT3GrVQq+GKs/MfAPYhwrG/95EUFZuwREpHQWqGWhdGQY JWwETQKGCDTBvHrqxdu6qbScg7geg7U/5OOCx3UX7jDKYY2Ir0w/O61VAvY8McrFaNEr D8ykf8/XKvuWWSAoO16pPimpCFClX4HdlKJkU24F/uMlwHifA5S3ArIXNIf1ADgv7C2c zX3C2SHVjoWn9ntwvJJzwoK8LVklsGuwbu+Hhl03VCM5xk0Z47KZ6+hLl4QgCdJKKZ+0 COKg==
X-Gm-Message-State: ANhLgQ0N6ekwQfZCAeBhrHk+uRQTA/WGBTUQxksRQi8+rbmXiBlXZbHh Lfwn5efTeSqaXQZZnfLdSNzwza3uhtg/Ijyq+djuezXH
X-Google-Smtp-Source: ADFU+vv8Pj8djyrUGtHe7a7exXtmiTyl/XPpuAu4gdOf6wUS5umwQmNOMf4LHbTzHlu3eJ7vVShJVz/ODH2OvJ5xh2M=
X-Received: by 2002:a9f:2612:: with SMTP id 18mr4755627uag.76.1583002103784; Sat, 29 Feb 2020 10:48:23 -0800 (PST)
MIME-Version: 1.0
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> <20190723053719.axmhtbizlntvyoe4@mx4.yitter.info> <87b6973f-ad9e-d007-2d8d-4091d630a084@cs.tcd.ie>
In-Reply-To: <87b6973f-ad9e-d007-2d8d-4091d630a084@cs.tcd.ie>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Sat, 29 Feb 2020 10:48:10 -0800
Message-ID: <CAL0qLwZcNZtSh3yg8AGqVT9ajjjCNPcMMn_REstutUzY5odZtA@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Andrew Sullivan <ajs@anvilwalrusden.com>, dbound@ietf.org
Content-Type: multipart/alternative; boundary="000000000000132992059fbb66d8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/FCKsNalajsc38LuxHCvvDKGBXJQ>
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: Sat, 29 Feb 2020 18:48:27 -0000

Did discussion of this continue someplace else, maybe DNSOP?  I'd love to
know where the work went after this round of conversation.

On Tue, Jul 23, 2019 at 5:50 AM Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
> Hiya,
>
> On 23/07/2019 06:37, Andrew Sullivan wrote:
> > 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.)
>
> That's ok. A #include form might work for follow-ups:-)
>
> >
> > 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.
>
> I agree rdbd matches case 2.
>
> I think calling that "policy" is maybe not a good plan though
> as people seem to generally infer that policy issues are
> always extremely weighty matters that require lots and lots of
> complex mechanics.
>
> > 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.
>
> Hmm. Two things I guess: 1) I fully admit my relative ignorance
> of DNS, so you may be right, and 2) I still think you're maybe
> wrong:-)
>
> If we're dealing with an rdbd tag of 1 (some, unstated, positive
> relationship), then I think the rdbd mechanism can still be
> uni-directional even if the real-world relationship is not. And
> using the mechanism twice, once for each direction, is entirely
> possible. So a uni-directional mechanism seems to me to be a
> better stake in the ground.
>
> Second, if we're dealing with some other putative tag value, say
> with some semantic related to ownership of the real-world entities,
> then that's an inherently asymmetric relationship, which again
> leads me to think that a uni-directional mechanism might be best.
>
> All that said, you're right that this is a topic to mull over,
> and (for this to work out well) we need to address it in some
> way that doesn't create big barriers to deployment.
>
> Cheers,
> S.
>
>
>
> >
> > Best regards,
> >
> > A
> >
> _______________________________________________
> dbound mailing list
> dbound@ietf.org
> https://www.ietf.org/mailman/listinfo/dbound
>