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

ken carlberg <carlberg@g11.org.uk> Tue, 13 June 2006 15:58 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqBI8-00043B-Rx; Tue, 13 Jun 2006 11:58:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqBI8-000436-0W for ieprep@ietf.org; Tue, 13 Jun 2006 11:58:56 -0400
Received: from hermes.hosts.co.uk ([212.84.175.24] helo=pallas.hosts.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqBI6-0001ne-Jk for ieprep@ietf.org; Tue, 13 Jun 2006 11:58:55 -0400
Received: from [69.138.71.89] (helo=[192.168.1.2]) by pallas.hosts.co.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from <carlberg@g11.org.uk>) id 1FqBHr-0002jc-2M; Tue, 13 Jun 2006 16:58:40 +0100
In-Reply-To: <20060612130135.GD9821@nordhorn.fkie.fgan.de>
References: <20060612130135.GD9821@nordhorn.fkie.fgan.de>
Mime-Version: 1.0 (Apple Message framework v750)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <AFFB0D31-7CA6-4CD3-8094-7BBD234F755F@g11.org.uk>
Content-Transfer-Encoding: 7bit
From: ken carlberg <carlberg@g11.org.uk>
Subject: Re: [Ieprep] Discussion of Internet-Draft for SMTP priorities
Date: Tue, 13 Jun 2006 11:58:48 -0400
To: Michael Schmeing <schmeing@fgan.de>
X-Mailer: Apple Mail (2.750)
X-Spam-Score: -4.4 (----)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
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

Hello Michael,

I would like to echo Janet's request of putting in place a  
prioritization field that is more extendable so that various sets of  
users could rely on different priority structures/values, but more  
importantly, different associated policies.  The one major headache  
is that if you go down this road, I think your draft will require  
some significant changes.

Janet mentioned RFC4412, whose structure is a string based BNF  
representation.  If you would prefer a strictly numeric  
representation for the NameSpace.Value tuple first mentioned in  
RFC4412, you should look at NSIS QSPEC draft (which I believe is  
under WG last call)
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-09.txt.  In  
either case, you can leverage previous work and choose to do so  
either in alphanumeric or strictly numeric form and not have to worry  
about specifying your own IANA registry.

One minor point involves Section 4.1  You mention using the ToS field  
as a means of supporting expedited transfer.  Its probably best to  
update that text with RFC-3168, which deprecates ToS (and precedence  
fields) in favor of the Differentiated Services field.

Also, I would disagree with your statement that your proposed field  
does not "raise any security issues not already endemic in electronic  
mail".  Currently, with FIFO based system we have a system where  
everyone experiences a form of best effort in obtaining MTA  
resources.  But with your proposed extension, one introduces a case  
where email labeled as low priority can be indefinitely starved of  
resources.  In some systems/domains, this may be desired.  In others,  
one may want a more weighted round robin servicing so that priorities  
correlate to the weights, but eventually, all message queues would be  
serviced.  Outside of that, it would seem desirable for your draft to  
at least advocate some measures of security like S/MIME for header  
protection (rfc-3851), and possibly the use of AUTH.

Finally, in section 6.5.3, you state some specific delivery time  
constraints.  I'm curious as to where you came up with those numbers  
-- it would probably be helpful to add some context.  Some deployed  
underlying HF and ULF systems would have a hard time meeting your  
constraints depending on message size.  My personal feeling is that  
it may be best to move text like that and 4.1 into an appendix

outside of that, its a nice document for discussion

-ken


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