Subject: Re: [Dbound] Status?

From: Suzanne Woolf <[email-masked]>
Date: Tue, 4 Nov 2014 09:09:33 -0500

Reviewing assorted things for IETF 91….

Has there been progress on the problem statement we discussed in Toronto?

I may have more time now than I did then for this work, and would like to pitch in.

best,
Suzanne

On Aug 23, 2014, at 12:52 AM, John R Levine <[email-masked]> wrote:

>> Would it be possible to offer a few use cases? It might help with
>> sorting out the different problems (and make sure the different
>> problems are properly represented). If a problem does not have a use
>> case, then it might not really be a problem ;)
> 
> We have plenty of use cases, and most of the problems are from existing applications.  There's a list of 11 of them in Casey's notes that Andrew sent out at the end of July.

---

From: Casey Deccio <[email-masked]>
Date: Tue, 4 Nov 2014 09:20:40 -0500

Hi Suzanne,

> I may have more time now than I did then for this work, and would like to
Progress was slower than I had anticipated in the last message that I sent
on the subject.  But, I have a draft problem statement, which I'll send out
shortly in another email.  I'm hoping to organize a bar BoF to discuss,
revise, and refine the draft problem statement.

Casey

---

From: Jothan Frakes <[email-masked]>
Date: Thu, 6 Nov 2014 20:09:39 -0800

I see the IANA TLD list as the alpha PSL or "patient zero" for things
that this DBOUND effort might enhance a structure around.  Anything that
extends details within that list is within scope.  Though that list is a
text file which perpetuates the hosts.txt issue, I refer to it more as a
resource than a file.

There is some review of "public suffix lists" like the IANA TLD list and
the Public Suffix List that is maintained by Mozilla under way, where there
is debate over the definition of "public"... in the context of "public
suffix list".

A) A list, such as the IANA TLD list or Mozilla PSL, which contains things
that behave as though they are a "TLD", which is accessible to the public

B) A region of public (root-down, trusted origination and administrative
realm) within a list of things that behave as though they are a "TLD",
followed by a region within that list that are self-nominated suffixes
after the defined top-down boundary.

It seems to me that dbound efforts work with definition a and b.  I have
heard robust energy that it might be "a" or "b".  I don't wish to constrain
the definition of public suffix list to those two either as there are
likely others, given the different angles we are looking at this through.

I do think that by leaving this aspect of the dialog undefined or loosely
defined, and working without a foundation, efforts to create any standards
may be challenging.  So far, I see different people putting forth great
ideas that work within their definition realm of "public suffix", yet some
of those great ideas stray into the realm of the obtuse when someone with a
slightly different definition looks at them from their point of view.

As pedantic as this sounds, I would encourage we think through and perhaps
identify a common vocabulary and definition of "Suffix".  Even if we define
them commonly within the role of the perspective (I.e. To a DNS
administrator, it means X, to law enforcement or anti-spam integrator it
means Y, to a software developer who is seeking to validate user input it
means Z, etc) I suspect this will aid the effort of the problem statement.

-jothan

On Tuesday, November 4, 2014, Casey Deccio <[email-masked]> wrote:

> Hi Suzanne,
>
> On Tue, Nov 4, 2014 at 9:09 AM, Suzanne Woolf <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>

-- 

Jothan Frakes
Tel: +1.206-355-0230

---

From: "John R Levine" <[email-masked]>
Date: 6 Nov 2014 23:21:29 -0500

> may be challenging.

Dunno if you've seen the notes, but the effort so far has primarily been 
focused on identifying the various applications for which people use the 
Mozilla PSL or something like it.  Then we can look at what semantics the 
applications need, how that does or doesn't match the various technical 
proposed approches, and we might be able to come up with a small set 
(ideally one, but don't count on it) that is broadly enough useful to be 
worth standardizing and implementing.

It's become clear that once you get much beyond "here is a TLD-like cut 
point" the semantics get rather difficult. For example, for some 
applications you want what I've called opt-in, assume two names are under 
different management unless you have a reason to believe they're the same, 
while for others you want opt-out, everything in a syntactic group of 
names (like a subtree) are under the same management unless you have a 
reason to believe they're different.  Then layer on top of that questions 
about whether people can make credible assertions on their own behalf, or 
whether you want to hear them from a third party (what the PSL is), what 
kind of distribution (batch download like the PSL or individual queries 
like the DNS?) and it gets messy fast.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 7 Nov 2014 16:01:08 +0000

On 11/6/14, 23:21, "John R Levine" <[email-masked]> wrote:

>Mozilla PSL or something like it.

Perhaps in there is a stumbling point.

We could attack this by looking at various applications that compare
properties of identifiers (one level up in abstraction over names).

We could attack this by looking at the way names are managed as domain
names, from DNS to PSL.

Combing the work to be applicationsŠus[ing]ŠPSL might be warping the
problem statement.  Whether by pulling in talk about the DNS and PSL
mechanics too soon or by inappropriately drawing a line around the use
cases needing a solution.

(Mostly a reaction to the ³the² in ³the effort² - as opposed to saying
that ³an effort so farŠ²)

Just throwing this out there.

---

From: Casey Deccio <[email-masked]>
Date: Fri, 7 Nov 2014 12:39:52 -0500

> Mozilla PSL or something like it.

The proposed problem statement focuses on identifying the nature of domain
name relationships, including the inherent characteristics of so-called
public suffixes, whose enumeration is the core functionality provided by
the PSL.  Identifying applications is a supporting component to give proper
perspective, motivation, and demand to the problem statement.

Best regards,
Casey

---

From: "John Levine" <[email-masked]>
Date: 7 Nov 2014 17:46:13 -0000

>properties of identifiers (one level up in abstraction over names).

The difficulty is straightforward: different applications have very
different needs. Deciding whether to issue a wildcard cert and finding
a policy record for DMARC both look for boundaries in the DNS, but the
issues are otherwise quite different.

It's hard to see how making things more abstract would help.

R's,
John