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

[Casey Deccio <[e-mail]>]

On Tue, Mar 24, 2015 at 4:00 PM, Jothan Frakes <[e-mail]> 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