Subject: [ftpext] BEHAVE WGLC of draft-ietf-behave-ftp64-03

From: "Dan Wing" <[email-masked]>
Date: Sat, 12 Jun 2010 09:08:40 -0700

FTPEXT2,

BEHAVE has working group last called draft-ietf-behave-ftp64-03 and is
soliciting reviews of the document.  Please send reviews to [email-masked] or
the authors at [email-masked].

Abstract:

   The File Transfer Protocol has a very long history, and despite the
   fact that today, other options exist to perform file transfers, FTP
   is still in common use.  As such, it is important that in the
   situation where some client computers are IPv6-only while many
   servers are still IPv4-only and IPv6-to-IPv4 translators are used to
   bridge that gap, FTP is made to work through these translators as
   best it can.

   FTP has an active and a passive mode, both as original commands that
   are IPv4-specific, and as extended, IP version agnostic commands.
   The only FTP mode that works without changes through an IPv6-to-IPv4
   translator is extended passive.  However, many existing FTP servers
   do not support this mode, and some clients do not ask for it.  This
   document describes server, client and middlebox (if any) behavior
   that minimizes this problem.

Thanks,
-d

---

From: Anthony Bryan <[email-masked]>
Date: Sun, 13 Jun 2010 01:02:30 -0400

>   that minimizes this problem.

Hi,

Some suggestions for readability.

The first time you use ALG, you want to be clear what it stands for.

OLD
Additionally, the document standardizes behavior for application layer
gateway functionality to provide connectivity between unupdated
servers and/or clients.

NEW
Additionally, the document standardizes behavior for application layer
gateway (ALG) functionality to provide connectivity between unupdated
servers and/or clients.

The following sentence sounds weird. Should "so in EPRT translation is
supported" be "so if EPRT translation is supported"?
OLD
However, in the case of EPRT translation, the ALG and translator
functions need to be tightly coupled, so in EPRT translation is
supported, it is assumed that the ALG and IPv6-to-IPv4 translation
functions are integrated within a single device.

OLD
If the client issues the AUTH command the client is attempting to
negotiate [RFC2228] security mechanisms which are likely to be
incompatible with the FTP ALG function.

NEW
If the client issues the AUTH command, then the client is attempting
to negotiate [RFC2228] security mechanisms which are likely to be
incompatible with the FTP ALG function.

OLD
"Note that if multiple clients are using the IPv6-to-IPv4 to..."

The IPv6-to-IPv4 what?

OLD
The main rationale for ignoring the IPv4 address in the 227 response,
even if the client has IPv4 connectivity, most servers will only allow
a data connection from the same client address as seen in the control
channel connection, see [Bernstein].

NEW?
The main rationale for ignoring the IPv4 address in the 227 response,
even if the client has IPv4 connectivity, is that most servers will
only allow a data connection from the same client address as seen in
the control channel connection. (See [Bernstein]).

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Jun 2010 14:05:57 -0700

Thanks!
-d

> -----Original Message-----
> From: Anthony Bryan [mailto:[email-masked]] 
> Sent: Saturday, June 12, 2010 10:03 PM
> To: Dan Wing
> Cc: [email-masked]; [email-masked]; 
> Behave Chairs
> Subject: Re: [ftpext] BEHAVE WGLC of draft-ietf-behave-ftp64-03
>