Subject: Re: [DNSOP] RDBD draft updated

From: "Martin Thomson" <[email-masked]>
Date: Thu, 10 Oct 2019 13:52:01 +1100

There's an interesting (web-only) effort looking at a similar problem: https://github.com/krgovind/first-party-sets  There, the goal is to establish commonality for the purposes of sharing state (and fate).

A great counter-example in that case is the relationship between github.com and github.io, which are administratively the same, but purposefully distinct from the perspective of web state.  

All this makes me wonder what your intent is with respect to semantics.

   o  0: states that no relationship exists between the domains

   o  1: states that some relationship exists between the domains

That's incredibly vague.

If you consider the possibility of there being richer expressions of semantics, this starts to look a bit like link relations at the DNS layer: https://tools.ietf.org/html/rfc8288

On Tue, Oct 1, 2019, at 07:17, Stephen Farrell wrote:
> 
> Hi all,
> 
> As per discussion at IETF 105, Alex and I did some more
> work on the RDBD draft (lots of text edits and a bit of
> prototyping) and have posted a new version. [1]
> 
> We'd be very interested in folks' opinions.
> 
> Thanks,
> Stephen & Alex.
> 
> [1] https://tools.ietf.org/html/draft-brotman-rdbd-03
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> Attachments:
> * 0x5AB2FAF17B172BEA.asc
> * signature.asc

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Oct 2019 09:03:44 +0100

Hiya,

On 10/10/2019 03:52, Martin Thomson wrote:
> There's an interesting (web-only) effort looking at a similar
> problem: https://github.com/krgovind/first-party-sets  There, the
> goal is to establish commonality for the purposes of sharing state
> (and fate).

Yes, I saw that recently. I agree there's a partial overlap
in goals.

> A great counter-example in that case is the relationship between
> github.com and github.io, which are administratively the same, but
> purposefully distinct from the perspective of web state.

Sure.

> All this makes me wonder what your intent is with respect to

My goal is to define a mechanism with minimal semantics but
that is extensible. (To be open about why - I think efforts in
this space have partly foundered because they've started out
too ambitious, so I figure a more modest starting point may
work out better.)

> o  1: states that some relationship exists between the domains

Nope, it's minimal:-)

Again, that is intentional.

To take the web example you started with, if someone wanted to
use RDBD as a part of that, then I guess it'd mean defining a
new rdbd-tag value (call it "W") and its related semantics, e.g.
if an RDBD RR with a tag W is published at example.com saying
that example.net is related, that might mean that a TLS server
cert ought exist that covers both at once before a client would
be willing to consider shared state for those names (or whatever
else is required to implement the web semantics for W).

The definition of W is envisaged to be in some other spec, with
whatever IANA registry rules would be adopted for rdbd-tag code
points. (Parts of that 16 bit space could be FCFS too of course
but I'd guess spec required might be most useful.)

> If you consider the possibility of there being richer expressions of
> semantics, this starts to look a bit like link relations at the DNS
> layer: https://tools.ietf.org/html/rfc8288

I think the better approach, if expressing relationships in DNS,
is likely to be to encode those down to rdbd-tags or similar. At
least, that's the approach we're espousing here.

Cheers,
S.

>> As per discussion at IETF 105, Alex and I did some more work on the
>> RDBD draft (lots of text edits and a bit of prototyping) and have
>> posted a new version. [1]
>> 
>> Thanks, Stephen & Alex.
>> _______________________________________________ DNSOP mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
>> 
>> Attachments: * 0x5AB2FAF17B172BEA.asc * signature.asc
> 
> _______________________________________________ DNSOP mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
>