IETF Logo Mail Archive

Re: [ftpext] Last Call: <draft-ietf-ftpext2-hosts-02.txt> (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard

Robert McMurray <robmcm@microsoft.com> Wed, 29 June 2011 02:20 UTC

Return-Path: <robmcm@microsoft.com>
X-Original-To: ftpext@ietfa.amsl.com
Delivered-To: ftpext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D599E8019; Tue, 28 Jun 2011 19:20:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.517
X-Spam-Level:
X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YR7dA7jFdrou; Tue, 28 Jun 2011 19:20:47 -0700 (PDT)
Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id EF1DA9E8004; Tue, 28 Jun 2011 19:20:46 -0700 (PDT)
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 28 Jun 2011 19:20:46 -0700
Received: from VA3EHSOBE005.bigfish.com (157.54.51.81) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.289.8; Tue, 28 Jun 2011 19:20:45 -0700
Received: from mail112-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.22; Wed, 29 Jun 2011 02:05:27 +0000
Received: from mail112-va3 (localhost.localdomain [127.0.0.1]) by mail112-va3-R.bigfish.com (Postfix) with ESMTP id 9C0811398121; Wed, 29 Jun 2011 02:05:27 +0000 (UTC)
X-SpamScore: -4
X-BigFish: PS-4(zz4015L103dKzz1202h1082kzzz31h793h2a8h668h839h34h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:157.55.61.146; KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT002.namprd03.prod.outlook.com; R:internal; EFV:INT
Received-SPF: softfail (mail112-va3: transitioning domain of microsoft.com does not designate 157.55.61.146 as permitted sender) client-ip=157.55.61.146; envelope-from=robmcm@microsoft.com; helo=CH1PRD0302HT002.namprd03.prod.outlook.com ; .outlook.com ;
Received: from mail112-va3 (localhost.localdomain [127.0.0.1]) by mail112-va3 (MessageSwitch) id 1309313111999234_13394; Wed, 29 Jun 2011 02:05:11 +0000 (UTC)
Received: from VA3EHSMHS004.bigfish.com (unknown [10.7.14.242]) by mail112-va3.bigfish.com (Postfix) with ESMTP id BB295580125; Wed, 29 Jun 2011 02:04:23 +0000 (UTC)
Received: from CH1PRD0302HT002.namprd03.prod.outlook.com (157.55.61.146) by VA3EHSMHS004.bigfish.com (10.7.99.14) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 29 Jun 2011 02:04:20 +0000
Received: from CH1PRD0302MB131.namprd03.prod.outlook.com ([169.254.11.234]) by CH1PRD0302HT002.namprd03.prod.outlook.com ([10.28.28.64]) with mapi id 14.01.0225.056; Wed, 29 Jun 2011 02:04:19 +0000
From: Robert McMurray <robmcm@microsoft.com>
To: Paul Ford-Hutchinson <paulfordh@uk.ibm.com>, "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: [ftpext] Last Call: <draft-ietf-ftpext2-hosts-02.txt> (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard
Thread-Index: AQHMNcZDcdEZfuFND0GouWGSZJApmpTTjkbg
Date: Wed, 29 Jun 2011 02:04:16 +0000
Message-ID: <01AA9EC92749BF4894AC2B3039EA4A2C194A07E2@CH1PRD0302MB131.namprd03.prod.outlook.com>
References: <20110616130503.4854.51928.idtracker@ietfa.amsl.com> <OFA9997572.88B3CCF9-ON802578BC.006F9F84-802578BC.00716B95@uk.ibm.com>
In-Reply-To: <OFA9997572.88B3CCF9-ON802578BC.006F9F84-802578BC.00716B95@uk.ibm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.28.29.114]
Content-Type: multipart/mixed; boundary="_004_01AA9EC92749BF4894AC2B3039EA4A2C194A07E2CH1PRD0302MB131_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: CH1PRD0302HT002.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%UK.IBM.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-OriginatorOrg: microsoft.com
X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com
Cc: "ftpext@ietf.org" <ftpext@ietf.org>
Subject: Re: [ftpext] Last Call: <draft-ietf-ftpext2-hosts-02.txt> (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 29 Jun 2011 02:20:50 -0000

Thanks, Paul.

I believe that I have addressed all of your comments with the following actions:

--------------------
Section 3:
--------------------

> Surely the first SHOULD has to be a MUST.
> Otherwise we have a situation where, upon
> receipt of a valid HOST, some server
> implementations will implicitly REIN and
> clear AUTH/USER/ACCT and some will not.

Agreed - I changed that verbiage.

--------------------
Section 3.2:
--------------------

> I suggest that either the "wrapper" concept is
> dropped from the document altogether...

I removed that verbiage. (That was detail for a possible server implementation anyway.)

--------------------
Section 3.2.2:
--------------------

> should be "to negotiate the security mechanism
> and relevant authentication token(s)"

I changed that as well.

--------------------
Section 4
--------------------

> The "strong method of encryption" is a bit
> vague. I don't think we can publish this
> paragraph without being more explicit about
> what this really means. 

I removed that paragraph. By way of explanation, this was in reference a server implementation detail that in hindsight probably shouldn't be in this document. More specifically, some FTP servers and clients support Implicit FTPS, but that is not defined by RFC and lately considered deprecated, so it's best to just remove that information.

> I repeat my initial point - this has to be a MUST.

Agreed - I changed that verbiage.

> I would like some mention of the linkage
> between the identity returned in an X.509
> certificate and the parameter to the HOST
> command at the protocol specification level.

I have attached a new version of the draft that contains suggested wording for this request, with all of the other changes that I have addressed as well.


Thanks!

Robert

v2.23.0 | Report a Bug | By Email