Last Call Review of draft-melnikov-smtp-priority-tunneling-
review-melnikov-smtp-priority-tunneling-genart-lc-thomson-2012-06-08-00

Request Review of draft-melnikov-smtp-priority-tunneling
Requested rev. no specific revision (document currently at 04)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-07-02
Requested 2012-06-07
Draft last updated 2012-06-08
Completed reviews Genart Last Call review of -?? by Martin Thomson
Secdir Last Call review of -?? by Shawn Emery
Assignment Reviewer Martin Thomson
State Completed
Review review-melnikov-smtp-priority-tunneling-genart-lc-thomson-2012-06-08
Review completed: 2012-06-08

Review
review-melnikov-smtp-priority-tunneling-genart-lc-thomson-2012-06-08

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-melnikov-smtp-priority-tunneling-02
Reviewer: Martin Thomson
Review Date: 2012-06-08
IETF LC End Date: 2012-07-02
IESG Telechat date: (if known)

Summary: This document is ready for publication as an Experimental
RFC, with one question.

Major issues: None

Minor issues:
I'm not sure that I agree with the SHOULD strength requirement on MSAs
or MTAs to strip mt-priority headers.  There's a marked difference
between failure to meet local preconditions for compliance and
whatever conditions some other MTA might place on mt-priority
observance.  GIven that each hop is expected to make their own
determination about priority anyway, what benefit is there in removing
information that might inform that choice?

Nits/editorial comments:
Section 7, check grammar: "within a close environment) ."
Section 7.1: I don't like statements like "has pros and cons" without
any guidance.  The pros and cons are probably easy to describe (they
seem intuitively obvious), so they are either important enough to
describe or not worth mentioning at all.  Either is better than the
tease.