Subject: [dbound] Requirements for administrative boundary data sources?

From: Jeffrey Walton <[email-masked]>
Date: Sun, 10 Apr 2016 13:31:11 -0400

What are the requirements for the data source? I.e., does it have to
come from DNS?

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 11 Apr 2016 17:19:30 +0900

> What are the requirements for the data source? I.e., does it have to

Not necessarily, as far as I remember. But one requirement (or at least 
desideratum) is that it come as directly as possible from the actual 
entity that's in charge. That property would be met easily by DNS.

Regards,   Martin.

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 11 Apr 2016 04:35:04 -0400

On Mon, Apr 11, 2016 at 4:19 AM, Martin J. Dürst <[email-masked]> wrote:
> desideratum) is that it come as directly as possible from the actual entity
> that's in charge. That property would be met easily by DNS.

Thanks.

If the PSL is moved into owner/operators web services and out of DNS,
then it may be easier to build a new system (say a PSL.txt like a
Robots.txt) rather than retrofitting (adding DNS infrastructure and
pushing record changes into DNS).

Jeff

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 11 Apr 2016 06:34:47 -0700

> pushing record changes into DNS).

The distribution of the DBOUND information is not nearly as important as 
the collection of the inputs. If DBOUND specifies a distribution using 
X, it should be trivial for someone to collect that information using X 
and repackage it in Y.

As Martin points out, the most logical way for the owner of zone to say 
the zone's policy is in that zone or a child of the zone. To me, that's 
the most important part of the DBOUND work.

--Paul Hoffman

---

From: Jothan Frakes <[email-masked]>
Date: Tue, 12 Apr 2016 12:45:45 -0700

> the zone's policy is in that zone or a child of the zone. To me, that's the
> most important part of the DBOUND work.
>
> +1 also

As one of the contributing volunteers on PSL I can say this is important to
us as well - that these policies be defined by the registry for 'top down'
TLDs that come from IANA delegation (we follow ICP-3 - one authoritative
root).  Some of the biggest challenges that the volunteers have are A]
multiple, conflicting requests from the same registry, B] ensuring requests
are from the authorized source, and C] if a request comes from a third
party - validating the request with the authorized source.  Having this
done in the DNS zone would eliminate all three issues for us within the
IANA chain.

That said, we also recommend any solution be designed to not discriminate,
nor have any opinion on innovation below that, such as done by Amazon,
Microsoft, Google, Github, Centralnic, Dyn or the many others who subdomain
or what they do - and encourage that if there is a top-down solution that
it not introduce burdens, walls. fees or gates where such innovation might
require blessing of the parent in some form.

We record changes the balance between these by maintaining two sections
within PSL, "Public" and "Private", respectively, as described above.

-Jothan

---

From: Jeffrey Walton <[email-masked]>
Date: Tue, 12 Apr 2016 18:16:36 -0400

On Tue, Apr 12, 2016 at 3:45 PM, Jothan Frakes <[email-masked]> wrote:
> are from the authorized source, and C] if a request comes from a third party
> - validating the request with the authorized source.  Having this done in
> the DNS zone would eliminate all three issues for us within the IANA chain.
>
> or what they do - and encourage that if there is a top-down solution that it
> not introduce burdens, walls. fees or gates where such innovation might

Thanks.

Forgive my ignorance, but has a centralized vs decentralized model
been decided upon?

Jeff

---

From: "John Levine" <[email-masked]>
Date: 12 Apr 2016 23:43:04 -0000

>Forgive my ignorance, but has a centralized vs decentralized model

No.  When you read the drafts, you should have noticed the part in
mine that said it'd work either for each domain publishing it's own
info, or for it all to be published under one domain name.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 15 Apr 2016 21:56:00 -0400

Hi,

> What are the requirements for the data source? I.e., does it have to

As others have pointed out, this has two meanings: mechanical "data
source" (i.e. DNS vs. some other way) and organizational "data source"
(i.e. who gets to assert the thing).

In terms of assurances that you have the answer that's actually as
authoritative as the DNS data generally, I think that the whole thing
ought to be anchored in the DNS, just because this is all an attempt
to link names in the DNS [1] with extra-DNS policies.  But there's no
reason that the data itself then needs to be there, though.  One (I
think unpublished) version of this idea early was to use a URI RRTYPE
to send people off to the policy document, which could say effectively
anything.  Many people reacted negatively because it was too
complicated.  Of course, that was maybe three years ago.  Given that
we've failed so far, maybe it doesn't look so complicated now.

[1] There is the possibility, of course, that this is all about domain
names that are _not_ in the DNS too.  See the recent arcing BoF.  In
that case, we should think differently.

> Forgive my ignorance, but has a centralized vs decentralized model

AFAICT, nobody's decided on anything, but I believe that the
centralised model is part of the problem.  We didn't get the massive
success of the DNS through centralisation.

A

-- 
Andrew Sullivan
[email-masked]