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

[Casey Deccio <[e-mail]>]

Hi Ed,

On Tue, Nov 4, 2014 at 2:47 PM, Edward Lewis <[e-mail]> wrote:

> 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.)
>

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. :)


>
> 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.
>
>
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.


> 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.)
>

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.


> 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.
>

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


>
> 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.
>

Agreed.


>
> 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?
>

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.


> 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...)
>
>
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.


> 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.
>
>
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