Dave Crocker <dcrocker(_at_)brandenburg(_dot_)com> wrote:
I think this particular disconnect between our terms of reference
occurs pretty frequently. You are describing a bunch of components
that exist.
Exactly.
Hence I believe you are thinking of "infrastructure" as referring to
a core set of routers over the "default free" (backbone) public
Internet. Hence, all of the email components under discussion are
outside the infrastructure.
No. The infrastructure is whatever is used to support the
deployment of a protocol. MTA's, routers, power grid, etc. all
support SMTP.
I am using the term infrastructure as describing a particular service
architecture. For example, a service that is a collection of user
nodes around a central server means that the server is an
infrastructure component and that the overall service is completely
centralized.
I agree.
I think that the difference between our points of view is even
subtler. I can't talk about infrastructure, deployment,
implementation, or anything except as in reference to real-world
components which do things. To people who view things on a different
level, this component-centric view is confusing.
To me, people who talk about infrastructure spend most of their time
talking about "goals of the infrastructure", or "intent", or "what's
good for the infrastructure". I don't understand that. The whole
point of the infrastructure is to DO something. The action of doing
something is performed by components in the infrastructure, so I talk
about those components, about what they do, and how they interact.
I don't know what's good for the infrastructure, except as how it
can be demonstrated to be good or bad for the individual components.
The sum of the good and bad for the components is what's good or bad
for the infrastructure (modulo interaction effects).
To me, the value judgment of "what's good for the infrastructure" is
a meaningless statement if it's not tied to components. It's like
saying "God told me it is good". That's nice, but not only does that
opinion have no foundation in real-world components, it can change
arbitrarily from day to day, without contradicting itself. Every day,
no matter what position it holds, the position is defined to be "God
told me it is good", and there's no concept that the position is
different than it was yesterday.
That's what I feel like is happening here. I'm pointing to
components in the network, and saying "implementing infrastructure for
RMX has costs A, B, and C for components X, Y, and Z. I believe that
the sum total of those costs is acceptable, as they prevent spam with
higher cost." Your posts respond with statements about the
infrastructure, which I can't relate to components within that
infrastructure. It then looks to me like there's an ever-changing set
of criteria that the components have to satisfy, in order to be
acceptable to some nebulous concept of "infrastructure".
I don't know what those criteria are, and I can't tell what they are
from your posts. All I can tell from your posts is that you're
opposed to deploying RMX, and that your opposition is often based on
things outside of the scope of what RMX touches. I find that
confusing and frustrating.
AD> We know how to do this. We can do this. It can take less than 3 years.
The number of components that need to participate in an MTA
registration scheme, the administrative overhead for the operations
staff, and the fact that this is all being retro-fitted into an
existing service all point towards much, much longer deployment times.
Which is why I've never talked about MTA registration schemes. I
talk about end-user registration schemes. Registering end-users in
order to access a service is a well-known problem, and easy to deploy.
VPN's, SSH, HTTP passwords, certificates, etc. all solve that problem
with minimal administrative overhead.
In many cases, all authentication for all services is done to a
central server. I know. I've deployed systems which authenticate
millions of users who use dozens of different protocols for different
purposes. The cost of deploying a new service is as small as
possible, because it's *designed* to be as small as possible.
In both cases, the concern I am raising is a) being careful and clear
about the nature and degree of impact, and b) the nature of the effect
from the change. (ie, cost/benefit.)
You've said in the past that deploying RMX prevents certain classes
of use which are currently acceptable, and indicated that that issue
was one reason why you opposed RMX. Such statements indicate to me
that there is an a-priori requirement that we change nothing, and
therefore do nothing.
Alan DeKok.