Subject: Re: [Dbound] identifiers vs. domain names (was Re: Sketch charter)

From: Dave Crocker <[email-masked]>
Date: Mon, 01 Dec 2014 07:23:07 -0800

On 11/30/2014 9:29 PM, Murray S. Kucherawy wrote:
> On Sat, Nov 29, 2014 at 7:29 AM, Dave Crocker <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     > Prior solutions for identifying relationships between domain names
>     > have relied primarily upon the DNS namespace and protocol to provide
>     > a service that actually exists outside of both. Relying on the DNS
>     > to do so thus renders such solutions unreliable and unnecessarily
>     > constrained. For example, confirming or dismissing a relationship between
>     > two domain names based on the existence of a zone cut or common ancestry
>     > is often unfounded, and the notion of an upward "tree walk" as a
>     search
>     > mechanism is considered unacceptable.
> 
>     Both of these examples are /within/ the protocol.  That runs contrary to
>     the opening assertion of this paragraph.  Other than the PSL, I've no
>     idea what other 'prior solutions' are being cited.  I doubt a non-expert
>     (or possibly expert) reader will, either.
> 
> 
> Both of those are examples of something happening via the protocol to
> try to discover something that exists completely outside of the
> protocol, and it doesn't work.  That's what the cited paragraph is
> trying to say.

I put honest effort into reading and understanding the text.  I have
some background in protocol design and in the DNS.  My interpretation of
that text's meaning matches what I said, not what you suggest was meant.

I'm not challenging what is intended by the existing text but what is
accomplished by it.  If someone with my background derived a meaning
significantly (and problematically) different from what is intended,
it's worth considering language that is more pedagogical to a wider
audience.

In particular, what is meant by 'within a protocol' vs. 'external to the
protocol' can obviously be easily misunderstood, even to the extent that
experts can disagree.

For example, I think that the structure of the stored DNS is a property
of the DNS.  Hence something that attempts to derive meaning from that
structure can plausibly be classed as working within the DNS. (I'm not
seeking a debate about the validity of this view; I'm merely noting that
I think it a plausible source of confusion.)

So some extra verbiage clarifying what is meant here is worthwhile.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 1 Dec 2014 11:30:20 -0800

> it's worth considering language that is more pedagogical to a wider

I'm also not impugning your criticism or expertise, but rather inviting (at
this point almost begging for) suggestions about what specific changes to
make.  I took a run at it and produced something that looks clear to me but
not to you.  Thus, I understand that you feel this text is a problem, but
I'm at a loss in terms of what else to try.

> So some extra verbiage clarifying what is meant here is worthwhile.

I've taken another run at it and pushed it to github, but I honestly don't
know if it's better or worse at this point.  So to repeat my previous
request: If this isn't good enough, and now that you know what was meant,
please provide me with new text to use rather than abstract guidance.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Mon, 01 Dec 2014 11:45:03 -0800

On 12/1/2014 11:30 AM, Murray S. Kucherawy wrote:
> I'm also not impugning your criticism or expertise, but rather inviting

oh boy. none was taken.

i invoked the pedantic style merely to make the baseline issue clear.

we are a very inbred group and often lose sight of how are knowledge and
assumption are different from other, desired readers of our charters
(and other documents.)

> I've taken another run at it and pushed it to github, but I honestly

I'm almost sorry to say that I like this latest current version...

I do note the interesting and relevant issue Olafur has raised but don't
know how to resolve it or whether it's essential to resolve it for
chartering.  My guess is that ongoing conversation about this will be
helpful, since it seems to touch on basic issues of modeling the working
group's problem and/or solution space, but again, I don't think it's
essential to resolve it first.

d/

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 1 Dec 2014 14:58:45 -0500

> So some extra verbiage clarifying what is meant here is worthwhile.

This is where I thought the distinction I was trying to suggest between the namespace and the wire protocol can be helpful; both are "within the protocol," but are distinct for the purposes of the problem we're trying to address. The namespace is being re-used by other applications as well, and they want to add properties to it that DNS protocol doesn't use or even have. But that description too appears to be subject to the "easily misunderstood, even to the extent that experts can disagree" limitation. I may be missing something, but I'm afraid there's no way to frame this at the level of clarity we'd all like.

> I've taken another run at it and pushed it to github, but I honestly don't know if it's better or worse at this point.  So to repeat my previous request: If this isn't good enough, and now that you know what was meant, please provide me with new text to use rather than abstract guidance.

I like this version but I was OK with the last one. We may be going in circles, and possibly even tripping over the problem we're trying to solve as we go.

Wider review will tell us. As someone already said (Andrew?), it's time for more eyes.

thanks,
Suzanne