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

[Edward Lewis <[e-mail]>]

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 <[e-mail]>
Date: Tuesday, November 4, 2014 at 10:42
To: "[e-mail]" <[e-mail]>
Subject: [Dbound] Draft problem statement and IETF "bar BoF"

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