Re: email "Common Operating Group"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]