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

[Michael Schmeing <[e-mail]>]

On Mon, Jun 12, 2006 at 02:07:22PM -0400, Janet P Gunn wrote:
> 
> 
> 
> 
> I have a bunch of detailed comments, which I am still working on, but I
> also have some high level questions/comments, which I will include here.
> 
> This ID clearly addresses a set of email requirements (not fully documented
> here) tied to the US DoD.

That is hardly surprising, since it was created during an ongoing
research project for the German MoD as I have already said.

> 
> While they haven't been set down yet, it is anticipated that there will be
> a set of priority requirements for NS/EP (National Security and Emergency
> Preparedness) email, which are likely to be somewhat different from the
> military requirements.  And I expect there will be other requirements from
> other parts of the world.
> 
> It would be nice if we had a more general solution, which could encompass a
> variety of related but distinct requirements.

Jan and I devided the I-D into two parts: A generic framwork and a
policy. The framework (which is the main part of the draft) should
allow for as much flexibility as possible. If there are restrictions
defined in that part, that are not necessary or are too specific, they
should be removed or rewritten.

The policy in Sec. 6.5 on the other hand is intended to be a concrete
example of some of the possibilities designers have when creating
their own policy. It is clearly inspired (and targeted) at the
Military Message Handling Systems (MMHS) of NATO as it stems from
there.

While the draft currently says this is the default policy, I have
since come to doubt whether the policy is really fit for general use
in the Internet. It may be a good idea to split the draft up into one
for the framework and one for an example policy.

> 
> The SIP RPH (RFC4412) (on which the IEPREP WG had significant input) has a
> more general structure which allows it to encompass both the (pre-emption
> based) MLPP functionality and the (queuing based)GETS/WPS/ETS
> functionality, by the use of (IANA registered) namespaces.
> 
> Is there a reason why we couldn't do something analogous for email?

I don´t know these standards so I don´t know if it is possible for
emails. But I think it should be.

> 
> Some of the specific areas where there might be  different requirements:
> 
> This draft focuses on “rapid delivery”  or “order of delivery” rather than
> “high probability of delivery”.  In fact, it stipulates that, for some
> priority levels, if the email cannot be delivered “with priority”, it
> should be rejected (see section 6.5.7).  I can think of many situations
> where it is better to continue with non-priority delivery than to reject an
> email.

As said above, Sec. 6.5 presents a specific policy. Give Jan´s and my
knowledge of military messaging, it seemed plausible that messages
with higher priority are as well of higher sensitivity. Therefore we
decided to split the defined priority levels up into the higher ones
which may not be transferred with non-priority and the lower ones
which may.

For other scenarios the reasoning may be different and the decission
may be another one. In this case, the applicable policy would just
have to define when to continue with non-priority (or just a lower
one?) and when to reject.

Please bear in mind that the given policy is not meant to be an
exhaustive example. You can make the algorithm deciding when to go
non-priority and when to reject or do something else as complex as you
like (or need to).

As the general default (in case the policy does not deal with this
topic), I feel that rejection is the right choice though. If you
deploy priorities you have a reason to and thus silently going
non-priority is probably not what you want.

> 
> There might be circumstances in which "preemption" of  current email
> transmissions is not desired, but "moving high priority emails to the front
> of the queue" IS desirable.  It would be nice if the mechanism could
> support both approaches.

Indeed it would. And it should be this way either (so I would be
thankfull for a suggestion of a better wording), but the final
decision whether to preempt or just move to the top of the queue
should by all means remain with the policy.

> 
> I understand the rationale for limiting the size of the high priority
> emails, but I can think of situations where other mechanisms might be a
> more appropriate way to make sure that  the overall "high priority" volume
> remains low.

Agreed. But the actual size limitation is (again) only in the
policy. The framework just says that a size limitation is imposed, it
is to be respected (or at least that what it should read like).

In the military context, there are other means deployed, but we did
not want to make the policy too complex. One these means is that they
strictly limit the nature of messages that may be sent at highest
priority (AFAIK in Germany only the message that an enemy division or
corps has first been discovered may be sent at highest priority).

> 
> Current implementations of  MLPP, eMLPP, WPS, and RPH use 0 to represent
> the high priority group, with 1.2.3.4, etc representing successively lower
> priorities.  What is the rationale for turning this upside down and using 0
> to represent "non-priority"?

One of the conditions of the draft is that normal
(i.e. non-prioritiezed) email from the Internet can still be
handled. To achieve this, we need a unique way to identify such
emails. The only sensible options Jan and I could think of were either
to mandate that such emails MUST NOT have the priority keyword added
to the recipients or to define a fixed identifier. We decided on the
identifier approach because it was easier to implement.

Originally, the length of the identifier was unlimited. That meant
that 0 was the only number that was guaranteed not to punch a hole
into the series of priority levels defined by any policy conforming to
the framework.

As the length of the priority identifier has been limited to three
digits in the current version, it would be no problem to reverse the
semantics of identifier (i.e. make lower numbers denote higher
priorities). The non-priority would then be fixed to the value of 999.

> 
> Why would the fact that a message is unclassified imply that it is lower
> priority?  I don't see the correlation.

Neither do I. This is just an example of some constraints a policy may
impose that inlude considerations from a content oriented perspective.

> 
> 
> Thanks,
> 
> Janet


Thanks for the input,
Michael
-- 
****************************************************
| Michael Schmeing       E-Mail:  [e-mail] |
| FGAN/FKIE              Tel: [phone]   |
| Neuenahrer Strasse 20  Fax: [phone]   |
| D-53343 Wachtberg, Germany                       |
****************************************************

_______________________________________________
Ieprep mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ieprep