Subject: [BEHAVE] Review: draft-ietf-behave-ftp64-00.txt

From: liu dapeng <[email-masked]>
Date: Thu, 31 Dec 2009 23:55:57 +0800

This is my review comments of draft-ietf-behave-ftp64-00.txt:

1.Introduction
The last sentence of 3rd paragraph from back: "Client that want to
engage more complex behavior, such as server-to-server transfer,may
take an FTP ALG go into transparent mode by issuing an AUTH command".
Shall we make this point more clearly by elaboration the reason, such
as: "...such as server-to-server transfer,may take an FTP ALG go into
transparent mode by issuing an AUTH command(see section 4.1 for using
AUTH to switch off the ALG function).

3. Client recommendations
"In that case, the cache entry should be cleared if older than 7 days
and the server indicates EPSV support in its FEAT response where it
previously did not indicate EPSV support in its
 FEAT response."
Should we make it more flexible by not specifying a fixed time of the
cache entry, such as: "...In that case, the cache entry should be
cleared if older than a period of time such as 7 days ...."

"...the server will respond to the PASV command with an IPv4 address
that the client must
   use to connect to for the data connection. "
little change of the wording: "...the server will respond to the PASV
command with an IPv4 address that the client is supposed to use to
connect to for the data connection. "

"The main rationale for ignoring the IPv4 address in the 227 response,
   even if the client has IPv4 connectivity, is the fact that most
   servers will only allow a data connection from the same client
   address as seen in the control channel connection, see
   <http://cr.yp.to/ftp/security.html>.  Using IPv6 for the control
   channel and IPv4 for the data channel means that the source address
   will almost certainly be different in both cases, making it unlikely
   that the data connection can be established successfully."

propose to add one short sentence in the end of the above paragraph:
"...making it unlikely that the data connection can be established
successfully. There are also other reasons that makes it inappropriate
to use the IPv4 address in the response message even if the client has
IPv4 connectivity, such as: the IPv4 connectivity may can not reach
the server due to configuration or other reasons."

"EPSV ALL" indicates that the client will use EPSV for all
   transfers, but an ALG may translate EPSV commands to PASV commands,
conflicting with the earlier "EPSV ALL".

Comments: Requiring client not using "EPSV ALL" at all maybe a not a
good approach considering that there are chances that the server
support EPSV ALL command and the communication between them may not
need an ALG.

4.  ALG functionality
Propose to add some sentences to clarity that there maybe a chance
that for optimized client and server which comply with this document
using ALG may lead to un-optimized result.

Appendix B.  Acknowledgements

Propose to move the  Acknowledgements section in to the main body of
the document and add a "contributors" section that lists all the
contributors of this document.

Best regards,
Dapeng Liu

---

From: liu dapeng <[email-masked]>
Date: Fri, 1 Jan 2010 00:15:35 +0800

> using ALG may lead to un-optimized result.

Proposed text for this clarification maybe:
"It is noted that there may be chances for the client and server which
comply with this document's recommendation may avoid using ALG but
since there is no ways for these client/server to inform the
translator to switch off ALG, it may lead to unoptimized situation
that the communications always go through an ALG even if it could be
avoided. "