Subject: Re: [domainrep] Discussion items for Repute session at Taipei

From: Eric Osterweil <[email-masked]>
Date: Fri, 4 Nov 2011 16:30:02 -0400

On Oct 18, 2011, at 7:37 PM, Chris Lewis wrote:

<snip>

> 
> On the DNS vs. "other UDP" light weight.  From a pure
> practicality/adoption standpoint, the existing DNSBL mechanism handles
> surprisingly well what _most_ sites would contemplate (and often already are) using for the short and medium term - meaning manual discovery of policy&meaning&interpretation of resulting A records (via the issuer's service description (usually web site)).
> 
> Given that most usage now and for the short-medium term future is
> adequately handled by DNSBL technology as it stands, anything else would have a pretty poor chance of achieving critical mass and success, even if it's "better" at the "fancier" end.
> 
> Reinventing the wheel seems a poor use of our time.

+1

There are a host of UDP-in-the-Internet issues that I think DNS has grown to handle well, and riding on those standards obviates this work from needing to re-discover them.

Eric

---

From: "John Levine" <[email-masked]>
Date: 4 Nov 2011 20:57:58 -0000

>1) XML vs. JSON; the drafts currently use XML, ...

Actually, there's one draft (draft-kucherawy-reputation-media-type)
which describes a text format similar to the one for ARF data, and
another (draft-kucherawy-reputation-query-http) which describes an XML
format.  I don't have any strong opinions about text vs. XML vs. JSON,
but since these are all intended for consumption by computers rather
than people I don't see the point of having more than one format.

>2) DNS vs. a new UDP thing: ...

Unless someone has a coherent argument for a new UDP thing, perhaps
we can consider this one closed.

I agree that it needs something for vocabulary discovery, both to know
what question to ask, and how to interpret the results.

I've also been thinking about plausible applications both close to
the standard examples (should I accept this mail or this IRC message)
and farther away (should I eat at this restaurant.)

It seems to me that it would be very useful to have what I might call
neighbor discovery, e.g., what are other names close to this one.  In
the mail world closeness metrics might be same or close IP or same MX
or same name server.  In the restaurant world it might be physically
close or similar food.

R's,
John

---

From: Denny Watson <[email-masked]>
Date: Sun, 06 Nov 2011 18:54:43 +0000

On 11/4/11 3:57 PM, John Levine wrote:
(snip)
> we can consider this one closed.

Well, the problem that I see with using DNS is that DNS will only cache
the specific questions that are asked of it, no matter what the response is.

> what question to ask, and how to interpret the results.

Agreed, but it may be simpler to look at the problem via some other
protocol that knows to cache the results and look for answers in these
results and not just the last specific question asked...  I just don't
know at this point.

---

From: "John Levine" <[email-masked]>
Date: 7 Nov 2011 00:29:20 -0000

>the specific questions that are asked of it, no matter what the response is.

They'll cache whatever the servers return.  Remember, DNS is a fairly
general query system so long as you can encode your question in a
string that looks like a domain name and the answer isn't too big.
And since the query is a single UDP round trip, you can make three of
them for the price of the cheapest TCP query.

>results and not just the last specific question asked...  I just don't

There's presumably also an http or other heavyweight protocol for bigger
questions and answers.  There's been a great deal of work over the past
decades on distributed and remote databases, so if we do anything beyond
a specific answer to a specific question, I would want to be really sure
that we take advantage of what people have already figured out and don't
go making famous database design mistakes.

R's,
John