Alan,
AD> 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.
AD> I understand. But I'm talking about work being done on concrete
AD> entities at the edge. You're talking about "infrastructure", without
AD> tying it to real-world entities. This leaves me floundering,
AD> wondering what the heck you're trying to get at.
interactions that rely on a central server cas that server as
infrastructure. that server is not at the edge. it is the core.
AD> What protocols does RMX interact with that aren't addressed in the
AD> current documents? What implementation costs haven't been
AD> acknowledged by people supporting RMX?
The effect on intermediaries is typically either dismissed or hacked
around, making the solution, itself, need fikxing.
AD> What deployment costs haven't been acknowledged?
large scale deployment costs, for usage scenarios outside the popular
set.
AD> What on-going maintenance costs haven't been
AD> acknowledged?
effect on various kinds of mobility.
AD> But we need to make *informed* decisions. So far, I haven't seen
AD> much in the way of information which addresses the above questions.
strange, since the details have been offered many times.
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.
AD> See ASRG archives for flame wars. I won't repeat them here.
You are asserting that I am making statements outside of scope, and I
have no idea what you are talking about. Referring to a massive
archive with no specific citation is not very helpful at providing a
basis for your assertion.
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> Exactly. SMTP also has localized deployment.
No it is not. SMTP is used -- without prior arrangement -- between
arbitrary, independent administrations around the global Internet. It
is difficult to think of a usage scenario that is LESS local.
Interaction between independent administrations, with no prior
arrangement between the administrations, strikes me as the ultimate
test of Internet-scale viability.
AD> The problem is that SMTP has non-localized deployment, too.
AD> e.g. Mail "from" a domain sent from sites not demonstratably
AD> associated with that domain. This is called "spam" in many cases, and
AD> is a problem that RMX addresses.
Unauthorized use of a name or address is not about locality vs.
non-locality. It is about authorization.
AD> Is there some other "infrastructure" thing I'm missing here? I can
AD> point to network diagrams of SMTP clients & servers, and point out
AD> which entities have to change, why they have to change, what the
AD> changes are, and what new protocols are used. I don't understand how
AD> there's anything else we need to talk about in the "infrastructure",
The intermediaries form an infrastructure. When there is relaying, it
is by infrastructure services.
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> RMX doesn't rely on central administration. Each independent domain
AD> administers it's own policies how it chooses. There is no need for
AD> interaction between domains, except as specified in the protocol
AD> proposal documents. Just like DNS. Just like SMTP. Just like HTTP.
AD> I don't see a problem here.
Having that are legitimate to use, but must first be registered with
some other, independent administration (the controller or the
originator's domain) creates a central administration style of
control, although yes, it makes for lots of central administrations.)
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.
AD> I have asked you in public and in private, in person and via email,
AD> what those costs are. The closest thing to an answer I've received is
AD> "the costs are higher than you think".
I've responded with rather more than that. In particular, the
administrative effort to handle various mobility scenarios can get
very high.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>