Subject: [Dbound] Draft problem statement and IETF "bar BoF"

From: Casey Deccio <[email-masked]>
Date: Tue, 4 Nov 2014 10:42:23 -0500

All,

Please find attached a draft DBOUND problem statement, resulting from the
action items taken at the bar BoF in Toronto on the same subject.  Please
take a read and comment on the document.  There is probably a better format
for this, but it's a start for now...

Also, if there's interest in a follow-up "bar BoF" (i.e., "unofficial"
meeting on the subject) in Honolulu, I'm happy to help organize one.  I am
proposing such a meeting during the Thurs morning session, with alternate
times being Wed afternoon II and Thurs afternoon III.  If there are enough
BoF-interested parties that can't make Thurs morning, we can have a doodle
poll to solidify a time.

In summary:
- Please read the draft problem statement (attached)
- Is there some interest in a DBOUND bar BoF?
- Are there Thurs morning conflicts with a DBOUND bar BoF?

Thanks,
Casey

---

From: Casey Deccio <[email-masked]>
Date: Tue, 4 Nov 2014 12:00:46 -0500

> - Are there Thurs morning conflicts with a DBOUND bar BoF?
Update: There was a venue conflict with the Thursday time, so I'm proposing
Tuesday morning in its place.

Thanks,
Casey

---

From: Gervase Markham <[email-masked]>
Date: Tue, 04 Nov 2014 17:55:48 +0000

On 04/11/14 15:42, Casey Deccio wrote:
> Please find attached a draft DBOUND problem statement, resulting from
> the action items taken at the bar BoF in Toronto on the same subject. 
> Please take a read and comment on the document.  There is probably a
> better format for this, but it's a start for now...

Here are some comments:

* Your "Contrived PSL Entries" table is a little sub-optimal, in that
one would never see those first two entries in the same PSL.

example:   example is public
*.example: All children of example are public

The first of these rules suggests that foo.example is private, the
second that it is public. Your Table 2 is therefore wrong, because the
PSL algorithm states that the longest matching rule applies, and so
foo.example is public, not private (by the second rule).
https://publicsuffix.org/list/ has the algorithm.

Perhaps the rules are intended to stand as 3 standalone examples, but
that's not clear from the presentation.

* "When an SSL certificate is for a wildcard domain, the entire range of
names covered by the wildcard needs to be under the same control."

It's not as simple as that. Google is allowed a cert for *.blogspot.com,
but by your definitions, foo.blogspot.com and bar.blogspot.com are not
under the same control. This is why the PSL is split into two sections -
"ICANN DOMAINS" and "PRIVATE DOMAINS". (Naming is hard.)

I think that this issue, which is separate from the one in the paragraph
immediately above it, needs a little more elaboration.

* The PSL was originally concieved by Mozilla community members, but is
positioned as a project for the benefit of the whole internet. The fact
that the canonical copy lives in the Firefox source code is an accident
of history, and something we are trying to change:
https://bugzilla.mozilla.org/show_bug.cgi?id=991749

* "The issue of determining relationships between domains that are
lineally connected (i.e., one is an ancestor of another) and within the
same public/private scope is not addressed by the PSL"

Actually, I think it is. If a fictional PSL had:

example
foo.bar.example

Then you would have example being public, bar.example being private, and
foo.bar.example being public. Or is that not what the quoted sentence is
saying?

Gerv

---

From: Jeffrey Walton <[email-masked]>
Date: Tue, 4 Nov 2014 13:19:36 -0500

> for this, but it's a start for now...
Thanks for moving this forward.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 4 Nov 2014 19:47:36 +0000

Thanks for writing this up. Now for the complaints. ;)

You lost me at the first sentence of 1.1.1.  (Saying that more
dramatically than I mean to.)

I don’t have a complete response to the paper.  In the spirit that
provoking thoughts is better than not at this point, here are some:

Fragment 1

I once believed that domain names were “dot-separated alphanumeric words”
but learned otherwise while working on the so-labeled clarifications on
wild cards.  In order to being to understand how the DNS organism is
architected, one has to view this as a tree.  And, ironically as I deal
increasingly with non-ASCII identifiers, there’s no dot "on the wire.”
(The root zone isn’t ‘.’, it’s a zero-valued byte.)

In section 1.1.2 an overly simplified view is given.  Not all domains fit
neatly into the public and private bucket.  Some top-level-domains are not
delegation only.

>From these two comments my mind leads instantly into recommending that
this paper attempt to describe the problem from two very different
viewpoints.

>From the “system-to-be-messed-with” viewpoint, the nature of the DNS data
model as being first based on a tree structure must be respected as well
as a clear description of the management model based on the units of
zones.  The DNS protocol permits management of resource record sets,
domain (nodes) as well as zones but does not permit management of a domain
(subtree).  (By the latter, I mean that DNS does not manage ‘across' a
zone cut.)

>From the “people-having-a-problem-to-solve” viewpoint, which you get to in
1.1.3 and 1.1.4, I prefer replacing “related” with “equivalent” for a
specific purpose.  (I’ve said that before, no need to belabor it now.)
For one, you talk about a parent/child relationship but there’s really no
such thing as that.  A parent delegates the child, the child knows nothing
about it’s parent - there’s no “relationship” as far as the DNS protocol
is concerned.

Without giving this much thought, cross-domain relationships have been
historically significant, more so in operations than in the protocol.  The
co-mingling of dotCom and dotNet bear this out.

I’m concerned about the problem set-up because, your chances of solving
the problem are better if you’ve properly set up the problem.

Fragment 2

What’s missing from the PSL is a discussion of the registry behind the
PSL.  Looking strictly at the list of entries and concluding we just need
to make that work better is like saying a domain name registry is just a
DNS operator.  I.e., how can you trust that the entries are legitimate?

Fragment 3

This is not related directly to the document, but comes from “Centralized
vs. Distributed…”  One of the issues to think of is - how do we avoid
shared fate when we are looking for a new angle?  I.e., the DNS
distribution model is great for doing just what the PSL wants, but placing
the PSL into the DNS is not helping.  Grossly arguing this way - if we
expect someone to try to register a child and use it to fool people using
the parent, what’s to stop the child from giving out fraudulent
information?  (This is a handwaving argument for why
what-ever-replaces-PSL should have some kind of separation from the DNS.)

On the one hand, following the DNS tree is the best way to track who knows
where the boundaries are.  On the other hand, that’s just the DNS
perspective talking.  And with only one source working here, we aren’t
making corrupting the system any harder than doing nothing at all.

(I’m assuming that all of this is rooted in a security concern related to
the authorization of some information to be applied/accessed/etc.
Therefore, the talk about corrupting, fooling, fraudulent...)

Fragment 4

It’s possible that here are multiple goals here, with a common theme not
clearly defined.  I see a desire to express the policies for a zone (not a
domain) from the registry to a relying party.  This is one use case, not
the only, but one use case.  This is also expressed in a DNS viewpoint.

The relying party applications I can’t speak as well for.

Fragment 5

I’m concerned about the mention of the gTLDs as being either “too much
detail” or “not enough detail.”  The “new class” of TLDs is only special
in two respects - the rapidity that they appear and that they share a set
of operating principles.  If by grouping them you default to grouping
ccTLDs and legacy gTLDs, you haven’t made a useful categorization.  Until
we know what criteria we will use to divide the top-level domains, we
should hold off on this.

-----Original Message-----
From: Casey Deccio <[email-masked]>
Date: Tuesday, November 4, 2014 at 10:42
To: "[email-masked]" <[email-masked]>
Subject: [Dbound] Draft problem statement and IETF "bar BoF"

>take a read and comment on the document.  There is probably a better
>format for this, but it's a start for now...
>
>
>meeting on the subject) in Honolulu, I'm happy to help organize one.  I
>am proposing such a meeting during the Thurs morning session, with
>alternate times being Wed afternoon II and Thurs
> afternoon III.  If there are enough BoF-interested parties that can't
>make Thurs morning, we can have a doodle poll to solidify a time.
>
>
>In summary:
>

---

From: Casey Deccio <[email-masked]>
Date: Tue, 4 Nov 2014 14:57:29 -0500

Hi Gerv,

Thanks for the feedback.

> *.example: All children of example are public
The goal was for a simple demonstration of how it works, with minimal
entries, but I can understand how the non-matching entry makes this a less
effective example.  I'll make some changes.  Thanks for the feedback.

Of course, future modifications make some of the remarks below moot, but
just to be sure we're on the same page...

> second that it is public

Well, technically the first rule only indicates the example is public.
Whether or not foo.example is effectively private depends on the complete
algorithm, not the stand-alone entry, correct?

> Your Table 2 is therefore wrong, because the

But there is a wildcard exception !foo.example (the third line), and the
algorithm explicitly gives precedence to exceptions.  Doesn't that mean the
third entry (!foo.example) wins?

In fact, I see this example on the public suffix site:
-----
*.tokyo.jp
!metro.tokyo.jp

Cookies *may* be set for foo.bar.tokyo.jp.
Cookies *may not* be set for bar.tokyo.jp.
Cookies *may* be set for metro.tokyo.jp, because the exception overrides
the previous rule.
-----

I read this more generically as:
-----
*.tokyo.jp
!metro.tokyo.jp

foo.bar.tokyo.jp is private
bar.tokyo.jp is public
metro.tokyo.jp is private
-----

Isn't that the same as the following?
-----
*.example
!foo.example

baz.bar.example is private
bar.example is public
foo.example is private
-----

> that's not clear from the presentation.

I'll make the examples more clear.  Thanks for the suggestions.

> "ICANN DOMAINS" and "PRIVATE DOMAINS". (Naming is hard.)
In the document I've defined the terms more generically.  If I understand
correctly, "ICANN DOMAINS" translates to what are referred to in the
document as "public domains in unbroken public scope", and "PRIVATE
DOMAINS" translates to names "under islands of private scope" (referred to
in the third paragraph of Section 3 and opening paragraph of Section 4).
In the former case, each name in the ancestry is of public scope through
the public boundary in question.  In the latter case, there are one or more
names of private scope prior to the public boundary in question.  There are
probably shorter/better terms for this.

> immediately above it, needs a little more elaboration.
In the document I think you're suggesting that I note that (at least in the
case of the SSL wildcard) the different types of public domains might be
treated differently.

> https://bugzilla.mozilla.org/show_bug.cgi?id=991749
And I think the list a great contribution.  Thanks!

Thanks also for the pointer to the bug reports.  I was unaware of the
efforts.

> foo.bar.example being public. Or is that not what the quoted sentence is

The sentence is a bit cryptic.  But what it means is the following.  Given
the following two domains, both "private" as far as PSL processing is
concerned:

sub.foo.example
foo.example

Are the two "related"?  The PSL cannot tell us.  It can only tell us
(assuming entries are correct) that there is no public/private boundary
between them.

Casey

---

From: Casey Deccio <[email-masked]>
Date: Tue, 4 Nov 2014 16:18:03 -0500

Hi Ed,

> Thanks for writing this up. Now for the complaints. ;)
:)

> (The root zone isn’t ‘.’, it’s a zero-valued byte.)

Good point.  The introduction in this document was to provide consistent
terminology sufficient to derive a model for understanding relationships
between domain names.  There is no talk of wire format, nor is there a need
to go into those semantics, as this is all about namespace.  The
representation in this document is dot-separated labels. :)

> neatly into the public and private bucket.  Some top-level-domains are not
For clarity, are you saying that for a single domain being public and
private are not mutually exclusive, or are you saying that top-level
domains are not all public?  I agree with the latter statement, and I'm
glad to offer more clarity in the document if it is misleading in this
regard.

> (subtree).  (By the latter, I mean that DNS does not manage ‘across' a

This is a valid point.  In this document I deliberately left zone cuts out
of the definitions.  The focus was on the problem of associating
namespaces, independent of zones.  Zone cut identification might be one of
the solutions considered, but even public/private boundaries need not map
consistently with zone cuts (in either direction), so the problem is about
namespace.

> about it’s parent - there’s no “relationship” as far as the DNS protocol

Yes - but let's be clear that I'm establishing terminology for discussion
of namespace (not DNS protocol) for the purposes of this document.

> the problem are better if you’ve properly set up the problem.

Agreed.

> DNS operator. I.e., how can you trust that the entries are legitimate?

I can't tell if this is a general comment or something specific to the
document.  The problem statement document is not intended to assess the
content of the PSL--except to indicate the application of the model
described in previous sections in the paper (e.g., third paragraph of
section 3).  The intent of the document is to define the problem and
identify existing solutions.  I make no conclusions.  The question about
the effectiveness of the PSL is partially addressed with the second bullet
under "problem statement" in section 4.

> Therefore, the talk about corrupting, fooling, fraudulent...)
The scope of the problem statement is just that--a statement of the
problem.  These are valid considerations for solutions to the problem, once
the problem has been identified and defined.

> we know what criteria we will use to divide the top-level domains, we
It is admittedly brief and can be fleshed out, if it needs clarity.  The
intent was not to give a discourse on the new gTLDs or to make a grouping
or categorization, but simply recognize that as gTLDs: 1) they fall into
the "unbroken public scope from the TLD" category and thus are pertinent to
the discussion of the problem (and solutions, including the PSL); 2) the
total number of gTLDs has (and will continue to) increased dramatically
with the delegation of the new gTLDs; and 3) their policies vary, just as
with previous gTLDs.  There are thus open questions of both complexity and
scalability that should be considered as the problem is defined and
solutions identified.

Cheers,
Casey

---

From: "John Levine" <[email-masked]>
Date: 5 Nov 2014 04:44:33 -0000

>Tuesday morning in its place.

I could do Tuesday morning.

R's,
John

---

From: Gervase Markham <[email-masked]>
Date: Wed, 05 Nov 2014 10:22:43 +0000

On 04/11/14 19:57, Casey Deccio wrote:
> Whether or not foo.example is effectively private depends on the
> complete algorithm, not the stand-alone entry, correct?

The PSL is both a list an an algorithm for interpreting it. One makes no
sense without the other. (People may choose to use alternative
algorithms, but they are entirely responsible for the results!)

Aargh! Clash of use of "foo"! I forgot the third example used foo.

Let me rewrite my comment:

The first of these rules suggests that fred.example is private, the
second that it is public.

Your Table 2 is therefore wrong, because the
PSL algorithm states that the longest matching rule applies, and so
fred.example is public, not private (by the second rule).
https://publicsuffix.org/list/ has the algorithm.

Does that make more sense?

My point is a clash between the first and second examples; I didn't
intend to drag the third one in.

>     It's not as simple as that. Google is allowed a cert for
>     *.blogspot.com <http://blogspot.com>,
>     but by your definitions, foo.blogspot.com <http://foo.blogspot.com>
>     and bar.blogspot.com <http://bar.blogspot.com> are not
> In the document I've defined the terms more generically.  If I
> understand correctly, "ICANN DOMAINS" translates to what are referred to
> in the document as "public domains in unbroken public scope", and
> "PRIVATE DOMAINS" translates to names "under islands of private scope"
> (referred to in the third paragraph of Section 3 and opening paragraph
> of Section 4). 

Ah, yes. I guess my point then is that this section doesn't seem to take
account of that distinction?

> In the document I think you're suggesting that I note that (at least in
> the case of the SSL wildcard) the different types of public domains
> might be treated differently.

Yes.

> The sentence is a bit cryptic.  But what it means is the following. 
> Given the following two domains, both "private" as far as PSL processing
> is concerned:
> 
> sub.foo.example
> foo.example
> 

I guess the hierarchical understanding of "related" is somewhat implicit
in the way the PSL works and the defined algorithm... but yes, I guess
the PSL does not have an isRelated() call.

Gerv

---

From: Edward Lewis <[email-masked]>
Date: Wed, 5 Nov 2014 14:21:49 +0000

Instead of being specific, I’ll offer a general set of comments.  I think
Casey and John have captured the state of the group, no argument with
that, so my observations are about where we are and not the specifics in
the paper.

Perhaps a mistake we are making is talking (so much) about the DNS
perspective.  Coming from the remark that zone cuts were avoided because
we are ruling out zone cut identification as a goal: first, I agree this
isn’t about zone cut identification.  But once we start analyzing the DNS
side of this, we need to be accurate and faithful to the DNS architecture
or we will screw this up - as in how one application screwed up an
understanding of how DNS wild cards work resulting in a mismatch in what
‘match’ means.  (I should cite the specific instance, it has been
mentioned on the list, but I just can’t find it now.)  That said, I’d
rather see the group “ignore” the DNS for the moment and concentrate on
what “service” needs to be defined.

I’m willing to go as far as recognizing that there are identifiers in play
represented as domain names.  Beyond that, such as the fact that they are
hierarchical and rendered in a format that makes them look more like a
route than a name, isn’t that important.  In fact I think the paper spends
a lot of words describing this and then saying this isn’t what is
important.  IMHO, it comes to taking two identifiers (represented as
domain names) and deciding if, for some operation they are to be
considered the same/treated equally, or (I’ll say it again) equivalent.

The material related to PSL falls into the same boat.  The PSL is a first
stab at solving some part of the still somewhat hazy problem.  It is the
crutch used to handle the first use case - the so-called cookies problem,
better known (again, in my opinion) as the common origin problem.  The PSL
and the DNS here are more “lay of the land” than part of the problem
statement.  These are two things we have to work with, like unfinished and
unset modeling clay.

Because of that, take my comments before with a grain of salt.  Perhaps we
need to go up a level and not down a level (as I was drilling into).

But on to the discussion of whether upper level domains are exculsive-or
public or private.  The problem I have is that in making such a divide (or
any exclusive-or divide) if there are corner cases you’ll pay for it
later.  I’m not sold that one can cleanly divide the domains, if so,
whether it is meaningful - and I wretch in my seat because these are
really zones, not domains.  E.g., dotUS is a mix of delegations and data.
Perhaps you can call US public (for the most part it is), but it has some
private elements.  And E.g., compare how dotUK has been run (until the
recent policy change) versus CO.UK.  dotUK is essentially private (and
signed with NSEC to boot) but CO.UK. would be public.

I guess what I’m saying is that I’m not so clear on why we are labeling
domains as public or private.

Looking forward to getting to a problem statement.  And I do believe that
there may be more than one problem to solve, which is why we seem to be
going (if that can be said) in circles.

-----Original Message-----
From: Casey Deccio <[email-masked]>
Date: Tuesday, November 4, 2014 at 16:18
To: Edward Lewis <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"

>between domain names.  There is no talk of wire format, nor is there a
>need to go into those semantics, as
> this is all about namespace.  The representation in this document is
>dot-separated labels. :)
> 
>
>
>
>glad to offer more clarity in the document
> if it is misleading in this regard.
>
> 
>
>This is a valid point.  In this document I deliberately left zone cuts
>out of the definitions.  The focus was on the problem of associating
>namespaces, independent of zones.  Zone cut identification might be one
>of the solutions considered, but even public/private
> boundaries need not map consistently with zone cuts (in either
>direction), so the problem is about namespace.
>
>
>
>
>described in previous sections in the paper (e.g.,
> third paragraph of section 3).  The intent of the document is to define
>the problem and identify existing solutions.  I make no conclusions.  The
>question about the effectiveness of the PSL is partially addressed with
>the second bullet under "problem statement"
> in section 4.
>
>
>
>
>Fragment 3
>
>problem.  These are valid considerations for solutions to the problem,
>once the problem has been identified and defined.
>
> 
>
>Fragment 4
>
>the "unbroken public scope from
> the TLD" category and thus are pertinent to the discussion of the
>problem (and solutions, including the PSL); 2) the total number of gTLDs
>has (and will continue to) increased dramatically with the delegation of
>the new gTLDs; and 3) their policies vary, just
> as with previous gTLDs.  There are thus open questions of both
>complexity and scalability that should be considered as the problem is
>defined and solutions identified.
>
>
>Cheers,
>
>Casey
>
>
>
>
>

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Nov 2014 09:36:30 -0500

> domains as public or private.

Your concern is precisely why, in my previous stabs at this, I have
attempted to avoid that.  It's the wrong classification, IMO, even if
it's a useful rule of thumb sometimes; and too much confusion has
resulted from trying to use it.

Instead, we should be looking for a way of grouping identifiers
according to other classifications.  The motivating stuff in the
earlier I-Ds I wrote or worked on with Jeff is there to explain why
the DNS hierarchy is _not_ the right classification, despite the
attempts in the past to use it.  

Unfortunately, to my way of thinking, people who have running code
that is already based on the faulty reading of the hierarchy are
unlikely to change that enough to work with new arbitrary groupings.
Moreover, there's the additional problem that allowing arbitrary links
out of hierarchy will potentially explode the data that clients have
to pay attention to, and nobody is enthusiastic about that.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Casey Deccio <[email-masked]>
Date: Wed, 5 Nov 2014 09:40:04 -0500

Hi Gerv,

> algorithms, but they are entirely responsible for the results!)
I completely agree.

:)

> The first of these rules suggests that fred.example is private,

To your previous point that the list and the algorithm make no sense
without each other, the inference that "fred.example" is private cannot be
made from the single list entry; according to the algorithm, the name in
question must be matched against all rules, and "the prevailing rule is the
one with the most labels" [1].  In other words, "fred.example" does not
ultimately match "example", but rather "*.example".  Thus it is (only)
considered public.

> the second that it is public.
>

> https://publicsuffix.org/list/ has the algorithm.
While "fred.example" isn't an example from the document, "bar.example" has
the same properties as "fred.example" would (i.e., they both match the
wildcard) and "bar.example" is in the table, having public scope, as you
and I would expect.  I'm not sure, therefore, how Table 2 is wrong.

> intend to drag the third one in.

I'm wondering if that is the confusion with the most recent point as well.
Is it possible that you were looking at the entry "foo.example" in Table 2
and forgetting that it matched the wildcard exception (i.e., was not in the
same category as "fred.example" and "bar.example"), just as the wildcard
exception for "foo.example" was overlooked when you contrived your own
example (and they ultimately clashed)?

On a related point, there was some question as to whether entries for
"example" and "*.example" were both useful in the list.  You indicated that
they were not (and I can see that is the case in the current PSL, both by
entries and by testing), and my initial response was agreement.  However,
it is not clear to me from the specified algorithm that "*.example" implies
"example".  If that implication is intentional, then it seems inconsistent
with the specification as I read it: "The wildcard character * (asterisk)
matches any valid sequence of characters in a hostname part" and "Wildcards
may only be used to wildcard an entire level" [1].

Whether or not the implication is intended, it might be useful to allow the
names to be considered separately--because of the question of whether the
name (i.e., the "parent" of the wildcard) itself is public or private,
which is distinct from whether a name matching the wildcard is public.

> account of that distinction?
Okay, I'll clarify.

> the PSL does not have an isRelated() call.

It might seem as though nits are being picked here, but the idea behind the
problem statement is to understand the abilities and limitations of

[1] https://publicsuffix.org/list/

---

From: Edward Lewis <[email-masked]>
Date: Wed, 5 Nov 2014 14:51:59 +0000

As a historical note:

-----Original Message-----
From: Andrew Sullivan <[email-masked]>
Date: Wednesday, November 5, 2014 at 9:36
To: "[email-masked]" <[email-masked]>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"

>to pay attention to, and nobody is enthusiastic about that.

Which is why (section 2.7 of) RFC 3008 was written as an update to RFC
2535.

I.e., we designed the DNSSEC signatures to follow “arbitrary links out of
the hierarchy”. Despite some research into that, we couldn’t make it
happen.  We couldn’t, for one, come up with a workable language to express
a policy of who can sign for what.  I.e., we couldn’t come up with a way
to say that two owners of KEY sets were equivalent when it came to
establishing trust in the signature.

---

From: Casey Deccio <[email-masked]>
Date: Wed, 5 Nov 2014 10:25:11 -0500

On Wed, Nov 5, 2014 at 9:21 AM, Edward Lewis <[email-masked]> wrote:

> later.

Perhaps.  The intent of the problem statement was to lay out a model for
understanding domain relationships, including public/private boundaries.
The boundaries already exist.  That's not new, nor is it a solution: it's
simply the way it is right now.  Whether or not those are (or can be)
accurately captured (that is, including corner cases) with the PSL or
anything else for that matter is yet to be determined/evaluated.  That's
why it is mentioned in the problem statement (first bullet under "problem
statement" Section 4).

"Paying for it" also depends on the application consuming the solution.
There have been some issues over the years with the PSL (you can browse the
bug reports for examples), but there are different consequences for being
"more specific" than "less specific" for example, and even those differ
depending on whether the application is cookies, DMARC, etc.

  I’m not sold that one can cleanly divide the domains, if so,
> really zones, not domains.

I can recommend alternative seating.  :)

> E.g., dotUS is a mix of delegations and data.
> private elements.

Hmm, this is exactly why we *are* talking about domains and not zones.  And
the model covers such mixes (as does the PSL--see the entries), completely
independent of zone cuts.

> And E.g., compare how dotUK has been run (until the

If you haven't had a chance to look at the current contents of the PSL, I
invite you to take a look.  It contains examples applying the model
described in the problem statement document.  There are even (gasp!)
comments and references.

> domains as public or private.

As I mentioned, much of the problem statement is intended to cover
background, terminology, and current state.  The actual (proposed) "problem
statement" is in Section 4.

> going (if that can be said) in circles.

Yep.  That's part of the reason I've tried to break things down.  Some of
the solutions that have been proposed--pre-problem statement--have had the
feel of solving the entire problem of domain relationships (or boundaries)
with a single blow.  Without having a finer grained understanding of the
problems (which may or may not be compounded) it is difficult to assess the
net effectiveness of those solutions.

Casey

---

From: Casey Deccio <[email-masked]>
Date: Wed, 5 Nov 2014 10:58:39 -0500

Hi Andrew,

> resulted from trying to use it.

Since we're laying out the problem statement, any clarification on "too
much confusion has resulted..." is welcome.  I assume you're referring to
the PSL, but do you mean confusion related to the transparency of list
modification, clarity of the algorithm specification, or resulting from
mishaps (e.g., k12.hi.us)? How do you quantify "too much"?  What is the
demand for identifying domain relationships, other than what the PSL
provides (public/private boundaries)?  I don't doubt that there is such
demand (and some of it has already been identified), but that is what needs
to be brought to the forefront as part of the problem statement.

> attempts in the past to use it.

Perhaps--but that is in line with solution consideration, not problem
identification.  I don't think there is a question about whether or not
there so-called public/private boundaries currently exist in the domain
space.  To me, the questions are in understanding the consuming
applications for domain relationships and using their properties (e.g.,
domain ancestry, public/private boundaries) to determine how to most
effectively meet the current and future demand for domain relationships,
all things considered.

> to pay attention to, and nobody is enthusiastic about that.

Those are both considerations (though not constraints, per se) that need to
be made when designing and evaluating solutions.

Cheers,
Casey

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Nov 2014 11:36:27 -0500

On Wed, Nov 05, 2014 at 10:58:39AM -0500, Casey Deccio wrote:

> space.

Actually, this is to me precisely the question.  I have been arguing
that the public/private distinction is actually a miscategorization of
the problem.  It's a good rule of thumb in lots of cases, but the
corners where the distinction breaks down are instructive.

For instance, some universities have delegated name spaces to
departments.  Is this a public registry, or a private one?  Well,
neither, exactly.  In some sense, this is a delegation across
organization boundaries, and the policies in one are most assuredly
not the policies in another.  In some other sense, they're all part of
the same legal entity.  Similarly, I really don't think it is a good
thing if information leaks between different government departments,
yet in some sense everything under gc.ca is in the same organization.
Or anyway, Stephen Harper wishes it were.

These cases show that the public/private distinction is not actually
clean enough.  

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 5 Nov 2014 16:51:02 -0000

>there so-called public/private boundaries currently exist ...

There are certainly boundaries, but they're not necessarily
public/private.  For example, uk.com sells subdomains like foo.uk.com.
So the boundary between com and bigbank.com is public/private while
that between com and uk.com is, uh, public/public or maybe something
else.

For me the goal has been to mark groups of names under the same
control (for some suitably vague definition of "same".)  In this
example, com is one group, uk.com is a second, and foo.uk.com and its
subdomains are a third.  I don't see any benefit in labelling a group
as public or private.  This grouping idea also allows us to avoid
for the moment deciding whether we want to group kitty.cat and kítty.cat.

R's,
John

---

From: Jeffrey Walton <[email-masked]>
Date: Wed, 5 Nov 2014 12:15:04 -0500

> that between com and uk.com is, uh, public/public or maybe something
+1

I'm interested in two boundaries. First, where are the gTLDs and
ccTLDs so I can perform a pre-flight check. Second, where are the
administrative boundaries for a non-TLD that might need to be checked
online.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Nov 2014 12:19:08 -0500

On Wed, Nov 05, 2014 at 12:15:04PM -0500, Jeffrey Walton wrote:
> ccTLDs so I can perform a pre-flight check.

I'd be interested to know what knowing those gains you.  (And is it
that you want to know which are g and which cc, or just all the TLDs?)

> Second, where are the

This is the one that I've been arguing for.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Jeffrey Walton <[email-masked]>
Date: Wed, 5 Nov 2014 12:48:02 -0500

> that you want to know which are g and which cc, or just all the TLDs?)

It saves a network call. I'm less worried about the 1RTT, and more
worried about a potential failure that I have to handle. If I don't
need to make the network call, then I don't have to worry about
handling the failure.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Nov 2014 12:59:10 -0500

> need to make the network call, then I don't have to worry about

Wouldn't it be better, in that case, to have a general cache about
boundaries, with information about how stale it is likely to be?  That
is, it's not TLDs you want, but attestations from zones that they let
anyone register within them, right?  For these purposes, there's no
difference between "com" and "dyndns.org", I think.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Wed, 5 Nov 2014 18:02:38 +0000

-----Original Message-----
From: Jeffrey Walton <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Date: Wednesday, November 5, 2014 at 12:48
To: Andrew Sullivan <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Dbound] Draft problem statement and IETF "bar BoF"

>need to make the network call, then I don't have to worry about

Like Andrew, I had the same question.  Your answer still leaves me
wondering.

I don’t mean to lead the witness, but what do you mean by a 'network
call’?  If this relates to what happens in something planning to iterate
through the DNS, could you describe further?  A caching element wouldn’t
care so much because it’ll look to find, if not the answer, the nearest
cut point it has and launch from there, regardless whether it is a TLD or
not.  If this is an application doing DNS queries without fully
implementing DNS (caching), well, that’d be interesting to know.

I’m taking 'network call' as a system call that causes a IP traffic to
flow, perhaps via a stub resolver (which by definition doesn’t iterate),
or perhaps via something else...

---

From: Casey Deccio <[email-masked]>
Date: Wed, 5 Nov 2014 13:29:31 -0500

> corners where the distinction breaks down are instructive.

My feeling is that the problems with miscategorization are often because
this categorization is the *only* one that has been used predominantly
(outside of simple ancestral relationships), not because there aren't such
things as public/private boundaries.

Or... The misuse of a hammer does not mean that we need to reevaluate
whether striking it on nails is appropriate.  Rather, it means that we need
to reevaluate the uses of the hammer and the goals that we are trying to
accomplish with it.

> These cases show that the public/private distinction is not actually

The draft problem statement document distributed to the list describes
public/private boundaries as only one property of domains.  It also
considers (for example) intra-scope relationships, and provides an example
nearly identical to the one you provided above (see section 1.1.4).

I am not arguing that public/private boundaries are *the* way to solve
things, nor am I suggesting that the definition of "public" is sufficiently
clear, as currently defined.  But to me there there is an apparent
distinction between a delegation from, say, "org" to "foo.org" and a
delegation from "foo.edu" to "cs.foo.edu".  In the proposal that would be
the difference between "public -> private" and "private -> private".
Inferring more than that is currently undefined and is referred to in the
third bullet of the problem statement (section 4).

Cheers,
Casey

---

From: Casey Deccio <[email-masked]>
Date: Wed, 5 Nov 2014 13:49:19 -0500

On Wed, Nov 5, 2014 at 11:51 AM, John Levine <[email-masked]> wrote:

> public/private.

I believe the current PSL (regardless of limitations) is a testament that
public/private boundaries exist, at least in some fashion.

For example, uk.com sells subdomains like foo.uk.com.
> that between com and uk.com is, uh, public/public or maybe something
Two names "uk.com" and "com" (as described in the proposed problem
statement document) would be considered intra-scope, i.e., two public
names, with no boundary.

> as public or private.

The benefit, as I see it, is the following.  If we can identify the use
cases for domain relationships, and we find that 99% of the use cases--or,
perhaps more importantly, 99% of demand--falls under category A, with the
balance falling under category B, does it make sense to find a more complex
solution that covers both A and B, or to find two relatively simple
solutions that address A and B, respectively, or something else (for
example)?

In this case, the A and B I'm talking about are public/private boundaries
and arbitrary groupings or relationships.  Presenting the current survey of
the land in terms of domain boundaries, registration, and dynamics, is a
first step to identify the problem space.

Cheers,
Casey

---

From: Casey Deccio <[email-masked]>
Date: Wed, 5 Nov 2014 14:16:42 -0500

All,

I appreciate the on-list discussion with regard to the content from the
draft problem statement.  I just wanted to draw attention to the obscure
bulleted list in the last section, intended to be the take-away after all
the background concepts are described.

   - Evaluate the effectiveness of the current PSL at performing the
   functions within its scope.
   - Evaluate the effectiveness of the maintenance and distribution of the
   PSL.
   - Determine demand for domain relationship identification other than
   that provided by the PSL.
   - Identify solutions to replace, extend, improve, or complement the
   functionality, maintenance, or distribution of the PSL according to
   perceived demands.

 I just want to make sure that this content is not overlooked as other
relevant topics are discussed.

Also, I am hearing no conflicts with the Tuesday morning time for the "bar"
BoF.  I have a room in mind that will seat about 20 people, and I would
like to know who plans to attend to make sure the venue will work.  Feel
free to RSVP off-list.

If any would like to attend remotely, I can look into something to enable
that, but I it would be best effort :)

Cheers,
Casey

---

From: "John R Levine" <[email-masked]>
Date: 5 Nov 2014 14:34:12 -0500

> statement document) would be considered intra-scope, i.e., two public

See, that's the problem.  They are in fact different groups.  Verisign 
(who runs the com TLD) would be very unhappy if someone issued a *.com 
certificate to Centralnic (which registered uk.com.)

> solutions that address A and B, respectively, or something else (for

If the 1% where A doesn't work involves catastrophic failures, like 
issuing a *.com certificate, then I think A is in practice a non-starter.

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

---

From: Edward Lewis <[email-masked]>
Date: Wed, 5 Nov 2014 20:17:52 +0000

Update - I did some fact checking and found that I am wrong about this:

"And E.g., compare how dotUK has been run (until the
recent policy change) versus CO.UK.  dotUK is essentially private (and
signed with NSEC to boot) but CO.UK. would be public.”

UK isn’t ‘NSEC' signed and I couldn’t find that it ever was.  I thought it
was, but I am wrong.

---

From: Jeffrey Walton <[email-masked]>
Date: Wed, 5 Nov 2014 15:53:56 -0500

> that you want to know which are g and which cc, or just all the TLDs?)

The IETF does not forbid issuing a certificate for *.com, *.net and
friends. The CA/B Forums does forbid it. As a preflight check, I want
to reject those certificates categorically.

If a certificate passes the gTLD and ccTLD preflight check, then I am
willing to reach out over the network to learn of administrative
boundaries. (Or, I might just skip the administrative boundaries
check).

I'm not sure why the IETF feels its OK to issue a certificate for
*.com, *.net, etc. I've looked in RFC 5280 and 6125, and I've never
seen any reasoning.

---

From: "John Levine" <[email-masked]>
Date: 5 Nov 2014 21:47:07 -0000

>*.com, *.net, etc. I've looked in RFC 5280 and 6125, and I've never

There are now vanity TLDs.  Why shouldn't a CA sign a cert for
*.neustar or *.williamhill if the TLD registrants (who are the same as
the registries) ask for them?

R's,
John

PS: Those are real TLDs, and I have the zone files to prove it.

---

From: Jeffrey Walton <[email-masked]>
Date: Wed, 5 Nov 2014 16:52:24 -0500

> the registries) ask for them?
Good point John. The vanities need to be accounted for, too.

But its still not clear to me why the IETF feels its OK for someone to
to claim to issue *.com or *.net. Even the CA/B got that one right ;)

---

From: "John R Levine" <[email-masked]>
Date: 5 Nov 2014 16:55:02 -0500

> to claim to issue *.com or *.net. Even the CA/B got that one right ;)

The IETF writes technical specs.  What's the technical difference between 
*.com and *.neustar?

(I realize there is a significant administrative difference.)

Regards,

---

From: Edward Lewis <[email-masked]>
Date: Wed, 5 Nov 2014 22:25:31 +0000

The global public internet is not the only inter-network using tcp/ip or DNS. 

Sent from my iPhone

On Nov 5, 2014, at 16:55, John R Levine <[email-masked]> wrote:

> The IETF writes technical specs.  What's the technical difference between *.com and *.neustar?
> 
> _______________________________________________
> Dbound mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dbound

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Nov 2014 18:11:32 -0500

> to reject those certificates categorically.

Ok, but aren't there other ones you also want to reject?  For
instance, it'd be at least just as bad to get *.co.uk.  That's not a
TLD.

If you respond, "Oh, but it's an _effective_ TLD," then you're
basically granting my point: the issue is not where in the hierarchy
you stand, but in what relationship you stand with everything else.
_One_ of those relationships is, "Always administrative delegation;
maybe not DNS delegation; no other administrative sharing."  That's
basically what people mean by "public suffix."  And I think we should
expect that various different models of this get more common as more
new TLDs come online and realise their business model is doomed.

Now, if you're saying, "Oh, but I need some of this to be cached on my
side," I agree.  That's really just a requirement for
effectively-infinite TTLs, however.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 7 Nov 2014 11:59:10 -0500

> PS: Those are real TLDs, and I have the zone files to prove it.

I had the same question John did. Isn't the question for the CA whether to issue a cert to the proper authority for the domain? TLDs have those just like domains further down the tree do.

This actually further confuses me about why the cc/g distinction is important in this context.

The cc/g distinction is about domain policy, but it's about where the policy authority comes from, not what it does. If I can register whatever I want there ("public"), how does it help to know whether the policy I'm relying on comes from an operator under a contract with ICANN?

The "vanity" TLDs, and the entire new menagerie of registry administrative attributes relevant to policy, ("closed," "new g/old g," "idn cc," etc.) seem to provide endless opportunity for fairly arbitrary policy about delegations. Public/private seems to be a proxy for that, allowing perhaps easy recognition of two of the most common sets of rules, but I suspect it's going to get less helpful as time goes by.

I do realize I must be missing something, as I know a lot about DNS, a lot about TLD policy, and a lot less about what's in between.

thanks,
Suzanne

---

From: Jothan Frakes <[email-masked]>
Date: Fri, 7 Nov 2014 09:53:16 -0800

>>The cc/g distinction is about domain policy, but it's about where the
policy
>>authority comes from, not what it does. If I can register whatever I want
>>there ("public"), how does it help to know whether the policy I'm relying
>>on comes from an operator under a contract with ICANN?

The domain policy thing is a component of the problem space

Developers and Integrators:  Form validations, email, search, and other
integration use just practically care where to snap the line on what aspect
of the domain provided is part of a static group and that it is a real
extension.  These folks are looking for a rapid, reliable, and stable
mechanism for their specific validation purpose, and don't necessarily care
about public/private - just existence and how many dots are included in it
working from the right.

They are pilots who want to land a plane and don't necessarily care if it
is a Spanish, British, French, Independent  or other territory or are part
of the UN, they just care about the runway length.

Jothan Frakes
Tel: +1.206-355-0230

On Fri, Nov 7, 2014 at 8:59 AM, Suzanne Woolf <[email-masked]>
wrote:

> I had the same question John did. Isn't the question for the CA whether to
> issue a cert to the proper authority for the domain? TLDs have those just
> like domains further down the tree do.
>
> The cc/g distinction is about domain policy, but it's about where the
> policy authority comes from, not what it does. If I can register whatever I
> want there ("public"), how does it help to know whether the policy I'm
> relying on comes from an operator under a contract with ICANN?
>
> The "vanity" TLDs, and the entire new menagerie of registry administrative
> attributes relevant to policy, ("closed," "new g/old g," "idn cc," etc.)
> seem to provide endless opportunity for fairly arbitrary policy about
> delegations. Public/private seems to be a proxy for that, allowing perhaps
> easy recognition of two of the most common sets of rules, but I suspect
> it's going to get less helpful as time goes by.
>
> I do realize I must be missing something, as I know a lot about DNS, a lot
> about TLD policy, and a lot less about what's in between.
>
> thanks,
> Suzanne
>

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 7 Nov 2014 13:44:37 -0500

Hi Suzanne,

On Fri, Nov 7, 2014 at 11:59 AM, Suzanne Woolf <[email-masked]> wrote:
>> ...
If I am reading it correctly, then there is no difference between
gTLDs and ccTLDs.

For my needs, I need to know how to recognize or detect gTLDs and
ccTLDs (and the vanities, as John pointed out). I also need to know
how to recognize second level domains, like *.co.uk (as someone else
mentioned). Finally, it would be nice to know how to recognize
administrative boundaries, like between blogspot.com, foo.blogspot.com
and bar.blogspot.com.

I'm more concerned with the first two cases (gTLDs/ccTLDs and second
level domains). I'm concerned about these two cases because I have
witnessed attacks on them. A nice feature would be to avoid DNS and a
network call since each could be complicit in an attack on the TLD.
That's why I differentiate between top level/second level and the rest
of the zoo.

I'm less concerned with the administrative boundaries between, for
example, blogspot.com and foo.blogspot.com. Right now, I'm using a
PSL-like list for the administrative boundaries, but I would like
something cleaner if its available.

Finally, I need to know where to tell people to go look when their
software needs the same security controls. I can't say "You need to do
X" and not have a reference for X. I hope DBOUND will provide X so I
can say "You need to do X, and go look at DBOUND".

---

From: Rubens Kuhl <[email-masked]>
Date: Fri, 7 Nov 2014 14:46:06 -0400

When one looks at maps and charts, some boundaries are different from others. So if the information source has a clear difference for those, for instance what has a match in RDAP delegation and what has not, it would be up for those who use the information to make a decision based on it. 

In your exemple, sometimes only the runway length matters, like landing a plane in an SOS situation. Sometimes the sovereignty lines matter, like a plane carrying a political refugee. 

Rubens

> On Nov 7, 2014, at 1:53 PM, Jothan Frakes <[email-masked]> wrote:
> 
> >>The cc/g distinction is about domain policy, but it's about where the policy 
> Developers and Integrators:  Form validations, email, search, and other integration use just practically care where to snap the line on what aspect of the domain provided is part of a static group and that it is a real extension.  These folks are looking for a rapid, reliable, and stable mechanism for their specific validation purpose, and don't necessarily care about public/private - just existence and how many dots are included in it working from the right. 
> 
> They are pilots who want to land a plane and don't necessarily care if it is a Spanish, British, French, Independent  or other territory or are part of the UN, they just care about the runway length.
> 
> 
> 
> 
> 
> Jothan Frakes
> Tel: +1.206-355-0230
> 
> 
> On Fri, Nov 7, 2014 at 8:59 AM, Suzanne Woolf <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On Nov 5, 2014, at 4:47 PM, John Levine <[email-masked] <mailto:[email-masked]>> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dbound <https://www.ietf.org/mailman/listinfo/dbound>
>

---

From: Edward Lewis <[email-masked]>
Date: Fri, 7 Nov 2014 19:10:38 +0000

>On 11/7/14, 11:59, "Suzanne Woolf" <[email-masked]> wrote:
>
>>policy authority comes from, not what it does. If I can register
>>whatever I want there ("public"), how does it help to know whether the
>>policy I'm relying on comes from an operator under a contract with ICANN?
>
>It might, in some applications.  I have heard some expectations that the
>³policy² of a TLD would impact how it is treated in end-user
>applications.  I don¹t have rock-solid examples to give, but I wouldn¹t
>rule this use case out just yet.  Yes, this might be a ³I want a pony²
>but I don¹t want to close the door on it.
>
>>The "vanity" TLDs, and the entire new menagerie of registry
>>administrative attributes relevant to policy, ("closed," "new g/old g,"
>>"idn cc," etc.) seem to provide endless opportunity for fairly arbitrary
>>policy about delegations. Public/private seems to be a proxy for that,
>>allowing perhaps easy recognition of two of the most common sets of
>>rules, but I suspect it's going to get less helpful as time goes by.
>
>The IETF shouldn¹t worry itself about policy because the expertise is not
>available.  But the IETF shouldn¹t burn in what it thinks of policy
>either.
>
>>I do realize I must be missing something, as I know a lot about DNS, a
>>lot about TLD policy, and a lot less about what's in between.
>
>Innovation comes in many forms - it might be related in how TLDs are run.
> It would be grand if the result of what here avoids stifling such
>innovation.  Yes, ³I want a pony."

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 7 Nov 2014 14:32:25 -0500

On Fri, Nov 07, 2014 at 01:44:37PM -0500, Jeffrey Walton wrote:
> witnessed attacks on them. 

That sounds to me like arguing that you're going to put a lock on your
back door because that's where the burglars came in last time, and
neglecting to put one on the front.  I have pretty good reason to
believe that dyndns.org has more policy boundaries within it than many
ccTLDs do.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 7 Nov 2014 14:35:08 -0500

> >but I don¹t want to close the door on it.

This is _exactly the same_ confusion as the one that led to the
original crumbly cookies problem.  Indeed, not only have I heard those
expectations; but when I told the relevant ministry people that zones
underneath them did not in fact inherit the policy rules from the
parent, they were shocked.  They said that ICANN should create a
policy.  I pointed out that what they were really saying was that
every computer in the known universe had to be upgraded for this to
take effect.  Even telco regulators understand field service problems.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 7 Nov 2014 14:55:53 -0500

>> but I don¹t want to close the door on it.

Right, and I'm fine with that, except that the actual distinction between g/cc tells you nothing at all about how a TLD, or its subdomains, are or should be "treated by end-user applications." It can't, modulo the very, very broad outlines provided by the attribute of a TLD that it's operated under a specific contract to ICANN. All you know about a cc is that it meets a specific syntactical rule ("this two-ascii-letter string appears in a specific lookup table") and *doesn't* have that "under a specific contract to ICANN" attribute.

The answers to my question have been pretty helpful in clarifying some distinctions I need to understand better, thanks.

>> available.  But the IETF shouldn¹t burn in what it thinks of policy

The IETF should make technical standards that allow people who do have relevant policy expertise (and operational need!) to encode the policies they want. That does mean having a certain level of understanding of what policy distinctions matter to the people who have to use those standards. Hence my question.

(Before we get any further into this, there are at least three meanings of the word "policy" already conflated in this thread. I spend a lot of time in that maze of ratholes all alike, and one of the things I think it's critical to do here is avoid it as much as possible. Clarity of terminology will help a lot.)

thanks,
Suzanne

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 7 Nov 2014 15:28:40 -0500

> believe that dyndns.org has more policy boundaries within it than many
Perhaps, but I need to solve problems I have seen in real life.

Jeff

---

From: "John Levine" <[email-masked]>
Date: 7 Nov 2014 23:41:11 -0000

>Right, and I'm fine with that, except that the actual distinction between g/cc tells you
>nothing at all about how a TLD, or its subdomains, are or should be "treated by end-user
>applications." It can't, modulo the very, very broad outlines provided by the attribute
>of a TLD that it's operated under a specific contract to ICANN.

Even the ICANN contracted domains have an irregular surface.  The
.name TLD originally only let you register 3rd level names like
john.smith.name, but they later added 2nd level.  Even with a copy of
the zone file it can be hard to tell where the boundary is.  This
kind of financially motivated flattening is common, e.g. .pro, .us,
and most recently .uk, with the legacy names left as lumps in the
new flat namespace.

R's,
John

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 7 Nov 2014 23:08:18 -0500

> and most recently .uk, with the legacy names left as lumps in the

Exactly, and as someone else said in the thread (Andrew?) the pressures are only going to increase as the new gTLD operators get creative with operational and business models. 

I don't want to get too stuck on challenging the usefulness of the distinction between g's and cc's, though. My question was about what distinctions *are* useful, and I have a better understanding of that now. 

thanks,
Suzanne

---

From: Edward Lewis <[email-masked]>
Date: Mon, 10 Nov 2014 20:03:45 +0000

>On 11/7/14, 14:35, "Andrew Sullivan" <[email-masked]> wrote:
>
>>take effect.
>I wanted to respond - I don¹t think that¹s a foregone conclusion.  I know
>what you are saying, but there may be not-yet-written applications that
>could . . . it¹s all conjecture.  Lacking any real example, it isn¹t
>worth arguing past saying I¹d also not rather assume a basic stub either.
>
>I.e., public vs. private is just something I wouldn¹t assume is an
>adequate starting point.  Lacking a more elaborate ³pony² does not mean
>we can do the minimum and be happy.  (Along the lines of WhoIs-aka-port43
>had no authorization model which effectively forced a all-or-nothing
>model on us.)

(PS - Although this indented, it¹s my reply.  I just don¹t understand my
mail client.)

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Nov 2014 12:10:11 -0800

I doubt this will be the kind of venue you'll hold the 'meeting' at, but
if the bar bof is actually going to be in a room and it is possible to
support remote participation, I'm interested.

Glad to supply my own bar food.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Kurt Andersen <[email-masked]>
Date: Mon, 10 Nov 2014 11:12:40 -1000

Seems like we should be able to secure a meeting room for the evening time
slots - I don't see a lot of contention for them.

--Kurt

---

From: Gervase Markham <[email-masked]>
Date: Wed, 12 Nov 2014 15:29:02 +0000

On 05/11/14 14:40, Casey Deccio wrote:
> I'm wondering if that is the confusion with the most recent point as
> well.  Is it possible that you were looking at the entry "foo.example"
> in Table 2 and forgetting that it matched the wildcard exception (i.e.,
> was not in the same category as "fred.example" and "bar.example"), just
> as the wildcard exception for "foo.example" was overlooked when you
> contrived your own example (and they ultimately clashed)?

Yes, indeed. This was it.

> "example" and "*.example" were both useful in the list.  You indicated
> that they were not (and I can see that is the case in the current PSL,
> both by entries and by testing), and my initial response was agreement. 
> However, it is not clear to me from the specified algorithm that
> "*.example" implies "example".  If that implication is intentional, then
> it seems inconsistent with the specification as I read it: "The wildcard
> character * (asterisk) matches any valid sequence of characters in a
> hostname part" and "Wildcards may only be used to wildcard an entire
> level" [1].

"*.example" does indeed NOT imply "example", or any shorter rule in
fact. However, if the number of labels in the two rules you are looking
at differs by only 1, what does it mean to list them both? In this case,
when would the "example" rule ever get matched? Only by http://example/
- but then such dotless names normally don't get checked against the PSL
anyway, as it's assumed that they are intranet names.

Gerv

---

From: Kurt Andersen <[email-masked]>
Date: Wed, 12 Nov 2014 11:17:07 -1000

On Tue, Nov 4, 2014 at 5:42 AM, Casey Deccio <[email-masked]> wrote:

>
> Please find attached a draft DBOUND problem statement. . .
>

Having had time to consider this write up (in the midst of all the IETF
traffic), I appreciate the work to clarify the scope and semantics, but it
seems like the problem summary puts the cart before the horse.

Taking the liberty of numbering the existing list:

   1. Evaluate the effectiveness of the current PSL at performing the
   functions within its scope.
   2. Evaluate the effectiveness of the maintenance and distribution of the
   PSL.
   3. Determine demand for domain relationship identification other than
   that provided by the PSL.
   4. Identify solutions to replace, extend, improve, or complement the
   functionality, maintenance, or distribution of the PSL according to
   perceived demands.

It seems to me that the primary problem statement is #3 on the list above.
Once that is established, then 1 and 2 are either irrelevant or important
and #4 becomes open to consideration.

I am slightly puzzled to not see any discussion of the question of
identifying ADMD boundaries since that question had come up in other
conversations.

The extensive conversation around public/private seems to be a concession
by approximation to the what people would really want to know about true
security boundaries (for some meaning of the words "security" and "true").

Looking forward to discussing these topics in Thursday's side meeting.

Cheers,
  Kurt Andersen

---

From: Casey Deccio <[email-masked]>
Date: Wed, 12 Nov 2014 14:15:51 -1000

On Wed, Nov 12, 2014 at 5:29 AM, Gervase Markham <[email-masked]> wrote:

> fact.

Yes, my quick test was faulty.  You are correct.

However, if the number of labels in the two rules you are looking
> anyway, as it's assumed that they are intranet names.

In the contrived case, yes, but wildcards aren't always attached to TLDs,
which means that there are other cases besides dotless domains (for
example, *.sch.uk).

But more importantly, with HTTP cookies the PSL provides the ancestral
boundary for the cookie domain, which means that it really only matters
when the server name has at least one more label than the cookie domain
(i.e., a cookie with the same domain as the server name doesn't require the
PSL).  But more generally (i.e., outside of HTTP cookies) it might be
important to know that a domain name itself is public, regardless of
whether or not all its children are (e.g., due to a wildcard).

Best regards,
Casey

---

From: Casey Deccio <[email-masked]>
Date: Wed, 12 Nov 2014 15:05:54 -1000

Hi Kurt,

Thanks for the feedback.

>    2. Evaluate the effectiveness of the maintenance and distribution of
>    the PSL.

The observation I have made as I've thought about the problem and examined
existing solutions is that public/private scope identification is a
significant contributor to the more general problem of domain association.
Certainly it is not the only aspect, and the solutions to public/private
scope identification do not generally apply to the domain association
problem.  However, because public/private scope identification has
significant existing demand within the more general problem, and there are
working solutions (e.g., the PSL), it seems fitting to give this aspect of
the problem appropriate attention.  This is especially the case because
there is relative simplicity, running code, and precedent, in terms of
install base.  Of course, that doesn't mean existing use cases and
solutions need to dictate future solutions, but they are certainly
considerations.

Therefore, I don't believe that #3 makes #1 and #2 irrelevant, as the #1 is
explicitly complementary to #3, and #2 is dependent on #1.  The intent to
#4 was to cover demands of both #1 and #3.

> identifying ADMD boundaries since that question had come up in other

Contributions are welcome :)

> security boundaries (for some meaning of the words "security" and "true").

Again, I see it as a subset of the problem with significant current demand,
not a concession nor a general purpose solution.

Likewise.  Thanks again for the feedback.

Best regards,
Casey