Subject: Re: [dbound] RDBD Questions

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 29 Feb 2020 10:48:10 -0800

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 <[email-masked]>
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dbound
>

---

From: Tim Wicinski <[email-masked]>
Date: Sat, 29 Feb 2020 13:56:57 -0500

Yes, the discussion has been kicking around DNSOP.  I've been a strong
proponent of this or other solutions
in the space.