Dave Crocker <dcrocker(_at_)brandenburg(_dot_)com> wrote:
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 understand. But I'm talking about work being done on concrete
entities at the edge. You're talking about "infrastructure", without
tying it to real-world entities. This leaves me floundering,
wondering what the heck you're trying to get at.
What protocols does RMX interact with that aren't addressed in the
current documents? What implementation costs haven't been
acknowledged by people supporting RMX? What deployment costs haven't
been acknowledged? What on-going maintenance costs haven't been
acknowledged?
The answers to those questions will cover any and all concerns about
"infrastructure". If it can be shown that RMX is too expensive for
what it does, then we can throw it away.
But we need to make *informed* decisions. So far, I haven't seen
much in the way of information which addresses the above questions.
There's just been vague assertions, with hand-waving about
"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.
I haven't seen that. What I have seen is people asking "WHAT
implications and WHY". There hasn't been much in the way of concrete
answers to those questions. I can see why it looks like those
implicications are being dismissed out of hand. They're not. They're
being dismissed until such time as there are concrete items for
discussion.
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.
See ASRG archives for flame wars. I won't repeat them here.
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.
Exactly. SMTP also has localized deployment. So the methods I
cited work just as well for SMTP.
The problem is that SMTP has non-localized deployment, too.
e.g. Mail "from" a domain sent from sites not demonstratably
associated with that domain. This is called "spam" in many cases, and
is a problem that RMX addresses.
Is there some other "infrastructure" thing I'm missing here? I can
point to network diagrams of SMTP clients & servers, and point out
which entities have to change, why they have to change, what the
changes are, and what new protocols are used. I don't understand how
there's anything else we need to talk about in the "infrastructure",
which is necessary for the deployment of RMX. And so far, you haven't
given me any indication that there is anything else to talk about.
You've just used the word "infrastructure" like it's some kind of
magic buzz-word, which stops all arguments.
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.
RMX doesn't rely on central administration. Each independent domain
administers it's own policies how it chooses. There is no need for
interaction between domains, except as specified in the protocol
proposal documents. Just like DNS. Just like SMTP. Just like HTTP.
I don't see a problem here.
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.
I have asked you in public and in private, in person and via email,
what those costs are. The closest thing to an answer I've received is
"the costs are higher than you think".
The focus on costs isn't obstructionist. The refusal to quantify
those costs is.
Alan DeKok.