Re: [dbound] RDBD Questions

[Tim Wicinski <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dbound
>>
> _______________________________________________
> dbound mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dbound
>