Subject: RE: [Asrg] Spam Control Complexity -- scaling, adoption, diversit y and scenarios

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 19 Apr 2003 16:07:41 -0700

I take issue with the core versus the edge argument. I know it is IETF
theology but that does not make it true.

It is empirically easier to deploy changes at servers than in mail clients.
It takes three to five years to deploy new client software to a significant
number of users. In comparison it is not that difficult to get the leading
ISPs to deploy server upgrades for the infrastructure that supports 60% or
more of the Internet end-users.

The real deployment hurdle is any system that requires double ended adoption
to provide value. Next to that problems are caused by systems that require
one party to bear the cost while the benefit will be felt by another.

	Phill
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Dave Crocker <[email-masked]>
Date: Sat, 19 Apr 2003 18:19:25 -0700

Phillip,

HBP> I take issue with the core versus the edge argument. I know it is IETF
HBP> theology but that does not make it true.

I'm not too interested in theology, either.  Pragmatics are far more
useful.

HBP> It is empirically easier to deploy changes at servers than in mail clients.

No doubt you have empirical data to substantiate your empirical
assertion.

So, please cite some major enhancement to an Internet-scale,
Internet-diversity, existing service, that could have been done either
in an edge fashion or a core fashion, that went quickly (or at all)
through core deployment, rather than edge.

My own counter-example will be multi-media mail, which failed to deploy
through a core approach in spite of 2 or three eager efforts over a 10
year period, while MIME became useful within the first year of its
release.

HBP> The real deployment hurdle is any system that requires double ended adoption
HBP> to provide value. Next to that problems are caused by systems that require
HBP> one party to bear the cost while the benefit will be felt by another.

"doubled ended" sounds like a dandy term.  what does it mean?

if it means "at both ends" then i would be quite interested to hear how
any enhancement that involves interoperability can be useful if deployed
to only one component.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: "Tom Thomson" <[email-masked]>
Date: Tue, 22 Apr 2003 14:58:48 +0100

Dave Crocker wrote on 20 April 2003 02:19

> any enhancement that involves interoperability can be useful if deployed

Example 1:
Email filteroing for viruses.  Implemented at receiver's end.  Or at
sender's end.  Doesn't matter which.  Doesn't have to implemented at both
ends for parties who wish to interoperate.  Implement at receiver's end only
if you don't wish to interoperate with deliberate transmitters of viruses.

Example 2:
Spam filtering using a reliable BL.  Implement at receiver's end.  Implement
at sender's end if you think of sender as including ISP MTA as well as
end-user MUA.  But don't implement at receiver's end if you don't want to
interoperate with spammers.

Frankly, I think your comment is crazy. I could go on listing enhancements
that can be applied at one end or at the other end or at both ends and still
allow all required interworking until I got writer's cramp, and still would
not have listed all the ones that I have seen implemented.

Tom Thomson

---

From: Dave Crocker <[email-masked]>
Date: Tue, 22 Apr 2003 08:20:12 -0700

Folks,

There seems to be some confusion about the nature of a networking
standard.

Networking standards are very different from software development.
They specify conventions for inter-operation.  That is, they provide
for some type of interaction that has functions and formats that are
pre-speicified (ie, standardized.)

So if this group has any interesting in doing work that leads to
networking standards that pertain to control of spam, it needs to
focus on conventions for interaction between Internet systems.  That
is, protocols for relevant distributed functionality, and formats for
relevant shared information.

The list that Vernon produced provides some excellent examples.  By
contrast, simply saying that there is a component somewhere in the
system -- such as a filter -- does *not* provide a useful example,
unless there is an indication of the types of conventions that should
be standardized, to permit the filter to do its job.

d/

TT> Dave Crocker wrote on 20 April 2003 02:19

>> any enhancement that involves interoperability can be useful if deployed

TT> Example 1:
TT> Email filteroing for viruses.  Implemented at receiver's end. Or at
TT> sender's end.  Doesn't matter which.  Doesn't have to implemented at both
TT> ends for parties who wish to interoperate.  Implement at receiver's end only
TT> if you don't wish to interoperate with deliberate transmitters of viruses.

TT> Example 2:
TT> Spam filtering using a reliable BL.  Implement at receiver's end.  Implement
TT> at sender's end if you think of sender as including ISP MTA as well as
TT> end-user MUA.  But don't implement at receiver's end if you don't want to
TT> interoperate with spammers.

TT> Frankly, I think your comment is crazy. I could go on listing enhancements
TT> that can be applied at one end or at the other end or at both ends and still
TT> allow all required interworking until I got writer's cramp, and still would
TT> not have listed all the ones that I have seen implemented.

TT> Tom Thomson

d/