Re: [Gen-art] Gen-ART review of draft-melnikov-smtp-priority-tunneling-02

[Alexey Melnikov <[e-mail]>]

Hi Martin,
Thank you for the review.

On 08/06/2012 18:47, Martin Thomson wrote:
> 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?
Are you talking about the Security Considerations section?

When relaying to non MT-PRIORITY-capable MTAs, the sender already has to 
remove all MT-Priority header fields (MUST level requirement), because 
it has to insert the priority value it calculated according to its 
policy into a new MT-Priority header field. The calculated value might 
be different from the value it received.

But now that I am looking at the two sections ("Security Considerations" 
and "Relay of messages to non-conforming SMTP servers"), they might be 
out of sync as far as requirements are concerned. So I need to tweak one 
or both of them to match.

> Nits/editorial comments:
> Section 7, check grammar: "within a close environment) ."

Fixed, thanks (s/close/closed).

> 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.

This is just trying to say that none of the solutions is perfect for 
everybody. I will try to reword.