From nobody Sat Feb 29 10:48:28 2020 Return-Path: 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 ; 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 ; 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 ; Sat, 29 Feb 2020 10:48:25 -0800 (PST) Received: by mail-ua1-x92d.google.com with SMTP id k24so2183140uaq.12 for ; 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: <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" Date: Sat, 29 Feb 2020 10:48:10 -0800 Message-ID: To: Stephen Farrell Cc: Andrew Sullivan , dbound@ietf.org Content-Type: multipart/alternative; boundary="000000000000132992059fbb66d8" Archived-At: Subject: Re: [dbound] RDBD Questions X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 18:48:27 -0000 --000000000000132992059fbb66d8 Content-Type: text/plain; charset="UTF-8" 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 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 > --000000000000132992059fbb66d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Did discussion of this continue someplace else, maybe DNSO= P?=C2=A0 I'd love to know where the work went after this round of conve= rsation.

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

Hiya,

On 23/07/2019 06:37, Andrew Sullivan wrote:
> Hi,
>
> Same disclaimer as before.=C2=A0 (Sorry that it gets dull, but we real= ly
> 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.=C2=A0 Instead, it's an attempt to affirm that= there is a
>>> _policy_ relationship between two domains.=C2=A0 This is reaso= nably 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 p= lace
> that I need a better understanding.=C2=A0 I think that inside a protoc= ol P,
> there are two things you can state:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A01.=C2=A0 This is how A & B relate inside= P; or
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A02.=C2=A0 This is how A & B, which are ob= jects 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<= br> > 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".=C2=A0 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.=C2=A0 I just thi= nk
> 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
--000000000000132992059fbb66d8-- From nobody Sat Feb 29 10:57:14 2020 Return-Path: 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 2C1F63A1127 for ; Sat, 29 Feb 2020 10:57:12 -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 jXQIQUQ8o5kc for ; Sat, 29 Feb 2020 10:57:10 -0800 (PST) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (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 8D91A3A1126 for ; Sat, 29 Feb 2020 10:57:09 -0800 (PST) Received: by mail-oi1-x22f.google.com with SMTP id j80so4324642oih.7 for ; Sat, 29 Feb 2020 10:57:09 -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=TVWOydmn+ZmtHPd2Zxu8bxroxKV2MxbCZaZQ+NwMrao=; b=E40HTPZqsIQlLUfXiIp9fKTgze+pW7sDs9gHutzazdtJRqFxrfLPkAY4g6JqGp66y5 I2+Vry2caFnJScsZqivtgen9Fo5YnmqiL2OuozVVStX33/Dx4sZDDHJNOVjkR9NiWMBz 0jERGdqV4+ZfmCTyF+lz4YSm051LwinP9kWgHGTlQ6R3UMjUB9Zvmwhv8jYVC4pUIuJu tSMrKnBObJLRWdMtFaczSarB5rF9epar0GQzFgN3BkLCtHVxoJt5yGybqBJdcplyi+lU h3KcXsXxBFpSJImJkn4RUBqPndxfVmRrIIzRs/YzqDQYm2rjoGswWDOX7X5AWNp/or6z crDA== 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=TVWOydmn+ZmtHPd2Zxu8bxroxKV2MxbCZaZQ+NwMrao=; b=Ydrm58NR9kPqDNvsdj5iRH5LlQPmwbmJM0RSWHKbGhP6CTZ+aWGJ3XBfdGAePxeFwC zooU8HWc8vao3y7bnMeiK1U+oU3xJm8gaqXxvpLFKyQzmVIvheaYP0SFugsusY+BqkFj PuByUohxcbTMImFhWh5Yv5KH6jiIUDYU7S3qaTLSSzjM6wYSWFiD/cStCD/joKDIWMbH ZPTpZY1UXQCe3ElTSNdEtHaaeHBinlqdCHlsBHp2VDN80IYD9NCbst6BdCKP/hv8g9Cd 1Bcgrl8ilXFsISPaXF8U9aMjGuGK9+7kwxhGR6+2ee50RFM8LSn2Pl7Jt+214ikRDyyT GqYw== X-Gm-Message-State: ANhLgQ3DE6H778ek3XyQzhJXfTqO27YCK8kXXLUbQANtjuhuNpkfZzvZ PeB/vpYAOXQnxeOHsbNoZrMAzC8vUI4IaA7Q4oE= X-Google-Smtp-Source: ADFU+vsVAnt4tfjL4T1msg0HBYGaobmyK0m51YESi3/Y5PwM6l99GO3aEUO22igsbOgtXKJZQ2orlRH2Ygp2m6efrbs= X-Received: by 2002:a05:6808:3d1:: with SMTP id o17mr542353oie.6.1583002628698; Sat, 29 Feb 2020 10:57:08 -0800 (PST) MIME-Version: 1.0 References: <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: From: Tim Wicinski Date: Sat, 29 Feb 2020 13:56:57 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: Stephen Farrell , Andrew Sullivan , dbound@ietf.org Content-Type: multipart/alternative; boundary="0000000000005cb733059fbb85cf" Archived-At: Subject: Re: [dbound] RDBD Questions X-BeenThere: dbound@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS tree bounds List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 18:57:13 -0000 --0000000000005cb733059fbb85cf Content-Type: text/plain; charset="UTF-8" Yes, the discussion has been kicking around DNSOP. I've been a strong proponent of this or other solutions in the space. On Sat, Feb 29, 2020 at 1:48 PM Murray S. Kucherawy wrote: > 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 > 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 >> > _______________________________________________ > dbound mailing list > dbound@ietf.org > https://www.ietf.org/mailman/listinfo/dbound > --0000000000005cb733059fbb85cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, the discussion has been kicking around DNSOP.=C2=A0 I= 've been a strong proponent of this or other solutions
in the space= .=C2=A0

On Sat, Feb 29, 2020 at 1:48 PM Murray S. Kuc= herawy <superuser@gmail.com&g= t; wrote:
Did discussion of this continue someplace else, maybe DNSOP?=C2= =A0 I'd love to know where the work went after this round of conversati= on.

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.=C2=A0 (Sorry that it gets dull, but we real= ly
> 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.=C2=A0 Instead, it's an attempt to affirm that= there is a
>>> _policy_ relationship between two domains.=C2=A0 This is reaso= nably 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 p= lace
> that I need a better understanding.=C2=A0 I think that inside a protoc= ol P,
> there are two things you can state:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A01.=C2=A0 This is how A & B relate inside= P; or
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A02.=C2=A0 This is how A & B, which are ob= jects 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<= br> > 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".=C2=A0 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.=C2=A0 I just thi= nk
> 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
_______________________________________________
dbound mailing list
dbound@ietf.org https://www.ietf.org/mailman/listinfo/dbound
--0000000000005cb733059fbb85cf--