[ftpext] Question about draft-bryan-ftp-hash-07

Robert McMurray <robmcm@microsoft.com> Fri, 20 August 2010 22:01 UTC

Return-Path: <robmcm@microsoft.com>
X-Original-To: ftpext@core3.amsl.com
Delivered-To: ftpext@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id DD56E3A6898 for <ftpext@core3.amsl.com>; Fri, 20 Aug 2010 15:01:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id XKzlGkLI61zC for <ftpext@core3.amsl.com>; Fri, 20 Aug 2010 15:01:00 -0700 (PDT)
Received: from smtp.microsoft.com (mail1.microsoft.com []) by core3.amsl.com (Postfix) with ESMTP id EB5453A67FB for <ftpext@ietf.org>; Fri, 20 Aug 2010 15:00:59 -0700 (PDT)
Received: from TK5EX14HUBC104.redmond.corp.microsoft.com ( by TK5-EXGWY-E801.partners.extranet.microsoft.com ( with Microsoft SMTP Server (TLS) id; Fri, 20 Aug 2010 15:01:34 -0700
Received: from TK5EX14MBXC127.redmond.corp.microsoft.com ([]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([]) with mapi id 14.01.0218.010; Fri, 20 Aug 2010 15:01:34 -0700
From: Robert McMurray <robmcm@microsoft.com>
To: "ftpext@ietf.org" <ftpext@ietf.org>
Thread-Topic: Question about draft-bryan-ftp-hash-07
Thread-Index: ActAsz/cDiAopKTASBWkx2ZFdKuoeA==
Date: Fri, 20 Aug 2010 22:01:32 +0000
Message-ID: <A5FC996C3C37DC4DA5076F1046B5674C3D2B58B3@TK5EX14MBXC127.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [ftpext] Question about draft-bryan-ftp-hash-07
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ftpext>
List-Post: <mailto:ftpext@ietf.org>
List-Help: <mailto:ftpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Aug 2010 22:01:01 -0000

It's been a few weeks since we've discussed the draft for the HASH command, which is logical given the discussions that followed IETF 78, but from an admittedly biased implementation point-of-view I'd like to see this draft continue to move forward towards publication.

With that in mind, I've been thinking through implementation scenarios in the wake of the denial-of-service discussion that took place before IETF 78. More specifically, I've thinking about a scenario where the maximum file size could be configured at the server, so HASH commands could be prevented from stealing too many server resources when larger files are involved. This is purely a server implementation detail that has nothing to do with the draft with the exception of considering which reply code to return.

Looking at section "3.4. HASH Command Errors" in the draft it would seem that none of the 5yz errors that are listed would apply, but returning a 504 reply might seem to make sense in this scenario. If so, would it be worthwhile to add a statement like the following to the draft?

   The server-PI SHOULD reply with a 504 reply if the HASH command is
   used on a file that cannot be processed for policy reasons. (For
   example, the file size exceeds the server's hashing policy.)

Or would a 4yz reply be better since this is a configurable option at the server? Perhaps a 452 reply?


Robert McMurray
US-IIS Product Unit
Email: robmcm@microsoft.com