Folks,
I'd prefer everyone move to secure, authenticated mail exchange, but the
reality is that it hasn't occurred. Getting organizations --
particularly large ones -- to make widespread client-side changes would
be difficult.
AD> They upgrade laptops regularly. So there's already an existing
AD> model for deploying software upgrades. Wait 2-3 years, and deployment
AD> will have reached the majority of users.
I would like to encourage folks to be more cautious about these sorts of
assumptions.
There is a long track-record with making changes to the running
Internet. The track record is that new services -- as opposed to changes
to an existing service -- take 3-5 years to gain widespread deployment,
and that is only if they require no changes to the infrastructure. Try
to change an existing service or institute infrastructure modifications,
and the timeframe is 5-10 (and the upper bound really is longer than
that, with the lower bound rarely being that short.)
We can formulate all sorts of scenarios about incentives and coercion,
but the track record is the track record. We project something different
from that record only at our peril.
That said, there are things that can be done to make adoption easier or
harder: Flexible implementation choice aids adoption. Easy and scalable
deployment and administration aid adoption. Incremental benefit aids
adoption. Broad utility aids adoption.
MCL> For that reason, it'd be better to come up with a recommendation whose
MCL> impact is largely, or completely, server-side, and transparent to the
MCL> client and end-users.
The best place for a new bit of capability will depend on quite a few
user, organizational and technical factors. However, here is something
to think about:
A change that is architecturally designed to go into servers MUST go
into servers.
A change that is architecturally designed to go into end user systems
MAY go into end user systems or MAY be put into servers (to work on
behalf of the users.)
Think about the difference in flexibility.
MCL> SPF is an example of a server-side solution, with minimum impact on the
MCL> client and transparent to the end-user.
Let's see.
It requires end-users to pre-register the MTAs that they will use.
Otherwise, it breaks third-party MUA usage, and quite a bit of mailing
list usage, and otherwise-legitimate mobility scenarios.
I do not think I'd call that "transparent to the end-user".
MCL> Perhaps when we reach the point in the agenda where we're discussing
MCL> potential solutions, we should start by coming to agreement on the
MCL> criteria the solution should meet, and stick to working within those
MCL> constraints.
Yes!
EA> I think this has been proposed before, but for each proposal (including
EA> these kind of discussions), I think it would be very helpful for folks
EA> to articulate which constituent does the work and which problem it is
EA> supposed to solve.
This is such a stellar suggestion, I'm inclined to recommend that the wg
chairs formally require it.
JL> In IETF, we often attempt to deny costs;
I'd say we are more inclined to ignore them than to even spend the
effort to deny them...
JL> and we often consider it
JL> out of scope to try to balance costs and benefits...
Of course! It isn't any fun to do the balancing assessment.
JL> We tend to think, not in terms of constitutents, rather in terms
JL> of functions. Thus we talk of MTAs, not of the entities which
JL> operate them.
This is another one of those massively important bits of insight that we
need to keep in mind.
d/
--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>