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

["Dan Wing" <[e-mail]>]

Thanks!
-d
 

> -----Original Message-----
> From: Anthony Bryan [mailto:[e-mail]] 
> Sent: Saturday, June 12, 2010 10:03 PM
> To: Dan Wing
> Cc: [e-mail]; [e-mail]; 
> Behave Chairs
> Subject: Re: [ftpext] BEHAVE WGLC of draft-ietf-behave-ftp64-03
> 
> On Sat, Jun 12, 2010 at 12:08 PM, Dan Wing <[e-mail]> wrote:
> > FTPEXT2,
> >
> > BEHAVE has working group last called 
> draft-ietf-behave-ftp64-03 and is
> > soliciting reviews of the document.  Please send reviews to 
> [e-mail] or
> > the authors at [e-mail].
> >
> > 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.
> 
> 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