I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments you 
may receive. Please wait for direction from your document shepherd or AD 
before posting a new version of the draft.

Document: draft-melnikov-smtp-priority-09
Title: Simple Mail Transfer Protocol extension for Message Transfer Priorities
Reviewer: Claudio Allocchio, GARR
Review Date: March 28th 2012
IETF Last Call Date: 2012-03-28
IESG Telechat Date: n/a

Summary:

In its declared scope, this document provides a mechamism (and 
implementation suggestions) in order to enble a "real" priority delivery 
service into the global e-mail handling scenario.

However, it also introduces a concept idea on how to "tunnel" new SMTP 
parameters requests via MTAs which do not support and ignore them, 
embedding them into e-mail Heders fields. In doing this it breaks the 
ideal separation between Envelope (SMTP) and Content (Headers and 
bodyparts) in a different a new way than it was done before, because is 
causes Headers to be able to modify Envelope parameters. There is no 
negative consideration in this, but this feature should also be stated 
more explicitly in the introduction.

In general the document is well specified, and no major technical issues 
are present. However I suggest yet another turn of consideraion for the 
state iself of the specification: the WG and many others propose to go 
into Standards Track, but in order to do this there are at least some more 
exlicit considerations to clarify into the text itself. Also, it is not 
easy to guess what will be the adoption level of this mechanism, and the 
risk introduced by possible inaccurate implementations shall also be 
evaluated before going Proposed Standard.


Major Issues:

The first major issue is non-technical. The e-mail service via SMTP (and 
gateways and other related transport protocols) is best-effort, often 
first-in/first-out based. And by itself, e-mail is a non real-time 
service, like a chat, or text broadcast services: it is delivered into a 
mailbox where the recipient will read it at his/her will. Although many 
mail clients now uses a push-like model, delivering messages on "always 
on" devices, the proposed new service extension aims to provide 
differentiated service among messages. As correctly stated into the 
document iself, there is a parallel between this and network transport 
level services, where packets are prioritised. But also in this case, the 
proposed mechanism will start to produce benefits only when congestion in 
some parts of the mail transport system exists. When congestion does not 
exist, the mechanisms will not result in better service. This is not a 
drawback, but it should be stated more explicitly in the document. Maybe 
expanding it into the 5.4 section, where comparison with RFC2474 and 
RFC2205 are done.

The other major issue to consider is the global trust model which is 
needed to implement the mechanisms. There are suggestions in the 
specification on how to enhance security when tunnelling across non 
supprting MTAs, for example, but in the document there are also other 
suggestions which consider the extension applicable easily only within 
restricted trusted communities. This apparently contradictory point shall 
be explained better. If this specification is going Proposed Standard, it 
shall be crystal clear about these scenarios, because implementers who did 
not take part in the original discussion will implement it, and thus all 
pre-assupmtions made during the discussion process of the specification 
discussion will not be available for them.

Minor Issues:

There is no discussion (explicit) about how this specification 
interacts/interferes with anti-spam techniques like graylisting / 
whitelisting. Section 5.1 suggests that shorter retry times shall be used 
for higher priority messages, but it does not mention at all graylisting, 
for example. This should be explicitly mentioned, and some guidance / 
suggestion given, to ensure a coherent behaviour.

The sentence in section 2 "The most important reason for emails to be 
delayed is a transient error response from the next MTA to which the email 
must be transferred." should also explicitly refer to the graylisting case 
(which also causes often a "reply" message to be delivered before the 
original message is).

Section 4.2: why allowing an X-something like X-Priority to be used? I 
understand why not "Importance" and why yes "Priority"... but...
Maybe this specification should "update" or even attempt to Obsolete 
partially RFC2156?

Section 4.5: the text say that in case of mailing lists and aliases the 
Header parameters tunnelling this specification extension SHOULD retain 
the original priority. What about the many implementations where headers 
are completely re-written and many parameters just disappear? Some 
sentence should be given aout this case, too.

Section 4.6... not all "non e-mail" environment allow addition of an 
"header field"... how do we handle this?

Section 9: given the current architecture, I'm very worried this will 
ALWAYS happen (different behaviours because different support at various 
MX-pointed servers). I'd make the consideration more explicit and suggest 
a stronger guidance.

Appendix A, B, C are very environment specific. Appendix A and C, however, 
seem very specific environment related (the NATO messaging military 
convetions for "A" and the USA Civil Protecion service for "C"). While "B" 
is really global, beacause it maps OSI X.400 service, the other two 
appendix seems too environment specific for an international standard RFC 
specification. I would suggest handling at least "A' and "C"  not as 
appendixes of this document, but as separate short "mapping 
specification", also to enable further similar documents to be 
published/registered more easily for other environments.

Nits:

none.

Best Regards!

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          Claudio.Allocchio@garr.it
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca