ietf-mxcomp
[Top] [All Lists]

Re: Choice of SMTP headers

2004-04-04 09:19:50

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>


<Prev in Thread] Current Thread [Next in Thread>