Subject: Re: [dbound] comments on draft-deccio-domain-name-relationships-00

From: Casey Deccio <[email-masked]>
Date: Mon, 6 Apr 2015 14:19:30 -0400

On Tue, Mar 24, 2015 at 4:00 PM, Jothan Frakes <[email-masked]> wrote:

> One observation that I have witnessed is that "Public / Private" has some
> different context, depending upon the reader, and the use and application
> of these terms.  I suspect that these contexts are blurring and confusing
> things a tad.
>
> There is a concept of those that have been delegated directly from
> IANA/ICANN, and those that jump in at some point within that which are not
> necessarily 'registries' (some are, some aren't) being Public and Private.
>

There was an attempt to describe the boundaries attached to these names
generically in the document as "first-level" and "lower-level"
boundaries--not to imply their differences or the impact of their
differences, but only to indicate that they existed.  Admittedly the model
needs tweaking to more accurately define these--from this standpoint.

> I think Casey and John have done a fair job of summarizing some of the
> contexts of Public/Private within Casey's draft, yet one thing that is
> possibly blurred between this and the IANA/ICANN direct relationships is
> the concept of administrative transition.
>
> I would not encourage that the PSL definitions of Public/Private sections
> or comments about entries from within the PSL .dat file be used as any
> frame of reference other than convenience.  The entries as submitted by
> respective administrators should be used for context of how these
> administrators wanted cookies to behave.  That's essentially it.  These are
> two separate things, regardless of where they are in the file.
>

There are two points to the document: historical context, including
description of the PSL and known current usage; and concepts for
identifying policy relationships between domain names.  It does not attempt
to endorse PSL use for one purpose or other, but it does speak of the
concepts (i.e., so-called "public"/"private" suffixes) introduced by the
PSL, as well a PSL-like registry to implement those concepts, as part of a
solution.  However, it explicitly mentions that neither the PSL nor a
PSL-like registry is sufficient for a complete solution to the problem.

> The cookie realm is different than the SSL Cert realm, is different from
> the email realm, is different than the _____ realm.
>
> Does the PSL get used for other things - absolutely.  And each potentially
> has its own concept of 'Public'/'Private'.
>

If there is a solution involving a PSL-like registry/oracle, then either
the registry must distinguish between uses, or it must be conservative
(e.g., default).  I personally think the latter is the right decision
(i.e., for something to fill the role of public/private registry, it should
be on a per-name basis).  The draft mentions other types of solutions
(e.g., per-name, in the DNS) that can be used to identify policy
relationships/boundaries more specifically.

> ...
The core focus of PSL is, from its origin, one of creating a solution to
> aid in securing cookies from bleeding out to the wrong places.  The
> derivative uses that have evolved since its creation have been amazing and
> very indicative of a need for solution space, such as search engines,
> browser 'omnibox' behavior, anti-spam, and the numerous development
> community.
>

 Agreed.

Candidly, (and I realize this additional and important color does not
> necessarily put these terms into clean buckets) the concept of
> public/private scope will absolutely change from circumstance of
> application/use and depend upon that scope - these are different in DNS
> than in EMAIL than in Cookies and varieties of Web activity.  Other
> examples of derivative uses include UX/UI (form validation being an
> example, wanting to exclude invalid entries), Security / Log Forensics
> (need to have a clear indicia of subdomain vs domain ownership breakpoints,
> to query a whois server, for example).  Each will have their own context
> and scope for 'public' or 'private'.
>

I don't believe that (that each will have their own context and scope for
public or private) is the case--if the scope is truly "public".  Neither am
I insinuating that the current PSL is 100% accurate based on the described
notion of public/private.

> I would encourage that where possible, there can be a scope included in
> DBOUND efforts which contextually identify the usage, akin to how MX vs A
> records work in DNS.
>

This is among the solution paradigms described in section 6.

> I'll repeat something that is frequently said within the community of
> developers who like myself help maintain the PSL, PSL exists only because
> nothing else did, and it is the least awful solution out there.
>

That might be true. But don't fault the concepts that have been brought to
light with the PSL because of the improper/overextended application of the
PSL.

In the context of our DBOUND efforts, there would be a grateful transition
> to something that does what it does or better, but it is likely that
> something that does not, shall not be attractive enough to the base of
> developers, libraries, and integrators to make the effort to pivot to
> something else.
>

The document considers at a high level per-domain name policy relationship
signaling, as well as supplementary (not stand-alone) registry based
solutions.  It attempts to be objective in identifying pros and cons of
these solution paradigms, without actually endorsing anything.

Regards,
Casey

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 6 Apr 2015 18:02:48 -0400

On Mon, Apr 06, 2015 at 02:19:30PM -0400, Casey Deccio wrote:

> solution.

I am not even a little bit convinced that the distinction is part of
any solution.  It seems to me that it is a distinction that obscures
at least as much as it clarifies, and it is the source of much
confusion.  I think outlining how we got the distinction and so on
might help for historical reasons, but I think the distinction will do
more harm than good in figuring out how to proceed.

> public or private) is the case--if the scope is truly "public".

But this is actually part of the problem: the so-called public
suffixes are often _not_ truly public, even though in many
circumstances we want to treat them as such.  If you need additional
gradations, then the public/private boundary starts to blur, and
pretty soon you have a bunch of different categories.

Best regards,

A
-- 
Andrew Sullivan
[email-masked]

---

From: Casey Deccio <[email-masked]>
Date: Mon, 6 Apr 2015 18:28:20 -0400

On Mon, Apr 6, 2015 at 6:02 PM, Andrew Sullivan <[email-masked]>
wrote:

> any solution.

Are you saying that there is no solution that can effectively use a
public/private distinction of names to determine whether or not there is
some sort of policy relationship between them?

Casey

---

From: Kurt Andersen <[email-masked]>
Date: Mon, 6 Apr 2015 15:33:50 -0700

> some sort of policy relationship between them?

I think that Andrew is saying, and I agree, that the names "public" and
"private" are not useful any more in the dbound discussions. They are badly
overloaded and, at best, vaguely defined. We would be better served to
start referring to "foo" names and "bar" names. But I think that
categorization in general is still a misdirection to the task of
identifying names which share policy scopes.

--Kurt

---

From: Gervase Markham <[email-masked]>
Date: Tue, 7 Apr 2015 10:16:06 +0100

On 06/04/15 19:19, Casey Deccio wrote:
> identifying policy relationships between domain names.  It does not
> attempt to endorse PSL use for one purpose or other, but it does speak
> of the concepts (i.e., so-called "public"/"private" suffixes) introduced
> by the PSL, as well a PSL-like registry to implement those concepts, as
> part of a solution.  However, it explicitly mentions that neither the
> PSL nor a PSL-like registry is sufficient for a complete solution to the
> problem.

When we split the PSL into two, various other use cases were floated,
but it was decided that the distinction we made was the one people most
commonly wanted to make, and would serve. But indeed, there may well be
use cases for which other distinctions would be better.

> Neither am I insinuating that the current PSL is 100% accurate based on
> the described notion of public/private.

Bug reports welcome :-) Although remember, we only add domains to the
PRIVATE section upon request of the domain owner, because we want to be
certain that the owner is aware of the ramifications of doing so. So
that list is necessarily incomplete, in that it does not contain all
privately-held domains which issue subdomains to mutually-untrusting
parties.

Gerv

---

From: Casey Deccio <[email-masked]>
Date: Tue, 7 Apr 2015 09:42:25 -0400

On Mon, Apr 6, 2015 at 6:33 PM, Kurt Andersen <[email-masked]> wrote:

> overloaded and, at best, vaguely defined.
>

I think you'll find that the terminology used in the draft being discussed
is consistent with descriptions within RFCs that use the terms (see RFC
6265 and RFC 7489, for example).

By overloaded, are you mostly referring to the "split" in the PSL that has
been noted by several individuals (i.e., the sections labeled "ICANN
DOMAINS" vs. "PRIVATE DOMAINS" in the file)?  Or do you mean something
else?  The draft makes an attempt to model the two sections of names--to
consider their conceptual merit.  But it (the draft) doesn't refer to them
in the same way the PSL does (i.e., by "ICANN DOMAINS" and "PRIVATE
DOMAINS").  Perhaps it could be more explicit in referencing those sections.

Among the solution considerations in Section 6 is the creation of a scope
definition resource (i.e., a PSL-like registry) to supplement a per-name
based solution.  While not explicitly stated in the draft, my personal
feeling is that the section of names that is under the section "PRIVATE
DOMAINS" (or "lower-level" public names, as denoted in the draft) should
*not* be candidates for such a registry.  Though that is not explicitly
noted in the draft.

Regarding "public" and "private" not being useful, I disagree.  See
Sections 3 and 6 in the -00 draft.

We would be better served to start referring to "foo" names and "bar" names.

I'm not sure that makes any sense.

> But I think that categorization in general is still a misdirection to the
> task of identifying names which share policy scopes.
>

There seems to be a lot of hang-up on the use of the terms "public" and
"private" in the draft.  I can't help but feel that some of this results
from an effort to distance ourselves from current "makeshift" notions and
solutions.  However, please don't throw out the baby with the bathwater.
While there is a general feeling that the existing solutions are misused
and inadequate, there is value in the concepts that they have introduced.
The draft at hand is not meant to be a solution, but rather presents a
picture of current notions for considerations for solutions, which current
notions include implementation (PSL) and specification (RFCs).
Understanding the starting point does not imply constraint by that starting
point.

That being said, the on-list discussions on this topic/draft can only be
contextually accurate if participants have read the -00 draft at hand, so
this is a general (i.e., not directed) request to read it if you haven't.

Regards,
Casey

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 7 Apr 2015 10:47:27 -0400

> some sort of policy relationship between them?

I'm saying that the categories are either too generic not to need
subclassing (in which case they're inadequate to our needs) or else we
will solve the wrong problem (in which case, they're inadequate to our
needs).

A

-- 
Andrew Sullivan
[email-masked]

---

From: Casey Deccio <[email-masked]>
Date: Tue, 7 Apr 2015 10:59:31 -0400

Hi Andrew,

> will solve the wrong problem (in which case, they're inadequate to our

Thanks for the clarification.  Please understand that the public/private
scope delineation discussed in the draft does not imply that it is a
solution; it is a conceptual notion from which a solution component might
be based (and by component, I mean does not stand alone).  Nor does the
draft intend to equate scope with policy.  Please don't dismiss the notion
or the language on that basis.  Sections 3 and 6 respectively discuss the
utility of scope knowledge and the high-level solution considerations,
which might be a composite set.

Casey