Alan,
AD> To me, the value judgment of "what's good for the infrastructure" is
I don't recall saying anything about the "value" of the
infrastructure. I recall distinguishing between work done in the
infrastructure, versus work done at the edges. I also recall saying
that deployment through the infrastructure usually is far more
difficult and takes far longer (to gain a level of utility) than
deployment through the edges.
AD> Your posts respond with statements about the
AD> infrastructure, which I can't relate to components within that
AD> infrastructure.
glad to pursue the details. however at this point, i do not know
which statements need clarifying.
AD> It then looks to me like there's an ever-changing set
AD> of criteria that the components have to satisfy, in order to be
AD> acceptable to some nebulous concept of "infrastructure".
interesting you express this concern. my own view is that every time
there is an attempt to get at the core criteria -- by looking at the
implications of particular proposals -- the difficult parts are
dismissed by folks.
AD> I don't know what those criteria are, and I can't tell what they are
AD> from your posts.
That is because I am still trying to get folks to look at
implications, so there can be legitimate review of trade-offs.
AD> All I can tell from your posts is that you're
AD> opposed to deploying RMX, and that your opposition is often based on
AD> things outside of the scope of what RMX touches.
oh? please explain.
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.
AD> Which is why I've never talked about MTA registration schemes. I
AD> talk about end-user registration schemes.
The RMX-category of schemes call for registering authorized MTAs.
AD> Registering end-users in
AD> order to access a service is a well-known problem, and easy to deploy.
AD> VPN's, SSH, HTTP passwords, certificates, etc. all solve that problem
AD> with minimal administrative overhead.
In fact, most of these do not have generalized deployment. They have
localized deployment. The password/certificate that you use for one
location is different than for another.
AD> In many cases, all authentication for all services is done to a
AD> central server. I know. I've deployed systems which authenticate
AD> millions of users who use dozens of different protocols for different
AD> purposes.
The challenge in development wide-spread Internet services is to make
them work across many _INDEPENDENT_ administrations. Schemes that
rely on central administration cannot do this.
AD> You've said in the past that deploying RMX prevents certain classes
AD> of use which are currently acceptable, and indicated that that issue
AD> was one reason why you opposed RMX. Such statements indicate to me
AD> that there is an a-priori requirement that we change nothing, and
AD> therefore do nothing.
There are a number of ways to respond to a focus on a cost. One is to
declare the cost irrelevant. Another is to declare the focus
obstructionistic.
And, of course, another is to factor in the additional cost into the
realistic calculation of cost versus benefit.
d/
--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>