Subject: [domainrep] Considering COAP

From: Dave CROCKER <[email-masked]>
Date: Tue, 13 Dec 2011 11:30:55 -0800

Folks,

At the Taipei wg meeting, it was suggested that the group might want to consider 
use of COAP as a transport.  This was specifically as an alternative to using 
UDP or the DNS. We took an action item to pursue this possibility.

(Let's not review UDP or DNS issues in this thread; I'm mentioning them only to 
establish context.)

Can folks comment on COAP, assuming that most of us have little background? 
Summaries with pointers are dandy.  The first goal should be education.

Also, what makes it better than, for example, using UDP?

What is the state of its software packages, deployment and use?

Personally I'd also be interested in some comparison to using HTTP.

Thanks.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Douglas Otis <[email-masked]>
Date: Tue, 13 Dec 2011 12:06:06 -0800

On 12/13/11 11:30 AM, Dave CROCKER wrote:
> Folks,
>
> At the Taipei wg meeting, it was suggested that the group might want 
> to consider use of COAP as a transport.  This was specifically as an 
> alternative to using UDP or the DNS. We took an action item to pursue 
> this possibility.
CoAP payloads seem like a good fit.  Inverted JSON name space as a 
payload would permit simple string sorting to combine parent and child 
domains. :^)
> (Let's not review UDP or DNS issues in this thread; I'm mentioning 
> them only to establish context.)
>
> Can folks comment on COAP, assuming that most of us have little 
> background? Summaries with pointers are dandy.  The first goal should 
> be education.
http://tools.ietf.org/html/draft-ietf-core-coap-03
http://tools.ietf.org/wg/core/
> Also, what makes it better than, for example, using UDP?
UDP that is not DNS can be problematic.
> What is the state of its software packages, deployment and use?
Largely for facility automation where bandwidth requirements on low 
power networks requires efficient low chatty restful protocols.
> Personally I'd also be interested in some comparison to using HTTP.
http://tools.ietf.org/id/draft-ietf-core-link-format-09.txt

-Doug

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 13 Dec 2011 13:13:00 -0700

On 12/13/11 12:30 PM, Dave CROCKER wrote:
> Folks,
> 
> At the Taipei wg meeting, it was suggested that the group might want to
> consider use of COAP as a transport.  This was specifically as an
> (Let's not review UDP or DNS issues in this thread; I'm mentioning them
> only to establish context.)
> 
> background? Summaries with pointers are dandy.  The first goal should be
> education.
> 

I think you really want to post this message to the CORE WG, because
they are the CoAP experts.

As I said in Taipei, I just don't see the fit here. CoAP is designed for
use by constrained devices in limited environments like home area
networks and building automation systems. Using it outside that context
feels inapprpriate to me.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 13 Dec 2011 16:05:41 -0500

> feels inapprpriate to me.

I think if you read RFC 1034, you will find scant evidence that the
DNS was designed to be expanded by underscore labels, much less the
expedient of overloading an address resource record type to carry data
about the reputation of a name.  Yet the DNS undeniably is
successfully used that way by some people.  I'd like to see the
analysis of CoAP.

Best,
A

-- 
Andrew Sullivan
[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 13 Dec 2011 14:09:12 -0700

> successfully used that way by some people.  I'd like to see the

Then I suggest that you ask something like this on the CORE WG list:
"over in the REPUTE WG we're thinking about using CoAP to communicate
reputation information over the world-wide about identifiers such as
domain names, IP addresses, and email addresses; do you CoAP experts
think that's an appropriate use of CoAP?"

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: TianLinyi <[email-masked]>
Date: Wed, 14 Dec 2011 03:19:28 +0000

Hi, All

+1

CoAP is suitable for constrained devices but it doesn't mean it can't be used in non constrained environment. There are already some efforts to use it in mobile phone outside ietf. It would be interesting to investigate how to use CoAP in REPUTE.

Cheers,
Linyi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
Sent: Wednesday, December 14, 2011 5:06 AM
To: [email-masked]
Subject: Re: [domainrep] Considering COAP

Best,
A

-- 
Andrew Sullivan
[email-masked]

_______________________________________________
domainrep mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/domainrep

---

From: TianLinyi <[email-masked]>
Date: Wed, 14 Dec 2011 03:23:07 +0000

Hi, All

There are already some debate on "lightweight protocol for all devices" or "protocol only for lightweight(constrained devices". I would think CoAP was originally designed for approach 2 but it doesn't limit people to use it in approach one. As peter mentioned it would be good to get opinions from CoAP folks. As one of them, my opinion is above. 

Cheers,
Linyi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Wednesday, December 14, 2011 5:09 AM
To: Andrew Sullivan
Cc: [email-masked]
Subject: Re: [domainrep] Considering COAP

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Leif Johansson <[email-masked]>
Date: Wed, 14 Dec 2011 09:29:27 +0100

On 12/13/2011 09:13 PM, Peter Saint-Andre wrote:
>> At the Taipei wg meeting, it was suggested that the group might
>> want to consider use of COAP as a transport.  This was
>> specifically as an alternative to using UDP or the DNS. We took
>> an action item to pursue this possibility.
>> 
>> (Let's not review UDP or DNS issues in this thread; I'm
>> mentioning them only to establish context.)
>> 
>> background? Summaries with pointers are dandy.  The first goal
>> should be education.
>> 
> I think you really want to post this message to the CORE WG,
> because they are the CoAP experts.
> 
> As I said in Taipei, I just don't see the fit here. CoAP is
> designed for use by constrained devices in limited environments
> like home area networks and building automation systems. Using it
> outside that context feels inapprpriate to me.

I agree. I firmly believe we should stick firmly to the mainstream in
this WG and that means REST+JSON today. This doesn't need to be more
complicated than that.

	Cheers Leif

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 14 Dec 2011 05:41:46 -0800

>> >  designed for
...
> I agree.

I should clarify that my question was not meant as a poll of preferences for or 
against using CoAP, but as an invitation to discuss technical merits.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 14 Dec 2011 05:59:06 -0800

David Dagon forwarded a list of relevant links:

Standards, et al:
    http://tools.ietf.org/html/draft-shelby-core-coap-01
    http://trac.tools.ietf.org/wg/core/trac/wiki/PlugFest

Papers, studies, blogs:
   http://people.inf.ethz.ch/mkovatsc/#pro
   http://zachshelby.org/
   http://lucato.it/CoAP

Tools:
   http://sourceforge.net/projects/libcoap/
   http://anonsvn.wireshark.org/wireshark/trunk/epan/dissectors/packet-coap.c

d/
-- 

   Dave Crocker

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 14 Dec 2011 15:08:04 +0100

>   http://tools.ietf.org/html/draft-shelby-core-coap-01

That is an 18 months old individual draft.
You want to look at the WG document:

	http://tools.ietf.org/html/draft-ietf-core-coap

On the tools side, Matthias Kovatsch (you already linked to him) has some more amazing stuff, including a firefox plugin called "Copper".

	http://people.inf.ethz.ch/mkovatsc/

Grüße, Carsten

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 Dec 2011 06:37:03 -0800

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Leif Johansson
> Sent: Wednesday, December 14, 2011 12:29 AM
> To: [email-masked]

Hi Leif,

That reminds me: You had indicated in Taipei that you didn't want authentication to be done the way that it's currently illustrated in the query-http document.  What's there is based on one extant implementation but may not be the best way, and I'm no HTTP expert so I don't (currently) know any better.  Can you point me to the better solution you had in mind?

-MSK

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 14 Dec 2011 17:25:21 +0100

> Personally I'd also be interested in some comparison to using HTTP.

one possible issue with CoAP (compared to the DNS and HTTP transports) 
might be the portnumber (5683 as per 
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml). 
Some firewalls/ISPs will block this port and the organization that wants 
to set up a reputation service might not always be in control of the 
firewall settings.

/rolf

---

From: SM <[email-masked]>
Date: Wed, 14 Dec 2011 12:50:53 -0800

At 08:25 14-12-2011, Rolf E. Sonneveld wrote:
>one possible issue with CoAP (compared to the DNS and HTTP 
>transports) might be the portnumber (5683 as per 
>Some firewalls/ISPs will block this port and the organization that 
>wants to set up a reputation service might not always be in control 
>of the firewall settings.

I heard this argument before in other working groups.  It is 
generally about short-term deployment considerations.

I suggest reading draft-bormann-coap-misc-10 and 
draft-ietf-core-coap-08.  An interesting point is that "unlike HTTP, 
the cacheability of CoAP responses does not depend on the request 
method, but the Response Code".

It's worth considering CoAP if there is expertise within the working 
group to work with that protocol.  I don't have a strong opinion 
about it currently.

Regards,
-sm

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Dec 2011 14:08:01 -0700

On 12/14/11 6:41 AM, Dave CROCKER wrote:
> I should clarify that my question was not meant as a poll of preferences
> for or against using CoAP, but as an invitation to discuss technical
> merits.

Technical merits to accomplish what? Are there special requirements of
REPUTE that would compel us to use something other than HTTP?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "David F. Skoll" <[email-masked]>
Date: Wed, 14 Dec 2011 16:12:15 -0500

On Wed, 14 Dec 2011 14:08:01 -0700

> REPUTE that would compel us to use something other than HTTP?

I think so.  A reputation system may receive many queries and might want
to use a lightweight, completely-stateless mechanism to respond to them.
Traditionally, DNS has been (ab)used for this.

Regards,

David.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Dec 2011 14:15:27 -0700

On 12/14/11 2:12 PM, David F. Skoll wrote:
> I think so.  A reputation system may receive many queries 

So does Twitter. :)

(Hey, reputation over Twitter...)

> and might want

What exactly stateful about a mere HTTP request-response pair?

> Traditionally, DNS has been (ab)used for this.

Indeed. That doesn't mean we can't use HTTP.

Just trying to understand the requirements here...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 Dec 2011 13:16:19 -0800

> Behalf Of Peter Saint-Andre
> Sent: Wednesday, December 14, 2011 1:08 PM
> To: [email-masked]
> Cc: [email-masked]

One of the oft-cited applications of reputation that exists today is Spamassassin, which in some configurations can fire off a dozen or more DNSBL queries for a single message.  The idea of initiating that many HTTP queries for each arriving message sounds rather heavyweight to me.  That's why we've always had the idea of supporting a lightweight mechanism that just returns a score and has all kinds of implied context established outside the protocol between the client and the server (as DNSBLs do today), and a heavyweight one that has the capacity to be a lot more explicit about both the question and the answer.

Are some of my assumptions about the heavyweight nature of HTTP/XML faulty?

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Dec 2011 14:30:30 -0700

On 12/14/11 2:16 PM, Murray S. Kucherawy wrote:
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Peter Saint-Andre 
>> Sent: Wednesday, December 14, 2011 1:08 PM To: [email-masked] 
>> Cc: [email-masked] Subject: Re: [domainrep] Considering COAP
>> 
>> Technical merits to accomplish what? Are there special requirements
>> of REPUTE that would compel us to use something other than HTTP?
> 
> One of the oft-cited applications of reputation that exists today is
> Spamassassin, which in some configurations can fire off a dozen or
> more DNSBL queries for a single message.  The idea of initiating that
> many HTTP queries for each arriving message sounds rather heavyweight
> to me.  That's why we've always had the idea of supporting a
> lightweight mechanism that just returns a score and has all kinds of
> implied context established outside the protocol between the client
> and the server (as DNSBLs do today), and a heavyweight one that has
> the capacity to be a lot more explicit about both the question and
> the answer.
> 

Leif mentioned JSON, not XML. I'm agnostic on that here.

As to HTTP, there's lots of practical experience in making those
deployments scale to large numbers of requests per hour/minute,
spreading the load across multiple servers, caching responses, and all
the rest. I would not assume that HTTP can't do the job.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "David F. Skoll" <[email-masked]>
Date: Wed, 14 Dec 2011 16:30:38 -0500

On Wed, 14 Dec 2011 14:15:27 -0700

> What exactly stateful about a mere HTTP request-response pair?

TCP is stateful.  The end that does the active close has to hang
around in TIME_WAIT state for a while.  For HTTP, the server
usually does the active close and a busy server could be swamped
with TIME_WAIT TCP connections.

Regards,

David.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 14 Dec 2011 13:34:36 -0800

> REPUTE that would compel us to use something other than HTTP?

Peter,

You are already getting responses that are in line with the basis for this 
sub-thread, but just to offer the first-person explanation for asking it:

      1.  The group already has the distinction between an http-based transport 
and a "lightweight" transport for smaller query/response exchanges.  The logic 
for that distinction is, ummmm, distinct from the choice of the particular 
lightweight alternative.

      2.  CoAP was offered as an alternative to DNS or UDP based queries. 
Presumably there are technical differences that are interesting, among this set. 
  My above clarification was to solicit the technical information that permits 
comparing CoAP to these other choices.  Just doing straightforward due diligence.

On a personal note, I'll comment that using HTTP as the transport for very large 
numbers of very small query/response exchanges is somewhere between silly and 
offensive, for anyone trying to pay attention to latency and overhead issues. 
To quote that great systems designer, Richard Nixon, "We could do it, but it 
would be wrong".

In the real world, all sorts of 'wrong' things are done and this might turn out 
to be one of them. But it's worth some group time to explore alternatives.

Speaking as chair I'll assure you (and everyone else) that this is not going to 
become a rathole in the short- or long-term...

d/

-- 

   Dave Crocker

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 14 Dec 2011 22:35:20 +0100

> What exactly stateful about a mere HTTP request-response pair?

From the point of view of a server operator, those TCP connections underlying HTTP are state.
In the process of answering an HTTP request the server builds up kernel and socket state while engaging in the three-way handshake, then it uses that state to respond to the request, and finally it needs to tear down the state with the final FIN/ACK, causing TIME_WAIT states depending on who does this first.

This kind of state makes both plain scaling and DoS hardening harder.

Grüße, Carsten

[Just answering the question; I have no opinion on whether that is relevant with respect to repute's objectives.
E.g., the state can actually be a good thing if it helps congestion-controlling multiple requests that occur in a row, as in HTTP pipelining.  The usual legacy arguments about HTTP pipelining don't apply in the deployment scenarios I can imagine.  
That is proof by lack of imagination, though.
If your security objectives call for TLS/DTLS, you need to build up some state anyway.  The DoS protection may be much better with DTLS, though.  
And so on…  
I really need to know more about your objectives.]

---

From: SM <[email-masked]>
Date: Wed, 14 Dec 2011 13:40:22 -0800

>(Hey, reputation over Twitter...)

+1 :-)

>What exactly stateful about a mere HTTP request-response pair?

HTTP is stateless.  TCP is stateful.

At 13:16 14-12-2011, Murray S. Kucherawy wrote:
>more DNSBL queries for a single message.

Yes.

>   The idea of initiating that many HTTP queries for each arriving 
> message sounds rather heavyweight to me.  That's why we've always 
> had the idea of supporting a lightweight mechanism that just 
> returns a score and has all kinds of implied context established 
> outside the protocol between the client and the server (as DNSBLs 
> do today), and a heavyweight one that has the capacity to be a lot 
> more explicit about both the question and the answer.

The use of terms such as heavyweight and lightweight mechanisms does 
not provide much information.  A HTTP mechanism can be 
optimized.  That requires more work than DNS, for example, as the 
optimization is done at more than one layer.

Points of discussion could be:

   (a) round-trip

   (b) payload size

   (c) cacheability

Regards,
-sm

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Dec 2011 14:47:10 -0700

On 12/14/11 2:34 PM, Dave CROCKER wrote:
> You are already getting responses that are in line with the basis for
> this sub-thread, but just to offer the first-person explanation for
> asking it:
> 
>      1.  The group already has the distinction between an http-based
> transport and a "lightweight" transport for smaller query/response
> exchanges.  The logic for that distinction is, ummmm, distinct from the
> choice of the particular lightweight alternative.

Agreed.

> Presumably there are technical differences that are interesting, among
> this set.  My above clarification was to solicit the technical
> information that permits comparing CoAP to these other choices.  Just
> doing straightforward due diligence.

Yes, that's good.

> On a personal note, I'll comment that using HTTP as the transport for
> very large numbers of very small query/response exchanges is somewhere
> between silly and offensive, for anyone trying to pay attention to
> latency and overhead issues. 

Probably, but that doesn't stop people from doing stupid and offensive
things.

> To quote that great systems designer,
> Richard Nixon, "We could do it, but it would be wrong".

I thought Al Gore invented the Internet. :)

> In the real world, all sorts of 'wrong' things are done and this might
> turn out to be one of them. But it's worth some group time to explore
> alternatives.

For sure, I think it's a valuable exercise!

> Speaking as chair I'll assure you (and everyone else) that this is not
> going to become a rathole in the short- or long-term...

I don't see any rat-hole here yet, just constructive discussion and
probing questions.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 Dec 2011 13:53:02 -0800

> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Wednesday, December 14, 2011 1:31 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]

Two questions come to mind:

1) Does the same scalability go for clients, or a mail server that's waiting on a dozen or more replies?

2) Should we engineer this assuming that all HTTP servers are equipped with those optimizations?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 Dec 2011 13:54:59 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Wednesday, December 14, 2011 1:40 PM
> To: [email-masked]
> not provide much information.

They aren't meant to be completely descriptive, only comparative between themselves.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 14 Dec 2011 14:14:08 -0800

> Points of discussion could be:

A reference like "round-trip" usually refers to a single RT latency.

A separate issue is the /number/ of RTs, or "chattiness".

And, thought it's not required, these two can have inverse correlation:  a 
design environment that expects lower latencies will often produce protocols of 
higher chattiness.

(This is the reason that WAN protocols usually translate well to LAN 
environments, but LAN protocols rarely translate well to WAN environments.)

 > 2) Should we engineer this assuming that all HTTP servers are equipped with 
those optimizations?

It's reasonable to distinguish between per-query overhead, per-message (or the 
like) overhead, and "aggregate" server or client overhead of the type you describe.

Any serious discussion about performance and cost ought to run over all of these 
sorts of issues, to consider what matters and what doesn't.

d/
-- 

   Dave Crocker

---

From: SM <[email-masked]>
Date: Wed, 14 Dec 2011 14:10:49 -0800

Hi Murray,
>They aren't meant to be completely descriptive, only comparative 

I owe you an apology.  I understood what you meant.  I was focusing 
on characteristics and cut down on the explanation.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Wed, 14 Dec 2011 16:10:01 -0800

Yes.

>And, thought it's not required, these two can have inverse 
>correlation:  a design environment that expects lower latencies will 
>often produce protocols of higher chattiness.
>

Yes.

>equipped with those optimizations?

When we are talking about HTTP servers, I'll assume that it is on the 
server side.  HTTP servers are usually general-purpose.  Some of the 
optimizations come with caveats.  One of them might even be described 
as bordering protocol violation.  Let's assume that anyone running 
such a service has the necessary expertise to do so.

The latency issue is addressed currently by having the cache close to 
the client.  It's not a problem as such at the moment as the 
recursive DNS server also provides that feature.  For HTTP, you'll 
have to install a HTTP proxy nearby.  That may end up increasing the cost.

I used the term round-trip but it is incorrect.  What we are looking 
at is actually response time.  Unless one can afford the expense, a 
classic operation would be dealing with a response time of up to 300 
ms for example.  That would make filtering unworkable.  If you get 
cacheability near or as part of the client, the occasional high 
response time becomes acceptable.

BTW, the above covers "GET" mostly.  If I recall correctly, there was 
also some discussion about "POSTing".

Regards,
-sm

---

From: Chris Lewis <[email-masked]>
Date: Thu, 15 Dec 2011 01:22:06 -0500

> the rest. I would not assume that HTTP can't do the job.

It may not be appreciated how big "large" is.  I believe some of the 
largish DNSBLS are answering thousands of queries per second per server 
[+], and that's even with DNS caching.

I know I've been doing DNSBL type TXT lookups at speeds of 13,000/second 
and more (none cacheable) sustained for 5-20 minutes at a time, and the 
server scarcely noticed.  I think I was limited by the async query 
library I was using.

I wouldn't rule out HTTP at that level, but it's undoubtedly a lot more 
expensive.

[+] I keep thinking I remember comments from DNSBL operators talking 
about query levels one or two levels of magnitude higher than that. 
600K/sec rings a bell somehow.  I should go ask someone who knows.

---

From: Chris Lewis <[email-masked]>
Date: Thu, 15 Dec 2011 01:39:01 -0500

On 11-12-14 07:10 PM, SM wrote:

> I used the term round-trip but it is incorrect. What we are looking at
> is actually response time. Unless one can afford the expense, a classic
> operation would be dealing with a response time of up to 300 ms for
> example. That would make filtering unworkable. If you get cacheability
> near or as part of the client, the occasional high response time becomes
> acceptable.

Given how current high-volume filters using reputation services are 
implemented/optimized now, 300ms response times shouldn't be an issue. 
It's probably comparable to SMTP command/response turnaround in many cases.

SpamAssassin, for example, seems to have a nicely efficient asynchronous 
query mechanism that causes all the reputation queries to be launched at 
once, and each returned when they become available.

More specialized filtering systems, such as qpsmtpd and many of the 
commercial big iron implementations are much more optimized than that.

In the qpsmtpd build I did, I set the reputation query timeout to about 
10 seconds (all queries were were in parallel), and left it alone.  We 
had the occasional timeout, but the servers never had any problems 
coping.  This was at a goodly volume - at times, 50 emails/second and 
higher average throughput per server.

Tho, certainly, 300ms might be too high for other services you might 
want to protect with this.

---

From: Chris Lewis <[email-masked]>
Date: Thu, 15 Dec 2011 01:57:36 -0500

On 11-12-14 04:16 PM, Murray S. Kucherawy wrote:

> That's why we've always had the idea of supporting a lightweight mechanism that just returns a score and has all kinds of
and the server (as DNSBLs do today),

Right, thanks for reminding me.

I was asked whether there were examples of existing reputation 
infrastructure that relied on out-of-band context for meaning, because 
he couldn't think of one.  I replied "Lots.  Most DNSBLs do exactly that".

Many of the existing DNSBLs have an implied context that you have to 
find out from their web site.  Even within Spamhaus, the 
recommended/supported meaning/usage of each of their component DNSBLs 
varies. Some DNSBLs recommend you use them in scoring, not one-strike 
blocking.  Etc.

So there's ample precedent for implied context of a reputation service.

This probably isn't a good thing, because there are many times where 
DNSBL users use them in direct contradiction to how the DNSBL operator 
recommends.  It can cause extreme problems when the DNSBL user naively 
or purposefully ignores recommended usage.

I would prefer that "our" lightweight protocol whatever it may be had 
some sort of discovery/automatable context - reduces 
mistakes/misunderstandings at least.  Presumably we can borrow the 
heavyweight stuff for that.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 15 Dec 2011 06:08:09 -0800

On 12/14/2011 10:22 PM, Chris Lewis wrote:
> [+] I keep thinking I remember comments from DNSBL operators talking about query
> levels one or two levels of magnitude higher than that. 600K/sec rings a bell
> somehow.  I should go ask someone who knows.

We should probably query some lists with blocklist providers to get their 
estimates of scaling requirement.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 15 Dec 2011 06:13:41 -0800

On 12/14/2011 10:57 PM, Chris Lewis wrote:
> I would prefer that "our" lightweight protocol whatever it may be had some sort
> of discovery/automatable context - reduces mistakes/misunderstandings at least.
> Presumably we can borrow the heavyweight stuff for that.

When a protocol syntax or semantic is only distinguished by the address being 
used -- that is, tied to the provider.A client must know/do something different 
for every server it contacts and it must know what to do with each through some 
sort of configuration table that is set by hand.  This is the essence of a 
significant scaling limit.

The purpose of protocols is to make these things standardized.  So, yeah, a 
separate discovery protocol or an inline "capabilities" or "features" or 
"tailoring" mechanism are the usual ways to accomplish that.

d/
-- 

   Dave Crocker

---

From: "John Levine" <[email-masked]>
Date: 15 Dec 2011 15:43:05 -0000

>estimates of scaling requirement.

I can ask a few of them.

R's,
John