Sam, et al.
Dave I see a number of people here saying that they like Keith/Bill's
model better. Can you help us examine things at a technical level by
explaining how treating both the organization's MUAs, MSAs and the
ISP's MTAs as part of the same MON would produce undesirable or
insufficient requirements? How would treating them as separate COGs
produce more desirable behavior?
Well, heck. If you are going to ask such a reasonable and potentially
productive question, seeking to understand the different perspectives, I
guess I'll have to try to respond reasonably and (potentially) productively...
A requirement for this discussion is familiarity with
"Tussle in Cyberspace: Defining Tomorrow’s Internet"
<http://www.acm.org/sigs/sigcomm/sigcomm2002/papers/tussle.pdf>.
A reasonable summary of it is powerpointed at
<http://www.cse.lehigh.edu/~brian/course/advanced-networking/presentations/Tussle.ppt>).
Now let's take a look at the definition of the construct that I put forward:
"a collection of Internet Mail service components
subject to unified administrative operations control"
I believe a single term is warranted, to be applied to each collection if
components that are subject to unified control. My reasoning is pretty simple:
1. The construct pertains to the boundaries between unified administrative
policy environments, not to the details within those environments.
So, the criteria are simply the presence of administrative coherence
and the boundaries between environments of that administrative coherence.
2. Like any good system design, a good architecture is marked by being
unable to remove anything from it, rather than by bulking it up with
unnecessary variations in terminology and components.
The variations are important operationally, of course, but only as
derivative, not as core constructs.
The two counter-suggestions in this thread are:
1. Have the architecture use different terminology to distinguish unified
control of the originator's environment from the unified control of a
recipient's environment.
Email policy-making and administration are typically done by a single
authority. It is not at all typical to have different authorities determine
an organization's sending policies and practises from that same
organizations receiving policies and practises.
More generally, email is about communication between entities
(individuals and organizations.) That a single transmission has a
particular directionality tends to distract us from the broader perspective
that a single transmission is part of a dialogue or group exchange. When
designing an architectural construct to reflect policy and operations, it
should be targeting this higher-level of abstraction, not the lower-level
mechanics of a single transmission.
2. Distinguish only originators and recipients, with no means of
distinguishing independent policies for transit environments, since they are
merely agents of the originator or the recipient.
Each administration in the email process can have its own policies,
independent of those of the originator or the recipient.
So when I plug my laptop into a hotel network and try to post mail
from my laptop's MUA to my email provider's MSA, the fact that the hotel
blocks port 25 means that it is not merely acting as an agent of my (the
originator) or of the recipient. They have their own, independent policies.
Thus, every coherent administrative environment needs to be identified
distinctly. Characterizing any intermediary site as merely an agent of the
originator or the recipient is plainly incorrect.
d/
ps. We do not have different architectural terms for the autonomous system
of an IP sender from that of an IP receiver? Why not?
--
Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf