[dbound] Suggestion for Prague: let's try to converge on problem(s)

[Andrew Sullivan <[e-mail]>]

Hi,

I've been trying to put together detailed comments on
draft-deccio-domain-name-relationships-00, and to propose some changes
to draft-sullivan-dbound-problem-statement-00.  But I'm failing to get
satisfying comments together, so sending this more general remark now
because I think we still have some sort of fundamental gap in our
collective understanding of what we're trying to do.  I'd like to
suggest we use some time in Prague to try to get this sorted out.

In my reading, draft-deccio-domain-name-relationships-00 starts with a
deep, fundamental division between "public" and (for want of a better
term) "private" domain names.  I think it starts there because the
authors genuinely believe that the distinction is a fundamental one.
In my opinion, that stance reifies a distinction that is implicit to
the way the PSL has always worked into a distinction that is part of
the world.

For instance, to me it is extremely artifitcial to claim that the root
zone and (say) the com zone are both "public" zones.  The rules by
which one gets an entry in the root zone are way more convoluted than
the rules by which one gets an entry in the com zone.

By the same token, the important relationship between (for example)
co.uk and uk is not that they're both public, but the way the policy
relationship between those domains works (and how it might evolve over
time).

My view is that this means we need a way to express these kinds of
relationships, but that one thing we _must_ be able to capture (or
perhaps emulate) the public/private distinction that is implicit in
the PSL now.

Part of the reason I keep harping on this is because, if we're merely
going to produce a new way to express the same public/private
distinction we have now, there will be poor incentives to use or
deploy the new protocol.  It imposes some costs, and if you don't get
anything better than the mechanism you already have then the
additional work will never be worth it.

But the problem is, I think, that our use cases suggest that PSL has
been embraced because it's the closest available, rather than being
close enough.  I'd like to spend the time we have in Prague really
hashing the rest of the details of what problems we're really trying
to work on, what ones are must-haves vs. nice to haves, and to
prioritize the nice to have cases in order to understand how we can
make trade-offs.

Best regards,

A

-- 
Andrew Sullivan
[e-mail]