Re: [Ieprep] Discussion of Internet-Draft for SMTP priorities (UNCLASSIFIED)

Michael Schmeing <schmeing@fgan.de> Tue, 13 June 2006 04:51 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq0ro-0004zt-4G; Tue, 13 Jun 2006 00:51:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq0rn-0004zo-3U for ieprep@ietf.org; Tue, 13 Jun 2006 00:51:03 -0400
Received: from mailguard.fgan.de ([128.7.3.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq0rk-0003Oo-FV for ieprep@ietf.org; Tue, 13 Jun 2006 00:51:03 -0400
Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with smtp (Exim 4.50) id 1Fq0ri-0002nY-OU; Tue, 13 Jun 2006 06:50:58 +0200
Received: from nordhorn.fkie.fgan.de ([128.7.5.132]) by mailhost.fgan.de with smtp (Exim 3.36 #5 (Solaris)) id 1Fq0rh-0003Ld-00; Tue, 13 Jun 2006 06:50:57 +0200
Received: by nordhorn.fkie.fgan.de (sSMTP sendmail emulation); Tue, 13 Jun 2006 06:50:57 +0200
Date: Tue, 13 Jun 2006 06:50:57 +0200
From: Michael Schmeing <schmeing@fgan.de>
To: "Nguyen, An P CIV NCS NC2" <an.p.nguyen@dhs.gov>
Subject: Re: [Ieprep] Discussion of Internet-Draft for SMTP priorities (UNCLASSIFIED)
Message-ID: <20060613045057.GA2448@nordhorn.fkie.fgan.de>
References: <9B4320CC9BC1D847AFFA97F25A422A59114AE9@vanualevu.disanet.disa-u.mil>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9B4320CC9BC1D847AFFA97F25A422A59114AE9@vanualevu.disanet.disa-u.mil>
Organization: Forschungsgesellschaft fuer Angewandte Naturwissenschaften e.V. (FGAN)
User-Agent: Mutt/1.5.11+cvs20060403
X-Virus-Scanned: yes (FGAN VirusScan III)
X-Scan-Signature: 306d475cb774b7f15678e7079d6bc338
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7
Cc: ieprep@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Errors-To: ieprep-bounces@ietf.org

On Mon, Jun 12, 2006 at 10:43:42AM -0400, Nguyen, An P CIV NCS NC2 wrote:
> Classification:  UNCLASSIFIED 
> Caveats: NONE
> 
> Michael,
> 
> I have the following questions:
> 
> 1. Is this draft intended for DOD only? When I first scanned the draft,
> my impression is that it's written for DoD. If not, the text should be
> rewritten to reflect it. 

An,

you are right: The draft actually was written as part of an ongoing
research project from the german MoD. This of course shows in the
wording. But we want its scope to be broadened beyond this. So yes,
the text should be rewritten.

> 
> 2. I know SMTP uses a store and forward approach, with messages being
> held at a sequence of MTAs (Message Transfer Agents) en route from
> originator to recipient. I think messages with higher priority would get
> processed first ( while mgs with lower priority might have to wait in
> the queue). 

That at least ist the general idea.

> They would be rerouted to the another MTAs because of failed links
> (e.g., dns problem, layer 3 disconnect, etc). And you use SMTP
> priority values to differentiate QoS for different messages. In
> order for this scheme to work, you would have a policy that forces
> all MTAs within a admin domain to accept/honor these priority
> values; otherwise, this would not work at all.

At least in the military domain (especially NATO) this is how it is
supposed to work with their X.400 based systems.

> Let's assume that you can do it in a single admin domain. How are
> you going to deal "global" configurations in MTA's in multiple
> domains so that you would get some levels of QoS?

You are touching here one of the major points that need to be
clarified before the extension can be standardized. I don´t have any
clear idea of what needs to or can be done with respect to this
question.


Regards, Michael
-- 
****************************************************
| Michael Schmeing       E-Mail:  schmeing@fgan.de |
| FGAN/FKIE              Tel: (+49) 228/9435 593   |
| Neuenahrer Strasse 20  Fax: (+49) 228/9435 685   |
| D-53343 Wachtberg, Germany                       |
****************************************************
> -----Original Message-----
> From: Michael Schmeing [mailto:schmeing@fgan.de]
> Sent: Monday, June 12, 2006 9:02 AM
> To: ieprep@ietf.org
> Subject: [Ieprep] Discussion of Internet-Draft for SMTP priorities
> 
> 
> Hello all,
> 
> sorry it took so long for me to get back to you, but it has been a
> very busy time. As there appears to be some interest in at least
> discussing the draft, I will start by summarising Dan Wings´s input
> (both his submissions to the list and his suggestions he made directly
> to me) and give my view on these suggestions.
> 
> Dan´s first suggestion in his email directly to me was to use priority
> levels 0, 100, 200, 300 and 400 instead of 0, 1, 2, 3 and 4. As the
> length of the priority identifier is now limited to three digits, I
> think that is a valid suggestion. I plan to include that in the next
> version of the draft, unless someone can give good reasons to stick
> with the old scheme or use a completely new one.
> 
> Another of Dan´s suggestions in that email was to use the IANA to
> register the priority levels. He mentions that this would remove the
> problem with the Priority: and Precedence: header fields where some
> vendors use keywords and others (numerical) values.
> 
> I am not sure it is really required to register the priority levels
> with IANA basically for two reasons:
> 1. The draft (and therefore the standard if it ever comes to that)
>    defines the allowed value of the PRIORITY keyword to be only a
>    numerical value. Thus the problem with the AFAIK not standardised
>    header fields can not occur: Anyone conforming to the standard has
>    to use numerical values according to the priority policy
>    indicated. If anyone decides not to obey the standard, they would
>    not care about IANA registration either.
> 2. The provided policy is only an example. Priority policy enforcement
>    across administrative domain boundaries is difficult to say the
>    least. For the general Internet, the most that I expect to be
>    realistic is some form of Quality-of-Service, where Internet
>    Providers would transport emails (or any other content) of some
>    customers (which probably have to pay extra for this) more quickly
>    than the traffic of other customers (keyword: net
>    (non-)neutrality). They would define their own policy with their
>    own priority levels for the use of email priorities, if they allow
>    their customers to downgrade their service level on a
>    per-email/per-connection basis.
> If, on the other hand, the group feels that we should go for IANA
> registration, that is fine with me. In that case, I would just ask
> someone to provide a wording example for this, because I have never
> done it yet.
> 
> A problem Dan mentions in his email to the mailing list is the problem
> of authorisation. He asks the question of what will stop him from
> using highest priority on all emails and says that it can be solved
> within an administrative domain but probably not across them.
> 
> As I have already indicated above, I see this problem as well.
> 
> When I created the I-D, it was for a scenario of cooperating
> administrative domains and thus, this problem did not present itself:
> The domain administrations had agreed on a policy for the use of
> priorities.
> 
> Of course, one thing preventing excessive use of high priorities is
> the size limit on high-priority emails. You can not put much data in
> two or four kilobyte, so you have to use lower priorities for larger
> emails.
> 
> Other than that, I only have one rough idea so far how this issue
> could be addressed in a general case that I would like your opinion
> on: The policy could impose a frequency with which one sender may
> issue emails of the higher priorities. Together with the smaller size
> of high-priority emails that should guarantee at least some space for
> lower priority emails
> 
> 
> 
> Best regards,
> Michael Schmeing
> -- 
> ****************************************************
> | Michael Schmeing       E-Mail:  schmeing@fgan.de |
> | FGAN/FKIE              Tel: (+49) 228/9435 593   |
> | Neuenahrer Strasse 20  Fax: (+49) 228/9435 685   |
> | D-53343 Wachtberg, Germany                       |
> ****************************************************
> 
> _______________________________________________
> Ieprep mailing list
> Ieprep@ietf.org
> https://www1.ietf.org/mailman/listinfo/ieprep
> Classification:  UNCLASSIFIED 
> Caveats: NONE
> 

_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep